3 ms·

I always wondered why DOS extenders were separate .exes. It looks like you were supposed to be able to replace them, or start them in advance and share one with

I always wondered why DOS extenders were separate .exes. It looks like you were supposed to be able to replace them, or start them in advance and share one with multiple programs. But that wasn't the case, when you launch it you just got a message to launch the main executable. Why did they bother to make it a proper executable? Wouldn't it make more sense to give it a .sys or .dat extension and to just load it yourself (in DOS a matter of reading it into memory and jumping to that address). Or, since it is proprietary and often delivered with the compiler, just link it in statically? Random anecdote: as a kid, DOS/4GW stood for "DOS for great win(dows)" (which I know makes absolutely no sense).

TonyTrapp 4y ago
You can replace DOS extenders to a certain extent. DPMI is standardized, so if an application is directly developed against the DPMI interface, it doesn't matter which DPMI server is present. I remember that some programs would run without any additional executable on Windows 98 (which provides its own DPMI server) but would require CWSDPMI.EXE when run from DOS. I guess that other programs would directly communicate with DOS/4GW through a different interface and that's when you can't just replace it with a different extender, but there are other extenders that can fully replace DOS/4GW such as DOS/32.
nu11ptr 4y ago
You can replace them. I forget the details on how I did it, but I recall doing this for a popular first person star wars game at the time. I replaced the DPMI runtime with a different one and the level load times skyrocketed in speed. My suspicion at the time was that the runtime included switched to real mode to do disk transfers but the other perhaps talked directly to the IDE hard disk staying in protected mode? Not sure, but it was very, very fast with I/O. I was pretty happy with my hack at the time.
- leeter 4y ago
  My suspicion is you're right. Mostly based on Raymond's blog on the role of DOS in Windows 95[1]. Where people using weird drivers and other things that got in the way of 32bit disk access could massively slow down the system. It's plausible that one extender was being "nice" and using your native drivers or at least trying to be compatible whereas another just went "Nah that crap is slow" and just went for it with a native direct driver and was thus massively faster. [1] https://devblogs.microsoft.com/oldnewthing/20071224-00/?p=24063 https://devblogs.microsoft.com/oldnewthing/20071224-00/?p=24...

TonyTrapp 4y ago

You can replace DOS extenders to a certain extent. DPMI is standardized, so if an application is directly developed against the DPMI interface, it doesn't matter which DPMI server is present. I remember that some programs would run without any additional executable on Windows 98 (which provides its own DPMI server) but would require CWSDPMI.EXE when run from DOS. I guess that other programs would directly communicate with DOS/4GW through a different interface and that's when you can't just replace it with a different extender, but there are other extenders that can fully replace DOS/4GW such as DOS/32.

nu11ptr 4y ago

You can replace them. I forget the details on how I did it, but I recall doing this for a popular first person star wars game at the time. I replaced the DPMI runtime with a different one and the level load times skyrocketed in speed. My suspicion at the time was that the runtime included switched to real mode to do disk transfers but the other perhaps talked directly to the IDE hard disk staying in protected mode? Not sure, but it was very, very fast with I/O. I was pretty happy with my hack at the time.

leeter 4y ago
My suspicion is you're right. Mostly based on Raymond's blog on the role of DOS in Windows 95[1]. Where people using weird drivers and other things that got in the way of 32bit disk access could massively slow down the system. It's plausible that one extender was being "nice" and using your native drivers or at least trying to be compatible whereas another just went "Nah that crap is slow" and just went for it with a native direct driver and was thus massively faster. [1] https://devblogs.microsoft.com/oldnewthing/20071224-00/?p=24063 https://devblogs.microsoft.com/oldnewthing/20071224-00/?p=24...