中国DOS联盟

Thanks Wengier, I'll take a look at the manual first ;P

Thank you very much, Wengier and jawbin. Your discussion also made me understand a lot about HXDOS. I will try it. If there are any problems, I will continue to post here!!!

Haha. Thank you again!

HX plus font support would be super perfect. It's really troublesome to draw fonts on GDI using FreeType by oneself, heh. Still, it's suggested that all brothers read the documentation first before asking questions ～

Today, the full version of HX 2.4 has been officially released. In addition to all the files and demo programs in the test version released yesterday, it also includes global description files (HXRT.TXT and HXGUI.TXT), etc. The download addresses are:

HXRT: http://www.japheth.de/Download/HXRT.ZIP
HXGUI: http://www.japheth.de/Download/HXGUI.ZIP

In addition, I have顺便 uploaded SDL.DLL and OPENGL.DLL/GLU32.DLL that can be used for HX to support SDL and OpenGL programs (just place these several DLL files in the BIN directory of HX):

Well, I downloaded it yesterday. Because the various documents were scattered and there wasn't a guide-like one, so it was a bit troublesome. But I can't download the current one today, don't know why. The development speed is really fast!

I also combined these several files into a DOS IMG and then used vmware to virtualize it. There also appeared the situation of "import not found" for GDI32 and WinSock. It seemed that when it was SDLTEST or DDTEST, the mouse appeared and the screen was drawn, but it was restricted in a small rectangle in the upper left corner (this might be related to the virtual machine not being real enough. At the same time, I was thinking, is there a more perfect virtual machine? I'll discuss this problem another time, heh heh). I think maybe I'm using Windows XP, and it uses the Unicode version instead of the ANSI version of the API names, so this problem occurs. I don't know if it's right! By the way, here it should specifically refer to my OpenGL library coming from my current system, Windows Xp.

Also, in VMWare, there's no need to pass the program name as a parameter to run, which is different from in the real machine. Of course, earlier Wengier said it might be that my configuration on the real machine is incorrect. But I still don't know where the specific problem is.

BWSkyer, just thank Wengier and asbai, I'm just a beneficiary :P

asbai uses FreeType to draw text? Calls GDI or VESA? Ported from linux?
It's already very good to be able to use FreeType. I can currently only use bitmap fonts. I tried vector fonts (on an 80186-compatible CPU and a non-VGA and non-VESA-compatible LCD), and the speed was very slow...
Of course, the HX documentation also said that it requires an 80386+ CPU... So it's not helpful for the 80186 clone I'm using

But still saw new hope for porting. At least SDL can be used, great! OpenGL and DirectX seem to be almost unused in ordinary applications. But if the GUI aspect is too lacking, can it also be considered?

Oh, originally it can be like this: DEVICE=C:\TOOLS\HXLDR32.EXE C:\TOOLS\DPMILD32.EXE
I need to try it, heh heh

Last edited by jawbin on 2006-5-17 at 09:42 ]

damn, www.japheth.de is blocked by the Great Firewall here, I accessed it using a proxy...

在主页看到了非常透彻的描述, 精辟:
HX DOS-Extender 是一个免费的 DOS 扩展器，内置对 Win32 PE 文件格式支持。通常，DOS 扩展器的目的是为 DOS 应用程序提供保护模式功能。HX 完全支持这个目标，但更进一步。HX 包含一个 Win32 API 模拟层，允许许多 Win32 控制台应用程序在 DOS 中运行。这种模拟远远超越了其他扩展器（Borland 的 PowerPack、WDOSX 或 Phar Lab TNT）中的类似方法。此外，HX 对窗口、DirectDraw、GDI 甚至 OpenGL 图形实现了 - 有限的 - 支持。这也允许在 DOS 中运行“简单”的 Win32 GUI 应用程序。

The very thorough description seen on the homepage is incisive:
HX DOS-Extender is a free DOS extender with built-in support for the Win32 PE file format. Usually, the purpose of a DOS extender is to make protected-mode features available for DOS applications. HX fully supports this goal but goes a few steps further. A Win32 API emulation layer is part of HX which allows many Win32 console applications to run in DOS. This emulation goes far beyond similar approaches in other extenders (Borland's PowerPack, WDOSX or Phar Lab TNT). Furthermore, HX implements - limited - support for windows, DirectDraw, GDI and even OpenGL graphics. This also allows running "simple" Win32 GUI apps in DOS as well.

Originally posted by jawbin at 2006-5-17 08:24:
...
asbai uses FreeType to draw text? Calls GDI or VESA? Ported from linux?
...

I seem to have said it uses GDI, heh :P

Blitting by oneself is after all troublesome. If done comprehensively, one also has to worry about text inversion, editing, etc...

If the HX's Font API is itself implemented with FreeType, it would be great. Then, as long as compiled in wxWidgets' universal mode, a Win32 GUI program with any standard controls can directly run in HX.

wxWidgets is a cross-platform GUI framework similar to MFC. The supported platforms include DOS/Win16/Win32/WinCE/Win64/Mac OS (X or classic)/Linux/Unix Like/MicroWin/QNX/VMS/AIX/BeOS, etc.

It can be seen that for some platforms, there are simply no ready-made Native GUI controls available. So it specifically has a Universal mode, which can draw all standard controls by itself in an environment with only basic DC and keyboard/mouse, including buttons, combo boxes, property pages, menus, Rich Edit, HTML View, Grid, List, and images (supporting bitmaps in more than a dozen formats), etc. What's more valuable is that the universal mode also has built-in support for theme, which can switch Win9x theme (officially said to be 99.9% realistic to the real Win95 environment, even professional users can hardly detect the difference), GTK theme, etc., and one can also write their own theme.

Later, the universal mode has even been able to be used on platforms with native gui controls (but usually just for testing). Under Win32, an application based on wxWidgets can be compiled into the univ mode. If combined with HX, such an application is a highly flexible tool with a consistent GUI interface under both DOS and Win32.

The only problem now is that the univ mode under Win32 still relies on Win32's own Font API. So if the HX's Font API is not solved, it can only display an English interface. But as long as the Font API is solved, and with a unicode font without M$ copyright, the application can immediately support multiple interface languages!

Oh, it seems I said it's using GDI, heh :P
I was too careless, sorry :P

Does wxWidgets support vectors? If it does, that would be great, and it could also be a backup test.
Vista seems to use vectors, but not necessarily "completely".

Also, does it support virtual screen?

Java also has similar solutions, and you can choose interfaces with Mac, Windows XP, GTK, etc. These things should become more mature.

Should the universal mode be more "open"? Not just limited to testing. Although "universal" generally sounds like a synonym for "slow" or "unaccelerated", but after all, it's "universal", it seems the structure is clearer.

"The only problem now is that the univ mode under Win32 still depends on Win32's own Font API"
Then this universal isn't very universal? Oh, this is the problem you mentioned, the font part isn't that universal. Yes, fonts are more troublesome. I don't know whether the DOS supported by wxWidgets is real mode or protected mode.

Thanks for asbai's detailed answer!

Last edited by jawbin on 2006-5-18 at 09:36 ]

Does wxWidgets support vectors? It would be great if it did, and it could also be used as an alternative test.

Vista seems to use vectors, but it may not be "completely" .

■ I don't quite understand. If "vectors" refers to drawing Bezier curves, then it can.

Also, does it support virtual screens?

■ Virtual multi - desktops? This function is actually implemented by the desktop manager itself and has nothing to do with the application. If you want to implement virtual multi - screens within the application, it's also very simple.

The universal mode should probably be more "open", not just limited to testing. Although "universal" generally sounds like a synonym for "slow" or "unaccelerated", after all, it's "universal", and it seems that the structure is clearer.

■ Universal is not only limited to testing. In fact, it's already very mature. The reason it's said to be mainly for testing is mainly referring to its Win32 version. Because Win32 has a complete GUI control and graphics environment, drawing by oneself seems a bit redundant, so the author said it's probably only suitable for testing.

■ Unless the graphics driver used by the DC is extremely inefficient, the efficiency of drawing controls in the universal mode itself won't be very low. The main problem is that if there is already a perfect GUI environment, the universal mode seems redundant, and it can't be consistent with the native control appearance of the current environment (for example, XP with Theme enabled or on MAC OS, etc.). Don't underestimate this point. Providing the original - looking control appearance and behavior on different platforms is very important. Java does this very badly.

"The only problem now is that the univ mode under Win32 still relies on Win32's own Font API"

Then this universal is not very universal? Oh, this is exactly the problem you mentioned. The font part is not so universal. Yes, fonts are relatively troublesome. I don't know whether the DOS supported by wxWidgets is real - mode or protected - mode.

■ The DOS mode supported by wxWidgets requires DJGPP + SciTech MGL + wxUniversal, which runs in DPMI protected mode. But this combination is obviously not as good as HX Dos Ext. + Win32 version of wxUniversal which has solved the font problem. The reasons are mainly three. First, HX implements capabilities that DOS doesn't have, such as TCP/IP, threads, etc., and provides standard Win32 interfaces, which are very important for many applications. Second, programs developed with this mode can be directly compiled -> debugged -> tested under Win32, with the highest productivity. Finally, such applications are amphibious in Win32/DOS and have the ability to provide a consistent GUI interface.

Originally posted by jawbin at 2006-5-17 08:24 AM:
... I think it might be because I'm using Windows XP, and it uses Unicode instead of the ANSI version of the API name, so this problem occurs. I'm not sure if that's right! By the way, here it specifically refers to my OpenGL library from my current system, Windows Xp. ...

Use the OpenGL library that is compatible with HX from the attachment I uploaded above. Don't use the one built into XP.

对于这个问题，其作者有做了什么回复吗？（这么好的功能，不用太可惜了）

这段中文部分未涉及需要翻译的内容，所以按照要求输出原文。
对于这个问题，其作者有做了什么回复吗？（这么好的功能，不用太可惜了）

Originally posted by Wengier at 2006-5-23 00:52:


Has the author of this issue made any response? (Such a good function, it's a pity not to use it too much)

Unfortunately, there is absolutely no news～

A workaround solution is: Win32 + MGL + wxUniversal + HX, so wxUniversal will use MGL's font support, and MGL's font function is implemented separately, without using the OS API. However, the font support of MGL is far inferior to FreeType in terms of display effect and font file format.

And it is not worth adding a heavyweight framework like MGL just for font support in terms of overhead and size.

BTW: wxUniversal is actually developed by wxWidgets and SciTech together, and the main developer is SciTech, so the efficiency should still be very high, heh heh.

PS: There may be no news from HX because my English is bad enough and I didn't make it clear. Brother Wengier might as well write a letter to ask~

Last edited by asbai on 2006-5-23 at 02:51 ]

I seem to have seen support for Truetype or Freetype in some cross-platform application frameworks. By the way, it seems that ReactOS supports it. Can it be ported over?

Originally posted by jawbin at 2006-5-25 09:21:
I seem to have seen support for Truetype or Freetype in some cross-platform application frameworks.
By the way, it seems that ReactOS supports it. Can it be ported over?

If you use ReactOS, there's no need to port it, heh.

React is originally an open-source NT Kernel Win32 environment reimplemented.