[Harbour] hbwin / win_dll.c - Portable solution?

[Mindaugas Kavaliauskas]

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