DosFreak wrote:COMPILING DOSBOXWindows NT 3.50DOSBox should work as long as correct msvcrt.dll is used and modifications to SDL to display fullscreen are made. Need to test.Also copy winmm.dll from NT3.51

Windows NT 3.10:DOSBox will not work. SDL 1.2.15 not supported on NT 3.10

MUNT Windows 98

This thread seems to be the most relevant to what I'm looking for.

DosFreak I appreciate the nod to my thread for Munt98. Although even it is not perfect and without hoops to jump through to work successfully.

I'm looking deeper to try and get Munt and DosBox to run under Windows 3.1 Standard to simplify the process.

Have you done any testing of compiling DOSBOX to work on Windows 3.1?

I also can't locate the source codes for older versions of DosBox v0.50 -> v0.72.

Is there a direct link to download the DOSBOX Source Codes for much older versions?

Or have these been removed/hidden as I can only see the standard compiled Windows executables and I need to get a hold of the source codes for the older versions to do some analysis and testing.

Although it seems you have more experience compiling DosBox from scratch you might be able to help make this happen sooner.

A preliminary Dosbox for Windows 3.1 might work with my P4 with a Sound Blaster ISA card since Windows 3.1 audio drivers seem to be more of an issue at the moment for only modern systems. Later it will involve porting the Audio to the Intel HD Graphics HDMI Audio port where the sound signal is purest running on Coffee Lake down to older Sandy Bridge systems where PCI and PCIe sound cards will later be adapted to work and eventually USB Audio devices.

Lowest SDL 1.2.13 supports is 95 (original) (unknown about betas) and NT 3.50 (Have to disable fullscreen support and use 3.51 joystick dll.). (SDL 1.2.14,1.2.15 and 1.2 branch work on 9x but DirectInput is bugged as of 1.2.14 so either have to use WINDIB, change a small bit of code or revert back to 1.2.13 mouse code)

For DOSBox to support Windows versions less than 95 or NT 3.50 SDL would have to support it which it does not and I definetly do not have the skills for that.There would be no point in using older versions of DOSBox since they all rely on SDL.

You can run DOSBox using HX DOS extender which would be more preferable than running it under Windows 3.x. HX DOS Extender is still being updated too and there is an unofficial build of HXRT that supports modern sound cards. Check my compilation thread for the HX post otherwise you'll be wasting time. Currently I haven't made any HX specific changes, just use my 9x build which works well enough in HX (Or official DOSBox which should work) but DOSBox-X has made some specific changes for HX that I'd like to incorporate.

Instead of Windows 3.x I'd focus more on HX or coding DOSBox for DOS itself.

Lowest SDL 1.2.13 supports is 95a (unknown about betas) and NT 3.50 (Have to disable fullscreen support). (SDL 1.2.14+ works on 9x but DirectInput is bugged as of 1.2.14 so either have to use WINDIB, change a small bit of code or revert back to 1.2.13 mouse code)

To go any lower than the above SDL would have to support it which it does not and I definetly do not have the skills for that.There would be no point in using older versions of DOSBox since they all rely on SDL.

You can run DOSBox using HX DOS extender which would be more preferable than running it under Windows 3.x. HX DOS Extender is still being updated too and there is an unofficial build of HXRT that supports modern sound cards. Check my compilation thread for the HX post otherwise you'll be wasting time. Currently I haven't made any HX specific changes, just use my 9x builds in HX which work well enough in HX but DOSBox-X has made some specific changes for HX that I'd like to incorporate.

Instead of Windows 3.x I'd focus more on HX or coding DOSBox for DOS itself.

I think the HX DOS Extender may have some compatibility issues on modern chipsets. DOS memory managers may not work properly on some Sandy Bridge chipsets and later. During SkyLake more DOS compatibility issues like Himem.sys no longer working properly began to occur. Have you tested on anything recent or from Sandy Bridge onwards?

Windows 3.1 can be made to support up to 512MB in standard mode and runs on modern Coffee Lake systems. 9x is a bit trickier to install than 3.1. However 95B with USB Support would be a good low end starting point OS due to its compact size and capable of supporting USB devices (limited) but no where near Windows 3.1's small footprint. But whether the Intel HD Graphics HDMI Audio out can be accessed under 9X for sound output is something that would allow the possibility of a USB portable DOSBOX running 9X on the go.

There's still the 9x display driver DOSBox requirement for 256 Colors that causes an issue unless DOSBOX can be made to do only the audio emulation and not do any video translation. Can you try to port DOSBOX to run on 95OEM and 95B with USB / 95C to avoid needing the 256 colors display driver requirement and keep the DOSBOX audio emulation separate and working or worst case running on the standard 16 color native OS display driver so any generic video card will work?

I'm not a coder so I'll have to start from the bottom with the less complex versions to analyze to catch up to where you are at. I still need to know if the original source codes to older Windows versions of DOSBOX can be downloaded.

If so are these available still can you provide the links to these?

Currently the oldest Windows executables I see is for v0.50 to 0.74 but no source code files are present with them.

If there are issues with HX then contact the developer.Since Himem.sys is no longer developed and if you have issues with it then should be using himemx or XMGR.

I haven't encountered any issues but I don't run DOS on anything that new except in VMs.

If you want to use DOSBox properly then you'll need at least 64mb of memory so 512mb isn't an issue.

I really don't know what your obession is with 256 colors. If your video card supports VESA and isn't buggy and if you don't have a video card driver then you should be able to use a generic vesa drive like VBEMP or similar instead of using standard vga....even DOS supports more than 256 colors so why would you limit the application for an artifical limitation?

It's possible Harekiet or Qbix have the source for those older versions, I believe they weren't using sourceforge before that. I doubt there would be anything to gain by going back that far as compatibility on both guest and host the latest ver of DOSBox is better.

DosFreak wrote:It's possible Harekiet or Qbix have the source for those older versions, I believe they weren't using sourceforge before that. I doubt there would be anything to gain by going back that far as compatibility on both guest and host the latest ver of DOSBox is better.

I'm not a coder like yourself so to analyze simpler code makes it easier to digest what's going on in the newer later much improved versions.

I just modify drivers to work on older operating systems from XP to work in 2K. Or I compact it so it doesn't require a bunch of unnecessary drivers to run compared to the original. Sometimes you just don't need the extra fluff. Take your typical nvidia Driver it can be rather large some in hundred of megabytes. I was able to get the nvidia driver down to its bare minimum while still fully functional without the massive bloat.

DosFreak wrote:If there are issues with HX then contact the developer.Since Himem.sys is no longer developed and if you have issues with it then should be using himemx or XMGR.

Yes I already used those to get around some of the issues. But in general DOS compatibility is lost on the much later chipsets beginning with SkyLake.

DosFreak wrote:I haven't encountered any issues but I don't run DOS on anything that new except in VMs.

If you want to use DOSBox properly then you'll need at least 64mb of memory so 512mb isn't an issue.

I really don't know what your obession is with 256 colors. If your video card supports VESA and isn't buggy and if you don't have a video card driver then you should be able to use a generic vesa drive like VBEMP or similar instead of using standard vga....even DOS supports more than 256 colors so why would you limit the application for an artifical limitation?

I only mentioned the 512MB because Windows 3.1 can handle it in Standard Mode. This extra memory could be allocated for a number of things like DOSBOX emulation or more sophisticated sound emulation. Running natively in DOS will pose conventional memory issues. Going to 9X and on another machine it may crash or not boot. Whereas booting in DOS or Windows 3.1 there's no need to configure anything on the OS if plugged into some random computer via USB.

The 256 colors issue is not an obsession but a way to make it possible to use DOSBOX with minimal requirements for the average user on any computer. I already tested VBEMP long ago on 9X and it's not compatible with the Intel HD Graphics and causes a corrupt garbage screen issue in DOSBOX in full screen. VBEMP will work with certain older generation graphics card in my tests but even with newer PCIe cards it will not be compatible for DOSBOX.

Navigating 9X with VBEMP in 2D doesn't pose any issues but running DOSBOX or any 9X 3D games will not work which is the point. If VBEMP worked properly I wouldn't be requesting this special DOSBOX 9X port. If DOSBOX sees a compliant card with proper 9X drivers then it should work as normal.

This is why I'm looking for a way to port DOSBOX to not check for this 256 colors requirement just to launch. I'm not limiting DOSBOX to run in less than 256 colors I just don't want to have any special 9X graphics driver installed for DOSBOX to function. If the user had a compliant working 256 color 9X driver then of course DOSBOX would then see it and use it so this wouldn't be an issue. But for generic systems with non compliant 9X drivers compatible for DOSBOX this is an issue.

If you don't believe me then try using DOSBOX on 9X with the Intel HD Graphics and you will see what I mean that DOSBOX will not run with VBEMP as you will get the corrupted graphics issue making it unusable.

Can you explain why DOSBOX even needs to have this 256 colors check compliance to work? What's wrong with running a 16 Color EGA game in DOSBOX while using the standard 16 Color Vga driver? Can't DOSBOX be separated to act in sound emulation mode only and let Windows itself run the DOS game in the Command Prompt window? I noticed DOS program will run fine in 256 colors mode using the Command Prompt in 9X. So why even enforce the 256 color graphics driver compliance for DOSBOX to even run?

DOS is the best method for running VGA 256 colors without any driver headaches but given the sound card restrictions on newer motherboards not having ISA slots this won't work for easy sound. Now if HX Extender can support USB Audio devices for sound output as if it were a genuine Sound Blaster card then that would solve that issue for native DOS sound compatibility. If it's gotten to that point then it could replace DOSBOX for OTG testing on any machine.

While building the latest DOSBox SVN using Visual Studio 2003 I found something kind of annoying under Windows 10. The first thing is that if I search through the source code base, the application locks up, hard. It turns out that this has been an ongoing issue with Windows 8 (maybe Vista/7?) with Aero rendering of all things. The fix is to disable Desktop Compositing & Desktop Themes, but the application comparability tab is hidden on many applications for Windows 10.

Broken Visual StudioSee how the application preview doesn’t render anything at all? This is the hint that it’s broken. I think it may be worth sharing this ‘fix’ as I’m sure that other applications that behave strangely have the same issue.

I found the solution to this over on stackoverflow in this discusstion:[https://stackoverflow.com/questions/2422581/visual-studio-net-2003-on-windows-7-hangs-on-search]. The fix is a registry entry in the “HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers” key.

The required settings to devenv.exe is:

“^ RUNASADMIN DISABLEDWM DISABLETHEMES”

Which, will run Visual Studio as Administrator allowing you to debug, and disable all the Aero assists for the application allowing things like resume to work again.

I had gone further and enabled the Windows XP SP3 compatibility settings, however on doing a clean build I was presented with this error:

]Which I never could find any good source on what caused it, other than by guessing to remove the Windows XP flag, and now I’m able to build.

In order to do a full build of DOSBox I had to re-build SDL, SDL-net, zLib, libPNG, and set them to a common C runtime linker setting to get a build where the final link didn’t complain. However when it came to existing project files I did have to find some older Visual C++ 6.0 stuff for many of the components, but using those I was able to ‘upgrade’ them to the 2003 environment and produce a working set.

I’ve got to say, that the AVI capture in the newer branches (I’m using build r4177) is really great!

But when I brought the resulting binary into the virtual machine it crashed when ran it: illegal instruction. Turns out it contained a conditional move (cmov) which is an instruction not available until the Pentium Pro (686). The “pentium” emulation is just a 586.

I tried to disable cmov by picking the specific architecture:

$ i686-w64-mingw32-gcc -march=pentium -Os hello.cThis still didn’t work because the statically-linked part of the CRT contained the cmov. I’d have to recompile that as well.

I could have switched the QEmu options to “upgrade” to a Pentium Pro, but remember that my goal was really the 486. Fortunately this was easy to fix: compile my own Mingw-w64 cross-compiler. I’ve done this a number of times before, so I knew it wouldn’t be difficult.

I could go step by step, but it’s all fairly well documented in the Mingw-64 “howto-build” document. I used GCC 7.3 (the latest version), and for the target I picked “i486-w64-mingw32”. When it was done I could compile binaries on Linux to run in my Windows 98 virtual machine:

$ i486-w64-mingw32-gcc -Os hello.cThis should enable quite a bit of modern software to run inside my virtual machine if I so wanted. I didn’t actually try this (yet?), but, to take this concept all the way, I could use this cross-compiler to cross-compile Mingw-w64 itself to run inside the virtual machine, directly replacing Borland C++.