Hi all, The safecall calling convention is now implemented for i386/linux in fpc-trunk. The next step to get XPCom working now is to update the QueryInterface (and AddRef and ReleaseRef) definitions in IInterface.
Problem is that they are defined as 'stdcall' but to make them work on Linux/i386 that should be 'cdecl'. So that will change in the near future. (using an ifdef, so it's stdcall on windows, cdecl on all others) This will break backwards compatibility on non-windows systems for users who implement their own QueryInterface, AddRef and ReleaseRef methods! But it's easy fixable and the compiler will complain. The problem that then still remains is that the IID parameter of QueryInterface has to be passed by reference. Now it's defined as 'const' so it won't be passed by reference in Linux (cdecl). Now I see three options: pass all records with a size bigger then the register-size by reference for all cdecl-params which are defined as 'const'. The same happens for stdcall parameters on Windows and this is suggested before by some people. This should not lead to any backwards compatibility problems, because when 'const' is used right, it leaves the decision to pass by reference or not to the compiler. So when this changes, there shoudn't be any problem. But this is also the weak part of this solution: with this change the developer will use 'const' to make the compiler pass the variable by reference, which should be free for the compiler to decide. (In other words: it will make the usage of 'const' parameters for connecting with external (c) programs very difficult, because the meaning of const will be difference than how c-compilers will handle it) Second option is to change the 'iid' parameter of QueryInterface from 'const' to 'var'. This is not a really option, though, because then you can not pass constant values to QueryInterface anymore. Which means that you also can not pass an IInterface (and thus it's GUID) to it directly. This leads to the third option: introduce a new parameter-type which will always pass the variable by reference, and will be handled as being constant by the compiler. We could name it 'in', for example. First and third option are possible. I would choose for the third option because this will also settle these kind of problems for the future. (This idea is also mentioned on this list before by others) Or are there any considerations/arguments that I missed? Joost _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel