Unicode v ANSI Calls
I am writing an application for which I am using unicode throughout.
However, I would still like my code to run on a Win9x machine without Microsofts Unicode Layer support.
What I have in mind is something like the following [psuedo code]:
In other words, if the application detects it is running on Windows 2000 or above, it calls the wide function, or on 9.x it calls the ANSI equivalent.
if RUNTIME OS is windows 2000 or above
WinCallW(); // call wide function
WinCallA(); // call ANSI function
While wide functions will never get called on Win 9.x, my question is will it run? Or will my app die with an error message because I have linked against a wide call? (I don't have any Win9.x platforms I could test it on).
PS. Please don't suggest I just define UNICODE -- it's not what I'm trying to achieve.
Think I found the answer. Wikipedia tells me:
"Normally, the Win32 API provides both A (ANSI) and W (Wide-character) versions of most functions. On Windows 95/98/ME, only the A versions are implemented and attempting to call a W version will fail with an error code that indicates that function is unimplemented..."
From this my code [I think] would be fine as the W versions don't get called on 9.x platforms.
Any comments appreciated though...
I think that most of the W functions are stubbed but it would probably be a good idea to test.
Could you create a unicode and non-unicode version? If you don't want to distribute two files, you could package both in an installer or mini-launcher and execute the appropriate version at run-time. This assumes that the program is of reasonable size.
Possibly, for extra safety, you could also consider delay loading.
>but it would probably be a good idea to test.
Yes. I think an old friend of mine may still have 98 laptop somewhere. May give him a call.
>Could you create a unicode and non-unicode version?
I'm kinda writing my own library for use in my own apps. My first project is going to be a DLL. I don't really want to have to tell other developers to use different DLLs for different platforms.
>you could also consider delay loading.
Thanks for the link. Looks interesting.