> This is ugly, yes, but when you consider the mmio{Set,Get}Buffer stuff
> as well, its really the only way. There are some issues in wine
> regarding combining 16 and 32 bit calls with the same mmio
> handle/mmioinfo structure (eg mmioGetInfo followed by mmioSetInfo16),
> but I'm not sure if windows handles this either, or if any app tries to
> do this.
to be more precise, since we need to share the same buffer between:
- user modification (being 16 or 32 bit depending if using mmio* or
mmio*16 functions)
- mmio* func implementation
- IO Proc (which can be installed either as 16 or 32 bit version)
we all know that it's easy to get a linear address from a segmented pointer
but the other way around is not doable (at least easily)
so all structs and buffers are stored internally as 16 bit entities even the buffers
(except when mmioSetBuffer is called directly; in which case we get a 32 bit
address... if buffer is internally allocated, we get a 16 bit address)
I doubt - as Andi - that the code works in all cases.
anyway, there are others issues I don't like with current code:
- it cannot work without 16 bit support
- the bitness handling is an utter mess (I guess some of you may have guessed it)
anyway, thinking a little bit more about it, I think we could come up with
a cleaner design, but which may need some structural changes, and breaking the
rule for sharing the buffer (see above). we could copy back and forth the buffer
content (when needed) from user-land down to I/O proc thru MMSYSTEM/WINMM
our current troubles boil down to the will of keeping the internal struct
for storing the mmio handle state as a MMIOINFO one (either in 16 or 32 bit
versions) I think we need more than that (16 or 32 bit buffers...), and some
more conversion routines
from original Andi's path, a few comment though:
- return 5; is spelt return MMSYSERR_INVAL_HANDLE; in M$ jargon
PS: :I don't wanna put my name at the top of the file, there's some risk
I'd be annoyed ;-))
A+
--
---------------
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle
