"Patrik Stridvall" ps@leissner.se wrote:
Noticing that you (Dimitry) have send in a few patch replacing Win16 calls by Win32 ones, I wish to point out that winapi_check can detect "illegal" calls from Win32 to Win16.
Just do winapi_check --cross-call-win32-win16
Great! Why didn't you just make a patch and submit it?
Well. Because I don't want to blindly do search and replace I haven't got around to do it since it will take some time to analyze each case for correctness. It is on my list of things to do but it has very low priority.
But since you seems to be doing it, I might just as well tell you how to easily find many of them.
Note that some of the fixes in your (Dimitry's) patches is not included in the result below because they are Win16 functions calling Win16 functions.
I do not say this is nessary wrong, but are you (Dimitry) really sure this is how it should be?
Well, as Alexandre already has pointed out, Win16 should be mostly implemented by using Win32. I agree with him that use of the 16-bit code should be eliminated as much as possible. Moreover, until now I just have replaced only obvious places: 16-bit functions which just thunk up to win32 without any argument processing.
Sure Win32 calls to Win16 should be eliminated that is without question. This is how Windows NT does it and Alexandre has a policy that Wine should doing like Windows NT does. I fully agree.
However I'm not positive that replacing Win16 calls to Win16 with Win32 calls is always good idea. See below.
Sure it probably runs a little faster, but then Win16 applications on a modern computer are likely to be _very_ fast, so it is really worth risking potential compabillity errors because of some probably irrelavant speed differences.
Not that functions like DeleteObject are likely to have such problems but still...
I'm not going to blindly replace 16-bit calls by 32-bit. I look into the code and do think twice before submitting a patch.
Of course you are not, but there might be subtle issues that break the code in the future then the full Win32 semantics is implemented. That requires much more thinking than just casually browsing the code and reading the documentation.
Actually just thinking and reading documentation is not enough either Win32 or Win16 might have undocumentation features on Windows not implement by Wine yet.
Note that I'm not convinced is a large problem if any at all. I'm just worried and think we need to think this through carefully.
So what should we do?
Correct me if I'm wrong but because of the DLL separation Win16 to Win16 calls between different DLL:s (or rather different .so files) must not take place.
I notice that, for example, user32.spec contains the following lines:
################################################################ # Wine extensions: Win16 functions that are needed by other dlls # @ stdcall CallNextHookEx16(long long long long) CallNextHookEx16 @ stdcall CallWindowProc16(long long long long long) CallWindowProc16 @ stdcall CloseDriver16(long long long) CloseDriver16 @ stdcall CreateDialogIndirectParam16(long ptr long long long) CreateDialogIndirectParam16 @ stdcall DefDriverProc16(long long long long long) DefDriverProc16 @ stdcall DialogBoxIndirectParam16(long long long long long) DialogBoxIndirectParam16 @ stdcall GetDriverModuleHandle16(long) GetDriverModuleHandle16 @ stdcall OpenDriver16(str str long) OpenDriver16 @ stdcall PostAppMessage16(long long long long) PostAppMessage16 @ stdcall SendDriverMessage16(long long long long) SendDriverMessage16 @ stdcall SetWindowsHookEx16(long long long long) SetWindowsHookEx16 @ stdcall UserYield16() UserYield16
and gdi32.spec contains these lines:
################################################################ # Wine extensions: Win16 functions that are needed by other dlls # @ stdcall CreateMetaFile16(str) CreateMetaFile16 @ stdcall CloseMetaFile16(long) CloseMetaFile16
This is what is guess Alexandre wants eliminated not calls like the call in SetDCState16 (Win16 GDI) to DeleteObject16 (Win16 GDI) that you "fixed" in one of your patches.
Of course Win32 to Win16 calls should be fixed even within a DLL but that is because of possible different semantics not because of the DLL separation.
In short I suggest the following policy 1. No Win32 to Win16 calls: This is because of semantic and speed reasons. 2. No Win16 to Win16 calls between different DLL:s: This is because of the DLL separation. 3. No Win16 to Win32 calls within a DLL (with the exception a function's Win32 counterpart or replacement in the case of obsolete function): This is because of semantic reasons but I'm not sure how hard we must enforce point, because if the the Win32 function generates a non Win16 message or some other non Win16 related stuff I guess we can quite easily can (and perhaps even now does) ignore or filter such things in more fundamental part of the code like in the message dispatching code.