Win16 calls by Win32 functions

[Patrik Stridvall]

> "Patrik Stridvall" <ps at 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.