Recent Changes - Search:

Recently Written


edit SideBar

HX (formerly known as HX-DOS Extender)

1.  About

HX (DOS Extender) is a DOS extender product, thus belongs to the same category as for example DOS/4GW, PMODE-xx, Causeway, DJGPP/CWSDPMI/GO32, DOS/32A, WDosX, and some others. However it can be used in several different ways (see next paragraph) and has several important benefits over those, the probably most spectacular one, making it quite unique, is that it also allows to run Win-32-PE-executables, programs designed for “Windows” (only 32-bit versions, 95 … XP) in DOS. It does not make all programs working, and probably will not do so soon, but a considerable amount of useful programs is already supported, see HX-DOS-lists? for complete list. Console apps (“file to file”, compressors, compilers, converters, …) are mostly supported, amount of working GUI apps is very limited, including mostly full-screen demos, emulators & games.

2.  One more needed ?

HX actually is not the first DOS extender product going this way, there used to be some versions of PharLap DOS extender also doing so, commercial, active around 1993, used for example with MASM 6.xx, now highly obsolete and unavailable as well, and WDosX , active from 1995 to 2002, newer and better, now free and open source, allowing to include all (DPMI kernel, even the DLL’s) into the main executable, but those achieved only sort of “Hello World plus” support, are now far behind HX and no longer under development. Only HX provides a GUI support, multithreading and compatibility with new compilers, and supports some new (2000/XP-specific) API calls.

3.  Usage

The HX project is quite large and can be used in several ways.

  • Users:
    • Use only HDPMI32 as DPMI host, replacement for CWSDPMI or bypassing the (bad) built-in DPMI of various other extenders
    • Use HDPMI16 with old 16-bit DPMI stuff (can reduce trouble)
    • Use “full” HX to run “Windows” software in DOS
  • Developers:
    • Develop dual-mode (DOS/Win32) applications, based on Win32 API
    • Develop DOS applications, statically linking-in the Win32 emulation. This bloats the executable size, however, tests have shown that for “serious” applications the overhead of this can be even smaller than the overhead of DGJPP ! Suitable for console applications, rather than for GUI ones.
    • Develop very “native” DOS applications, without involving any Win32 API, but using PE file format. This way also standalone DOS executables are possible, supported compilers are DJGPP (2.03 only (?), experimental), CC386 (seems to work well), and WATCOM (1.8, soon ?) by now. The new PE file loader with built-in HDPMI32 is called LOADPEX .
    • See Development .

4.  Packages

There are 4 packages available for download:

4.1 HXRT

Files needed to run Win32-PE console apps in DOS: HDPMI (DPMI kernel), API emulation DLL’s, loader & some other files, cca 15 files of total size cca 200 KB + docs + test files


Needed additionally for Win32-PE GUI apps (limited), additional DLL’s, cca 15 files of total size cca 512 KB + docs + test files


Only for the “original” DOS extender purpose: development of 32-bit DOS apps, contains Includes, Libraries, Examples, Utils, … Supports almost any compiler, incl. Visual-C++ . Disadvantage: Standalone EXEcutables can’t be created.


The source code of HX-DOS Extender, almost completely released (HDPMI, emulation DLL’s, PESTUB, VESAMTRR, …), original code written by Japheth completely in assembler (MA$M, note that project started cca 15 years ago, there was no other/better/usable assembler at that time :-( ), cca 600 files having totally cca 3 MB (!) in size, lacking only WSOCK32.DLL and most of the small test progs. WSOCK32.DLL is written in C and contains 3rd party code, and is closed source for this reason, and also quite big (cca 1/2 MB, complete asm source would be 5 MB at least  :-D  )

5. ”DOS program does not work in DOS - What’s wrong ?”

It is common for many people to run “DOS” programs inside “Windows” using a so called “DOS Box”. Everything works fine. But when you try to run such a program in DOS, you get an ugly message “This program cannot be run in DOS mode”. What’s wrong ? Well, the affected programm is NOT a DOS one. It is a Windows 32-bit console, also called WinNT-console program. “DOS” is NOT a synonyme of “console”, and “Windows” is NOT a synonyme of “GUI”. Both DOS and Windows programs can be console or GUI.  ;-)  Now, why such Windows console programs don’t work in DOS ? They are NOT “crippled” to do so (“Test for Windows and if not found do not run”), they are written and compiled in a way significantly differring from 16-bit, but also partially from 32-bit DOS ones. The differences are:

  • DOS programs are either 16-bit real mode executables (MZ-EXE) or 32-bit DPMI (rare and obsolete: also 16-bit DPMI) programs, using appropriate DOS extenders, having special executable formats (mostly COFF or LE) and some tricky loading code. Win-32-PE programs are always 32-bit PE-executables (obsolete Win 3.xx used 16-bit NE-executables), and do not contain any “extender” or loading code.
  • DOS programs use DOS and BIOS INT’s for I/O accesses, and can also access the hardware. Win32-PE programs use the “API” and do not and may not directly use INT’s, access DOS, BIOS or even the hardware (in Win95/98 era, some INT’s (most notably INT $13) were used since accessible via some hacks, but still not directly).
  • The memory management of Windows differs significantly from the 16-bit real mode, and slightly also from most DOS extenders, most important: Win32 uses paging and offers a private address space to every application, while DPMI 0.9 and most of DPMI hosts and DOS extenders provide one space only. Also, Windows supports DLL’s, while DOS and most of the “ordinary” extenders don’t.
  • Win-32-PE programs can use multithreading (multiple threads running at “same” time on one CPU (additional CPU’s came much later) ), while neither DOS kernel nor any of the “ordinary” DOS extenders do support this. Some compilers and related extenders, however, do offer ways to “fake” it, with more or less usable results (ported (recompiled without generous rewriting) multithread code works).

HX-DOS Extender now bypasses all these problems:

  • Provides a 32-bit DOS extender functionality (like many others)
  • Provides a memory management compatible with 32-bit “Windows” and supports PE-executables and DLL’s (unlike most others)
  • Emulates the API (translates API calls to DOS and BIOS INT’s) (unlike most others)
  • Supports multithreading (unlike any other “ordinary” extender)

As result of all this, most of such “DOS” programs (+ some Windows GUI ones) now do work in DOS. ;-)

6.  Implemented functionality and limitations

HX-DOS Extender can be used to run Win32 software in DOS. Therefore, it provides some of the functionality of Win32 kernel and other components. See also previous (“DOS program does not work in DOS”) and “Known problems” sections.

  • 32-bit PM code support, DOS extender (some similarity with Win9x/ME), paging, multiple address spaces (optional, need HDPMI=32 hack)
  • “PE”-executables loading and execution, incl. DLL’s. Because of incomplete loader implementation (“strings in the header” ?) and some other detail problems of HX, a small minority of executables won’t load, see also “Known problems”
  • Filesystem API: YES, the “old” Win95-like API is emulated since cca HX 1.20, since cca HX 2.12 also the “new, extended” 2K/XP-like API (for ex. “GetFileSizeEx”) is emulated, however, file size is still limited to 2 GB (while the original API allows up to 2^63 bytes !!!), in future, using FAT+, files up to 256 GB could be supported. For files up to 2 GB, HX is, unlike Win ME/98, ready for new “XP-only” console packers/converters relying on the new “Ex” API ;-)
  • Console API: mostly implemented
  • GUI API: very limited (features are missing or dummy only). The control elements and menus are dummy only, just “MessageBoxA” is supported as working, but icons lacking, correct buttons do appear but no click on them - press appropriate key instead. The “low-level” graphics API works better (GDI, OGL, SDL, DDRAW, DIRECTX), but is still incomplete so that there can be missing imports or screen may look badly (lack of transparency for example). GDI supports plotting, line drawing and text output, OTOH there is only one font (?), and text scaling has no effect. Also, all this is emulated through VESA, so it is slower than in original Win systems. Nevertheless, the performance is sufficient for many games and QEMU/BOCHS on cca >=500 MHz machines.
  • Clipboard is implemented (needs HX 2.10 or newer, previous versions do have a bug), but inside one application only (text editor for example), content vanishes when application terminates
  • Mouse support: implemented, works well for console (!!!) apps and emulators (QEMU and BOCHS), no wheel support yet (coming soon ?), clicking API buttons does not work, “mouse bugs” fixed since HX 2.14
  • Sound API: to some degree, but see “Known problems” below
  • Multithreading: implemented, works well (one CPU only, HX 2.10 or newer preferable, older version do have a thread/stack related bug, 7-ZIP, however, works down to HX version cca 1.20)
  • Multitasking: NO. Only one “Windows” app at same time ;-)
  • The “core” feature of “Windows”: the rectangular boxes placing themselves on the screen area and containing text and other screen output, called “windows”: Not really implemented. In HX, there is only one “window”, covering the full screen, no margin, no close/minimize/maximize buttons. Applications relying on multiple such “windows” can’t run. However, some apps use 2 “windows” only, one for text (potentially completely or almost empty, or containing irrelevant junk only) and one for the graphical output: with HX the graphical window can be activated using the “-g” (force GUI) switch for DPMILD32. Note: except in HX 2.11 , tried to “be smart”, but reverted.
  • Networking: implemented, but does not work well (?)
  • “devices”: since version 2.14 (actually 2.13, but buggy), HX emulates some “device” services of Win ME/9x and NT/XP, most notably physical disk access
  • Filesystems: not part of the project, relies on DOS filesystems, DOS kernel and other DOS components (like filecache, ramdisk). Need NTFS in DOS ? Check for “NTFSDOS” or “NTFS4DOS” products instead.
  • Device (low-level) drivers: not implemented, supporting Win9x/ME or NT/XP drivers does not really fit into HX project, HX relies on DOS kernel and DOS drivers, VESA for graphics, ISA sound card or “emulation” DOS sound drivers (weakness), and DOS mouse and network drivers. Want to use NT/XP drivers without the original kernel ? Check for “ReactOS” project instead.
  • Security/Admin/TCPA/DRM/WGA: not implemented, nor useful ;-)
  • Spying: not implemented :-D , no data is saved to the HD except in some cases “HXSTDERR.LOG”, and data the user saves intentionally, of course.
  • Piping: very limited, SHARE issues (???)

7. System requirements

7.1 For console apps

  • CPU: for HX DOS Extender itself 80386 is sufficient (if the “INVLPG” hack in HDPMI is used, 80486 required), but Win32-PE apps might require more (Pentium 1 or Pentium 2, or FPU 80387 at least)
  • RAM: depends of the used app, few MB for simple apps, much more for memory hogs (256 MB preferred for 7-ZIP), up to 4 GB is supported
  • DOS: FreeDOS 1.1 (soon), 1.0 (kernel compiled 2006/07/26 or later, older kernels do have a heavy bug and can trash FAT32 filesystems), Enhanced DR-DOS (use latest 7.01.08 WIP or 7.01.07 stable ) , older DOS’es (MS-DOS 5.0 or above, open/closed DR-DOS 7.x) reported to work also
  • DOSLFN (depends, see the DOSLFN section below for details)

7.2 For GUI apps additionally

  • A VESA 2.0 compatible graphics card with LFB (for some older cards VESA 2.0 can be provided using a DOS resident (TSR) driver, check for “S3VBE” or “UNIVBE”)
  • A fast CPU (>=200 MHz) is highly preferable
  • More memory (depends)
  • Mouse and mouse driver (except for some view-only demos)

8.  Running Win32-PE executables in DOS

Before doing this, you have to:

  • Install HX-DOS Extender. Simply extract the “BIN” (optionally also the “TEST”) directory of “HXRT.ZIP”, optionally also of “HXGUI.ZIP”. Mix all EXE and DLL files into same directory.
  • Activate it. The “standard” result of starting a Win32-PE app in DOS is appearing a rude message like “ This program cannot be run in DOS mode ” or similar on the screen. Well, now we can safely ignore this “fact”  :-D  . There are 3 ways of activation of HX DOS Extender:
    • PESTUB: This util will patch the executable, so it will use help of HDPMI32 and DPMILD32 when started in DOS. See shot Nr. 4.6 in the Gallery how it works. The EXE size remains mostly exactly constant - generous paddings will be truncated to make space for the new MZ code, and can even sink in rare cases  :-D  , and the EXE still works in Windows as before (some rare exceptions, see below “Known problems” ) - no need to unpatch or keep original). Patching works on most executables. There is an only residual risk that PESTUB will trash it - test first and if it works erase the original file renamed to ”.BAK” . Beware: do NOT PESTUB installers or self-extractors (or at least, do not erase the .BAK file). Some of them (like WinZIP) do perform a self-check or store some “relevant” info into the PE-header. After PESTUB, they do no longer self-extract, not even in “Windows”, but cry about “header corrupt” instead. Also, PESTUB’ing UPX’ed executables is not the best idea: they will still perfectly work with HX and in Win32, but will become no longer easily decompressbile :-(
    • HXLDR32: This is a TSR program which will hook DOS interrupt 21h and check all programs to be launched if they are PE binaries. It quasi adds support for PE executables to DOS. Note: it possibly (?) has a bug.
    • DPMILD32: No patch, no TSR, all what you have to do is to precede the name of your app by “DPMILD32″. For example instead of “PNGOUT PAINTING.BMP” you type “DPMILD32 PNGOUT PAINTING.BMP”

Irrespective what method you use, you have to care about the PATH variable. You can have all involved files (HX-DOS files, PE-EXEcutable, processed files (archiving, compiling, …) ) in same directory - then the PATH is irrelevant. If you have the PE-EXEcutable located or the working directory set to elsewhere than where HX files are, then the PATH variable must be set correctly and point into the directory, where HX files are, otherwise, “file not found” like messages will occur. Also, if you have a WINDOWS/SYSTEM, WINNT/SYSTEM32 or similar directory on your system, make sure that in DOS your PATH does NOT point into it (or at least it is “behind” the HX directory), otherwise weird exceptions and crashes will occur. On the other side, if you use “Windows” when HX is installed, make sure it cannot find any DLL’s inside the HX directory (do not load any files like images or text from there), otherwise crashes & bluescreens will appear.

9. Long file names, DOSLFN

Running “Windows” software in DOS can expose filenaming problems, since most files used in “Windows” have DOS-incompliant names. If the DOS used does not have full LFN support in the kernel, use of DOSLFN can be preferrable or even required. In some cases, including QEMU, DOSLFN is NOT required, if filenames are truncated correctly. For example, “vgabios-cirrus.bin” must become “VGABIOS-.BIN”, and NOT “VGABIO~1.BIN”. When QEMU asks for opening “vgabios-cirrus.bin”, name gets truncated to “VGABIOS-.BIN”, and the appropriate file can be found. If QEMU needed also “vgabios-cumulus.bin” for example, truncating would no longer work since both “vgabios-cirrus.bin” and “vgabios-cumulus.bin” would truncate to same name. Since HX-DOS itself does not rename too much (only “KERNEL32.DLL” → “DKRNL32.DLL” and a few other DLL’s) and does not support any additional renaming (useful feature to add ???) of file requests, DOSLFN is required if 2 or more affected LFN’s truncate to same short DOS name and the long names are “hardcoded” somewhere like inside an EXE. If the LFN’s are stored in text files ( ”.INI” , source code), they can be renamed, but if there are many of them, using DOSLFN can be preferred from manual “chasing” and renaming all the LFN’s.

10.  Performance

How good is the performance of PE-executables running in DOS compared to Win ? It depends.

The good things in DOS:

  • Single tasking. Brings a speed benefit  :-)  of cca 4% against a clean Win system (irrelevant whether 9x or XP, almost no difference), benefit can be significantly bigger if compared with a “dirty” system (many viruses active, also so-called “Anti-Virus” programs running in the background, mail/spam-checkers, “calling-home”, dummy network/internet traffic, …). The benefit can be verified for example with brute-forcing, compression tests (running in memory only) or very strong compression (negligible time loss for file accesses).
  • Very little memory occupied by system (DOS & HX-DOS Extender) and no swapping. Almost complete memory is immediately available for the Win32-PE program. In “windows”, almost so much memory can be made available also but first all the expensive GUI, unused buffers, other “opened” things, etc. have to be copied to the hard disk and later from there read back into memory. Not to talk about some compressors allocating the swap “memory” (in fact hard disk) as compression dictionary and running at cca 1/1000 of supposed speed then.  :-D

The bad things:

  • Low performance of the filesystem, because of low buffers capacity (DOS bufffering limited to 640KB real mode) and mode switches. Possibilities to reduce this problem: use a filecache (like LBACACHE) or RAMDISK (like SRDISK), both do require XMS memory, this amount is no longer available for HX DOS Extender of course. Use 2 different hard drives (2 partitions on one HD is not good enough) for source and destination file (compression for ex.) or 2 files accessed at same time if this is the case. The final solution will be a fully 32-bit DOS, like FreeDOS-32, Enhanced-Dr-DOS-32, DexOS, or BOS. You can detect this problem but it is not really serious. ;-)
  • No graphics acceleration (applies to HX-GUI only). HX DOS Extender uses “only” VESA 2.0 with LFB, while Win has private drivers offering more acceleration for every card. Mostly not a real problem either, it’s still fast enough.  ;-)
  • HX DOS Extender supports “only” 32 bit and 1 CPU. Apps optimized for 64 bit or multiple CPU’s might run slower on HX DOS Extender. No panic needed: still fast enough, and you can save the time elsewhere: smaller backups, no security problems in DOS. ;-)

11.  Text/Console vs GUI, Screenshooting

HX-DOS Extender has support for Win32 console and with the GUI extension also (quite limited) for GUI programs. What is the difference ? Well, it is NOT always obvious. White text printed on the screen from top to bottom, and making the screen scroll, is console. TrueColor objects flying around the screen and a mouse arrow (or other small pictures) is GUI. The catch: programs using a text-based GUI ( ”Turbo-Vision” ), and optionally even a rectangular mouse cursor. Such programs are considered as Console for HX-DOS purpose. Examples are: ACE32 (obsolete compressor), FAR file manager (port of “Norton” to “Windows” while keeping the classical “Norton” look), VirtualPASCAL IDE (faking the TurboPASCAL look).

The HX GUI extension allows creating screenshots of GUI programs running under it. Pressing an appropriate hotkey (<CTL>-<BREAK> or <APPS> (one of the famous new keys for Win95), configurable via HXGUIHLP.INI , OTOH no <PrintScreen>) interrupts the program and displays a menu. From this menu, the screenshot can be saved (BMP file) or the program terminated. After saving the shot, program execution continues. This method does not work with console programs. Also, classical DOS-based screenshooters do not work while a Win-32 console program is running on HX. Why ? HX takes full control over the keyboard, and, even if it could be intercepted, because of the memory management and multithreading, it would mostprobably crash on such an act. How to shoot the screen ? Either with a classical DOS screenshooter, but after HX-DOS and the program terminated, or using QEMU: DOS → HX&GUI → QEMU → DOS → HX → target program. Need 2 instances of DOS and HX-DOS Extender, and 2 instances of mouse driver if required. Again, see also shot Nr. 3.12 (needs fixed) in the Gallery how it works. Complicated, but can shoot even freezers & crashes.  ;-)

12.  Other usage of HX DOS Extender

12.1  Most universal and reliable 32-bit DPMI kernel

Besides of making Win32 apps working in DOS or developing 32bit apps for DOS using the “complete” HX Extender, HX DOS Extender provides 2 more possibilities of usage: running other DPMI32 based extenders under HDPMI32. Just type “HDPMI32 -r” before running your app. In this case, only the file “HDPMI32.EXE” is needed. What is the benefit ? Many DPMI kernels are of low quality or have compatibility problems. Using HDPMI instead allows sometimes to bypass the problems, because it is better or because it is simply different. If a program crashes for you, trying it under HDPMI provides a second chance to get it working. Especially some DGJPP/GO32/CWSDPMI apps are verified to run better under HDPMI than the standard/embedded/included CWSDPMI. Other old and newer extenders also do work under it. For DOS/32A no benefit is proven so far, and a potential problem exists, see Development for details. Some apps might missdetect HDPMI as “Windows” : don’t care, it is not malicious, it is a historical design flaw: HDPMI “supports” INT $2F/AX=$160A call by default, this can be suppressed with SET HDPMI=16384 before HDPMI is loaded. Finally, HDPMI32 is very good for development of new 32bit apps running on “raw” DPMI, especially in assembler, since it supports the feature called “TrueDPMI” or “DOS API Translation”. While some extenders like DOS/4GW or DOS/32A have this functionality inside the “non-DPMI stuff”, having it in the DPMI kernel makes the rest of an “Extender” no longer necessary. HDPMI32 runs the apps in Ring3 with IOPL=3, meaning full hardware access in real time, supports up to 4 GB RAM, and does not swap.

12.2  16-bit stuff

The HX-DOS project is quite old and contains also some 16-bit stuff, partially originating in pre-Win95 era already, like HDPMI16 (16-bit DPMI kernel) and DPMILD16 (loader for NE-executables). Recently it got sort of reactivated for usage with some BP 7.0 projects (Deskwork, GV/GVFM, …). Those projects failed to switch to 32-bit, and have been suffering from very poor quality of the original Boreland’s “Ergo” DPMI/RTM extender. Switching to HX-16 partially fixes the problems: RTM.EXE and DPMI16BI.OVL get kicked and replaced by HDPMI16.EXE, DPMILD16.EXE and RTM.DLL.

13.  Known problems

  • The GUI API implementation in HX GUI is very incomplete, the high-level GUI API almost unsupported / “dummy” , apps will not run or GUI elements (“windows”, buttons, pop-up-menus …) will simply miss on the screen … low level GUI API is better but still has limits
  • Color problems (truncating color info to 12 or less bits (minor) or completely wrong colors (blue becomes red or yellow or vice versa), depends also of color resolution set in HXGUIHLP.INI (changing it can help), some other screen problems
  • Text screen brightness reduced after HX GUI exits - some (many :-( ) machines only (preferably ATI), bug of BIOS
  • Some programs (some console and most GUI) need MS C runtime DLL’s (MSVCRT.DLL, MSVCP60.DLL, MSVCR71.DLL, MSVCP71.DLL, MSVCR80.DLL, MSVCP80.DLL, CRTDLL.DLL), need to steal them from WINDOWS\SYSTEM, WINNT\SYSTEM32 or similar directory, or download them from somewhere, compatibility problems, not all versions are suitable. To get these files you can google for “C++ Runtime” . The files are included in micro**** but the link may change. You can unpack that installer (I`ve done it on Windows with UniExtract.) Small note for VC++ developers only: You can avoid this missing MSVCRT.DLL error by static linking the C++ Runtime Library. Project Properties → Code Generation → chose something static (no option with ‘dll’). To start your win32 console application in DOS: hdpmi32 ; dpmild32 programname.exe. Also note static linking might also have disadvantages.
  • Need of some other unfree DLL’s (like GLU32.DLL, OPENGL32.DLL, WNASPI32.DLL)
  • Some apps might need some external free DLL’s also (SDL.DLL, CYGWIN1.DLL)
  • No good way of playing sound so far. Sound theorretically is supported, some of the API features are implemented and do work, FMOD sound library works with HX DOS Extender, but: Sound has to be pushed from HX DOS Extender into the soundcard and this is the weak point. As there is no good way to use sound in “ordinary” DOS apps (like games), the same problem affects HX DOS Extender also. It is based on the obsolete ISA-based “SB” sound “standard” expecting ISA card / chip or “emulation drivers”: Installation from Windows only, refuse to install on Cyrix CPU (crippled :-( or lack of I/O debug ???), usage of debug registers (inappropriate / no other way ??? , hard to debug HX DOS Extender when active), bad reliability (crashes, freezers). See also SoundCardChip.
  • Some HX’s DLL’s have same names as the Windows one’s (for example SHELL32.DLL), unlike the renamed ones (KERNEL32.DLL → DKRNL32.DLL) - make sure that always the correct versions are accessed, otherwise exceptions (in DOS) and Bluescreens (In Windows) are guaranteed
  • Some GUI programs (when running in “Windows”, they create 2 “Windows” : one (possibly empty  :-D  ) text and one graphical) can be started with the “DPMILD32″-method only using the “-g” (force GUI) switch. This problem affects for example QEMU, BOCHS, and some “nice but useless” demos. This is a weakness open since HX GUI was introduced (named HX SDL at that time), and persisting up to HX 2.14. HX 2.11 had an “auto switch” feature (no need for “-g” ) but this brought other problems and got reverted very quickly.
  • Some EXE-compressed executables don’t load correctly. See below.
  • Some files (small minority, 512 bytes aligned ones) will no longer work in XP (no problem in ME/98) after PESTUB: “ This is not a valid Win32 application ” . Replacing the “too long” stub with a smaller one makes them accessible again. PESTUB doesn’t increase the “SizeOfHeaders” value (reason = ???), don’t use PESTUB on such files (there are 2 other options left), don’t use XP, or keep 2 versions of the file. This is not the same problem as the “Stub size vs RVA”, although the symptoms are similar. It’s a very bad idea to patch “full” DPMILD32.BIN or HDLD32.BIN into Win32 executables: they won’t get standalone in DOS, because of the DLL’s, and won’t work in XP/NT anymore.
  • Input problems: “mouse bug” and “keyboard bug”. Mouse bug was discovered with HX 2.8 supporting BOCHS (mouse movements had no effect , or some effect but not predictable/useful) and is fixed since HX 2.12 . Also a few GUI programs (from FreeBASIC) do not react to keypresses, related (?) to “bad” design of keyboard INT’s (to be fixed one day, but low (?) priority).
  • Using disk caches like Hyperdisk with HX frequently hangs or crashes the machine.
  • Networking support is (?) faulty.
  • Spawning problems: need DPMILDR=8 and HDPMI=32

14.  Installers

A problem that can arise when trying to run Win32 software in DOS is the habit of most developers to pack such software into installers. We can distinguish cca 3 types of installers being around:

  • Based on an archiver: [Win-]ZIP, [Win-]RAR, 7-ZIP
  • Sort-of standardized, but not archiver based: NSIS, InnoSetup, some more
  • Misc, special

For extracting you have first to find out what type of installer was used. This is not always easy, and not all installers are extractable (without disassembling) at all. A good help is the GT2 file format identifier ( see HX-DOS-lists? ). Sometimes it reveals the truth, sometimes not. If it fails, the chance is not very good but you still can use try-and-fail / brute-force method. Mostprobably you will need DOSLFN as well, otherwise you get duplicates and truncated filenames at best, or even worse extraction aborts at first long name.

The archiver based installers can be extracted using the appropriate archiver/extractor: PKUNZIP, Info-UNZIP, UNRAR, 7-ZIP.

NSIS can be extracted using 7-ZIP (DLL-based version only, 4.41 and above).

InnoSetup can be extracted using InnoUnp ( see HX-DOS-lists? ).

For most others, including NSIS-based Pelles/PO-Install you are probably out of luck.

15.  Files using EXE-compressors

One more potential problem are executables using an EXE-compressor. The reasons for doing this can be saving space (well, obvious), faster loading (discussable …), and (mostly ;-) ) an attempt to prevent cracking or disassembling of the code. There are executables processed by various compressors around:

  • UPX. Compatible with HX since 1.xx. UPX’ed executables are supposed to be decompressible with UPX as well. Problem: PESTUB makes them no longer easily decompressible.
  • UPX, but “cracked” - developer patched the compressed executable to prevent from identifying UPX usage or decompressing. This violates the UPX license (except the complete project is GNU GPL’ed). Most such executables still do load with HX.
  • ASPACK. Commercial product, no official unpacker, therefore officially used for “protection” also. Problem for HX: ASPACK decompression stub verifies some imports (no idea why ??? ), missing imports generate a message box (yes, even from console apps, related to “-g” problem) reporting this fact, depending of HX version and “-g” used or not used results in a silent failure, or abort after a keypress. “ SET DPMILDR=128 ” alone does NOT help in this case. Hack: use “ AspackDie ” v. 1.41 product ( Download: ASPACK.ZIP? ) to uncompress - doing this is NOT possible on DOS. On some files “probably unsupported version of ASPACK” message occurs, but file still correctly unpacks. After BOTH hacks: unpacking AND “ SET DPMILDR=128 ” , file should have a good chance to run in DOS.
  • Other. No tests so far.

16.  Software compatibility & wish lists

The list is quite long and can be found in HX-DOS-lists? !

17.  Project page and download

Go to

18.  See also

Edit - History - Print - Recent Changes - Search
Page last modified on December 13, 2018, at 02:50 PM