Hi Przemek, >> If that simplifies things (which it definitely does), and >> the majority of developers agree with it, we can drop >> non-UNICODE mode altogether from Harbour source code. >> It's unlikely we shall ever support Windows 3.x or Win32s, >> and unicows solution works just perfect now to cover Win9x/ME >> host versions, so I can see no hard reason to maintain duplicate >> code paths for both UNICODE and non-UNICODE Windows API >> support. >> Having only UNICODE path could greatly simplify code in >> many crucial points, making it easier to maintain, >> extend, debug and keep bug free. Especially if we want >> to move towards internal (HVM) unicode support in the >> future. > > I would like to keep support for non unicode windows builds. > I do not see anything what give noticeable simplification in > Harbour core code because we will still have to keep support > for other platforms which do not use unicode. For me native > Win9x support is as important as WinCE port and I want to be > able to create application which can be executed on Win9x without > any overhead due to dummy emulation layer and I do not plan to > fight with any more or less important problems or incompatibilities > in libunicows and look for workarounds or send patches to the > authors.
libunicows is just an open source, compiler portable variant of the unicows import lib + load code to be able to use the actual wrappers in unicows.dll (shipped by Microsoft) with all compilers (not just MSVC). So there is nothing which you need to fight with here. It just works and the code stable since long years. As I mentioned already, but maybe it wasn't clear, the whole wrapper logic (or "dummy calls") is completely inactive on WinNT and above platforms, so for any apps that are designed to run on these platforms in the first place (using UNICODE), there is _no_ _overhead_ when using unicows. On Win9x, you indeed need to go through the wrappers, but given that these systems are much of an exception these days, it looks a much better compromise for an app than having the go through ANSI to WIDE wrappers on all modern (> WinNT) operating systems, which are the waste majority. BTW I expect the overhead to be minimal for GTWIN/GTWVT apps, as there is not too many UNICODE sensitive calls used in normal app operation, and practically none when doing processing using pure Harbour code. Pls correct me if I'm wrong with that assumption. To put this issue into wider Win9x perspective, most Harbour apps, even when using non-UNICODE builds, will need to have these extra Win9x components to be able to run properly or at all: 95/95B/98/ME/NT: http://download.microsoft.com/download/vc60pro/update/1/w9xnt4/en-us/vc6redistsetup_enu.exe 95B: ftp://ftp.microsoft.com/softlib/mslfiles/vrdrupd.exe 95: http://download.microsoft.com/download/0/e/0/0e05231b-6bd1-4def-a216-c656fbd22b4e/w95ws2setup.exe [ all listed in INSTALL. ] BTW, can you tell some examples where you still need to design apps to run specifically on Win9x? Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
