Baron-von-Riedesel
Video card independent version of HX
In most cases HX is treated as Win32 emulator to run real Win32 applications in DOS. But it can also be treated as DOS Extender to run applications, that wish to control hardware by themselves. My project is exactly such application. Major problem - HX touches VGA registers directly. And on non-VGA video cards it causes following problems. This can happen on both pre-VGA video card and VGA-incompatible SVGA.
Can we have video card independent version of HX, that:
- Would launch Win32 GUI apps without trying to load hxguihlp.dll
- Wouldn't access any VGA registers, if it's not demanded explicitly
Can we have video card independent version of HX, that:
Would launch Win32 GUI apps without trying to load hxguihlp.dll Wouldn't access any VGA registers, if it's not demanded explicitly
You may create a modified version of DPMILD32.EXE that won't load hxguihlp.dll. See file HX/DPMILDR/PELOAD.ASM, procedure "loadguihelper". For testing,I guess it's possible to just rename file hxguihlp.dll to a different name - then this dll won't be loaded.
I can fix all problems, but unfortunately I don't have time for forking your project now. May be some day in a future. But I don't know when. That's why I decided to ask your help.
I also had some problems with recompiling your project. Can it be done in DOS? What version of nmake is required? Modern one? Or MASM one too?
hxguihpl.dll isn't big problem. I have to set application type to console as workaround and only side effect is - unnecessary console windows, appearing in background. For now it's bearable.
Accessing VGA registers directly is bigger problem. I'm not 100% sure, what causes it. But, I guess, it's caused "IsGraphicsMode" routines. Almost all registers are write only on pre-VGA cards. So, even saving previous register value to restore it later can break things.
HDPMI has one place where it reads VGA register 3CEh: proc IsTextMode in putchr.asm. It's called when an exception occured and the client is to be terminated. It can now optionally be changed not to access the port and simply query the video mode instead: modes 0-3 and 7 are supposed to be text, the rest is supposed to be graphics. Currently it's "optional", but I guess it will be made the default in next version.
If it's called only there, then it can't be cause of my problem. My problem happens, if my application terminates without mode change, that can happen if suitable mode isn't found for example. It isn't due to exception or something like that. Then it must be something else. But it still should be something related to reading write-only registers, writing some hardcoded values or using some VGA-only features, such as scanline double bit for example.
If it's called only there, then it can't be cause of my problem. My problem happens, if my application terminates without mode change, that can happen if suitable mode isn't found for example. It isn't due to exception or something like that.
Well, since you don't supply a test case, I can't do anything. So lets close this issue...
Here is another possible cause of problem
DOSBox-X debug feature shows, that attribute controller's mode control register is set to 17h, that is some sort of graphic mode, while it should be 08h.
Test case?
- Download my application.
- Download DOSBox-X.
- Set machine=ega.
- Run Launcher.exe.
- See garbled screen, as my app is configured for VGA by default, so it wouldn't find suitable mode.
[Here is another possible cause of problem]
But that's in DKRNL32 - and that's part of HX's Win32 emulation layer. Since you wrote "But it can also be treated as DOS Extender to run applications, that wish to control hardware by themselves. My project is exactly such application. ", I did assume that the Win32 emulation part isn't used, just hdpmi and the PE loader dpmild32.
Sorry for confusion. But I thought, that emulator would aim at running native Windows applications on another platform. Like Wine for example (that isn't emulator). Extender - is little bit different thing. Extender aims at DOS. Is Borland Power Pack emulator or extender?
Ok, I'll add a switch (?VGA) to DKRNL32.INC. Default is 1 - setting it to 0 makes dkrnl32.dll to not assume a VGA compatible card. Changing this switch will require to rebuild the binary.
Yeah. Setting blink-intensity bit can be done via BIOS call. Detecting graphic mode is little bit more complex. It's easy in case of standard VGA modes, as only modes 0-3 and 7 are text modes. But it's much more harder in case of SVGA. Probing mode info is expensive operation. But if it's called only when exception happens - then no problem.
I want to ask this question again. I had problems with compiling HX on DOS. Is it possible? What version of nmake is required? Old one or modern one?
I want to ask this question again. I had problems with compiling HX on DOS. Is it possible? What version of nmake is required? Old one or modern one?
Yes. I use MS NMake v6.00.8168 - it says "Copyright Microsoft ... 1988-1998". I guess that was shipped with MSVC 6. It needs msvcrt.dll.
Yes. I use MS NMake v6.00.8168 - it says "Copyright Microsoft ... 1988-1998". I guess that was shipped with MSVC 6. It needs msvcrt.dll.
So, yeah, v1.2 shipped with MASM is too old.
~~P.S. Can you also add option to completely skip this test? Don't get me wrong. I can do it myself. But I would need to fork your project, if I'd modify it. Shame on me, but I don't have such experience yet.~~
Ahh, sorry, setting ?NOGUIAPPS=0 and ?ALLOWGUIAPPS=0 already does it.