Andreas Mohr wrote:
>
> > 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)
> Definitely...
Yeah. This was my first big patch, and so it was built up in steps by
experimentation, rather than actually designed :)
>
> > 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
> Exactly. Wanting to base everything on MMIOINFO16 is problematic.
> I already had the idea of using a completely different (and much more
> verbose !) internal structure, too.
What about something like the driver code has? This still leaves the
problem of mixing 32 and 16 bit calls. In windows they are in separate
dlls, so I suspect that this isn't valid. mmioInstallIOProc16 is in the
32 bit mmsystem dll, but is stubbed out in wine, even though we have
that implimented. I noticed it, but left it because of testing issues.
The existance of this function is undocumented, but I suppose it
registers 16 bit code as an io procedure. Does anyone know? (I'm not
sure what the unicode mmioInstallIOProc does compared to the ansi
version though) This presumably means that it is valid to register a 16
bit proc and then call mmioOpen (the 32 bit version) on a file with the
registered extention. This has ugly consequences, and unless I've missed
something pointer arithmatic will still be needed.
Also, we currently don't differentiate between global and local ioprocs.
I'm not sure of the best way to do this. We also don't follow windows
rules for resolving conflicts between two ioprocs registered with the
same extention, but thats easy to fix.
Is a global ioproc registered with mmioInstallIOProc from the 16 bit dll
able to be used with functions from the 32 bit ioproc? What happens if
you try to do mmioSetBuffer with a 16 bit ioproc installed?
How vital is it to remove 16 bit handling? Eric, does that mean that the
ideal would be code which doesn't know about 16 bit stuff at all? What
does winNT do with mmioInstallIOProc16 on non x86?
> BTW, the stuff using mmioAdvance is Dilbert Desktop Game Demo (~ 14 MB).
> (you might have guessed it from my patch ;)
> Just download it if you need a test app.
OK, thanks. I'll grab it soon.
> Bradley, maybe you could do the needed patch for now ?
> I'm still way too inexperienced, it seems :-\
Um, my windows coding experience comes from wine, and Eric's help, and
MSDN. You've been doing wine stuff for longer than me :).
Uni starts again on Monday for me, and depending on various discussions
that may mean I have lots of time to do wine stuff, or not much, in the
next few weeks.
There are quite a few mmio things which need working out though, and
testing, and discussing. If we can work out the answers to my questions,
then we can work out the best way to do things.
> I'll try to experiment a bit more with mmioAdvance and stuff.
That'd be very nice thanks.
>
> Andreas Mohr
Bradley
PS I still plan to think up the reasoning behind the mmio stuff from my
previous mail. I'm currently upgrading computers, and am moving files
across, and lots of things are in bits at the moment... I also don't
have a windows compiler on my current machine - I have to find the CD on
my shelf somewhere.
