Vista, Mac OS X 10.5 - which are the earliest versions still supported as host for running Staging?

[Torinde]

Are you using the latest Dosbox-Staging Version?

• I have checked releases and am using the latest release.

Different version than latest?

0.80.1

What Operating System are you using?

Windows Other

Whats your question and how can we help?

Tried running DOSbox Staging under Vista (both x86 and x64) in VirtualBox - could not run it:

• The setup files give for example "dosbox-staging-v0.81.0-alpha-172-gfb493-setup.exe is not a valid Win32 application".
• Trying various builds without setup:
  
  ...
  TryAcquireSRWLockExclusive - requires Win7 at minimum?

Is there something else that has to be done to run it? Or Virtualbox is the problem (maybe its GPU driver)? Or Vista is also not supported at all?

Originally posted by @Torinde in dosbox-staging/dosbox-staging.github.io#27 (comment)

Current About text:

Non-goals
Support old operating systems (Windows 9x/Me/XP, OS/2, and Mac OS X 10.4) and limited CPU/memory hardware, which are constraints DOSBox continues to support.

I can't test Mac OS, but see at SDL2:

SDL2 has dropped support for PowerPC Macs and Mac OS X versions older than 10.6 (SDL 1.2 still supports PPC and 10.0, though). That being said, some small changes can make it work, but they make the codebase uglier for small gains

So, which are the earliest Windows and macOS versions still supported as host for running Staging?

Code of Conduct & Contributing Guidelines

• Yes, I agree.

[GranMinigun]

For Windows, it's dictated by usage of glib, which is a dependency of FluidSynth. The minimal version they support is Windows 8.1, if I remember correctly. That said, treat any EoL systems support as best-effort (8.1 went EoL on 10 January this year). Windows 10 versions still supported by Microsoft are thus the current baseline.

For macOS, I believe our CI builds are targetting 10.15 for x86_64 (and likely 11 for ARM?). MacPorts (or Brew? Not sure, not a Mac user) can go much lower, but I don't remember the details.

[kcgen]

MacPorts: https://ports.macports.org/port/dosbox-staging/details/

My Linux PPC-7400 system is unfortunately broken down, so I haven't been able to test PPC (or big endian in general) for a couple years now.

Maybe someone with a fast and working PPC or Power system can report in.

[Torinde]

The Macports results currently:

• 10.5, 13 arm64 - nothing
• 10.6 x64 - OK, 4 warnings
• 10.6 x86 - OK, more warnings
• 10.7, 10.10 - 13 - OK, 4 or more warnings
• 10.8, 10.9 - not OK
  Which kind of matches what's in About (10.4 not OK, implying 10.5 minimum). Then the macOS downloads page mentions a similar number plus the 10.15 explained by GranMinigun:

This package is compatible with macOS 10.15 (Catalina) or newer.
...
The MacPorts package should build on systems as old as macOS 10.7 (Lion, circa 2011) or newer.
So, the macOS side looks more or less OK. I don't see any further clarification possible unless somebody explicitly tests 10.5 and 10.6.

Windows:

• XP mentioned as excluded in About
• Vista - not working (per my Virtualbox test)
• Win7 - not sure (starting it in Virtualbox doesn't give me warnings.... but also I never got to see the C:> - window remains black). As for FluidSynth - isn't it optional, e.g. PC speaker games will work without it?
• Win10 - working on real hardware, but in Virtualbox - I have same problem as with Win7...
• Win8.x - didn't test in Virtualbox, but kind of meaningless if I can't make Win10 one run properly?

[kcgen]

@Torinde , my understanding is that the MSVC-built executables can be used for Win7 and newer, while the Msys2-builds are good for win10 and newer.

Try with the setup.exe installer; it includes all the binary options to try out.

[Torinde]

Based on the above - my suggestion:

• test older Staging versions in Vista to see the last one "starting" (I don't expect any to work in my Virtualbox, but 0.75 at least should "start")
• mention that last version in the Downloads\Windows
• test again/more Win7 per kcgen's suggestion on MSVC/MSYS2/setup.exe - if myself or somebody else nails it down (e.g. which build works in Win7) - mention that in Downloads\Windows
• as for Fluidsynth - it seems to have win10-x64 and winXP-x86 builds. Staging has MSYS2 x64 and MSVC x64 and x86 builds from what I see. So, I'm unsure what will happen in win7/8, but can't test unless I find out how to make it work in win10 Virtualbox first. If it gets nailed down - can be mentioned as well in Downloads\Windows?

[kcgen]

Suggestions sound good; curious what you find!

[GranMinigun]

OpenGL output doesn't work in VirtualBox for whatever reason, switch output to texture. FluidSynth is optional, you can disable it during building and feed DOSBox with an external MIDI synth if you want (not recommended, as that way one is giving up on internal mixer features like high-quality resampler and compressor).

Also keep in mind DOSBox Staging requires a compiler which supports C++17 standard. Microsoft Visual Studio deprecated its WinXP tools some time ago (but they're still available for download). MinGW-w64/MSYS2 also might be worth looking into. That is, if you're willing to build the project yourself.

[kcgen]

Adding to @GranMinigun's suggestion to disable FluidSynth: also disable slirp, because it too depends on glib.

What about people with older generation hardware stranded by Microsoft and Apple, stuck with an EOL'd operating system and no upgrade path? The best option is to switch to an operating system that does support their hardware, like a Linux distribution tailored for lean hardware.

[Torinde]

• Yes, output=texture solved the Virtualbox problem - both in Win10 and Win7
• Yes, MSVC build works in Win7 (to be mentioned on the website?), while MSYS2 doesn't. To run the MSVC didn't need to disable Fluidsynth or slirp (but I didn't test using them either). MSYS2 error:
  
• x86 - releases after 0.78.0 don't have 32-bit zip, so it'll be good if MSVC development build is mentioned for those users?
• installer setup.exe - it offers choice between MSVC x64 and MSYS2 x64. But are executables present somewhere after installation (so that user can switch at any moment) or the choice is possible only at the moment of installation?
• installer setup.exe - on x86 Windows it installs unworkable (x64) versions. Still useful, because it provides the .conf file, but I would suggest installing the x86 build or at least mentioning to the user where to download it from?
• when running - ver shows the Staging version number, but not the build (MSVC or MSYS2) and not the architecture (x86, x64, ARM, etc.) - can those be seen somewhere?
• dosbox-staging.conf - when NOT using the setup.exe (e.g. starting with release.zip or development build artifact) - where should users take this file from?
• I took .conf from previous installation, changed output=texture, mididevice=none (to disable Fluidsynth), ne2000=false (to disable slirp), copied the file into the MSVC x86 build unzipped folder, ran from cmd.exe dosbox.exe -conf dosbox-staging.conf - didn't help for Vista with 0.81.0 - same error messages as on the top. Is there some other way to try disabling those?
• 0.78.0 release x86 - runs under Vista. I will try newer versions and x64 builds next.

[Torinde]

In Virtualbox with Vista x64 + SP1 + SP2 + Platform update + Platform Update Supplement + MSVC++ redist 14.29.30135.0 x64:

• 0.78.1 release x64 zip - works
• 0.79.1 or later - releases x64 zip and installers - doesn't work - error messages from the top post here
• MSVC artifacts - earliest I can find is v0.80.0-alpha-181-g083e - doesn't work - error messages from the top post here

So, remaining questions:

• how to disable Fluidsynth and slirp in 0.79.1 or later?
• dosbox-staging.conf - when NOT using the setup.exe (e.g. starting with release.zip or development build artifact) - where should users take this file from?

[rderooy]

Removing fluidsynth and slirp requires recompilation.

A standard dosbox staging config file can be generated with the config -wcd command on the dosbox-staging cmd line. Or alternatively from the host with:

dosbox -c 'config -wcd' -exit

[Torinde]

0.80.1 x64 release setup.exe - both MSVC and MSYS2 work under Win8.1

[kcgen]

So, remaining questions:
how to disable Fluidsynth and slirp in 0.79.1 or later?

@Torinde , nice progress in here!

We have some notes on how to build under MSYS2:

https://github.com/dosbox-staging/dosbox-staging/blob/main/docs/build-windows.md#build-using-msys2

You only need to perform a Clang build (instead of GCC), as that's what we use for the release binaries.

When you get to step 8 (Meson setup with Clang): meson setup ... <snip>, you can add any of the follow after the setup command:

-Duse_fluidsynth=false
-Duse_sdl2_image=false
-Duse_sdl2_net=false
-Duse_opengl=false
-Duse_mt32emu=false
-Duse_slirp=false
-Duse_png=false
-Duse_alsa=false

So for example, to knock out FluidSynth and Slirp, your new "Step 8" command would become:

meson setup -Duse_fluidsynth=false -Duse_slirp=false build/release-clang --native-file=.github/meson/native-clang.ini

This is the only deviation in the notes needed (to customize your build), and you can carry on following them, and it should produce a build that doesn't depend on Glib.

[kcgen]

@Torinde - also, thank you for breaking out separate topics into new issues (32-bit MSVC builds and a separate one for showing more build-specific details) 👍

[Torinde]

I don't yet have the tools to test the build from source procedure, but I made a PR with the Windows-related outcome from above.

For macOS - I can't test and MacPorts shows 10.5 (albeit with question mark) and 10.6 (green check), while Staging website says 10.7, so I'm fine with leaving it as is until somebody has better info.
Issue to be closed together with the Windows PR? Or to leave it open until somebody checks macOS 10.5 and 10.6?

[Torinde]

About macOS - can DOSbox Staging even run on PowerPC Macs? If not then there are only a few Mac models that don't support 10.7 (max mentioned on Staging website) or 10.6 (max having green on MacPorts).

From what I see I think Staging website can be updated to mention MacPorts starts from 10.6 onwards? Again - until somebody can check 10.5 (PPC, x86, x86-64)

[johnnovak]

Quick thoughts:

• Why do we care about Vista at all?
• Knowing whether it still runs on Win 7 is reasonable, but I wouldn't go earlier than that...
• I wouldn't trust VMs at all when it comes to a complex emulator like this that supports OpenGL.
• Actually stating that it runs on "OS x.y.z" carries a maintenance burden... Are we prepared to pay that? "Started up on Win 7 and I played a game for 5 minutes" is different than saying "it is fully supported on Windows 7"

[johnnovak]

OpenGL output doesn't work in VirtualBox for whatever reason, switch output to texture. FluidSynth is optional, you can disable it during building and feed DOSBox with an external MIDI synth if you want (not recommended, as that way one is giving up on internal mixer features like high-quality resampler and compressor).

Out of curiosity, if you never use mididevice = fluidsynth, would DOSBox be still usable on earlier Windows? You could still play the vast non-GM catalogue of games, or of course use hardware MIDI modules.

[johnnovak]

So @Torinde, it's great that you're looking into this, but you need to appreciate that we don't quite have the bandwidth to do extensive testing on long abandoned legacy OSes...

This is not exactly well defined at the moment, but the general idea is that we support the current major version of Windows, macOS, and Linux. Generally speaking, I don't think we want to out-perform current "industry trends", e.g. a good criteria would be to look at what Steam and GOG is currently doing. They don't seem to be supporting Windows 7 or anything before that, so that will be good for us too. Probably they only support current macOS minus 1 or 2 major revisions. As I don't use Linux, I'm not sure about the Linux situations, but I'm sure others from the team can chime in.

So, if you have the bandwidth to spend lots of time playing around with this, by all means do it and let us know the answers! 😄 But keep in mind this needs to be a long-term effort on your part, it's not a one-off thing. You would need to keep redoing the same testing on legacy OSes for every new DOSBox Staging release.

I can't speak for everybody in the team, but my general stance is the above — we can only guarantee the thing works on the OSes we are personally using, and given this is not a commercial project, we simply don't have enough time and energy to perform extensive regression testing on older OSes. That would multiply the testing effort required for rather questionable benefits.

All in all, I think we should be guided by some concrete OS usage statistics, like the Steam one:
https://store.steampowered.com/hwsurvey/Steam-Hardware-Software-Survey-Welcome-to-Steam

Hope you're not interpreting this as being dismissive, but we have finite amount of energy we can dedicate to this project, and I personally want to spend it on where it really counts. Making 1% of our users happy by enabling them to keep running Staging on Vista or Windows 7, versus bringing in for example the new OSD functionality so the remaining 99% can benefit from it — is that even a question I need to ask? 😄

We really need to keep the scope focused on what's important.

[kcgen]

@Torinde , I previously tested and added minor fixes for PPC because it was the one host I (had) that was big endian. Having correct endian code is important, however my system is unfortunately no longer working, so now rely on our (few) MorphOS users to flag issues. Presumably it's still working there.

We also merged jmarsh's PPC dynrec core (a patch on vogons), which works great.

We welcome any bug reports, regardless of what OS they originate on.

If we can't repro the bug, then there's not much we can do. There's also the potential the bug is due to interactions specific to the (possibly EOL'd) OS itself, in which case we won't rollback to prior libraries or older C++ standards just to reanimate Staging back to life on an EOL'd system.

But if the team can repro the bug on our current dev systems, then that's great -- we can improve the codebase!

[GranMinigun]

Out of curiosity, if you never use mididevice = fluidsynth, would DOSBox be still usable on earlier Windows?

No, glib would still dynamically load by the OS and fail, you have to disable relevant features at compile time. It's possible to handle dynamic loading by software itself, but that's additional resource management headache.

[Torinde]

Out of curiosity, if you never use mididevice = fluidsynth, would DOSBox be still usable on earlier Windows?

No, glib would still dynamically load by the OS and fail, you have to disable relevant features at compile time. It's possible to handle dynamic loading by software itself, but that's additional resource management headache.

Yes, in my tests - new releases don't work on Vista and kcgen provided instructions above on how to build a workable version.

[kcgen]

Yes, in my tests - new releases don't work on Vista and kcgen provided instructions above on how to build a workable version.

Any luck, @Torinde ?

To get video working inside VMs, use:

[sdl]
output = surface

Or

[sdl]
output = texture
texture_renderer = software

[Torinde]

@johnnovak @kcgen My intention is not to ask to add support for older OSes, I understand your decision that the limited time developers can spend is better used for higher priority changes.

I approach the topic from a documentation perspective (thus: question, not a bug) - to be clearly listed what is supported out-of-the-box, what is potentially buildable (by experienced users) and what is totally not supported. Currently it seems a little bit murky after the "really very old, totally not supported" (About page: XP and earlier, OS/2, macOS 10.4 and earlier).

For Windows I think it's now clear - I made a PR for the website (although I afterwards saw that on the macOS page you list the supported version next to each build, so I will change the PR to do the same on the Windows page)

For macOS I still see a gap:

• 10.15 and newer: supported (per Staging macOS downloads page)
• 10.7 and newer: builds at MacPorts (per Staging macOS downloads page and results present on MacPorts page)
• 10.6 x86, x86-64: builds at MacPorts (results present on MacPorts page) - Staging macOS download page to be changed? (e.g. change 10.7 -> 10.6)
• 10.5 PPC32, PPC64, x86, x86-64: unknown (MacPorts selector has "10.5 PPC legacy", but it gives no results)
• 10.4: totally not supported (per Staging About page)

[Torinde]

Any luck, @Torinde ?

Yes, VirtualBox works with output=texture - for Win7 and Win10 (both x86 and x64)
Vista build - I haven't tested your instruction, sorry. I don't have the tools (or you can argue: the time to get the tools).

[kcgen]

Ok, well, hopefully it works when you have time.

For macOS users of 10.14 and prior, we suggest installing the macports package. Failing that, build from source using the steps described in README.md.

(as opposed to a fine grained breakdown going back through the old OS versions. With brew and macports supporting modernish SDL2's all the way back, it should be very doable to get a build from source working).

[Torinde]

PR for the website changes I mention above: dosbox-staging/dosbox-staging.github.io/pull/28

[johnnovak]

My intention is not to ask to add support for older OSes, I understand your decision that the limited time developers can spend is better used for higher priority changes.

Yeah, that's fine. I was kinda saying even figuring out that info for documentation purposes can be time consuming. I'm glad you're doing it, thanks for your efforts! 😄

[Torinde]

MacOS 10.5 - from what I understand ALL Staging releases are using SDL2. As mentioned on the top here, per the SDL2 page:

SDL2 has dropped support for PowerPC Macs and Mac OS X versions older than 10.6 (SDL 1.2 still supports PPC and 10.0, though). That being said, some small changes can make it work, but they make the codebase uglier for small gains

Staging About page:

Non-goals
Support old operating systems (Windows 9x/Me, OS/2, and Mac OS X 10.4)

So, which is true?
a) Staging has "small changes to make SDL2 work on 10.5, while also making the codebase uglier"
b) About page has to be changed to mention 10.5 as not supported
c) something else

[johnnovak]

b) About page has to be changed to mention 10.5 as not supported

That's the lucky winner! 😁 Like I said, we don't really bother tracking all this for legacy OSes, so thanks for the detective work 😄

Can you append this change to your current PR?

[Torinde]

If someone can make a build(s) per kcgen's instruction above with:
meson setup -Duse_fluidsynth=false -Duse_slirp=false build/release-clang --native-file=.github/meson/native-clang.ini
I can then test in my Virtualbox Vista x86 and x64.