Re: Re: [DMUSIC/DINPUT] includes fixes

[DMUSIC/DINPUT] includes fixes

[Robert Reif]

[e-mail] wrote:
> Hi Alexandre,
>
> At least for directx headers it's not a good idea.
> many old games (using old directx) need to have compatible headers
> else they won't build (it's why bug 2483 exists: build problem on an 
> old dx game) 
> http://winehq.com/hypermail/wine-patches/2005/03/att-0200/01-includes_and_bug2483.diff
>
> And as for directx < 8, microsoft used to reuse same headers name we 
> need to flag
>
> But for classic windows headers i'm ok with you
>
> Regards,
> Raphael
>
> ----Message d'origine----
> > A: Raphael
> > Copie à: [e-mail]
> > Sujet: Re: [DMUSIC/DINPUT] includes fixes
> > De: Alexandre Julliard
> > Date: 11 Mar 2005 11:04:30 +0100
> >
> > Raphael writes:
> > > --- dinput.h 5 Oct 2004 04:38:15 -0000 1.46
> > > +++ dinput.h 10 Mar 2005 22:13:43 -0000
> > > @@ -640,7 +640,9 @@
> > > DWORD dwData;
> > > DWORD dwTimeStamp;
> > > DWORD dwSequence;
> > > +#if(DIRECTINPUT_VERSION >= 0x0800)
> > > UINT_PTR uAppData;
> > > +#endif
> >
> > As a rule we avoid that sort of thing in Wine (I know there are other
> > such #ifs in that file but they should be removed). It makes no
> > difference for binary compatibility, and it's very unlikely that an
> > app would depend on it at the source level, so it's not worth the
> > extra headaches.
> >
> > --
> > Alexandre Julliard
> > [e-mail]

If you have source written for an early version of DirectX, then you have
two options:
1 port the source to a later version of DirectX
2 use the compatibility structures provided by both Microsoft and wine

In the second case you would use DIDEVICEOBJECTDATA_DX3 rather
than DIDEVICEOBJECTDATA.

I know it is a pain to have to change the source but if you have the
source, at least you have that option.

[DMUSIC/DINPUT] includes fixes

[Raphael]

Hi
> If you have source written for an early version of DirectX, then you have
> two options:
> 1 port the source to a later version of DirectX
> 2 use the compatibility structures provided by both Microsoft and wine
>
> In the second case you would use DIDEVICEOBJECTDATA_DX3 rather
> than DIDEVICEOBJECTDATA.
>
> I know it is a pain to have to change the source but if you have the
> source, at least you have that option.

It can be a solution, but a real pain.

For binary compatibility, isnt a problem as we must check size/version of 
structures

Regards,
Raphael

[DMUSIC/DINPUT] includes fixes

[Alexandre Julliard]

[e-mail] writes:

[e-mail] wrote:
> At least for directx headers it's not a good idea.
> many old games (using old directx) need to have compatible headers
> else they won't build (it's why bug 2483 exists: build problem on an
> old dx game)

What sort of code breaks because of extra fields in a structure? Could
you give an example?

[DMUSIC/DINPUT] includes fixes

[Raphael]

On Friday 11 March 2005 17:47, Alexandre Julliard wrote:
> [e-mail] writes:
>
> [e-mail] wrote:
> > At least for directx headers it's not a good idea.
> > many old games (using old directx) need to have compatible headers
> > else they won't build (it's why bug 2483 exists: build problem on an
> > old dx game)
>
> What sort of code breaks because of extra fields in a structure? Could
> you give an example?

Almost all old dinput codes (or you can say old non-portable and buggy 
games) :)

I'll try to retrieve a little sample

Regards,
Raphael