While I’m waiting for my real PC-9821 to arrive, I’ve been playing with various software. Â One fun thing was the old DJGPP, as the version 1.x had a customized version of go32 to support the PC-98 hardware. Â This is cool, but I’d love to perhaps start down the road of porting something to the PC-98. Â There is no VGA adapter, and the I/O is mapped differently so naturally this is why they are only loosely compatible. Â So while I was looking for any kind of source code using DJGPP, I found the FCE: Family Computer Emulator (NES). Â It includes source code, which is great but it builds against DJGPP 2.x What makes it more interesting is that it has DPMI hooks in place, unlike the old DJGPP 1.x’s DOS extender which is DPMI incompatible. Â So how do you magically get a DPMI environment for MS-DOS? Â Well one way is to run it under Windows 3.0 or higher. Â And certainly with MS-DOS 3.30 that is an option. Â However lurking in the disk images of MS-DOS 5.00A was a fun program DPMI.EXE . Â Well now that is interesting!
Using a generic config.sys I have 600kb of low RAM available, and 7MB of extended RAM.
Now the real interesting part is DPMI.INI
As you can see this is pretty much the 386 enhanced portion of Windows 3.0! Â So you get all of the DPMI services offered by Windows as part of the OS.
As you can see, with DPMI running I have access to EMS, and XMS memory now available. Â Additionally with paging you can even over commit memory.
My only question, is why was DPMI not an added in feature of the English versions of MS-DOS? Â Granted there was a LOT of OEM bundling with new machines so you were forced to purchase a copy of Windows along with MS-DOS on all new computers, regardless of what you were going to do with them, and this would have been a bit more interesting.
This kind of environment was extensively documented in the “Unauthorized Windows 95“, byÂ Andrew Schulman that showed how DOSX.EXE could chain load Win386 + command.com achieving the same thing. Â The DPMI environment from MS-DOS 5.00A is dated 11/11/1992, I wonder if he knew about this going into the Windows 95 book. Â It’s been too long since I’ve read it to remember, but I don’t recall any details about Japanese PC-98 releases of MS-DOS. Â There was also a ‘MSDPMI’ environment created for the beta versions of Microsoft C 7.0, but I’ve been unable to find one to verify. Â MSC 7.0 was released in 1992, so it fits in the same timeframe, but the shipping products used QEMM’s DPMI server instead.
Oh my god! You finally found the legendary MSDPMI executable! (Japanese version, but whatever).
Also, DOSX can’t chainload WIN386.exe, that’s Win.com. Win.com can start both environments, Win386.exe without switches, or DOSX with /S switch. And yeah, you can force a sort of 32bit managed DOS prompt if you replace KRNL386.exe in System directory by Command.com.
About why they didn’t include it in western DOS editions… Well, probably because this environment was enough powerful to delay Windows adoption a few years more, and MS didn’t wanted that. Remember in these times Windows apps were still less advanced that their DOS counterparts and the only reason for many people to use windows was mostly a glorified task switcher, a way to run many dos apps at same time. Accessing VMM API inside MSDPMI would allow people to create fast and powerful text mode taskswitchers without the need to load the whole windows, being able to run many DOS sessions for apps in a protected 32bit environment, and what is more, being able to use the same VXDs as Windows to drive hardware and emulate stuff for these DOS sessions. And ofc, MS feared about it, and killed the project, unnecessary for their goal, which was put MS Windows in every PC, displacing DOS in the process and killing it.
I haven’t tried to run it on a normal PC yet. Since it’s 1991 release it literally sits between Windows 3.0 and Windows 3.1.
To me at the time, I really couldn’t see the ‘advantage’ of MSDPMI say verses WAT4G/W, TNT. I would suppose the real advantage would be on vintage hardware with 32bit disk drivers, better caching. A task switcher would have been cool, but perhaps too much like OS/2 1.0?
I think the larger issue was the lack of DPMI extenders for PC-98 hardware, and MS saw that by gutting a copy of Windows, and providing that DPMI with the OS, it would make the eventual process of making everything run under Windows all the easier. With the release of Windows 95, the PC-98 standard basically was over.
Not QEMM, I think it was 386Max.
This is correct.
Well, for PC-98 emulation, you should really try Neko Project 21/W, a fork by simk that is able to run up to Windows 2000 as a guest (NT 3.5, 3.51 and 4.0 run too).
If only they allowed raw disk access so I could put something onto my PC-9821..