Quoting Heimo Claasen <[EMAIL PROTECTED]>: > Isn't it so that the Win$-"DOSbox" is just some _arbitrary_ RAM/mem area > designated for that purpose at that moment ?
Yes indeed; my comments on the manner in which COMMAND.COM gets trampled by apps was intended more as an aside to show that the observation that Win9x overwrites it in RAM was probably correct. It also shows that what remains in RAM while Win9x is running is the barest minimum of COMMAND.COM You are quite correct in that every DOS box in Windows has its own associated block of RAM; they aren't quite full virtual machines, but rather protected memory spaces for each session. This is handled by the monolithic virtual memory manager, VMM32.VXD, which you can see in the MEM /C output. Each DOS box can see the memory used by the modules loaded before Windows -- for instance, IO.SYS, HIMEM.SYS, KEYB, and even WIN.COM. This is presumably protected so that apps can't trash that shared space. Your comment on memory mapping mirrors one I was going to make in my previous post, but decided against on the grounds that it was based on other operating systems and so could be more advanced than the scheme employed in Win9x. Under Linux, and possibly WinNT/2k/XP/2003, second and subsequent copies of identical processes don't have to be loaded off disk into RAM/swap. Instead, any initialised data (static variables in C, for instance) is loaded into some newly allocated memory, a new stack is created, and then the existing copy of the program in memory is mapped to the new process space in a mode called Copy- On-Write. What this means is that the same physical copy of the program appears in two virtual memory locations, and if the second copy writes to the it gets its own copy of only those bits of the program that have changed. If Win9x employs this scheme, then only one copy of COMMAND.COM needs to be loaded inside Windows, in addition to the stub left outside. If Win9x can't do this (I suspect it can, DLLs are often handled in this way too), then you get a new copy for each DOS box that has a shell in it. However, also bear in mind that you can start a DOS app -- EDIT or MEM /C /P, say -- without starting COMMAND.COM. Just double click on the executable or do Start->Run->MEM /C /P to see that COMMAND.COM isn't loaded in this case. -- Regards, Ben A L Jemmett. (http://web.ukonline.co.uk/ben.jemmett/, http://www.deltasoft.com/) ---------------------------------------------- This mail sent through http://www.ukonline.net
