Ok, bat file woes. Heres the question:

If I for instance want a bat file to run ant clean followed by ant jar I write a bat file as such:

ant clean
ant jar

Upon running I would expect both to be run one after the other, like any other sane scripting environment. This is not the case here though, only the first line is run. You actually have to prepend them with call!

call ant clean
call ant jar

Without call execution seems to be lost from the bat file and never return.

Now, I do not know precisely why this is, but I have an inkling.

If I use start then an new cmd.exe is opened and the commands are tun in that, this is unideal you would lose your environment variables.

If I don’t use call then I assume that ant doesn’t return in a way that bat files expect even though the process finishes so the bat file just stops because, why not.

Using call seems to make your bat file wait and carry on regardless of return value, and also maintain environment.

Basically I think this might be something to do with the poor quality implementation of processes and threads in nt as opposed to unix.

It feels like nt doesn’t have the tools to really cope with launching processes non concurrently.

Now, I do not know this to be true, it’s just suspicion. But it feels right.

Follow

Ok so execution of a bat file exits immediately if you run another bat file from within it.

Call appears to have been introduced, in dos 3, so that you can EXIT /B from a bat file and have execution pass back to the original running script.

I can’t see much about why this odd choice was made about the running of bat files though.

It seems like a choice that was accepted due to system limitations rather than an actual design choice.

It really feels like win preferring threads over multiprocessing led them down a path where execution had to stop if another bat file was run because there was no concept of passing control back.

The inclusion of the call command feels like a hack added in to navigate around what seems to be a poor architecture leading to less than optimal design choices.

@jameschip batch file processing semantics have little to do with processes vs threads, only with the batch processor. You don't necessarily want to keep state around that usually isn't needed when running on 32K of RAM, and from there it was compatibility that dragged things down.

@jameschip in early programming systems there was no such thing as a return stack, and variables tended to all be globals. So the idea of invoking a routine and then returning to continue simply wasn't possible.

Early DOS was behind the game in terms of implementing the latest ideas because of time and commercial pressures, so I'm not at all surprised by this.

I remember programming extensively in DOS and developing ways to circumvent the limitations.

@RiderOfGiraffes yeah, I get that. I can’t believe that a return stack was not available before dos was though, surely.

Either way, it’s not surprising that an old machine would behave like this at all. It is however surprising that this behaviour persists in the system still.

@jameschip You can trace the lineage of NT a long way back. Return stacks did existe before DOS, but implementing them still required reasonably up-to-date understanding, and the original implementors of DOS were direct practitioners, not necessarily strong an *any* of the theory.

Remember, Fortran didn't have recursive routines for a very, very long time, and it's a similar limitation.

CC: @RiderOfGiraffes

Sign in to participate in the conversation
Merveilles

Merveilles is a community project aimed at the establishment of new ways of speaking, seeing and organizing information — A culture that seeks augmentation through the arts of engineering and design. A warm welcome to any like-minded people who feel these ideals resonate with them.