• Please review our updated Terms and Rules here
  • Exhibitor application for VCF West 2022 is now open! If you are interested in exhibiting, please fill out the form here.

HX DOS Extender Fun


Veteran Member
Feb 25, 2005
Sparks, NV
Okay, now for something I've been brewing on for almost 2 years now.......experiments in HX DOS Extender.

So what is HX DOS Extender? It's a special Protected Mode Interface that a guy named...I think Japeth (who unfortunately passed away awhile back) created to allow you to run win32 console apps in pure DOS. Apparently now it's on SourceForge and has newer versions - which is what I'm using now as it comes with some of the needed libraries (DLLs mostly) to run these apps under DOS, including some graphical (single window) apps. However, I decided to write this up here, because I don't see a good document of this for the layperson anywhere....and I can see how intimidating and over-one's-head this could be.

It seems a common use for this is on a modern computer to run DOSbox from within DOS to get around the limitations of modern non-SB Compatible soundcards with no FM synth on board. Also, in my digging, it seems people are able to get several Windows games working under DOS this way - something I'd definatley love. Also, it seems some of the new modernized engines run on this, such as Scummvm. Which made that big ole' lightbulb go off in my head that hey - maybe I could run Exult on this and get around the problem of Ultima VII/Serpent's Isle not working in FreeDOS - because I truly want to go 100% open source, cleanly, and squarely.

So - the test subject is my NEC Versa M/75 - a 1994 Active Matrix 800x600 with touch 486DX4 notebook that I've been hammering on hardcore since 2020. This one is my favorite laptop in the collection, and it's a monster. But it has 2 shortcomings, my quest to go full open source lead me to put FreeDOS on it - causing certain software not to work because memory managers on FreeDOS 2.1 are Jemmx, EMM386, and Himemx, and they tend to not always be the most agreeable with older software - and it has a Windows Sound System chip (Crystal CS-4231-KQ) with no OPL on it - but when I it works, it sounds bloody amazing for a 30 year old laptop.

I installed HX's binaries and ini file all to my c:\fdos\bin folder - so I don't need an extra path or environment variables - for it to work. I went into this fully understanding that this was primarily designed for CONSOLE APPS and not intended for graphics, but some graphical stuff works on it. I also feel the somewhat "techie" presentation on other sites probably put's people off this utility that has such great potential in retro-computing. The new version comes with proper approximations of various Dynamic Link Libraries (DLLs) and other subsystem components to allow it to work properly with HX. Earlier I was nabbing chunks off Windows 95 on my dX4 desktop - then trying likely 10 x86/8 x86/7 x86/XP x86 resources that caused more problems than they solved. See, I'm dedicated at this point to get free of M$ as much as possible now, and move mostly to FreeDOS and Linux at home. One way that helps that, is no longer needing Windows For Workgroups 3.11 or Windows 95 to run old games - instead I can just run it on original "iron" using open source FreeDOS.

The INI file is HXGUIHLP.INI - and it contains all of the settings for HX's GUI helper - which is what allows HX to run GUI based (Single Window Only) apps. While it's implementation is only partial according to the readme's it seems they are fleshing it out pretty good. It DOES require UniVBE so you will want a VESA compliant SVGA card in whatever machine you use. In my case the M/75 has a pretty strong 1MB of VRAM equipped C&T 65545 LCD controller and graphics chipset - and it's pretty happy running UniVBE 6.5 - which I already have - and it's maxxed out on RAM and Hard Disk space (40MB/80GB).

I setup the resource file for 800x600 at 8bpp color mode 0x103, and it works, I also did that with 640x480 at 8bpp color mode 0x101. I also removed the "1" from the save= line as that was causing the LCD to go "milky white" on most programs (it still does in Scummvm).

So how does one run win32 apps this way? Well, it uses a dpmi program called dpmild32 for standalone loading, I chose this over the HXDPMI32 (or whatever it is) because I want to run these programs almost like they are native to DOS - and I'm plotting to do this by using a batch-file that loads univbe and then the dpmi with the PEstub EXE (unaltered - though you can remove the pestub by using pestub filename.exe to scrub the stub from it allowing DOS to attempt to run it without the whole "This program requires Microsoft Windows" or "This Program cannot be run in DOS mode" error.

As for the programs....

Civilization II - This one does not work yet, not sure what's stopping it, could be audio, could be something else, need to setup a log. I'm trying this because it's there.

Exult - The idea of running this stems from the fact t hat Ultima VII/Serpent's Isle does not run under FreeDOS and neither does u7dpmi.com or u7run.com (they both crash out due to the hot-rodded memory managers FreeDOS comes with), as well as another idea I'll mention later.

Scummvm - Yet another one having to do with my sound idea. It seems this one actually works. But it milks up the screen so we could have a problem with visual compatibility with this one, it might be demanding 16-bit color or higher to work.

Post Apocalyptic Petra - goes dual screen like my versa is trying for a job with a VR Headset, but with a "nuclear puke" color pallet.

Quake (Qlaunch.exe) - similar to Civ 2

Postal - out of the lot, ,this seems to be the most likely game to s tart working. It launches, does not milk up the screen, but it does not run because it cannot find an audio subsystem....which has me thinking, there might be a way to get all this working if there is a way to get a rudimentary driver subsystem from Windows working in FreeDOS - which also would allow for an added benefit - Windows Sound System soundblaster emulation in pure DOS.

See, one of my only gripes about the M/75 is that blasted Crystal Semiconductor CS-4231-KQ chipset. It's a WSS Audio Codec chipset that's only about 75% compatible with the AD1848 of the original wSS cards, and it lacks a OPL, probably because it's marketed as "business audio" and nobody wants to hear something that sounds like their kid's game of Monkey Island as a serious business meeting. BUT - when you can get that chipset to work in DOS, it sounds incredible.

So some theories I've got is this.....

- We could get soundblaster emulation working via HX. The WSS used to do this through Windows by using the virtual x86 mode of EMM386.EXE to capture the "hooks" for the resources for the virtual SoundBlaster, at the settings set by WSSXLAT.EXE (sbio220 irq5 dma1 usually). Windows 95 and higher had this functionality already baked in for these cards with the Microsoft driver set. Also, I read somewhere that WSS still lives on as a part of the Windows sound subsystem....so...

- If we could get the WSS portion going this way, we MIGHT be able to virtualize the OPL. IE, using Timidity or some other "virtual FM Synth" solution....which could be a fun experimeent. Which means no more looking for PCMCIA sound cards (though I still want three for my old Versas but still), and being able to pick higher quality emulations such as MPU-401. SoftMPU perhaps? We'll see.

- Having SoundBlaster emulation would fix something else I've been struggling with due to FreeDOS/Windows 95 memory managers, PCMCIA stuff, and the goofiness of this chipset - Sound Setup not working for DOS games that support WSS. The 7th Guest, AD COP, and some others all puke out to the DOS prompt when auto-detecting the sound hardware. T7G won't work, Tyrian locks up randomly ranging from before setup even starts to gettiing into the game and then it hangs/locks up, and there's a gaggle of stuff I could have PCM on with SoundBlaster emulation that does not have WSS drivers of some kind.

There's also a dpmi for Win16 apps on there that I still have yet to get working. Using it like dpmild32 still brings up a "This Program Requires Microsoft Windows" message when I try using it like that (dpmild16). So I may have to dig around more. Too bad there's no NEstub utility so I could clear the NE Stub and maybe they would run. It does however, come with a DOSX.EXE file to replace the one that comes with regular 3.1....so that might be a viable solution.