17

We're looking at upgrading from Visual Studio 2005 to Visual Studio 2008. I discovered the following disturbing comment.

From Update WINVER and _WIN32_WINNT:

Beginning with Visual C++ 2008, Visual C++ does not support targeting Windows 95, Windows 98, Windows ME, or Windows NT.

Does this mean that if we rebuild our products with Microsoft Visual C++ 2008, they will stop working on Windows 98 machines? It sounds like it, but I have trouble believing they'd make that big a change.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Colen
  • 13,428
  • 21
  • 78
  • 107
  • 4
    It's confusing when they say they don't "support" it. Sometimes it will work, they just don't want to help you out if you run into problems. Sometimes, it definitely won't work. I wish they would distinguish between "do this at your own risk" and "you can't do this". – DOK Oct 17 '08 at 20:32

8 Answers8

15

It's not just about .NET 3.5. It's about the Windows SDK header file macros and definitions pulled in by the mandatory version bump in WINVER. So yes, Colen, Visual C++ 2008 binaries will target the Windows NT APIs only and while occasionally they may work on Windows 98, you should assume that you cannot use Visual Studio 2008 to target Win9x. You will have to use Visual Studio 2005 or older.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Mihai Limbășan
  • 64,368
  • 4
  • 48
  • 59
  • 3
    You should do more than assume. VS9 generated binaries will physically not load on Windows & Windows NT versions lower than 5. – Chris Becke Oct 27 '08 at 08:24
  • 1
    You should not assume that I assume. You can play with the PE file header flags in the linker step to get the 9x PE loader to properly parse the VS9 output. Then it's just a matter of resolving DLL imports. But there is a wide gap from "loads" to "works properly", which is why I used "occasionally." – Mihai Limbășan Oct 29 '08 at 13:09
3

Yes, it does mean that: The Windows CreateProcess and LoadLibrary APIs on Windows NT before Windows 2000 and all of Windows (95, 98, and ME) will not load a DLL or EXE file made by Visual Studio 2008 (VS 9), because the PE header in the file has the required OS version field set to 5.

The error message upon attempting to load a Visual Studio 2008-generated EXE file will (be a very unfriendly modal error dialog) actually say "You need to upgrade your operating system to run this program".

I experimented with editing the field to 4. The binary will be loaded, but any use of the Visual Studio 2008 C-runtime will hang or crash the process. There are ways to get Visual Studio 2008 projects to not use their native C-runtimes, but if massive use of C++ features is important to you, this approach is not going to scale past a small application.

Visual Studio 2005 (VS 8) has most of the features of Visual Studio 2008, but it still targets early OS versions which is why at my shop we are sticking with that for the moment.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Chris Becke
  • 34,244
  • 12
  • 79
  • 148
1

It's natural that they do not support older versions of their operating system on their newer products. It would cost them more (not just monetary cost, but also making harder or impossible to provide some newer useful features) to make things work with the limitations (and often bugs) of older systems. This happens all the time, and with everyone; new versions of GCC drop support for older less popular architectures; new releases of glibc require a more recent minimum kernel version; and so on.

These operating systems have long been retired; from Microsoft's point of view, nobody should be using them anymore. If you still want to develop for them, you can use older tools of the same vintage.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
CesarB
  • 43,947
  • 7
  • 63
  • 86
0

According to .NET 3.5 information, Windows 98 is not supported by .NET 3.5, so I would imagine that is what they mean. You can still do .NET 2.0 and lower development, but if you use the 3.5 libraries, Windows 98 is not supported.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Jeremy B.
  • 9,168
  • 3
  • 45
  • 57
0

The 3.5 Framework won't even install on Windows 2000 Server at this point. So I don't believe that they will on 95, 98, or NT either. Microsoft doesn't want the responsibility of supporting these retired operating systems anymore.

Scott Dorman
  • 42,236
  • 12
  • 79
  • 110
JFV
  • 1,803
  • 6
  • 24
  • 38
  • 1
    Please don't use terms like "M$". It's not appropriate for this community. – Rob Oct 17 '08 at 20:36
  • Sorry about that, I started out on the support side of things and recently moved to development. I guess some old habits still bleed through. Thanks for the edit! – JFV Oct 17 '08 at 21:36
0

I'd recommend that you take this as an opportunity to stop supporting Windows 9x. This is a good reason as any to do so. And, at least if you're writing C/C++ code for the Win32 API, life is much easier if you can assume that the target OS is Windows 2000 or later.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
JesperE
  • 63,317
  • 21
  • 138
  • 197
0

While I agree with JesperE, Windows 98 is such a small percentage of users that it makes little sense to target them, unless of course you know a large percentage of your customers are in fact using Windows 98.

In any case, you can in fact target Windows 98 in Visual Studio 2008 (you can't develop on Windows 98). You must, however, target your projects at .NET 2.0 only, you cannot use any 3.0, or 3.5 features.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Its me
  • 173
  • 1
  • 6
0

It is my understanding that with the most recent KernelEx all MSVC versions targeting XP could potentially work (results depending on how many "newest" functions/features you will then decide to use)

With respect to what the answer could have been in 2008 instead, there were quite a number of patched libraries even back then (check links on the Wayback Machine if they are broken).

mirh
  • 514
  • 8
  • 14