Enables Win9x support on a Pentium3 PC #4612
Conversation
There was a problem hiding this comment.
Changing from SSE to SSE3 should be incorrect, at least it should be SSE2. if uses SSE the dynamic branch of SSE2 is OK but it still got compiled, when targeting to pentium3 it failed to compile.
add target specific _WIN32_WINDOWS should be OK.
|
Related: #3577
Is there a Github Actions .yml file in this PR - for automatically making those builds? That would help to catch if some future change affects the tweaks here. |
|
NT4 has similar API set to Win9x, so at least It's possible to make it run, with a few changes if needed. But I didn't test it yet, I don't have legacy PCs that run NT4. Also I need correct my previous statement about the custom toolchain, it is essential because the original MSYS2 mingw32-crt startup routine will call some inline NT functions and corrupt the memory. Maybe an older mingw32 will help. What edition of Mingw32 is used to build DOSBox-X lowend exactly? And I've found some new problems and still been testing, for sometimes the build exe fails with page error on start, and it always does. but another build will always run. This only happens on my Penntium3 laptop, but works well in VMWare Player (with modern CPU features, which indicate the problem lays on instruction sets). - So it is not ready for PR yet. I don't know about Github Actions, but I can try to make one when the build is stable. |
I don't know what's used for the MinGW-lowend build, but there is also a HX DOS build, which I think doesn't use any NT functions.
I can test in VirtualBox - when you have an executable ready. |
|
the executable is here: https://github.com/crazii/dosbox-x-w9x/releases/tag/beta |
|
Ready for me to merge your pull request or should I wait for some testing to complete first? |
|
I did some tests - results are in #3577, basically the 9x build works under 98/Me/2000/11 and ReactOS. Doesn't work under 95 or NT4 (so I haven't tested NT3.x and Win32S) - can that be corrected? Would be nice to default into video output surface and to get the debugger enabled. Besides Github Actions, would be good if it gets an Installer (the NSIS used for XP/Vista installers supports down to Win95/NT) and added to the DOSbox-X Release scripts |
I suppose an #ifdef could be added to default to surface output if compiling the lowend version for systems below XP. Not sure if pdcurses can run on an OS that low. Is the missing component that prevents Windows 95/NT4 MSVCRT.DLL? That seems to be a common thing with MinGW compiled binaries in that they require MSVCRT.DLL which is provided by default on Windows 98/2000 on up. Another idea is that if pdcurses can't compile for Windows that old, perhaps the SDL interface itself could provide the debugger interface. In the same way that when you switch to the mapper interface the SDL window changes to an 8bpp mode to render the mapper buttons and such. Then the debugger interface could call some code that does very minimal ncurses emulation on the SDL window when active. If you can find a version of the NullSoft installer system that runs on Windows 95/NT4, that could be used for those systems, sure. |
|
Win 95 error messages are for IPHLPAPI.DLL (resolved by taking it from WinME), DHCPCSVC.DLL (resolved by taking it from WinME), NTDLL.DLL (resolved by replacing the one in WINDOWS\SYSTEM with one from WinME), unresolved for KERNEL32.DLL (Windows can't boot if the file is replaced with the one from WinME) Win NT4 first error is about IMM32.DLL (resolved by placing it in the DOSbox-X folder), then user32.dll (couldn't resolve) Error message sometimes mention specific function inside the DLL that's required. I will make screenshots of those later. |
|
NSIS installer - from the link above (which I think is the official/regular one used already by DOSBox-X) it seems to already support Win95/NT (maybe even NT3.x, because number isn't mentioned): |
|
Win 95 RTM + Winsock2 + OpenGL95 + IE4SP2 + DirectX:
I haven't tested with Microsoft Layer for Unicode, but it's not expected to help since the 9x build already has OpenCOW, correct? Win NT4 SP6a
|
No yet, it needs more tests. |
Yes. Thanks for the testing, I will try to fix it on win95 in VM first. Can you "at" someone who's familiar with the toochains used to build the lowend binary? I could check if that helps. |
|
@joncampbell123 @maron2000, can you please tell:
|
This would be the original 32-bit MinGW (not the MinGW x64 which seems to support only Windows Vista and up). |
|
I suspect the IPHLPAPI dependency might be the SDLNet library, which is not required by DOSBox-X unless you want the IPX tunnel code or the ability to connect a serial port to a TCP socket, and it might have something to do with the WinPCAP support. |
|
You should be able to comment out a #define to disable the IMM32.DLL dependency. Some contributors have added IME support especially where it concerns Japanese/Chinese keyboard input and/or PC-98 mode. You could also comment out the "multiple monitor" support code to eliminate the USER32.DLL dependency error. DOSBox-X is only trying to use that to determine your monitor's DPI and which monitor it's on. To my recollection, the multiple monitor API didn't appear in Windows 9x until Windows 98 when it was one of the Big New Features added by Microsoft. Not sure about when Windows NT added it (maybe it was added in Windows 2000?). |
|
Come to think of it, I already have plenty of LoadLibrary and GetProcAddress() for more recent Windows APIs like the one in Windows 7 to add buttons and define the portion of your window shown when you hover over the app icon on the taskbar, perhaps I should LoadLibrary/GetProcAddress IME support and multiple monitor support too when targeting Windows. If done right you could do that well enough to run on Windows 95 while using all the newer APIs you could ever want. |
|
OK, I was using the customized 32bit toolchain of MINGW-w64, I'll try to build a new binary with the legacy toolchain from SF. |
You can use that, or a slightly more recent version from the official site https://mingw.osdn.io/. However, for me the official site is unreachable at the moment. As an alternative you can also use https://osdn.net/projects/mingw/. |
It seems like the original MinGW site has gotten more and more inaccessible since about 2017 when I noticed the GUI to install it's packages stopped working. |
|
FYI, the mingw32 environment used to build the x86 lowend builds is found here |
|
Thank you guys, I've finished the build (with extra modifications of the source code) using toolchains from both SF and OSDN, tested good in win95, 98 and NT4. |
|
I ran a simple & fast test on the toolchain used to build lowend target (it seems a i686-w64-mingw32 for ming-w64), under win98 there's a missing function AddVectoredExceptionHandler in kernel32.dll, which is XP(or maybe 2k) only. For now the legacy MinGW from SF/OSDN is a sound choice. The built binary runs on win98 p3 real pc or win98/95osr2.5/nt4sp1 in VirtualBox. But I have to use Pentium instruction instead of p3, for win95 will fail on a invalid instruction of SSE1 (win98 works fine), didn't figure out why, but it shouldn't happen - Virtualbox won't limit such CPU caps on guest OS. |
|
What's the problem of the Linux/MacOS CI build check? I've no idea what happens, probably due to some changes on the configure.ac? |
It can't find the ".in" file 😆 because it forgot that "configure" is part of it. |
Yes I can see that in the check log, only a .in, but why? |
|
The source code itself is ready. There's my questions about CI workflow I checked the yml for build lowend, it runs under msys2, while the legacy MinGW runs on msys1, I don't know whether it works if the shell is changed to MinGW or msys, and the package installing part, should a pre-made zip be used (like mingw lowend zip) or install packages on the fly? I should test it on my fork to make sure everything works. But I don't know how. Should I enable the workflow on my fork and add a new one to test? The original workflows are disable by github, and I don't know the consequences if it is enabled. Anyone can help with this? |
If you do that, please make it a separate pull request. |
|
You can take a look at |
You converted configure.ac to DOS text format (\r\n). If you convert it back to UNIX format (\n) the problem will be solved. |
Thanks. I didn't remember doing that. Doesn't git always use LF in remote? I've seen articles about that, there's a auto CRLF option for windows local clones. |
|
WfW 3.11 + Win32s 1.30c: goes trough IMM32.DLL, MSVCRT.DLL, OPENGL32.DLL, GLU32.DLL, DCIMAN32.DLL, OLE32.DLL and then reaches unresolvable 'system component out of date' and w32scomb.dll (see at #3577 (comment)) So, it seems NT 3.51 is much closer to working (IMM32.DLL, then USER32.DLL). Would you be able to adapt the 9x/NT4 to build to work on NT 3.x? |
Could you create a pull request with the fix? It appears no one else will do that and the issue breaks the build on at least Linux and macOS (for everyone, not just for CI). |
Sorry for the inconvenience. #4651 |
Not for now probably. I wonder how many users in real world runs DOSBox-X under a pre 2k era machine. Me for instance, I've a win98 laptop with HW SBPro and soft FM emulation by the vxd driver, but a few games have problem with the FM emulation and they have no sound, and after they exit, the system get muted. After test them on DOSBox in win98 I got a satisfied result, then I want to see what happens if with the OPL hardware passthrough of DOSBox-X? But it fails to run. That's my initial intention of the fork. Those games runs with sound in DOSBox-X with sound in hardware OPL mode, but after exit DOSBox-X, the system still got muted. it's the bad driver of the host. |
Thanks. I'm trying to add a new job in mingw32.yml to build the 9x binary, I don't want to put the toolchain pack (90mega) into the repo so I tried use wget to download it. But I got a error that -The error logs are here: https://github.com/crazii/dosbox-x-w9x/actions/runs/7073571460/job/19253760479 |
|
OK, after reading the yml carefully, I get that the setup step uses a bash shell which is separated from msys2 shell, so msys2 has wget but bash env hasn't. |
The OPL pass-through code is not enabled by default, but your use-case may be a reason to change that. In order to enable the code change line 6 of src/hardware/hardopl.h as indicated in the comment (https://github.com/joncampbell123/dosbox-x/blob/master/src/hardware/hardopl.h#L6C12-L6C12). Edit: I was not reading carefully. Sorry. You already stated you ran the games with hardware OPL pass-through enabled. |
|
Yes, I checked the source that it is not enabled, I've enabled it on my local builds (didn't want to commit to the repo). |
Here's an article from IBM who, unlike Microsoft, doesn't throw away their old Knowledge Base articles: https://web.archive.org/web/20231203070203/https://www.ibm.com/support/pages/win32s-errors Apparently something to do with OLE32.DLL? |
There's a community of NT3.51 enthusiasts, for example Running NT 3.51 on real new hardware (Ryzen 3900X), Gaming on Windows NT 3.51 and VOGONS DOSBox 0.65 is reported as the last version working under NT3.51, so those users would benefit greatly if latest DOSbox-X lowend9x can be made to run there. (I also wonder if NewShell patches will help or allow NT4 Internet Explorer to be installed, which may also help) |
OK, cool. I'll mark this as unread in case I forget about that. |
|
@crazii, at DOSBox Compilation Guides (by @DosFreak) there are instructions for building NT3.50 and NT3.51 DOSbox SVN - probably similar procedure can applied here? Also, in some of the comments they discuss a use-case for DOSbox on Win3.1 (although it seems more difficult than for NT3.50). What I tried is your lowend9x build on NT3.51 + newshell2 - doesn't work. |
|
SDL 1.2 working on Windows 3.1 with Win32s and WinG: https://github.com/ccawley2011/SDL-1.2/tree/win32s (from this discussion) |
Enables Win9x support on a Pentium3 PC.
Unicode functions (e.g. GetOpenFileNameW to choose dosbox-x.conf) which is not originally supported on Win9x, it just fails silently with no error code. (similar found in code: FindFirstFileW/FindNextFileW, GetFileAttributeExW, InsertMenuItemW)
For MSVCRT it is the same, e.g. wstat/wopen won't work. mounted drive in DOSBox-X will fail getting file information and result in empty mounted disks.
The OpenCOW lib will translate *W calls to *A calls: adjust wide strings to ANSI string with current system code page and call the corresponding ANSI function, and make the win9x build compatible with Unicode functions.
Win9x uses FAT32 which doesn't need 64bit file offset, so it is not supported.
Additional information
A custom toolchain that targeted to pentium3 is needed (https://github.com/crazii/MINGW-toolchains-w9x/releases/tag/v1.0),
otherwise the built binary can not run.
Tested working on a real Pentium3 Win98SE laptop.