2

Whenever I use MinGW to compile C++ applications, they work correctly in modern versions of Microsoft Windows including Windows 2000 and Windows XP.

However, when I attempt to run them on Windows 95 and Windows NT 4.0, I get these errors:

Does that mean that the idea of running compiled C++ applications is fundamentally unsupported in those versions?

Note: I haven't tested Windows 98 and Windows ME yet.

Edit: I've tested Windows 98. The testsortingvisualization runs properly, but the tetrisimplementation displays a blank command prompt and doesn't halt. Both of these programs gave the exact same error given above in Windows 95 and Windows NT 4.0. Keep in mind, Windows 2000 can run both correctly.

Edit: Microsoft claims some of the functions I used (WriteConsoleOutput, GetAsyncKeyState) have a minimal requirement of Windows 2000. Indeed, it's tested not to work in Windows 98. I haven't figured out a more compatible way to do console output (system 8-bit codepage, 80 columns, 25 rows, 16 colors) or key detection.

The MSVCRT.DLL failure: the DLL is a critical dependency for compiled C++ applications, so it's fundamentally not possible to run any compiled C++ applications on Windows 95 at all.

I haven't found an explanation for the NT 4.0 issue.

Cody Gray - on strike
  • 239,200
  • 50
  • 490
  • 574
  • On which platform did you compile your `.exe` file? I expect that in order to run under Windows 95 you'd better compile it under Windows 95 as well – Denis Sheremet Jan 16 '20 at 07:52
  • No, it just means that Windows 95 is missing the correct runtime environment, and you use a function ([`SetCriticalSectionSpinCount `](https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-setcriticalsectionspincount)) directly or indirectly that didn't exist in Windows NT 4.0. – Some programmer dude Jan 16 '20 at 07:53
  • 4
    And when you call Windows 2000 and Windows XP *modern* that's a bit of a stretch... Neither of those versions (not to mention Windows 95 and NT 4.0) have been supported for over a decade. Why do you need to run on such old systems as Windows 95 and NT 4.0? – Some programmer dude Jan 16 '20 at 07:54
  • It's not like I am developing a browser supporting the very recent HTML5 standards. Plenty of application ideas can be implemented to run on all sorts of hardware and operating systems, not just the recent most expensive ones. It's more like the other way around, introducing too complicated code and losing support for older operating systems is a waste of time. –  Jan 16 '20 at 08:39
  • @PiotrGrochowski you are going back 25 years. Programming is not a time machine - if you want to make money that is. – Michael Chourdakis Jan 16 '20 at 08:43
  • Nope — I am developing exclusively free software. –  Jan 16 '20 at 08:48
  • 2
    Then why limit yourself to Windows 95? Why not Windows 3 or even Windows 2? The WIN32 API was introduced in Windows 3 series, and many functions in the WIN32 API came from the 16-bit API's of Windows 2. When do you stop supporting old operating systems that even Microsoft themselves haven't supported for two decades? By keeping such long backward compatibility, you limit yourself and your programs *a lot*, not to mention that you need to write code that becomes overly obfuscated and really hard to maintain. – Some programmer dude Jan 16 '20 at 08:50
  • 1
    *"introducing too complicated code and losing support for older operating systems is a waste of time"* - **Nothing could be further from the truth with that statement.** Keeping backwards compatibility with every OS is a waste of time if no one uses those platforms. Further, it makes it hard to take advantage of new features, frameworks, and even newer compiler tools when you have the burden of legacy support. You could probably keep backwards support for Windows 95, but you probably won't be able to use modern C++. – selbie Jan 16 '20 at 09:35
  • Think about it: By the recent technologies, a game of Tetris would have to use WebGL collision detections and such. It wouldn't run on Windows 2000 and below. I would rather implement a few logical operations that do the same thing as the collision detection but don't require the latest CPU to run at full 60fps speed. –  Jan 16 '20 at 11:04
  • Who would complain if your Tetris game didn't run on Windows 2000? :) – selbie Jan 16 '20 at 20:39
  • Are you kidding me? A game of Tetris can be broken down into series of a few logical operations (including the recent rotation system, SRS https://tetris.wiki/Super_Rotation_System), and that can be done much more efficiently in C++ than in HTML5. I would rather give it the amount of compatibility it deserves for its lack of sheer complexity. –  Jan 17 '20 at 11:18
  • 1
    Who said anything about HTML? I was just saying if you wanted to support Windows 95, you likely wouldn't be able to find a modern C++ compiler that supports all the modern features of the languages. You'd be stuck on compiler tech from before the modernization. I stand by my answer below. Go get Visual Studio 2005 for Win9x compat development. – selbie Jan 20 '20 at 07:02
  • 1
    Being able to run on such old systems is not a benefit, it is a liability. These systems are no longer supported with security updates or third party security software. Anyone running such a system with exposure to the Internet will be very vulnerable and their continued use is ill advised. If cost and running on old hardware is an issue, a modern Linux distribution is cheaper and more secure. – Clifford Feb 15 '20 at 03:20

4 Answers4

3

When compiling, the compiler doesn't seem to find the correct definitions for a specific Windows version or a specific Internet Explorer version. Why is that? You need to set defines _WIN32_WINDOWS, _WIN32_WINNT, WINVER and/or _WIN32_IE to the minimum platform you plan to support before including the windows.h header file. Possible values for these definitions can be found in the header w32api.h file.

Taken from here

nivpeled
  • 1,810
  • 5
  • 17
2

The MS Visual C++ runtime DLL was not distributed with early versions of Windows, you either statically linked the code to the Microsoft libraries (not possible with MinGW), or you deploy the dependencies with your application.

The redistributable parts of VC++ (in which MSVCRT.DLL is included) are provided in a redistributable package specific to various versions of VC++, MSCVRT.DLL is from VC++ 6.0, and no longer available from from official sources; at your own risk you can get it from here for example.

Your Windows NT 4.0 error is a matter of your code using an API that was not part of the Win32 API when NT 4 was current. You can specify the target Windows version through various macros to restrict the API available to your code. That will then generate a compile time error rather then a runtime error. If that particular call is critical to your application, then it simply cannot be run on WinNT. The documentation for SetCriticalSectionSpinCount() states that the minimum supported system is XP.

With respect to your console I/O issue, MSVCRT.DLL includes Microsoft's conio library (not the same or as extensive as Borland's). MinGW includes conio.h header I think or here. That may provide what you need.

Clifford
  • 88,407
  • 13
  • 85
  • 165
0

I could write novel here on the actual set of issues, but the bottom line is this:

Newer C/C++ runtime libraries, whether linked statically or dynamically into the target EXE, depend on OS APIs that were not available in Windows 9x. You'll need a set of tools that are still compatible with these a̶n̶c̶i̶e̶n̶t legacy versions of Windows.

You are going to need Visual Studio 2005 or earlier if you want to target Windows 95 and NT 4. As per the Wikipedia page:

Visual Studio 2005, codenamed Whidbey ... was released online in October 2005 ... ... It is the last version available for Windows 2000 and also the last version to be able to target Windows 98, Windows Me and Windows NT 4.0 for C++ applications.

You might be able to do some hybrid thing with MinGW - let it still be the compiler, but link with the older MSVC*.lib files from Visual Studio 2005.

selbie
  • 100,020
  • 15
  • 103
  • 173
-1

Perhaps you can statically link to the required libraries?

christianO
  • 167
  • 11
  • This would ALMOST work. Except that the OP is likely compiling with static C/C++ runtime libs that depend on new APIs that weren't in NT 4 or earlier. – selbie Jan 16 '20 at 08:41
  • 1
    You cannot link Microsoft's static libraries with MinGW (at least not within the licence terms), the static libraries are distributed with Microsoft Visual Studio. The kernel library in the NT error is a system component not a static library in any event. MinGW uses MSVCRT.DLL because it is included in later versions of Windows and was a redistributable component for earlier versions. – Clifford Feb 15 '20 at 03:05