Alexandre Julliard a écrit :
>
> Eric Pouech <[EMAIL PROTECTED]> 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+
