Doom95 and PrBoom not running correctly on Windows 95

[com_tam_fan]

So Doom 95 has been having grey-blob-in-the-corner-of-the-screen syndrome, much like many other people before me. I've added both the mouse fix and the recording fix, could those be the source of the problem?

Another source port that I tried to run was PrBoom. Whenever I try to run it, it says, "PrBoom.EXE is linked to the missing export KERNEL32.DDL:SetProcessAffinityMask".

Are there any alternatives that I could use? I'm currently running these on a Toshiba Satellite Pro 430CDL laptop, running Windows 95.

...As a side note, I did want to mention that vanilla works fine for me, but I'd like to be able to use WASD movement+ horizontal mouse control.

[entryway]

did you try prboom-plus?

[Grazza]

com_tam_fan said:

As a side note, I did want to mention that vanilla works fine for me, but I'd like to be able to use WASD movement+ horizontal mouse control.

That is available in vanilla. Run SETUP.EXE and choose the relevant options. NOVERT can be used if you want to remove forward/backward mouse movement.

[Quasar]

This is caused by the port not supporting Win9x/ME. In order to use SetProcessAffinityMask you need a version of Windows >= NT4, as the 9x kernel does not support multi-processor systems.

Very few ports support 9x because no modern compilers target it. Not even GCC is available in builds beyond 3.x except in rare cases where you'll find bugs in GCC's CPUID code cause invalid opcodes to be executed anyway, making the resulting binaries useless even if they aren't missing imports or making unsupported system calls.

ConSiGno does have a working build of Eternity for Windows 95. He managed to build it on an older version of MinGW IIRC, which just barely supports enough C++ to keep up with our current state of development. Maybe he could manage the same for PrBoom. He had to tweak the build files to disable any stuff not supported, such as the aforementioned affinity mask call.

[Gez]

ZDoom 2.4.1 was reported to work on Win95, but without sound since FMOD Ex doesn't support this OS. More recent builds of ZDoom require Win98 at the very least; but I'm not sure when support for Win95 broke.

[wesleyjohnson]

Could try DoomLegacy 1.42 on SourceForge as that is old enough, but I have fixed so many bugs since then.

The DoomLegacy 1.44 Alpha4 is available on the DoomLegacy home page.
I have compiled that on Windows 98 with MinGW.
It is C code with no strange requirements.
Compiling it for SDL is preferred as the ports for Win and Dos interfaces have not been tested for years and will require some debugging. May require Allegro depending on your choice.

[com_tam_fan]

entryway said:

did you try prboom-plus?

I tried to use it, and sadly it didn't work either. ("WS2_32.DLL not found")

Grazza said:

That is available in vanilla. Run SETUP.EXE and choose the relevant options. NOVERT can be used if you want to remove forward/backward mouse movement.

I did this and found out that it worked well. However I did have trouble figuring out how to use NOVERT with it; Is there a way to only have it activate when Doom is running?

Quasar said:

This is caused by the port not supporting Win9x/ME. In order to use SetProcessAffinityMask you need a version of Windows >= NT4, as the 9x kernel does not support multi-processor systems.

Very few ports support 9x because no modern compilers target it. Not even GCC is available in builds beyond 3.x except in rare cases where you'll find bugs in GCC's CPUID code cause invalid opcodes to be executed anyway, making the resulting binaries useless even if they aren't missing imports or making unsupported system calls.

ConSiGno does have a working build of Eternity for Windows 95. He managed to build it on an older version of MinGW IIRC, which just barely supports enough C++ to keep up with our current state of development. Maybe he could manage the same for PrBoom. He had to tweak the build files to disable any stuff not supported, such as the aforementioned affinity mask call.

I wasn't able to find the build you mentioned. Do you have a link to it?

wesleyjohnson said:

Could try DoomLegacy 1.42 on SourceForge as that is old enough, but I have fixed so many bugs since then.

The DoomLegacy 1.44 Alpha4 is available on the DoomLegacy home page.
I have compiled that on Windows 98 with MinGW.
It is C code with no strange requirements.
Compiling it for SDL is preferred as the ports for Win and Dos interfaces have not been tested for years and will require some debugging. May require Allegro depending on your choice.

I tried using Legacy 1.42, but it says that DINPUT.DDL is missing when I try to run it.

[entryway]

com_tam_fan said:

I tried to use it, and sadly it didn't work either. ("WS2_32.DLL not found")

That's because of Fluidsynth MIDI player

Try this:
http://prboom-plus.sf.net/prboom-plus-2.5.1.4.test-win95.zip

[wesleyjohnson]

DINPUT.DLL is a Microsoft DirectX file.
A valid DirectX should not be missing this file. The indications from a web search are that the DirectX installation is broken and should be reinstalled properly.
See the following link
http://pcsupport.about.com/od/findbyerrormessage/a/dinput-dll-not-found-missing-error.htm

It may be that Win95 did not have DirectX, and the port of DoomLegacy
downloaded was expecting DirectX.
You probably would have to compile DoomLegacy yourself.
We do not have an explicit Win95 port, the best fit would be the DOS port. I think the Win port is DirectX.

It would really help to know what game libraries are installed on this machine as every port required something.

Win::
-- SDL ?? and which version
-- DirectX ?? and which version
-- Allegro ??
-- FMOD ??
Dos::
-- Allegro ??
-- FMOD

The latest DoomLegacy 1.44 Alpha4 still has a DOS port, but no one has compiled it since 1990's. It requires Allegro which I did not have. (From my memory... It could be FMOD, or could even be both ?? ).

If you cannot get FMOD or Allegro then not much is going to work.
Almost every doom port used one of those. Anyone know of any exceptions.

[Quasar]

Win95 *has* DirectX, but it doesn't *ship* with it. DOOM 95 is all about DirectX, and was in fact developed as a demonstration of its power to bring gaming out of the "DOS age." You gotta find the installer though.

As for Win95 EE, you'll need to get in contact with user CSonicGo (aka ConSiGno, since SEGA gave Sonic blue eyes, or something...). I don't have an actual copy of it myself.

[Csonicgo]

I'll happily provide a copy. watch this space.

Okay.

EternityMINGW32.zip (4.1 MB)
https://mega.co.nz/#!RoIGnJRL!dGQOTlAgYtSQxCKcQ4X9KTgM4TJX-bIvyiZotUFkHb0

Here is the file. Included are the EXE for Windows 95 + the related changed sources. the other sources are in the SVN.

DirectX is needed. OpenGL is optional.

[myk]

com_tam_fan said:
So Doom 95 has been having grey-blob-in-the-corner-of-the-screen syndrome, much like many other people before me.

Have you tried launching it from the command line with -emulate? This parameter disables graphics functions that cause issues on many systems.

I did this and found out that it worked well. However I did have trouble figuring out how to use NOVERT with it; Is there a way to only have it activate when Doom is running?

Novert is ignored by most other programs on DOS. You could add novert to a shortcut with the "batch" option in properties. Personally, I open a DOS window that launches a batch file first which enables novert.

[Ramon_Demestre]

@com_tam_fan or any Win95 user

For Doom 95 I suggest David Kay's dmousexp.zip patch
I have a copy here :
ftp://gillibert.homelinux.net/BINNT/dmousexp.zip

For PrBoom 2.5.0, I made a fixed version for Win 95:
ftp://gillibert.homelinux.net/BINNT/PrBoom250_Fixed.zip

The latest PrBoom+ working I have is a cracked 2.5.0.7-test:
ftp://gillibert.homelinux.net/BINNT/PrBoom-plus-2.5.0.7t.fixed.zip

Eternity (latest version v3.40.37 "Gungnir") works nice and is a very good port.

ZDoom 2.5.0 Is the latest I have working but without sounds.

ZDoom 2.7.0 Works with small cracks, however you need to edit config witd notepad to change display resolution. and no sounds.
ftp://gillibert.homelinux.net/BINNT/ZDoom270_Fixed.zip

Maybe I will try more later.

ZDoom 2.2.0 Works nice with sounds, recommended.

I hope It helps

=============================
@entryway

functions not present on Win95 and used in PrBoom test build.

IN portmidi.dll
-- KERNEL32.DLL:IsDebuggerPresent
-- KERNEL32.DLL:InitializeCriticalSectionAndSpinCount
do you realy need portmidi.dll? Does not SDL handles this allready?

IN PrBoom-plus.exe
-- KERNEL32.DLL:IsDebuggerPresent

IN SDL_net.dll
iphlpapi.dll Is imported and not present by default in Win95.

However there are a lot of Win95 compatible SDL_net.dll builds.

EDIT:
Be shure you have set_process_afinity_mask 0 on prboom config.
I put some newer SDL* instead of old ones becuse they just fixes things, olders are named "Old SDL*.dll" if you need them

for PrBoom in config you should take a look at
sdl_video_driver "x"
try x = directx, windib, opengl
There is also an environement var that affects all SDL programs.

If you have problems with directx try:
Start->Run or (Win+R)
type DXDIAG
A config box should apear. On the Display tab you should clic near "DirectDraw accelertion" the [Disable] button.
Do not close dxdiag because you probably will want to enable it again after playing, unless you use no others directx programs.

I beleve it has the same effect than "-emulate" for Doom95

Hope I am clear.

[Quasar]

IsDebuggerPresent is dragged in by Microsoft CRT0 if any program OR library is built with Visual Studio 2005 or later. There is an "IsDebuggerPresent95" mentioned in the executables which was apparently supposed to fill in for it (and very well may have under 2003 and earlier), but it is either

• Not working as it is meant to work or
  
• Intentionally nerfed by Microsoft to kill Win95 compatibility deliberately.
  

Eternity for example never calls or references this function anywhere but you will find that an EXE for it compiled by anything VC2005 or later has this dependency. In fact, even the CRT0 does not have to call it, as you can remove it from the DLL imports table by overwriting it with an innocuous function, and nothing bad seems to happen as a result.

[Blzut3]

Ramon_Demestre said:

ZDoom 2.2.0 Works nice with sounds, recommended.

I'm going to guess sound broke with the switch to FMOD Ex. Is it broken in 2.3.0? If that is indeed the case, the last revision to fully support Windows 95 would be r788. If you can still find a copy of the fmod 3.75 API.

[Ramon_Demestre]

Quasar said:

IsDebuggerPresent is dragged in by Microsoft CRT0 if any program OR library is built with Visual Studio 2005 or later. There is an "IsDebuggerPresent95" mentioned in the executables which was apparently supposed to fill in for it (and very well may have under 2003 and earlier), but it is either

• Not working as it is meant to work or
  
• Intentionally nerfed by Microsoft to kill Win95 compatibility deliberately.
  

I am aware of this, I am used to put FreeConsole instead of IsDebuggerPresent (takes no parameters and returns BOOL. FreeConsole will fail if gui program and I use no Debugger.)
I do beleve like you MS Intentionally did this because Win95 end support, and making programs not working at all is the best solution to really drop support.

I could fix somme exe this way (including MSV*80.DLLs). Somme time when I try to fix this way the programm just crashes at startup (not working at all) on w95 (Not w98+), including newers PrBoom+

@Blzut3

Yes, this is because newer Fmodex uses SetWaitableTimer and CreateWaitableTimer I tryed to put the older version of Fmodex but there are somme obscure importations errors (functions names are really stupid).

[Graf Zahl]

Ramon_Demestre said:

I could fix somme exe this way (including MSV*80.DLLs). Somme time when I try to fix this way the programm just crashes at startup (not working at all) on w95 (Not w98+), including newers PrBoom+

Aren't you a bit paranoid? Back in 2005 Win95's market share was already close to non-existent. They simply didn't care anymore about it.

You wouldn't think that it may - possibly - use this function to check (gasp!) if a debugger is present and if so, enable some special debugging help settings?

Seriously, what do you expect when you use an ancient and obsolete operating system? Does anyone with something newer have to suffer just because you refuse to upgrade. Nobody cares about an OS that's only used by a handful of people - today much of the same applies to Win98 and WinME.

[Blzut3]

Ramon_Demestre said:

Yes, this is because newer Fmodex uses SetWaitableTimer and CreateWaitableTimer I tryed to put the older version of Fmodex but there are somme obscure importations errors (functions names are really stupid).

What version of Fmod Ex works on Windows 95? I may be able to identify if any version of ZDoom was able to work with it.

[Graf Zahl]

Blzut3 said:

What version of Fmod Ex works on Windows 95? I may be able to identify if any version of ZDoom was able to work with it.

None, if I'm not mistaken. I think they skipped these old versions with the change from 3.75 to 4.x.

[Ramon_Demestre]

Graf Zahl said:

Aren't you a bit paranoid? Back in 2005 Win95's market share was already close to non-existent. They simply didn't care anymore about it.

You wouldn't think that it may - possibly - use this function to check (gasp!) if a debugger is present and if so, enable some special debugging help settings?

Seriously, what do you expect when you use an ancient and obsolete operating system? Does anyone with something newer have to suffer just because you refuse to upgrade. Nobody cares about an OS that's only used by a handful of people - today much of the same applies to Win98 and WinME.

No, I am not paranoid, I just thought as you said before.
But with VS 2012 MS did not support at first WinXP as a target platform (fixed now) and this means they decided to really drop XP, because you cannot just "Ignore" WinXP if you are making a compiler. After many complains, they decided to change this.
You are right, you just need to stop testing to be incompatible, no need to purposely do it.

I know I am using a very out-dated system however.
1) I use mainly Win98
2) This is so freaking cool to play old games and specially doom.
3) I realy think the real quantity of 9x machines is underestimated because 90% of 9x machines I saw were not connected to network.
4) For old hardware 9x is good and old hardware is necessary sometime for
-- Acquisition PC (eg old ISA card that are not uncommon sometime for a 20y old extremly expensive setup)
-- Old software like Doom.
Win 9x is perfect because it offers you a real DOS execution for the old crappy dos drivers you need and a cool Win32 api alowing a ton of modern programms to run.

I daily use for my work an ellipsometry setup at my labs working with a DOS acquisition program on a PC running Win98.

For Doom, you may argue I should use old DOS ports, however lot of cool wads needs ZDoom/EE/PrBoom+, why should not I use them?

I do not want to disturb anybody that does not care about Win9x
I am a Doomer so I am a retro old legacy stupid dude.
Thanks for reading.

[Quasar]

Graf Zahl said:

Aren't you a bit paranoid?

This, regarding Microsoft? A company ever in favor of reducing consumer rights, deploying restrictive DRM, monitoring technologies, and planned/forced obsolescence schemes, a company that wants to put surveillance equipment in everyone's living rooms? A company that has killed off whole services in the past and told everybody using them to get bent without recourse? The company trying (however unsuccessfully) to dictate that PC hardware be locked down to its own OS? A company that lobbies for every single law that would make it illegal to modify your own hardware and software or increase punishment for minor computing-related offenses, up to and including prison terms?

Paranoia isn't paranoia when it's actually happening.

Windows XP Home Edition has a curious little problem that I wonder if you're aware of. If you install Microsoft Security Essentials on it, it will require and enable Microsoft Update (not the light-weight friendly Windows Update that XP ships with). If you disable Microsoft Update, MSSE will silently force it back on.

The problem? Microsoft Update uses 90% CPU and leaks memory at an astonishing rate of over 100 MB per minute. This will grind any XP Home Edition machine to a halt.

The interesting thing? Doesn't happen on XP Pro. Same or even worse configuration of machine running XP Pro, zero effect. XP Home? Bogged down. Given what I know about the differences between XP Pro and XP Home Edition, you would have to deliberately cause this to happen.

All threads opened about it on the MS support forums have either been completely ignored, or trolled by loud shouting corporate shills posting useless "IT WORKS FOR ME" and "THERE IS NO SUCH PROBLEM". Official response is "Upgrade to Windows Vista or later!".

[jval]

Quasar said:
"Upgrade to Windows Vista or later!". [/B]

Upgrade to Linux LOL!

[Graf Zahl]

Quasar said:

Official response is "Upgrade to Windows Vista or later!".

Question: Is XP even an officially supported platform?
If no, no need to complain. It wasn't designed for it, it won't run with it.

Concerning Paranoia, Microsoft has indeed become far, far worse in recent years, the big problems with their products hadn't happened yet in 2005. Windows was still mostly ok back then. Feel free to be paranoid, there's certainly enough reason that Microsoft is doing some evil stuff these days, that still doesn't mean that everything they do is evil.

As for IsDebuggerPresent, it's indeed used for checking if a process is debugged. One place where it's used is the code that checks stack integrity.

[Quasar]

Graf Zahl said:

Question: Is XP even an officially supported platform?
If no, no need to complain. It wasn't designed for it, it won't run with it.

Concerning Paranoia, Microsoft has indeed become far, far worse in recent years, the big problems with their products hadn't happened yet in 2005. Windows was still mostly ok back then. Feel free to be paranoid, there's certainly enough reason that Microsoft is doing some evil stuff these days, that still doesn't mean that everything they do is evil.

As for IsDebuggerPresent, it's indeed used for checking if a process is debugged. One place where it's used is the code that checks stack integrity.

Until next April, yes. There's an XP version of MSSE and Microsoft Update. You didn't think I tried to install Vista software on XP did you?

If you have Microsoft Update already installed on XP, it will hassle you about installing everything it can access, including MSSE. Microsoft pushes this stuff onto your desktop but doesn't take any responsibility for the piss poor performance it's causing. Think about it from their POV - the more people frustrated with their XP computers' suddenly unusable behavior, the better, because in MS's eyes that's potential customers looking for a new Windows 8 computer.

They have the means, and they have the motive. The evidence, IMO, is the fact that this behavior specifically targets XP Home Edition. MS knew better than to fuck around with the corporate market, virtually none of whom use MSSE anyway but some enterprise AV solution like we do at my job.

I know what IsDebuggerPresent does (the name is self-descriptive) but it's also a very stupid reason for an EXE to not be able to run on Windows 95 too. Especially when there's a symbol obviously linked into the EXE which is supposed to be taking its place, but is not, because Microsoft disabled it from doing so.

[Maes]

Quasar said:

The problem? Microsoft Update uses 90% CPU and leaks memory at an astonishing rate of over 100 MB per minute. This will grind any XP Home Edition machine to a halt.

BUT QUASAR, L0L, THAT'S OBVIOUSLY BECAUSE TECHNOLOGY ADVANCES RAPIDLY AND YOU'RE COMPUTER DOESN'T SUPPORT ALL OF THE NEW AND ENHANCED FEATURES OF THE LATEST WEB 2.0 SOFTWARE REQUIRES!!! YOU SHOULD UPGRDAE TO A BETTER OS LIKE WINDOZE VISTAS L0L

Spoiler

Between us, I'd just keep using that OEM self-activating XP SP3 CD I have from 2008 forever and ever, at least until they ban the i386 architecture. Problem solved.

[Graf Zahl]

I really don't know what's more idiotic - Microsoft's pathetic attempts to drive users away from their obsolete OS versions or the users sticking to their outdated software like superglue and still expecting that everything works without hiccups.

[Maes]

Since Microsoft created a near-unbreakable rule that everything from DOS 1.0 to Windows 8 should be at least somewhat backwards compatible, "sticking like superglue" to decade-old software doesn't sound so extreme.

OTOH, if MS was known to adopt the Apple route where you can't expect ANY forward compatibility from a given Mac OS revision, and backwards compatibility is very limited, too (the fact that Apple doesn't stick to a hardware architecture for too long is also a factor), then maybe I could understand your surprise.

In the end, it's the year-old debate about "that bloody binary" ;-)

The DOS/Windows .COM and .EXE binaries are eternal. The Apple/Unix/Sun/whatever binaries are not, simple as that.

[Graf Zahl]

That's not the problem here.

This discussion is about the opposite: Trying to run recent software on an old OS and still expecting it to work.

Most Win95 software I still have after 15+ years still works - and most that doesn't work anymore used hacks to accomplish things (case in point: the mouse driver issue with Doom95.) For example, I got a CD with a game lying here which I wrote in 1995 for Win32s(!) Still works flawlessly - but that's because I didn't do that hacky stuff.


I think this can easily be generalized. There's so much badly written software out there, it's amazing. That some people absolutely have to use the worst way to do a thing is well known. That this type of software eventually breaks is inevitable.

[Quasar]

Thing is it's not hard to write software that WILL still work, on 95, right now, so long as you avoid APIs it didn't support.

Eternity itself has absolutely no requirements that 95 can't meet. We hide system specific stuff behind conditionals and behind hardware abstraction layers. Together, it's well more than enough to build a largely complete engine on 95 (you lose, basically, registry scanning for IWADs, XInput support, and some Win32-specific tweaks that don't apply to 95 anyway). You're just forced to use MinGW to do it, since Microsoft stopped supporting anything earlier than XP.

[Blzut3]

It's about to get a little harder though. SDL 2.0 has no intentions to support Windows 9x. From the sound of it, the developers aren't interested in pulling fixes for it either due to the extensive use of unicode. (Outside of maybe whatever minor tweaks need to be done to support an unofficially updated Windows 98.)