You'll find a lot of if statements in the code base when this is done right.I was not insulting you. This allows you to support new functionality on new systems, while still retaining whatever degree of support for legacy operating systems is appropriate. This is much more convenient, but obviously you'll need to ensure that you only call the functions that are available on your target operating system, otherwise the application will crash.Įither way, the GetVersionEx function will tell you everything that you need to know about the current host operating system so that your code can take different paths (calling newer functions if available, or falling back to older ones if not) depending on the environment. It's not fun, but it does work.Īlternatively, you can configure the linker to "delay load" the libraries (check your project's properties). That means defining function pointers yourself, and using the LoadLibrary and GetProcAddress functions to call them. The information there goes back at least as far as Win 98, if not 95 (I don't remember exactly).įor instances where you want to call functions that didn't exist back in Windows 98 when you're running on newer systems where they are available, you'll need to take extra care to call them dynamically, rather than adding them to your application's DLL import table (what the linker generally does for you automatically). In order to get accurate information, you'll need to obtain an old version of the SDK documentation what came with your installation of VS 2005 should be fine. The entire API was not introduced as late as W2K. All of the SDK docs say that the minimum supported version is Windows 2000 now, and you know that's not correct. You can't trust what the online MSDN documentation tells you for the "minimum supported client version" anymore, because Microsoft is no longer supporting Windows 98.
If that's the case, you might look into the Microsoft Layer for Unicode on Windows 95/98/ME Systems, which provides an abstraction layer that allows you to call Unicode functions on the legacy Windows 9x operating systems where they are not natively supported.īeyond Unicode/MBCS, the only thing to watch out for is that you're not calling any functions that didn't exist in the Win32 APIs way back in the Windows 98 days. It may be a lot of work to go back and fix this if you haven't done it from the start. Make sure that when you call functions, you always call the generic typedef'ed versions, rather than the ANSI- or wide-specific ones that end with an A or a W suffix. Use string manipulation functions that begin with _tcs., rather than the ones specific for wide or narrow characters. Always define strings using the TCHAR type (or LPTSTR or LPCTSTR types), which is conditionally defined to wchar_t or char, as appropriate. This is why you need to use generic character types and functions defined in tchar.h, rather than their wide character equivalents that are preferred for Unicode builds. You should be able to change the project settings and be fine, but if you've written your code to assume Unicode, then you'll have a problem. Windows 9x platforms do not support Unicode without some extra help. It will not work when compiled as Unicode, which is the default project setting. The trick is that you must compile the application for the multi-byte character set (MBCS). Version 2005 of the CRT redistributable is supported as far back as Windows 98.
I've run several of them myself, and keep VS 2005 around and installed for precisely this purpose. Yes, apps compiled with VS 2005 work perfectly fine on Windows 98 and Me.
0 kommentar(er)
