mmsystem16.h incorrect? SEGPTR vs. LPSTR

[Joerg-Cyril.Hoehle at t-systems.com]

Executive summary: I believe LPSTR is all wrong in mmsystem16.h's MCI defs.

Hi,

I've some doubts about the correctness of some definitions in
mmsystem16.h, esp. the use of SEGPTR vs. LPSTR types.

Please compare
typedef struct  {
    DWORD   dwCallback;
    LPSTR   lpstrReturn;
    ...
} MCI_DGV_INFO_PARMS16, * LPMCI_DGV_INFO_PARMS16;
http://source.winehq.org/source//include/wine/mmsystem16.h
typedef struct {
    DWORD   dwCallback;
    SEGPTR  lpstrReturn;
    ...
} MCI_INFO_PARMS16, *LPMCI_INFO_PARMS16;

These definitions do not match.  SEGPTR requires the use of the
MapSL() helper function to correctly access the segmented pointer,
while LPSTR is a linear string pointer.

For reasons I recently explained in
http://www.winehq.org/pipermail/wine-devel/2011-May/090060.html 
I very much doubt that both pointer types were used simultaneously -- unless
the digital video device (mciavi16.dll?) embedded different return
types in its resource file.  It's not impossible, just very unlikely.

Within one winmm, The return type MCI_STRING (value 0001) can *either* denote
linear C strings, or segmented ones.  Should 2 types really have been
used as the above structure definitions suggest, then one will
have a distinct return value in its resource definition file
(e.g. mciavi_res.rc or extractable from the .dll).  For instance,
that's how we derived that there must exist a distinct value for
64bit use we then named MCI_INTEGER64 in Wine's mmddk.h

However, I feel it's more likely that LPSTR above is wrong, that no
distinct return type was used and that segmented pointers were used in
most places within the MCI in 16 bit times, partly because Wine
currently uses the SEGPTR definitions and MapSL() helpers in its
current code base and would have crashed otherwise (but if that code
is never exercised?).

Likewise for MCI_OPEN_PARMS16 and MCI_DGV_OPEN_PARMS16.  Wine's
current MCI code would choke if it had to deal with 2 different types
of pointers here.

To give another example, I find it illogical that MCI_LOAD_PARMS16
takes an LPCSTR, while MCI_SOUND_PARMS16 takes a SEGPTR according to
mmsystem16.h.  It's not about a different name, it's entirely
different content!

I'd be pleased if somebody could grab out an old SDK and have a look
at the includes or otherwise shed light on this issue.

Thank you for your help,
	Jörg Höhle