Hi Mateusz, >>> You don't need to load the entire binary a second time, just a copy of >>> the environment data and possibly internal stateful variables. FreeCOM >> >> I guess, the(ir) excuse is, that MS-DOS works the same way. ;-) > > It does not. MS-DOS command.com allocates a little memory segment and > keeps there all its runtime data, while the memory used by the binary > itself is marked as "free" so it can be used by whatever program is > being executed. Then, once the program quits, a stub of COMMAND.COM > checks if its binary is still intact in memory: if yes, then it uses it > as-is, otherwise it is reloaded from %COMSPEC%. > > When loading several instances of COMMAND.COM in MS-DOS, each one takes > only 3K of memory (size of the stub + runtime data) because the > transient part is loaded only for the current instance on demand. That's > roughly 25x less than what FreeCOM does.
Thanks for explaining. :-) >>> Possibly. But I am not sure it will work, since you have to call a DOS >>> call (several of them, actually: two writes + one redir check) from >>> within a DOS call handler. Lack of reentrency might be a problem, but I >>> don't know for sure, didn't look it up in detail. >> >> Sure, I would have to test stability first. > > http://www.techhelpmanual.com/365-indos_flag.html > > According to this, only character I/O functions are safe, while you need > the write-to-handle and redir functions, both part of the unsafe zone. I remember, but never used it (until, maybe, now). Cheers, Robert -- +++ BTTR Software +++ Home page: https://www.bttr-software.de/ DOS ain't dead: https://www.bttr-software.de/forum/ _______________________________________________ Svardos-users mailing list Svardos-users@lists.osdn.me https://lists.osdn.me/mailman/listinfo/svardos-users
