Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
invictius

I thought zdoom was meant to work on windows 95?

Recommended Posts

The oldest that it officially works on right now is Windows XP - but the last official release can still run on Windows 98 AFAIK.

With some massive changes to the header files, the old MinGW project apparently can compile it for 95/98 but you'd have to talk with Blzut3 on how that is pulled off because I don't know.

Share this post


Link to post

Technically, yes, it can compile on Win95, or it should - but I haven't tested that in years. The last build I did that way was in 2013 or so.

Share this post


Link to post

No. The current compiler toolchains no longer allow building for anything pre-XP so it cannot be supported anymore.

It may be possible to get working with MinGW but do not expect any official build being done with that. It's just not worth doing that for the handful of users with such an old OS.

Share this post


Link to post

I must commend the people who place professional care on their hobby software to be so backwards compatible with long-gone OS, instead of playing with the bells and whistles that are typically accessible only on latest OS.

Share this post


Link to post
printz said:

I must commend the people who place professional care on their hobby software to be so backwards compatible with long-gone OS, instead of playing with the bells and whistles that are typically accessible only on latest OS.



Unfortunately that's easier said than done. Just looking at Microsoft Visual Studio, the last version to support pre-XP OSs was VS 2008, if I am not mistaken, and for Win 98 it was 2005, and Win95 had been discontinued even earlier.

So, in order to support Win9x we have to cope with a considerably weaker compiler with less advanced code optimization and outdated language support (i.e. no C++11) - and that doesn't even consider the fact that these old compilers are quite hard to come by these days and do not work that well anymore on modern OSs.

Add to that that some of the third party libraries an application depends on eventually remove support for these old OSs and it becomes even harder.

Yes, it's surely possible to keep things compatible but at some point one really has to weigh the advantages. What is more important? Keeping code compatible at all costs or gradually transition to a more modern version of the language and provide a product that works better on the vast majority of computers as currently in use? All this backwards compatibility is not free, at some point it will cost you on more relevant systems.

So, you can see the things from two points: Either commend those people because they are so considerate to a small minority - or curse them because their software may underwhelm on modern hardware.

I see the same tendency with OpenGL implementations. Some programmers are so concerned with the less than 1% who are still stuck with a pre-GL 2.0 graphics card that they forgo the possibilities modern OpenGL offers.
In GZDoom I set GL 2 as minimum requirement because that gives me all the features needed to keep the compatibility layer small and unintrusive - but with GL 1.x it would have meant compromising the engine to death and making the compatibility layer massively larger. But as things are, my focus is on GL 4.x, not 2.0, because that's what the majority of users has support for.

I see the same with supporting old OSs - and even 32 bit. 32 bit may still be necessary but I consider it a legacy platform. Nearly every computer bought in the last 8 or so years came with a 64 bit OS and the market share of 32 bit will inevitably sink, so it's pointless to put the emphasis there - it should be where things are heading toward in the future, not where they were 10+ years ago.
In GZDoom I have been considering 64 bit as the primary target platform for a year or so, and that's where my optimizations are directed against.

Share this post


Link to post

You can use the original MinGW project to build C++14 for Windows 9x, but support for that project is rapidly vanishing.

The time to let go of Windows 9x was at least 12 years ago. :p

Share this post


Link to post

For what it's worth, a MinGW build just before the assembly code was ripped out works on Windows 98SE with KernelEx. Didn't test with KernelEx disabled, but I suspect a few of the recent commits need just a little tweaking. Still ran decent on a Coppermine Pentium III 1000EB.

Windows 95 support was dropped after 2.2.0 since FMOD Ex doesn't support it and no one noticed it was broken for a long time. I suppose the OpenAL code could theoretically work on 95, but from what I understand an older version of MinGW is required and strictly speaking ZDoom doesn't officially support the OpenAL backend (GZDoom does).

Share this post


Link to post
chungy said:

You can use the original MinGW project to build C++14 for Windows 9x, but support for that project is rapidly vanishing.

The time to let go of Windows 9x was at least 12 years ago. :p


Try 23. XP is 16 years old.

There was only six years or so between the two.

I am setting up a build environment for Windows 98SE. Most custom 9x builds use the 98SE kernel or the Me Kernel now, so retro builds shouldn't have an issue.

Share this post


Link to post
printz said:

I must commend the people who place professional care on their hobby software to be so backwards compatible with long-gone OS

I don't see anything "professional" about doing this at all. Fact is, if you're claiming your product runs on something as old as Windows 95, chances are it: isn't being properly tested; bugs for that system aren't being taken as seriously as more recent systems; is probably buggy and flaky in a bunch of undiscovered ways that haven't been discovered yet.

Here's my experience: a few years ago I made some small "fixes" to Chocolate Doom to get it to run on Win9x. The result is that there are a whole load of subtle bugs that are difficult to reproduce, partly because it's unclear at what level in the stack they're occurring, partly because I just don't have a Win9x system to reproduce them on, partly because I have other more important things to work on.

If "professional" means trying to provide a solid and dependable product, it also means being honest with "customers" about what expectations they can reasonably have for what you're giving them. Nowadays I'd much rather be honest and say that a 20 year old OS isn't supported than put in hacks that make it run in an unreliable and unpredictable way. I've been down the latter path and it just isn't realistic. "Professional" to me means saying "no, I'm not going to give you a shoddy product".

It's worth always bearing in mind that you never develop software in isolation: you're always part of an ecosystem. That means you're dependent on the compiler / toolchains and usually libraries too. I suspect some of the bugs that were reported are SDL bugs, but good luck getting them to care about Win9x. Anyway, Chocolate Doom 3.0 will drop support for Win9x - a necessary move since SDL2 doesn't even run on it any more.

Share this post


Link to post
fraggle said:

Chocolate Doom 3.0 will drop support for Win9x - a necessary move since SDL2 doesn't even run on it any more.



A wise decision. I don't get it either that some people waste endless time trying to get something to run on an obsolete platform, but then do not invest the added time to make it actually WORK on that platform. Getting something to compile is only half the story.

Where it really gets bad is when this compulsive need to get something to run on an obsolete system is actually blocking progress for current systems - this is not so much here but with hardware accelerated rendering it's far more pronounced. It is simply not possible to cater to both the lowest common denominator and cutting edge hardware without compromising the experience on what's in the market today.

To be blunt, if some people flat out refuse to upgrade to a computing platform that is actually supported by currently developed software in general, they really have no right to complain here.

Share this post


Link to post
fraggle said:

Anyway, Chocolate Doom 3.0 will drop support for Win9x - a necessary move since SDL2 doesn't even run on it any more.

Seems that you've already switched to building Chocolate Doom 2.3.0 with mingw-w64, which already doesn't support Windows 9x. 2.3.0 requires Windows XP or newer just to run.

Somebody might make a custom build or use some OS hack like KernelEx to do it anyway, but for all intents and purposes, Choco 2.3.0 dropped Win9x compatiblity :)

Share this post


Link to post

Reminder that Doom itself didn't run on the still-common low-end hardware of 1993. Going from Catacomb 3D to Quake, id Software have abandoned EGA with Wolfenstein 3D, 80286 with Doom, and floppy drives with Quake. How do you think Quake would look like if they had tried to make it fit on five inch floppies and run in EGA on a 286?

Going out of your way to support obsolete hardware and software isn't professional, it's the pinnacle of amateurish: it's something you can only justify if that's your hobby. Perhaps you enjoy trying to get Doom 3 to run on a ZX Spectrum, and then more power to you; but nobody will seriously try to get money out of that work.

Share this post


Link to post
Gez said:

Going out of your way to support obsolete hardware and software isn't professional, it's the pinnacle of amateurish: it's something you can only justify if that's your hobby. Perhaps you enjoy trying to get Doom 3 to run on a ZX Spectrum, and then more power to you; but nobody will seriously try to get money out of that work.

Most of what you say has some basis, but this statement is ridiculous - it's why we're here, duh.

Share this post


Link to post
kb1 said:

Most of what you say has some basis, but this statement is ridiculous - it's why we're here, duh.



Are you *professionally* making software work on old systems?

In reality, most software developed today does not even need to work on XP anymore, unless you happen to work for someone who missed the signs years ago.

My latest project has the requirement "needs to work on Windows 8.1 and 10 only."
Nobody will complain if I don't go out of my way to screw up Win 7, of course, but it clearly means that I'll be free to use Windows features that were introduced after XP.

Share this post


Link to post

I really don't get it.

Windows 9x has been unsupported for - how long now? If I am not mistaken the last Microsoft compiler release which allowed building for Windows 98 is 8 years old by now - or is it even 11, I don't know if it was Visual Studio 2005 or 2008.

The market share of this is - how much? Anywhere you look it's not even being measured anymore.

Are there really people out there which do not have anything newer? I can understand that someone keeps a retro gaming machine with an old OS because the newer ones do not work anymore with old games - but is that really a reason to compile actively developed software for such old hardware? Any of the active source ports will provide a better gaming experience on modern hardware.

To invest any work here seems to be like a waste of time.

The same can be said about trying hard to support old graphics hardware. Reading Graf's posts about OpenGL 1.x, I have to wonder: Are these few users really important enough to diminish the experience on current hardware? Just looking at the Steam hardware survey - which seems to be the only even remotely relevant resource here - shows that more than 70% of all users actually have up to date hardware and 95% have hardware that can handle most modern features without problems.

So by all means, OpenGL these days should mean core profile with vertex buffers, not immediate mode. But how many ports are there: Last time I checked it was only one.

Share this post


Link to post
kb1 said:

Most of what you say has some basis, but this statement is ridiculous - it's why we're here, duh.


1. Most source ports out there are concerned with making the game run on newer systems than the original. Look at what ports were released in the last few years, how many can run in DOS?
2. And besides, how many source port developers are doing that as their professional activity? I'm asking about people being paid for that because it's their job. Answer: unless whoever have done Doom Classic for Doom 3 BFG Edition and the PlayStation Network have been incognito members of Doomworld, none of them.

Share this post


Link to post

I think the problem is that users of new hardware never report that something isn't working, because it mostly works.

It's always the users of old hardware that report "xyz is not working on system with abc." so it will inevitably result in a distorted picture.

But realistically: For GZDoom the reports that "GZDoom is not working on Windows 9x" has been close to background noise, as have the reports "I have a {insert GL1.x hardware here} and GZDoom does not start". For all intents and purposes these issues do not exist, the user base depending on them is so small that trying to appease them will be a huge disservice to the vast majority of users operating on modern up-to-date hardware. I can still support OpenGL 2.0 with the framebuffer extension with a relatively small file (25kb) and a few checks here and there to call this code, so this isn't a big problem. Supporting OpenGL 1.x on the other hand would necessitate a lot more differentiation that goes way, way beyond reasonable.

I do not know how large the OpenGL 2.x user base is - the last download that separated GL 2 and GL 3 was 1/4 for the old version, but nobody knows how many of those actually needed it and how many just downloaded it for testing or out of error or just out of lack of knowledge what their hardware actually could do. However, looking at Steam's hardware survey, DirectX 9, which is mostly equivalent to OpenGL 2.x was less than 2%. (What's interesting is that the number for DirectX 8 is a lot higher, and slowly growing - but here I suspect some measurement error where certain hardware gets misreported, it's not something I take seriously.)

Share this post


Link to post
Graf Zahl said:

I can still support OpenGL 2.0 with the framebuffer extension with a relatively small file (25kb) and a few checks here and there to call this code, so this isn't a big problem.



Out of curiosity: How much immediate mode stuff is GZDoom still using? Searching the source code, I only could find a single glBegin call in RenderFogBoundaryCompat plus another one in the OSX system code.

Share this post


Link to post
Hell Theatre said:

Out of curiosity: How much immediate mode stuff is GZDoom still using? Searching the source code, I only could find a single glBegin call in RenderFogBoundaryCompat plus another one in the OSX system code.



Not much, actually.

What can be done from vertex buffer objects is being rendered from VBOs. The only exception is the global streamin vertex buffer. It still doesn't use classic immediate mode but an old-fashioned client array. This has the advantage that it still can be driven by the same code as the modern core-profile render path, which is the important thing here to allow the renderer to continue to work.

Using a real buffer object here is prohibitive because the map/unmap functionality is too inefficient - most of this old hardware does not have glMapBufferRange, it only has glMapBuffer which is way too costly.

Of course, due to lack of shaders, again because they are too slow, it cannot use
'modern' vertex attributes but has to resort to the old client array types for vertices, texture coordinates etc. From a technical standpoint, GL 2.x could fully run with the shader-based render path, but it isn't done solely for performance reasons. The affected hardware, nearly exclusively some low-end Intel integrated chipsets in older laptops, is far too weak to process a full scene with active shaders.

Share this post


Link to post
Gez said:

2. And besides, how many source port developers are doing that as their professional activity? I'm asking about people being paid for that because it's their job. Answer: unless whoever have done Doom Classic for Doom 3 BFG Edition and the PlayStation Network have been incognito members of Doomworld, none of them.

There's also Quasar and Kaiser that did Strife: Veteran Edition.

Share this post


Link to post

So, how much deliberate Win9x tweaking did they do, aside from maybe using an older compiler that's still capable of creating compatible executables?

Share this post


Link to post

I might have misunderstood the question, or you did. the Doom 3: BFG Edition example seems to imply that Win9x compatibility wasn't part of it.

Anyhow, Strife: VE doesn't run on Win9x. It doesn't even run on XP, just Vista and up.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×