CALL command does not work if script is executed from Windows \ VOGONS

CALL command does not work if script is executed from Windows

Topic actions

First post, by crystal

Posted on 2025-05-17, 08:50

crystal Offline

Rank Newbie

Rank: Newbie
Posts: 4
Joined: 2025-05-17, 08:35

I have installed Windows 3.11 inside Dosbox v0.74-3 to get some old games working, and I was trying to write some batch scripts to automate swapping CDs and launching games. I encountered an issue when I tried calling a common batch script where any further commands inside the calling script will be ignored. The CALL command is supposed to allow the calling script to continue executing, and it does when I run the command from the DOS prompt, but when I execute the script from Windows by creating a shortcut to it in Program Manager and opening it, it behaves exactly the same way as it does without the CALL command.

I found this thread from 2013 which I am pretty sure is discussing the same issue, though it's talking about Norton Commander and not Windows. There is a patch on that thread, so I guess I'm kinda curious as to why this hasn't been upstreamed if it fixes things in Windows.

Reply 1 of 3, by doshea

Posted on 2025-05-24, 08:01

doshea Offline

Rank Member

Rank: Member
Posts: 489
Joined: 2009-05-22, 09:37
Location: Australia

crystal wrote on 2025-05-17, 08:50:

There is a patch on that thread, so I guess I'm kinda curious as to why this hasn't been upstreamed if it fixes things in Windows.

That thread was actually discussing roughly the same version of DOSBox as you're using - in the last 12 years, it's just had a few hotfixes for critical issues, but not much else. There's probably a thread somewhere in one of the DOSBox-specific forums on this site explaining why there haven't been any significant updates for some time. You might find that one or more of the more actively maintained forks of DOSBox includes the fix. I'm afraid I don't use any of the forks so I can't recommend one, but if you look around some of the forums you might get some idea of which ones people prefer.

Reply 2 of 3, by jmarsh

Posted on 2025-05-24, 09:03

jmarsh Offline

Rank Oldbie

Rank: Oldbie
Posts: 1694
Joined: 2014-01-04, 09:17

Ripsaw committed that fix 10 years ago, just use any build that isn't ancient.

Reply 3 of 3, by crystal

Posted on 2025-06-08, 18:59

crystal Offline

Rank Newbie

Rank: Newbie
Posts: 4
Joined: 2025-05-17, 08:35

doshea wrote on 2025-05-24, 08:01:

crystal wrote on 2025-05-17, 08:50:

There is a patch on that thread, so I guess I'm kinda curious as to why this hasn't been upstreamed if it fixes things in Windows.

That thread was actually discussing roughly the same version of DOSBox as you're using - in the last 12 years, it's just had a few hotfixes for critical issues, but not much else. There's probably a thread somewhere in one of the DOSBox-specific forums on this site explaining why there haven't been any significant updates for some time. You might find that one or more of the more actively maintained forks of DOSBox includes the fix. I'm afraid I don't use any of the forks so I can't recommend one, but if you look around some of the forums you might get some idea of which ones people prefer.

I see, I didn't realize the version I was using was so outdated since it was the latest released version from my distribution's repositories. I'll try again with one of those forks compiled from source. Thank you.

Go to top of page Go to top of page

Back to DOSBox General