Hi Xavi,
> Hi Viktor,
>
>> I can easily implement pure .c win32 .dll call support
>> which drops support for int64/double parameters and
>> int64/double/float return values. I'd also guess they
>> are not very widely used, so it's probably not a big
>> loss.
>
> I agree. If need it, is better to
Hi Viktor,
I can easily implement pure .c win32 .dll call support
which drops support for int64/double parameters and
int64/double/float return values. I'd also guess they
are not very widely used, so it's probably not a big
loss.
I agree. If need it, is better to have a specific wrapper.
Bes
Hi Xavi and All,
On 2010 Feb 11, at 16:23, Xavi wrote:
> Hi Viktor,
>
>> That can work, but it means we don't support int64/double
>> parameters and int64/double/float/char return values anymore.
>>
>> Currently we do, so maybe it'd be good to take care of it.
>>
>> We should also support both
Hi Viktor,
That can work, but it means we don't support int64/double
parameters and int64/double/float/char return values anymore.
Currently we do, so maybe it'd be good to take care of it.
We should also support both cdecl and stdcall versions.
Yes I know, this is not perfect.
Also I just t
Hi Xavi,
On 2010 Feb 11, at 05:20, Xavi wrote:
> Hi Viktor,
>
>> You've introduced a new permanently set macro called HB_OS_WIN64_32,
>> redefined a Harbour type (which should be avoided by all means)
>
> Is to work with win64 implementation in win32 with minimal changes.
> If the system is win
Hi Viktor,
You've introduced a new permanently set macro called HB_OS_WIN64_32,
redefined a Harbour type (which should be avoided by all means)
Is to work with win64 implementation in win32 with minimal changes.
If the system is win32, not be used HB_U64 used HB_U32 to compile only win_dll.c
Hi Xavi,
Maybe I'm missing something, but it's not exactly clear for me what
the patch is meant to solve.
You've introduced a new permanently set macro called HB_OS_WIN64_32,
redefined a Harbour type (which should be avoided by all means)
and shifted parameter offset by one for reference types
Hi Viktor,
To avoid ASM the compiler needs to know the call and sizes at compile time.
Too many combinations for a job that may not be perfect and maybe unused.
It's possible to simplify overwriting the stack with struct of byte array more call more choice but I think with some
optimizations wil
Hi,
>> From this point it's users responsibility to
>> pass parameters properly.
>
> Ok. Next topic: coverage of potential C .dll functions.
>
> IMO it's unworkable cover functions of n parameters with n size,
> seems reasonable to restrict to 15 the number of parameters.
This limit already exi
Hi all,
From this point it's users responsibility to
pass parameters properly.
Ok. Next topic: coverage of potential C .dll functions.
IMO it's unworkable cover functions of n parameters with n size,
seems reasonable to restrict to 15 the number of parameters.
Currently only covering sizes
>>... its users job to
>> passing parameters according to call specification of
>> .dll function.
>
> Yes, but I think it's not only Harbour.
> Apply the patch attached to testdll.prg
> Could someone test that about xBase++ and/or xHarbour?
Sorry, I can't see your
Hi all,
... its users job to
passing parameters according to call specification of
.dll function.
Yes, but I think it's not only Harbour.
Apply the patch attached to testdll.prg
Could someone test that about xBase++ and/or xHarbour?
--
Xavi
El 08/02/2010 10:5
Hi,
>> ... I wonder if it's possible to fix this
>> function to not be sensitive on this setting.
>>
>> Any idea?
>
> Yes, of course. ??? :)
> I can fix this without ASM, but a bad use of these functions always cause GPF.
That would be the nicest. I guess protection against
'bad use' is not
ards,
Fernando Athayde
*De:* Itamar Lins
*Para:* harbour@harbour-project.org
*Enviadas:* Sábado, 6 de Fevereiro de 2010 10:10:57
*Assunto:* [Harbour] MinGW dllcall function not run.
Hi!
sorry to insist on that but there is a possibility to make it work
ro:handle,)
>> dllcall(hdll,DC_CALL_STD,"TWAIN_AcquireToFilename",::oFormCadastro:handle,"file.bmp")
>> freelibrary(hdll)
>>
>>
>> Best Regards,
>> Fernando Athayde
>>
>> *De:* Itamar Lins
>> *Para:* harbour@harbour-projec
ll)
Best Regards,
Fernando Athayde
*De:* Itamar Lins
*Para:* harbour@harbour-project.org
*Enviadas:* Sábado, 6 de Fevereiro de 2010 10:10:57
*Assunto:* [Harbour] MinGW dllcall function not run.
Hi!
sorry to insist on that but there is a possibility to make it work with him.
ile.bmp")
freelibrary(hdll)
Best Regards,
Fernando Athayde
De: Itamar Lins
Para: harbour@harbour-project.org
Enviadas: Sábado, 6 de Fevereiro de 2010 10:10:57
Assunto: [Harbour] MinGW dllcall function not run.
Hi!
sorry to insist on that but there is
Hi!
sorry to insist on that but there is a possibility to make it work with him.
I need to take MinGW.
Best regards,
Itamar M. Lins Jr.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/
18 matches
Mail list logo
