Hi Przemek,

>>> I'll also add public C API to HB_LIBLOAD()/HB_LIBFREE() which can be used
>>> by HBWIN code.
>> Thank you.
>> As for the recent .dll development, I've just committed 
>> finalized type conversions, so it should now work, but 
>> I'd appreciate if you could review it if you have some 
>> free time. Only ULONGLONG passing is wrong (just like in 
>> OLE engine) and I could't find a fix for it. Plus 'float' 
>> support on x64 doesn't work for some reason (while 'double' 
>> does).
> 
> I'll look at it later today.
> I've seen that you made it more general not only MS-Win oriented
> so public API to load/free libraries and find symbol addresses can
> help to create multiplatform solution.

Yes, the core logic is ready to be moved to Harbour core, 
it's completely MS Windows independent. Well, the default 
callconv is stdcall, that's the only Windows API specific 
in it, but we can switch it to cdecl.

The high-level WIN_DLLCALL() function is still win specific, 
but if we fine-tune the defaults and create lib load/free and 
func address lookup functions in core, it can also be ported 
to core as well.

> BTW I think that we should also remove HB_LIBDO() function.
> It's nothing more then limited DO() function and can seriously
> confuse users.

It's OK with me.

Brgds,
Viktor

_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to