But the OS/c-lib might cache it, and only make changes visible after flush or something.

tricky_trev wrote:

The only problem i see now is passing parameters (%2 %3 etc...) in call statements with "=" characters...

behaviour is different in real dos to DOSBox.... i suppose this is another thread 😀

seems to be a DOS peculiarity:

if %2 is /L= and %3 is 5, /L=5 can be called with %3. wierd but i got around the problem.....

if %2 is /L= and %3 is 5, /L=5 can be called with %3

Er what? If you have the parameter /L=5 the %2 gives /L= and the %3 /L=5???
What dos version is that?

dos version was XP SP2 dos...

That's not a msdos compatible dos, parameter parsing under the xp shell
is quite different from the real thing, but well.

Just in case anyone is still not convinced, I know for sure that in DOS (5/6) days, batch files were parsed directly from disk, with a byte counter. If you modified the file and modified lines above the current position, it was easy to mess up everything by changing line length. Parsing would continue from mid-line or wherever the byte position happened to be afterwards. Having done much batch programming, I learned this the hard way 😉

i rember that problem exactly in the dos 5/6 days too!
oh those were the days....

it is really true that the xp dos is not a real dos shell, which probably results in the peculiarities i exposed.

anyway, now to the next problem (in another thread)... mouse cursors in text mode (blinks too slow).

The command prompt in NT OSes initially is a Win32 application which does the parsing. If you start a 16-bit-program ntvdm comes up and takes over the window.