Yes, applications compiled with VS 2005 work fine on Windows 98 and Me. I myself launched several of them and support VS 2005 and install it for this purpose. Distributed CRT version 2005 is still supported on Windows 98.
The trick is that you have to compile the multibyte character set (MBCS) application . It will not work when compiling as Unicode, which is the default project setting. Windows 9x platforms do not support Unicode without further assistance. You should be able to change the project settings and be fine, but if you wrote your code to accept Unicode, you will have a problem.
This is why you need to use the common character types and functions defined in tchar.h rather than their wide character equivalents, which are preferable for Unicode assemblies. Always define strings using types of type TCHAR (or LPTSTR or LPCTSTR ), which are conditionally defined as wchar_t or char , if necessary. Use string manipulation functions starting with _tcs... rather than those designed for wide or narrow characters. Make sure that when you call functions, you always call generic versions with a type, not ANSI or broad-based ones that end with the suffix A or W
It can be a lot of work to come back and fix it if you haven’t done it right from the start. In this case, you can take a peek at Microsoft Layer for Unicode on Windows 95/98 / ME systems , which provides an abstraction layer that allows you to invoke Unicode functions on legacy Windows 9x operating systems where they are not supported.
Apart from Unicode / MBCS, the only thing to consider is that you do not call any functions that were not in the Win32 API back in Windows 98 days. You cannot trust that the online MSDN documentation tells you more about the "minimum supported client version" because Microsoft no longer supports Windows 98. All SDK documents say that the minimum supported version is Windows 2000, and you know this is not correct . The entire API was introduced no later than W2K. To get accurate information, you need to get an old version of the SDK documentation; what came with your VS 2005 installation should be fine. The information there goes back at least to Win 98, if not 95 (I don’t remember exactly).
In those cases when you want to call functions that were not in Windows 98, when you work on newer systems, where they are available, you will need to be especially careful to call them dynamically, and not add them to your DLL import table applications (what the linker usually does for you automatically). This means defining function pointers on your own and using LoadLibrary and GetProcAddress to call them. This is not fun, but it works.
Alternatively, you can configure the linker to "delay loading" libraries (check project properties). This is much more convenient, but obviously, you will need to make sure that you only call the functions available in your target operating system, otherwise the application will crash.
In any case, the GetVersionEx function will tell you everything you need to know about the current host operating system, so that your code can take different paths (call new functions if available, or revert to older ones if not) depending on the environment. This allows you to support new features in new systems, while maintaining any degree of support for legacy operating systems. You will find many if in the code base when this is done correctly. :-)