Hi Przemek, > I have a question about using HB_OS_WIN_CE macro in HBWIN library. > As I can see many functions are disabled and sometimes even such > basic ones like GetProcAddress() which for sure exists in WinCE. > So my question is why this macro was used?
I didn't verify this specific case in change history, but I'd guess it once appeared as error when testing some WinCE builds, and it was simply guarded off. > If you only had not time to update some code for WinCE builds > then please at least leave a not about it or add iTODO warning. > Now seems that we have to verify all > #if [!] defined( HB_OS_WIN_CE ) > conditional compilation macros and mark the ones which cannot be > implemented due to limited WinCE API and the ones which can be > implemented but so far we had no time for it. Such guard in most cases is equivalent to "further check needed for WinCE". Unfortunately the topic is wide and very time consuming, so there was no precise research made for every function, ever committed to hbwin. > Current behavior is also very confusing for final users because .prg > code can be cleanly compiled and linked but it will not work due to > dummy functions in WinCE builds. Here the general approach in all contribs is to always defined .prg level wrappers, and return error (value or RTE) when they are not available in low-level layer. Or we can emulate the missing feature, like we do in hbwince.c. I think we should keep this behavior, since for .prg level function is better to not pass over the whole ugliness of low-level WinCE programming, plus .prg code doesn't really have the tools to verify the exact low-level details (compiler version, API version, etc). > Usually when the code can be at least compiled with WinCE header > files though it will not work due to missing functions in standard > libraries then I'd suggest to enable such code in WinCE builds > (in separate files of course to not create dependencies which > break other functions) because link time errors can greatly help > to early detect the problems and if possible use some 3-rd party > libraries giving missing functions like console or printing > libraries for WinCE. It's good, but very time consuming since it needs test apps for every function in question, for every WinCE compiler (+ version) to verify link errors. It can only be done by real WinCE programmers. Maybe some test tools could be built to more easily verify it, f.e. a hbwinext.ch which pulls all hbwin functions, and a test app which does nothing but tries to link everything. But even this should be built automatically to give us desired results. One more related issue: I noticed in MSDN documentation that several WinAPI calls will set LastError on WinCE, but no such thing is signaled by non-WinCE docs. This is one issue I didn't invest huge amount of time when creating GDI wrappers f.e., but maybe it may be interesting for WinCE users. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
