On Mon, 2009-08-31 at 17:48 +1000, Jake Anderson wrote: > On 31/08/09 14:16, grove@xxxxxxxxxxx wrote: > > Is not a shell defined by this exact ability (ie fork())? > The "dos" shell didn't really have that ability, (it was kinda hacked on > with TSR's and the like but still) Actually, it did. Sort of. DOS supports child processes — but obviously, as it is not a multitasking OS, the application will block until the child process has quit. According to the 1988 MS-DOS 4.0 Programmer's Reference that's been sitting on my desk for the last two weeks, the function ‘Load and Execute Program’ (function 4BH, code 00H) is used for this exact purpose. That function is pretty self-explanatory — it loads the executable code of the child process into memory, and appends an instruction to the end of the child which makes it jump back to precisely where it left off in the parent process when it terminates. Command.com is not a TSR (‘Terminate But Stay Resident’, interrupt 4BH) AFAIK. Possibly what you're thinking of is its transient architecture, which if you're an old school gamer, there's only a slim chance you won't have encountered. You know the drill — boot DOS off a floppy, load some high-memory game off a second floppy, and when the game quits, it complains that it can't load command.com to load parts back into memory, and wants to be fed your DOS disk again. Command.com is made up of three main parts, a resident part, and initialisation and transient parts, the of which the latter two get overwritten if your app has high memory requirements (I've not yet looked into exactly how to trigger that). So command.com nags you to load itself back when the app quits if it can't find itself. Command.com actually did a fair whack more than your average Unix shell (in relative terms — /bin/bash is 897K on my box right now; way larger than your typical bare-bones DOS setup), but wasn't quite as exotic as you think. Those were the days...
Description: This is a digitally signed message part