> On Mon, 18 Jan 2010, Szak�ts Viktor wrote: >> Is there any particular reason to define stubs >> for non-WinCE winapi calls in hbwince.c, like >> Ellipse(), Arc(), FrameRect(), FloodFill(), >> FreeResource()? >> Looks like these could be simply handled by >> HB_OS_WIN_CE guards, just like we do for all >> other similar case. > > 1. It's necessary to update code in many different places and > in some cases it makes code really unreadable > 2. I do not know which missing functions are real WinCE limitation > and which one are missing only in provided WinCE RTL, i.e. each > new release of MinGWCE adds new functions. It's much easier to > update single file then scan whole code for different: > #if ! defined( HB_OS_WIN_CE ) || ... > Please note that in few cases these are very important functions, > i.e. without file lock functions any WinCE application cannot access > concurrently the same DBF files. > 3. We added functions to emulate environment. We can also add functions > to emulate some other things like current directory and in such case > it's good to keep the same code for desktop windows and WinCE.
I understand this, but since in 95% of cases we're doing well with simple #if guards, I'm not sure all of these exceptions are valid one. F.e. the ones I mentioned are solely used in GTWVT and GTWVG, pretty easy to guard them, although f.e. in my mingw tests, they worked well, so they seem to be supported. Maybe it's not true for all old versions of all compilers, but in this case it's still better to fine-tune it with version guards. > BTW I also think that if some code can be compiled for WinCE and does > not create some fixed dependencies which break existing functionality > then we should compile it. I.e. with some minor fixes win_prn[123].c > can be compiled for WinCE by MinGWCE. In current version of WinCE RTL > low level functions do not exists but maybe they will be supported in > the future or even by some 3-rd party extensions i.e. there is 3-rd > party windows console for WinCE so it should be possible to use GTWIN > with it so we can provide GTWIN for WinCE builds but of course it cannot > be included in harbour.dll. Please also remember that new MinGW compilers > support direct linking with .dll libraries and do not need any > intermediate import libraries (BTW it's even suggested to eliminate > import libraries from new projects because direct linking with .DLLs > is faster and consumes less memory) so it's enough that user has valid > .dlls to link his application and use new functionality. So what should be the final conclusion here? I'd personally simply remove those few GDI WinCE stubs, as they seem to be supported and wait for feedback where they exactly fail. (f.e. I can't test msvcarm). As for the rest, I don't know, we may leave them, but it would seem much cleaner and uniform to add guards to them, where they are used. I somehow feel it very uncomfortable to publish system function form our own libs, be it .dlls or static libs. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
