mmsystem16.h incorrect? SEGPTR vs. LPSTR

[Damjan Jovanovic]

On Mon, May 23, 2011 at 2:54 PM,  <Joerg-Cyril.Hoehle at t-systems.com> wrote:
> 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
>
>
>

AFAICT Wine's 16 bit headers cannot be used to compile Win16 code into
a Winelib. The only purpose of Wine's 16 bit headers is to allow 32
bit code to read and write 16 bit structures and thus play nicely with
16 bit binaries. That's why Wine's types and names of 16 bit fields,
structures, functions and headers don't always match what Win16
actually used, and why those headers are in a special directory that
won't exist on any Windows API (include/wine/).

According to Openwatcom's headers, LPSTR is a FAR pointer to char.
"FAR" is a 16:16 segmented pointer, which makes sense, because Win16,
being 16 bit, had no 32 bit linear pointer type in user-space (only
kernel VxDs had it). So the Win16 MCI headers' LP[C]STRs were still
16:16 pointers to char.

The SEGPTR type doesn't exist on Win16 at all. It's a Wine invention
to conveniently mark a 16:16 pointer and since it's an integer type,
it catches attempts to assign directly between 32 bit linear pointers
and SEGPTRs with compiler warnings. So it seems Wine's headers should
never use LP[C]STR in 16 bit structures, SEGPTR should always be used
instead.

Damjan Jovanovic