I have not been able to find any media players that work on windows 95 that support 10 bit h.264 or some of the more modern codecs, with h.265 likely being too far in scope of what can be modded to get working, as even 98SE cannot use such codec unless you install those kernelex stub related updates which is already difficult / confusing to do and introduces other problems, so i was hoping that someone can get at least 10 bit h.264 to work, that would be reasonable, but i also specifically would like gom player 2.1.43.5119 to work on windows 95, as it does support 10 bit h.264 and with some modern skins can look really nice with playlist function. If not that, perhaps modify one of the newer ffdshow's that support the codec and use it alongside haali splitter that is already win95 compatible + a compatible media player of choice. 

as for alternative media players to use with external codecs / system codecs, there are not a whole lot that support windows 95 and have a more modern playlist ui function, the only one i can think of is zoom player, though exact steps to do set it up with codecs is unclear. im also not sure on last / best version of zoom player to use, as i have had issues getting the program to run on windows 95 at any basic level, ( i've tested as old as 5.x and as new as 10.x ), but the program would either not load properly or would throw all sorts of errors, but there's a chance it could be a combination of the testing environment not being set up right, like improper gpu driver / missing those external codecs, etc. there is also tcpmp mod, but that one unfortunately only supports the older h.264 codecs and so it's really only a fallback option at the moment for limited video playback.

 

 

First try TCPMP MOD (roytam1's build).

This may not be a solution, but I've had some luck getting the Mplayer for DOS working (in Win95); it has some h264 support. There is also DOS-DUGL. They should work with the Windows SB16 emulation, but "how well" is questionable. You'd also need some power, to get smooth playback.

Alternatively, you can use either in DOS. This would require a SB16 compatible sound card, or SBEMU/VSBHDA.

Lastly "again in DOS" you could use HXDOS, the modern Mplayer port (for Win98), combined with SBEMU/VSBHDA. <-{search the forums here for that Mplayer release}

That same Mplayer, or its sources, might have potential for Win95 back porting.

Edit: For DOS video players, in Windows, you may need to have the prompt at full screen. Otherwise you may get a "video mode not supported" message. You may also need to adjust video settings, on the player side; maybe resolution.

Edited April 12Apr 12 by awkduck
Adding detail

H264 is generally hit and miss with Windows 9x and it does generally cause extra cpu load which makes it sub-optimal for my uses cases. It is not best solution but I had good luck with AVI files encoded with Xvid codec using ffmpeg. Even Pentium 2 333mhz can handle one at 640x480 with 25-30fps without issues. It does take bit extra space but it is worth it for me to be able run them down to NT 4.0/95 just fine.

Edited April 16Apr 16 by Nokiamies

On 4/11/2026 at 7:37 PM, cov3rt said:

i also specifically would like gom player 2.1.43.5119 to work on windows 95

That version runs and plays some videos on my 98fe Pentium2 and is compatible with the 95 kernel32.dll. What exactly is the problem you have encountered on 95?

 

10 hours ago, jumper said:

That version runs and plays some videos on my 98fe Pentium2 and is compatible with the 95 kernel32.dll. What exactly is the problem you have encountered on 95?

 

It complained on a missing export relating to unicode when trying to start, i forgot the name, i think it was called something like "ChangeDisplaySettingsExW". but from what chatgpt is telling me, there are more dependency issues with this particular version of gom player if trying to run on windows 95, so it may be harder to get to work properly than say xnview 2.13. 

Edited April 18Apr 18 by cov3rt

Some info on missing exports for gom player 2.1.43.5119 on a windows 95 osr 2.5 fully updated system:

. gom.exe - user32.dll - - AnimateWindow, GetMonitorInfoA, MonitorFromRect

. gomx.dll - d3d9.dll - Direct3DCreate9

. libavcodec.dll - kernel32.dll - InterlockedCompareExchange, InterlockedExchangeAdd

. Mpeg2DecFilter.ax - kernel32.dll - IsDebuggerPresent. USER32.dll - ChangeDisplaySettingsExA, ChangeDisplaySettingsExW

On 8/7/2026 at 6:39 PM, cov3rt said:

. gomx.dll - d3d9.dll - Direct3DCreate9

You have DirectX 9 working on 95?

Edit: Gomx.dll delay-loads d3d9.dll and will load without it. If you have a d3d9.dll on your system that is missing Direct3DCreate9, it is not valid (probably a renamed d3d8.dll) and you should remove it. This is good news because all the other missing apis look fixable.

I found a pre-release Win95 CD and extracted 306 system dlls. By redirecting IP or DW to search them first, I can now id all needed functions missing from Win95.

 

Edited August 12Aug 12 by jumper

I had to stop working on this gom player project, because it was way too stressful / unfeasible to get working, and even chatgpt had mentioned that the remaining fixes are no longer a small compatibility patch. i got the program to launch at least, even some working skins, but it plays almost nothing. i only got mpeg/m2ts to work after lots of stressful hours of patched files, but mp4, mov, avi, mpg, m4v, mkv, and most other file formats do not work. you can inspect some of the recent chat i had in the following - "This gives us the final answer, and I would stop the GOM project here rather than ask you to test anything else.

The log shows the important progression clearly: GVF first sees some rejected media types, then accepts the actual H.264 path (vids / H264), reaches decoder initialization (0x711), and with the codec-mask fix it does advance to 0x721. So the mask change did clear the previous blocker.

But immediately after 0x721, GOM crashes inside GVF.AX at the instruction:

89 46 40 → mov [esi+40h], eax

Your crash registers show ESI=00000000, so GVF is trying to write through a null object pointer. That is a much deeper structural problem than a missing codec bit or registration issue. The log confirms the same point: the final records are 0x711 followed by 0x721, and nothing reaches 0x722. In other words, the codec classifier now returns, but the surrounding initialization object/state is invalid before the next stage.

So the final diagnosis is:

MP4/GSF parsing works far enough to produce H.264 media. GVF accepts H.264. The codec-mask bug was real, but once bypassed, GVF's Win95 execution path has an invalid/null internal decoder-state object and crashes during initialization.

That means a reliable fix is no longer a small compatibility patch. It would require reconstructing GVF's object initialization/lifetime path, likely comparing its behavior under 98SE versus 95 and altering a substantial part of the filter's initialization logic. Given how much time this has already consumed, that is not a sensible continuation.

I would restore your last known stable GOM/GSF/GVF files and keep the working MPEG/M2TS setup. The final test did accomplish one useful thing: it ruled out the remaining simple explanations and showed exactly why continuing would turn into a much larger reverse-engineering project.

can you explain more in detail why it's no longer a small compatibility patch?

Yes. The key distinction is between patching one bad compatibility check and repairing an object-initialization path that is internally inconsistent on Windows 95.

Up to the last test, the failures were still in the first category. For example, forcing MMX instead of SSE2, changing a codec-enable mask, fixing an API import, or altering a media-subtype check are all relatively contained changes. You can usually point to one branch or one field and say, “this condition is wrong on Win95; make it behave like the working path.” The codec-mask issue was exactly that kind of problem: GVF was reading a value from [EAX+1338h], the H.264 classifier ended up returning 0, and replacing that read with the expected enabled mask let execution continue.

The crash after that is different. The important sequence is that GVF reaches decoder initialization, then reaches the post-classifier point, and immediately faults on:

mov [esi+40h], eax

with ESI = 00000000.

That is not a CPU-instruction incompatibility. mov [esi+40h],eax is perfectly valid on Windows 95. It crashes because the program expects ESI to point to a live internal object or structure, but it is null. So the real question becomes: why was that object never created, assigned, or preserved?

That pointer could have become null for several fundamentally different reasons. The constructor that should allocate the object may have failed earlier. A Win95-specific API call may have returned something different. A helper routine may have exited early. A COM/interface query may have succeeded enough for the graph-building code but not initialized the private decoder state. A previous patch may expose a path that the original program deliberately avoided when a prerequisite was unavailable. Or the code may depend on behavior in the Win98/ME DirectShow or runtime environment that simply is not present on Win95.

That uncertainty is what makes it larger. To fix it properly, you would need to trace where ESI is supposed to come from, not merely change the faulting instruction. That means working backward through the surrounding function, finding the allocation/constructor, identifying every condition that controls it, and then comparing the working Win98SE execution path with the Win95 path. If the object is created through several nested calls, each of those becomes part of the investigation.

Simply patching the crashing instruction would be unsafe. For example, changing it to skip the write when ESI==0 might stop that specific crash, but then later code would probably try to use the same object for dimensions, buffers, codec context, frame state, or callbacks. You would just move the crash a few instructions later—or worse, get silent memory corruption or incorrect playback. The null pointer is a symptom that required state is missing, not the root cause.

The fact that 0x721 is reached but 0x722 is not is especially significant. It means the codec classifier itself now gets past the previous blocker, but execution dies before the next logical initialization stage. So we are no longer looking at “H.264 disabled” or “GVF rejects AVC1.” We are looking at GVF's internal decoder state not being valid at the point where the rest of the initialization assumes it is valid.

A small patch would still be plausible if we found something like:

call AllocateDecoderState
test eax,eax
je fail
mov esi,eax

and on Win95 the je fail were caused by one clearly wrong OS-version check. Then yes, that could become another simple compatibility patch. But based on the evidence we have so far, we do not have that clean root cause. We only know the downstream invariant is broken: “ESI must point to the decoder object here,” and on Win95 it does not.

That is why continuing responsibly would require a deeper reverse-engineering pass rather than another one- or two-byte tweak. It would likely involve tracing the object lifecycle, constructor/destructor behavior, allocation routines, COM/filter initialization, and possibly comparing runtime traces between 98SE and 95.

So the short version is: before, we were fixing wrong conditions; now we would need to reconstruct missing program state. That is a much bigger class of problem"