Ove Kaaven wrote:
>
> On Wed, 23 Feb 2000, Andreas Mohr wrote:
>
> > Hi all,
> >
> > - fix bad TRACEs in dsound_main.c
> > - introduce MMIO_SendMessage for 16/32bit pointer fix
> > - mmioGetInfo glaring bug fixed
> > - two fixes for finally making Dilbert Desktop Game Demo hearable
>
> > -void MMIO_infoMap16To32(LPMMIOINFO lpmminfo, const LPMMIOINFO16 lpmminfo16) {
> > +void MMIO_infoMap16To32(LPMMIOINFO lpmminfo, const LPMMIOINFO16 lpmminfo16,
> > + BOOL b32bit)
>
> I thought the bitness of any Map16To32 routine would be obvious.
Be very careful here - its basically impossible to have an
MMIO_infoMap32To16 function, because of stored pointers. See below.
<snip not-my-bit>
> > @@ -879,8 +898,11 @@
> > (LPARAM) lpmmioinfo->cchBuffer);
> > lpmmioinfo->pchEndRead = lpmmioinfo->pchBuffer + count;
> > lpmminfo->pchEndRead = lpmminfo->pchBuffer + count;
> > +#if 0 /* what the hell should that do ? It's WRONG !
> > + (pchNext should point to pchBuffer after mmioAdvance, no ? */
> > /* Manually update pchNext for the 16 bit struct */
> > lpmminfo->pchNext += count;
> > +#endif
>
> Perhaps Eric misunderstood something, I didn't write that comment. Perhaps
> Eric should put his name in the copyrights at the top of the file so
> people can "annoy" him about things like that...
That one is my change from when I updated mmio.c to handle 32 bit
mmioInfo structs. I probably should have put my name in the top of the
file but...
Basically, the logic of the mmioinfo structures goes like this:
mmioinfo and mmioinfo16 are structures. The structures contain pointers.
Some of these pointers can, under various restrictions, be
examined/changed by an app, the mmio procedure and/or the windows mmio*
routines. Since we can't convert from 32 bit to 16 bit pointers,
everything is internally stored as a 16 bit struct. Note that the
pointers can only be set within wine, although they can be modified
externally, with restrictions.
The info structure can only be obtained and modified by an app as
follows:
1. Call mmioGetInfo
2. Read up until the end of the buffer, or before.
3. (Optional) Call mmioAdvance to advance to the next bit of the file.
4. Repeat steps 2-3 as needed
5. Call mmioSetInfo
Plus the 16 bit versions of the above. Nothing else may be done to the
mmioInfo structure between the mmioGetInfo and the mmioSetInfo, and only
certain fields in the structure can be modified.
When we are required to pass a pointer to the 32 bit struct (from
mmioGetInfo) we do a copy (MMIO_infoMap16To32). When mmioAdvance is
called we then have to update our 16 bit version of the struct at the
same time we advance the 32 bit version which was passed to us. We then
do pointer arithmatic on our internal 16 bit version to keep it up to
date. The bit that got #if 0'd out points the internal version's pchNext
member forward by the ammount which was read from the buffer passed in
from the app. mmioSetInfo then calls MMIO_infoUnmap16To32, which unmaps
the buffer by updating only the values which could have been changed
(see the comment). Again, its impossible to do an MMIO_infoMap32To16,
because of the pointer issue.
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.
That's what I understand anyway, partly from Eric's explanations in
private mail, and from MSDN.
The reason I started doing all of this is because the original code
assumed that the mmio procedure was always 16 bit. In the case of a
custom mmio procedure, this is not neccessarily the case. Eric Pouech
noticed this bug while helping me to get sound in Encarta working.
The mmioAdvance stuff was fixed to work with the new system, but not
tested. I did ask on wine-devel if anyone had any apps which used
mmioAdvance, but didn't get a response from anyone. Its quite possible
that it doesn't work, but I think that the changes I made were right. I
may have missed updating something somewhere though. See
http://www.integrita.com/cgi-local/lwgate.pl/WINE-DEVEL/archives/1999-12/Author/article-416.html
although the diff got modified a bit before I submitted it.
Thanks,
Bradley
