ThešHX DOS Extenderšis a freešDOS extenderšwith built-inšWin32šPE file formatšsupport. Usually the purpose of a DOS extender is to makešprotected modešfeatures, especially large memory andš32-bitšaddressing, available foršDOSšapplications. HX fully supports this goal, but goes some steps further. AšWin32 APIšemulationšlayer is part of HX which allows many Win32šconsole applicationsšto run in DOS. The developers say this emulation goes far beyond similar approaches in other extenders (such asšBorland'sPowerPack,šWDOSXšandšPhar LapšTNT).

The Win32 layer has limited support for Windows,šDirectDraw,šGDIšandšOpenGLšgraphics. This lets some WindowsšGUIšapplications run in DOS, includingšBochs,šQEMU,šMPlayer,šDOSBoxšand some (mostly older) games.^[1]

HX DOS Extender contains the following components:

• HXRT: the extender runtime
  • HDPMI: a DPMI server for DOS (can be used as standalone tool)
  • DPMILD32: Win32 PE file loader
  • Win32 API emulation library
  • HXLdr32: a TSR Win32 PE loader
  • PEStub: a Win32 PE header stub tool to add a Win32 PE loader to DOS entry point
• HXGUI: GUI extension
• HXDEV: development support
• HXSRC: source code

Am 15.05.2012 11:56, schrieb Sven Barth:

šAm 14.05.2012 17:56, schrieb Andrew Faulds:

šHmm, apparently, Wine does NTVDM using DOSBox. I tried to run a DOS
šapp recently and it spawned WINE's NTVDM (I'm on Ubuntu), which spawns
šDOSBox.

šSo I guess we could just copy in Wine's NTVDM?

šIt might not be that trivial. While it's true that it uses DOSBox (and
šmounts all Wine drives besides Z) there is also some stuff going on
šwhich is currently hidden behind an external function
š"__wine_load_dos_exe" which I yet need to find and which is the one
šresponsible of loading the binary into DOSBox somehow (and this is the
šinteresting part!). Also one might need to test whether Win 3.11
šapplications work in Wine. If so then it might indeed be interesting to
šinvestigate this further.

I've looked a bit more into this and it is so that Wine supports two
approaches:
* run 16-Bit executable natively (basically the same that Windows does)
* if that fails (e.g. on 64-bit Linux) run the application in DOSBox

So in the first case the application might correctly interact (and
display) like other non-16-bit applications, but in the second case the
application will be emulated and thus the application will not integrate
as nicely as in the first case (especially if it is a graphical Win3.11
application which also might require that you set up your DOSBox correctly).

Regards,
Sven


_______________________________________________
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev