> the proposed code was not self modifying. Included machine code is only to
I know, I was referring to Int86(). > avoid .asm file. If we can include __asm or another kind of asm inline in > code, the problem is solved. I'd avoid ASM if possible. We already have a CPU specific solution with inline ASM. If not possible we should keep it, but it won't be much better than current solution which is x86 only. x64 might be added like that, but IA64 and all sorts of WinCE CPUs not very easily. Also ASM isn't available in some compilers like BCC 5.5. > 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 ) I understand, and if we want to solve that (at least for part of the cases - without structs) we indeed need some sort of syntax or protocol just like what you say. Some other higher-than-C level languages also used to have them. Such syntax can use native Windows types names as they are listed in MSDN API docs to make them easier to form, like: "int: HWND, LPCTSTR, LPCTSTR, UINT" (for MessageBox()). With such param description, Harbour could even automatically do Unicode conversion where required. Anyhow a reasonable initial goal would be to clean the code to the extent it's portable across all Windows supported CPUs and after that we can speculate on making it more foolproof for users. But that can be a second step IMO. Brgds, Viktor _______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
