Hi Przemek,
I understand these, but these are WinCE _OS_ calls,
not RTL ones, so even if they are present in some
buggy headers shipped with some compilers, the OS doesn't
provide them, regardless of compiler. (there may be
exceptions, but this should be clearly documented
f.e. in MS headers).
The only guard that exist in hbwince.c is HB_OS_WIN_CE,
(except for MulDiv, but this can be replaced by a
low-level Harbour function with different name), so
moving these to code is not something clumsy or horrible.
So overall, I don't really see the advantage of keeping
dummy stubs for them, now that only a few ones are left.
These are simple missing functions, and simply guarding
them makes it much more obvious that the functionality
is missing, and we also avoid any potential problems by
exporting functions with Windows API names. Some 3rd
parties may start to build on that, and it may also cause
collisions, none of them very good.
IMO, if we absolutely want to stick to keep this
special way of treating this regular problem, we at least
have to use distinctive names, and use PP macros to
map these to WinCE API names, f.e.:
BOOL WINAPI hbwince_LockFile( ... )
{
...
}
#ifdef WINCE [&& WHATEVER_COMPILER && WHATEVER_VERSION]
BOOL WINAPI hbwince_LockFile( ... );
#define Arc( ... ) hbwince_LockFile( ... )
#endif
This way the solution is much better controlled and
less "hidden", with less side-effects.
[ BTW this method is used by sqlite3. ]
Plus some of the not so often used stubs could easily
be dropped without major maintenance consequences.
(f.e. GDI ones).
Finally, contribs/3rd parties should never rely
on above "stub service" of Harbour core, to avoid
future problems. All of them should handle WinCE
missing functions on their own (preferably
by using portable Harbour core functions and adding
guards as needed)
How does this seem as a possible direction?
Brgds,
Viktor
On 2010 Jan 18, at 21:40, Przemysław Czerpak wrote:
> On Mon, 18 Jan 2010, Szak�ts Viktor wrote:
>> 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.
>
> They are not supported by MinGWCE 0.55 I'm using in my
> Linux box though they exists in header files so code can
> be cleanly compiled. Fails when harbour.dll is created.
> Which version of MinGWCE do you use?
> 0.55 is the last official release. I've downloaded 0.59.1
> And checked that it also does not contain Arc(), FrameRect(),
> FloodFill(), MulDiv() and few others functions. But it has
> Beep() and file lock functions so I plan to enable then ASAP
> when I installed it and verify it with real compilation and
> link test. It will be nice if someone can also make runtime
> tests at least in some WinCE emulator.
> BTW I'm really happy that I have to update only single file
> instead of grepping the whole code and reverting hacks for
> functions missing in older MinGWCE versions and increasing
> number of #ifdef... conditions in core code. As long as we
> will not have new official release of MinGWCE I think it's
> good to keep support also for 0.55.
> I hope that someone can verify also MSVC and POCC WinCE builds.
>
>> 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.
>
> If these functions are missing only in WinCE RTL then guarding
> them in source code is IMO very bad and dirty solution which is
> also hard to update.
> It's much cleaner to add them in single file which is easy to
> update when new compiler is released and supports some additional
> functions. Otherwise we will left like in contrib where a lot of
> code which probably can be compiled for WinCE is simple disabled
> by !defined( HB_OS_WIN_CE ).
>
>>> 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).
>
> They are not supported by MinGWCE 0.55 and MinGWCE
> 0.59.1
>
>> 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 do not find anything clean in hacking core code
> adding workarounds for missing functionality in some
> chose compiler versions. IMO it's much cleaner to
> keep all such hack in one place only and for sure
> it's much easier to update only single file and instead
> of introducing and reverting hacks in many different
> files.
>
>> I somehow feel it very uncomfortable to publish
>> system function form our own libs, be it .dlls
>> or static libs.
>
> Me two but it's minor problem in comparison to adding:
>
> #if !defined( HB_OS_WIN_CE ) || \
> ( defined( __MINGWCE__ ) && __MINGWCE__ >= ... ) ||
> ( defined( _MSC_VER ) && _MSC_VER >= ... ) ||
> ( defined( __POCC__ ) && __POCC__ >= ... ) ||
> [...]
>
> in many different places and then updating each of them
> when new compiler is released. I simply do not have time
> for it and I do not believe that will be updated by others.
> One file I can update from time to time very easy. Additionally
> I have documented in one place all missing functions so I can
> immediately locate what may be wrong when user reports some
> strange behavior.
>
> best regards,
> Przemek
> _______________________________________________
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
