Hi Chen, > Viktor, > > What is special about "non-unicode Windows" in compare to other > non windows OS that are currently supported by Harbour? Can't it
All Windows API calls that has to do anything with strings have two versions: one which deals with "ANSI" (8-bit) string types and another flavor which deals with "WIDE" (UTF-16 aka. "UNICODE") string types. Every time Harbour has to call a Windows API function, which has two versions, we need to take care of both types to maintain compatibility with both normal (non-UNICODE) and UNICODE builds. F.e. when we call GetCurrentDirectory(), it will be translated to either GetCurrentDirectoryA() in non-UNICODE (= "ANSI") call, or GetCurrentDirectoryW() UNICODE (= "WIDE") call when '-DUNICODE' compile-time option is used. The two modes will return different string, so we need to deal with it differently to convert it to Harbour string. We have a quite sophisticated set of functions and macros to deal with the issue. In pure UNICODE mode, we could either define -DUNICODE as static option, or replace all Windows API call to WIDE flavor (f.e. GetCurrentDirectory() with GetCurrentDirectoryW()) and drop all the code which deals with the ANSI type. On WinNT and newer Windows OSes, the ANSI Windows API function (*A() calls are wrappers to "native" WIDE ones, so they are slower than direct WIDE calls. On Win9x/ME there are no WIDE functions implemented, so there the ANSI versions are the native ones. This means that apps built in UNICODE mode won't work by default on these OSes since the requires WIDE function calls are missing from system libraries. Microsoft developed a solution though, which is UNICOWS.DLL, and this .dll provides WIDE wrappers to native ANSI ones, when the executable is run on such old OS version. On NT and upper OSes, it's invisible and doesn't cause any overhead. > be just considered another type of Os? Could be, but it would require lots of duplicate code, and such solution would be in essence a reworked way of keeping two parallel versions of every code which calls the Windows API. Overall, we wouldn't gain much at the end after a painful conversion process. > (I know that in maintanance therms, it is best to have less variations > as possible) Yes. Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
