Alexandre Julliard a écrit :
Eric Pouech eric.pouech@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+