On Wed, Feb 23, 2000 at 08:03:02PM +0000, Eric Pouech wrote:
> I doubt - as Andi - that the code works in all cases.
Exactly. I doubt it.
> 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...
> 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.
> from original Andi's path, a few comment though:
> - return 5; is spelt return MMSYSERR_INVAL_HANDLE; in M$ jargon
Ah. That makes a lot of sense.
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.
Bradley, maybe you could do the needed patch for now ?
I'm still way too inexperienced, it seems :-\
I'll try to experiment a bit more with mmioAdvance and stuff.
Andreas Mohr
