really don´t runs causes GPF
i am using
#include "hbdll.ch"
hdll:=dllload("EZTW32.DLL")
dllcall(hdll,DC_CALL_STD,"TWAIN_SelectImageSource",::oFormCadastro:handle,)
dllcall(hdll,DC_CALL_STD,"TWAIN_AcquireToFilename",::oFormCadastro:handle,"file.bmp")
freelibrary(hdll)
Best Regards,
Hi,
I guess that is because hbwin is compiled with -fomit-frame-pointer.
Try copy win_dll.c to the folder tests and compiled with .-
hbmk2 testdll.prg win_dll.c -lstdc++ -debug
Ok, I've only tested with gcc-dw2.exe
--
Xavi
El 06/02/2010 15:19, Fernando Athayde escribió:
really don´t runs cau
Hi Xavi,
Very good point.
I can add ugly hack to makefiles to always keep frame
pointers for mingw in hbwin lib to make hb_DynaCall()
function happy, but I wonder if it's possible to fix this
function to not be sensitive on this setting.
Any idea?
Brgds,
Viktor
On 2010 Feb 6, at 17:41, Xavi
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.
--
Xavi
El 06/02/2010 18:37, Viktor Szakáts escribió:
Hi Xavi,
Very good point.
I
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
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
>>... 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,
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
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 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 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,
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,
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,
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 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,
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,
> 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
17 matches
Mail list logo
