Viktor Szakáts wrote:
I use approach listed below. And I suggest... not to use it! :)
And this code is NOT the one I want to see in Harbour. It's Windows 32bit
only, code is on data segment, etc.
Well, I agree :) Przemek had some good suggestions how to
make this clean by adding stubs for different call combinations.
This whole issue reminds me of implementing generic int86()
call in a protected mode compatible way (no self-modifying code).
blah.. looks like this kind of code never dies however time passes,
OSes develop. It even gets worse.
Anyway I hope we will have it fixed inside Harbour once.
Hi,
the proposed code was not self modifying. Included machine code is only
to avoid .asm file. If we can include __asm or another kind of asm
inline in code, the problem is solved.
The real problem is parameter conversion. C language does not contain
information about number or type of parameters. C code get it from the
stack or registers, but you never know if it is a pointer or number.
This leads to the conclusion, that you could not do a universal and
fail-safe conversion from Harbour to C without doing parameter
validation in wrapper function.
The universal function will always be not GPF safe. It can only be more
hacky (like CallProcByStackFrame()), o less hacky (like CallProc()). We
can add some validation, I remember Clip4Win had something like this:
CallFunc( ptrFunc, "int:char*,int", cParam, nParam )
This "int:char*,int" can by used to do some parameter validation and
return the value of correct type, but you can always GPF by using:
CallFunc( ptrFunc, "int:int,int", 0 /*zero char pointer*/, nParam )
Regards,
Mindaugas
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
