winmm 16/32 code split

[Eric Pouech]

Alexandre Julliard a écrit :
> 
> Eric Pouech <eric.pouech at wanadoo.fr> writes:
> 
> > agreed. but if you really want to split, the glue code must be generated
> > from the 16 bit code only, thus the 32 bit code cannot link directly to
> > the glue code (the kind of pointer you suggested in some previous mail).
> 
> It seems we are still not understanding each other. Of course the glue
> code would be in 16-bit code with that technique; *everything* would
> be in the 16-bit code except for an extra field in the 32-bit
> structure. SetAbortProc16 is a good example of what I mean.
unfortunately, this doesn't apply to (directly) to the mmio interface:
- most (*) the outter functions (mmioOpen/mmioClose...) use a handle to
a 
  mmio object
- the mmioXXX functions are mapped (from some of them) to ioProc which
  handle part of the work (one parameter of ioProc being a message
  describing the action to be taken)
- so far, nothing really new, the plain old service/driver architecture
(*) however, what some API designs for mmio don't work with your scheme:
	+ ioProc get a handle thru the MMIOINFO structure
	+ however, this field is not always filled (for example, the 
	  message MMIOM_RENAME doesn't use it)

which leaves as solutions (assuming we store the 16 bit segmented
pointer
for the ioProc in the 32 bit part)
1/ use reserved fields of MMIOINFO to store this pointer
1bis/ use extra fields of MMIOINFO to store this pointer. for example, 
   ensure that when a ioProc is called, the pointer to MMIOINFO points 
   to a MMIOINFO struct contiguous to some extra information. this 
   extra information would then be used in the "proxy" (32=>16) ioProc
   1bis would a bit safer since, even if MS says the fields are
reserved,
   values stored in them are passed to the ioProc (but I don't know of
   any app making use of it)
2/ from 32 bit code, call a wrapper for the 16 bit call, with an extra
   parameter compared to the standard ioProc (the segmented address of
   callback). It's what is done in user32/ddeml. However, to let the
   16 bit DLL to be splitted, the wrapper function must called thru
   a pointer (the 16 bit library would initialize this pointer if it's
   loaded, as you suggested before).

sorry for making this discussion so long, but I'd prefer there's an 
agreement and a clear scheme defined so that it can be safely applied
across all DLLs. There are lots of ways for doing it, but it's better
we select a few of them. It'll be easier to maintain.

A+