UCyborg

My previous PC had 2 GHz Intel Celeron codenamed Northwood, NetBurst architecture. It wouldn't take even newer web browser to take 5 min to load, but back then two games that I played, Call of Duty 2 and Need for Speed Most Wanted needed about 5 minutes to load their maps. Minimum requirement for 256 MB of RAM was good enough for gameplay, but not for decent load times.

I was wondering if anyone has any experience with legacy applications bundled with BDE Administrator used to configure parameters to connect to a Firebird database. I've come across a problem on some systems where you just can't connect to the database using computer's name, set in Windows System properties, but using localhost (if the database is on the same system) or IP address works just fine. Pinging the problematic system using hostname also works fine, both from the local computer or another computer on the network. Makes no sense.

That color can be set on Glass colors tab under Glass color section.

Dragging opacity slider to the far right in the GUI tool on the Accent tab does the trick. It sets what is outlined in the following .reg file: Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\DWM] "GlassOpacity"=dword:00000064

.NET applications can be a mix of managed and native code and call native APIs.

Bugs inherited from the old Firefox code. Regular user may only employ workarounds, either restart the browser when it takes too much or run the 64-bit build on the 64-bit OS on the hardware with sufficient amounts of spare RAM.

And back then, as far as I've read, Czech Republic handled the situation significantly better than they're handling it now.

Unless he comes here and says something, we can speculate ad-infinitum. For some people, not much has changed with the pandemic.

Missed some things: Installer has an OS version check, it runs only on Win2000+, easiest to bypass with KernelEx. Cinematics just crash the game. I tried the game on WinME, they start there, but don't play to the end, they play for several seconds, then they're skipped.

The default values of SizeOfStackReserve and SizeOfStackCommit when compiling executables are 1048576 and 4096 bytes, at least with MS tools. Devs changed the first one to 65536. Game seems to work fine when restoring the default values. When I had both at 65536, it crashed when a handful of extra map files were present. Having both at the same value just avoids overhead of committing reserved memory pages, also noticeable when the map is loaded for the first time. Though it's one-time thing. In other unrelated cases of memory management committing everything right may needlessly consume memory. In this case, we're talking about 1 MB range. That sounds silly when you think about it, I guess just more stack space is needed when running on Win9x compared to WinNT. It's possible to make the otherwise hidden console window visible and see the console output there, so full console output can be seen in case when it isn't dumped to log file. Might write the how-to at the later point. It would be really easy if Process Hacker could be used.

I tested on a VMware virtual machine. Windows 98 was patched with AutoPatcher. I got in the menus right away after copying SwiftShader 2.01's d3d9.dll in the game folder since there's no 3D support in the virtual machine on Windows 98. I was unable to load any map at this point, it crashed, the error message mentioned stack fault. To be even able to see the error message, I had to force the game to run in windowed mode, I could do it by setting appropriate option SwiftShader.ini, otherwise, the game appeared to have just closed. I ended up modifying the executable file by changing the value of SizeOfStackCommit in IMAGE_OPTIONAL_HEADER32 structure from 4096 to 65536. It's pretty easy with OllyDbg, open the executable, press Alt+M, at the top, there should be an entry that says "PE header" under Contains column and "CoD2SP_s" under Owner column, double-click it then in the window that opens, find SizeOfStackCommit, double-click it, type 65536 in (Un)signed field, confirm, right-click on SizeOfStackCommit->Edit->Copy to executable, OK the message prompt, right-click anywhere in the window that opens and click Save file... and save it under the different name. NoCD patched executable is probably needed for this as copy protected executables are harder to tamper with. Multiplayer executable (CoD2MP_s.exe) doesn't have any copy protection out-of-the-box. So CoD2 doesn't seem to have any mandatory reliance on any special APIs, so the OP's issue must be related to DirectX/drivers, given the error message. And my experience hints that Windows 98 may not actually be able to grow program's stack on its own when the need arises. It's possible to enable log file by adding +set logfile 1 at the end of the Target field on the Shortcut tab in the game shortcut's properties. The file console.log will appear in the main subfolder, though it's possible that it may not actually log anything if it's forced to bail out too early.

I didn't play MechWarrior 2: 31st Century Combat, but I played Interstate '76, which is built on the modified MW2 engine. Had no idea how to get it running on XP years ago, so ran it in Microsoft VirtualPC 2004 on Windows 98 then. Had better results on the current PC, at least on Windows 7 and newer, it still crashed randomly on XP. Of course, external frame rate limiter was mandatory to work around physics problems. Reading tons of advice on forums about using CPU cycle burning slowdown utilities made me cringe. Eventually got around patching it and solved or worked around most of critical issues. It runs even on Windows NT 4.0 now, which was never supported and never worked. Reason for all its problems? None other than sloppy coding. There are significantly worse examples of crappy coding out there. The Windows version of The Need for Speed: Special Edition is an absolute joke.

I guess the official Facebook Messenger app can be added to the list. Even though it's an electron app, which should work on Windows 7, it hangs on startup and no UI is shown.

Using DOSBox for anything other than DOS games is at your own risk. DOSBox IS NOT SUITED TO RUN YOUR NON-GAMING DOS APPLICATION

I don't have an answer, but you might want to try an alternative that works on Windows 7, such as Caprine. Few years ago, there was Messenger for Desktop. It seems it was taken over by some corporation (https://messengerfordesktop.com/). If you download version 2 from GitHub, it will offer to update to the version that web installer from mentioned website downloads.

That mess of the start menu also doesn't show Startup folder.

Apparently XP has limited support for SHA-2 with only supported algorithm being RSA. The mentioned certificate uses ECDSA. Probably, I haven't come across a POSReady 2009 update that would increase the version of crypt32.dll from 5.131.2600.6459.

It does contain crypt32.dll, you can peek inside the installer with 7-Zip. http://download.windowsupdate.com/d/msdownload/update/software/secu/2015/06/windowsserver2003-kb3072630-x64-enu_e4e5d7c372ddb9474fba3947d45a62cad7051a35.exe

I noticed my XP x64 doesn't handle certain certificates, eg.: Symantec Class 1 Public Primary Certification Authority - G4 - This certificate has an nonvalid digital signature. I just installed an update KB3072630, which installs supposedly the latest crypt32.dll version 5.131.3790.5668, but the issue remains. Does the certificate use unsupported signature algorithm and this is just how it is on XP or is there a solution?

https://github.com/mohic/Relocation-Section-Editor

It won't. You already have ISRG Root X1 certificate if you keep certificates up-to-date with the updater here. Firefox based browsers are the special case that use their own certificate store.

What about AutoCopy 2? This one gives file not found error.

I've only read about PotPlayer's popup ads, but never actually seen one, nor the white box.

I suggest verifying if hardware is actually functioning properly. Run Prime95's stress test for several hours. Scroll down to find XP compatible version. Also, if CPU isn't fed sufficient voltage, it can't be expected to operate 100% properly.

Sounds like some script failing to execute properly due to lack of whatever newer JS features are required.