DOSBox Compilation Guides

General information and assistance with DOSBox.

Re: DOSBox Compilation Guides

Postby 95DosBox » 2018-11-02 @ 08:47

DosFreak wrote:COMPILING DOSBOX
Windows NT 3.50
DOSBox 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.
User avatar
95DosBox
Member
 
Posts: 343
Joined: 2017-5-23 @ 09:34

Re: DOSBox Compilation Guides

Postby DosFreak » 2018-11-02 @ 09:16

Official DOSBox (0.74-2 and current SVN) supports 95 and NT4 with Active Desktop.
My builds support NT 3.50, NT 3.51, 95 and NT without Active Desktop. (Still haven't submitted patches yet)

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.

Modified HXRT with Intel-HDA, ICH/AC97, VIA82xx, ENS1371/1373, CMI 8338/8738:
http://www.bttr-software.de/forum/forum ... p?id=14645
User avatar
DosFreak
l33t++
 
Posts: 9972
Joined: 2002-6-30 @ 16:35
Location: Your Head

Re: DOSBox Compilation Guides

Postby 95DosBox » 2018-11-02 @ 10:37

DosFreak wrote:Official DOSBox (0.74-2 and current SVN) supports 95 and NT4 with Active Desktop.
My builds support NT 3.50, NT 3.51, 95 and NT without Active Desktop. (Still haven't submitted patches yet)

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.

Are there source codes to any older versions of Dosbox pre v0.50?
User avatar
95DosBox
Member
 
Posts: 343
Joined: 2017-5-23 @ 09:34

Re: DOSBox Compilation Guides

Postby DosFreak » 2018-11-02 @ 11:06

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.
User avatar
DosFreak
l33t++
 
Posts: 9972
Joined: 2002-6-30 @ 16:35
Location: Your Head

Re: DOSBox Compilation Guides

Postby 95DosBox » 2018-11-02 @ 13:03

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.
User avatar
95DosBox
Member
 
Posts: 343
Joined: 2017-5-23 @ 09:34

Re: DOSBox Compilation Guides

Postby DosFreak » 2018-12-08 @ 09:58

12-8-2018

Verify compilation with builds on Google drive. Supposedly network support not working. Check log.

Check variables (Decide if should include variables automatically....probably not):

User stated this worked with SDL_net 1.2.8+:
"./configure --enable-core-inline LDiatic -s LIBS=-lsdl_net -lws2_32 -liphlpapi CXXFLAGS=-O3 -march=i386 -mtune=i386"

Possible I tested with modified sdl_net that removes iphlpapi (Dependency introduced in SDL_net 1.2.8 but not needed for DOSBox) Need to check Mingw on Google Drive and review guide.
User avatar
DosFreak
l33t++
 
Posts: 9972
Joined: 2002-6-30 @ 16:35
Location: Your Head

Previous

Return to DOSBox General

Who is online

Users browsing this forum: No registered users and 6 guests