Thousands of apps ported back to Windows 95 twenty-eight years later — .NET Framework port enables backward compatibility for modern software

[Pelican Press 0]

Thousands of apps ported back to Windows 95 twenty-eight years later — .NET Framework port enables backward compatibility for modern software

YouTuber

This is the hidden content, please

• Sign In
• or
• Sign Up

, in his own words, ported “thousands of apps” to Windows 95 by painstakingly porting Windows 98’s most prominent feature, the .NET Framework, back to old 95. The main restriction of Windows 95 compared to 98, after all, is the lack of the .NET Framework— in most other ways, Windows 98 is astonishingly close to its predecessor in design and function. But why did he do this?

The 51-minute video we watched a few times over mostly reveals genuine enthusiasm for that era of hardware and software, as one would imagine if he were willing to make a film about expanding Windows 95 28 years after its release. The original video, embedded below, also has several amusing live-action tangents that set the tone and character, including a few beautifully shot intermissions.

Cursing KernelEx is not working on Windows 95; MattKC has to find out how to get the .NET Framework working correctly. Missing .DLL files abound, but using a dumping tool allows the names of missing files to be identified so the missing DLL can be substituted or ignored. Even after porting all the missing DLL files, .NET still does not yield.

For .NET to work on Windows 95, more registry keys are required than the seconds in the original 51-minute, 53-second video —  the total number of registry keys needed was 5,409.

But even once ported, .NET cant properly JIT (Just In Time) debug itself on Windows 95. The cause seems to be “ndphlpr,” a mysterious legacy Windows driver unused in Windows 98 yet “required” for .NET since .NET crashes without it. MattKC determines that lying to the PC about having ndphlpr might work, but after research reveals that no one knows what it is, he tries to fix it entirely.

This spits a machine code exception error. The WinDebug tool doesn’t support .NET natively (since it isn’t supposed to exist yet), so MattKC still has to deal with some compatibility issues while testing Windows 95 and 98 in parallel. W95 and W98 were run on WinDebug for days to find the problem, and resetting progress was painstaking.

Eventually, MattKC finally found an obstructed block of code that WinDebug could not read. Once deciphered, the code was revealed as:

Join the experts who read Tom’s Hardware for the inside track on enthusiast PC tech news — and have for over 25 years. We’ll send breaking news and in-depth reviews of CPUs, GPUs, AI, maker hardware and more straight to your inbox.

F2 0F 10 44 24 08 F2 05 2C CO

This bugged code pertained to a missing Windows API for some click functions. The exception was that it could not find “NotifyWinEvent in user32.dll,” and SSE2 obfuscated an instruction in the code. Then, .NET had to be patched to remove SSE2 reliance—but this didn’t fix compatibility, just the .NET debugger itself.

After much more debugging for Lego Island, MattKC eventually manually coded a method for the Exception/error message to print to a window instead of happening where he can’t see it. This works and allows for the last bit of DLL compatibility to get ironed out. Following this, Rebuilder for Lego Island and a custom, more modernized screenshot function app now works fine on Windows 95.

And that’s yet another figure for the “Sufficiently-Determined Madman” techies of legend. 

This is the hidden content, please

• Sign In
• or
• Sign Up

#Thousands #apps #ported #Windows #twentyeight #years #.NET #Framework #port #enables #compatibility #modern #software

This is the hidden content, please

• Sign In
• or
• Sign Up