Re: Temporary fix to trying to put a pointer in a DWORD

[Dmitry Timoshkov]

"Vincent Béron"  wrote:
> We try to put a pointer in a DWORD in a static initialization of
> CRITICAL_SECTION_DEBUGs. Of course it doesn't work on Win64. We'll have
> to find a better solution though.

Another way to fix it is to use full 'DWORD Spare[2]' to store a pointer
on Win64 and leave it as it is now for Win32.

--
Dmitry.

Temporary fix to trying to put a pointer in a DWORD

[Vincent Béron]

Le sam 16/10/2004 à 23:54, Dmitry Timoshkov a écrit :
> "Vincent Béron"  wrote:
> > We try to put a pointer in a DWORD in a static initialization of
> > CRITICAL_SECTION_DEBUGs. Of course it doesn't work on Win64. We'll have
> > to find a better solution though.
>
> Another way to fix it is to use full 'DWORD Spare[2]' to store a pointer
> on Win64 and leave it as it is now for Win32.

I tried, but since it's a static initialization you don't have access to
& (addessof), so you can't put the high part in one and the low part in
the other. Maybe with a union, but then we'd extend a MS type.

Vincent

Temporary fix to trying to put a pointer in a DWORD

[Shachar Shemesh]

Vincent Béron wrote:
> Le sam 16/10/2004 à 23:54, Dmitry Timoshkov a écrit :
> > "Vincent Béron"  wrote:
> > > We try to put a pointer in a DWORD in a static initialization of
> > > CRITICAL_SECTION_DEBUGs. Of course it doesn't work on Win64. We'll have
> > > to find a better solution though.
> >
> > Another way to fix it is to use full 'DWORD Spare[2]' to store a pointer
> > on Win64 and leave it as it is now for Win32.
>
> I tried, but since it's a static initialization you don't have access to
> & (addessof), so you can't put the high part in one and the low part in
> the other. Maybe with a union, but then we'd extend a MS type.
>
> Vincent

How about this, then?

Temporary fix to trying to put a pointer in a DWORD

[Vincent Béron]

Le dim 17/10/2004 à 01:24, Shachar Shemesh a écrit :
> Vincent Béron wrote:
> > Le sam 16/10/2004 à 23:54, Dmitry Timoshkov a écrit :
> > > "Vincent Béron"  wrote:
> > > > We try to put a pointer in a DWORD in a static initialization of
> > > > CRITICAL_SECTION_DEBUGs. Of course it doesn't work on Win64. We'll have
> > > > to find a better solution though.
> > >
> > > Another way to fix it is to use full 'DWORD Spare[2]' to store a pointer
> > > on Win64 and leave it as it is now for Win32.
> >
> > I tried, but since it's a static initialization you don't have access to
> > & (addessof), so you can't put the high part in one and the low part in
> > the other. Maybe with a union, but then we'd extend a MS type.
> >
> > Vincent
>
> How about this, then?
>
> -- 
> Shachar Shemesh
> Lingnu Open Source Consulting ltd.
> http://www.lingnu.com/
> Index: dlls/dinput/keyboard.c
>
> RCS file: /home/sun/sources/cvs/wine/dlls/dinput/keyboard.c,v
> retrieving revision 1.9
> diff -u -r1.9 keyboard.c
> --- dlls/dinput/keyboard.c	21 Sep 2004 20:04:37 -0000	1.9
> +++ dlls/dinput/keyboard.c	17 Oct 2004 05:23:04 -0000
> @@ -75,11 +75,12 @@
>  static BYTE DInputKeyState[256]; /* array for 'GetDeviceState' */
>
> static CRITICAL_SECTION keyboard_crit;
> +static const char * const critsect_debug_strid = __FILE__ ": keyboard_crit";
>  static CRITICAL_SECTION_DEBUG critsect_debug =
>  {
>      0, 0, &keyboard_crit,
>      { &critsect_debug.ProcessLocksList, &critsect_debug.ProcessLocksList },
> -
>  0, 0, { 0, (DWORD)(__FILE__ ": keyboard_crit") }
> -
>  0, 0, { HIDWORD(critsect_debug_strid), LODDWORD(critsect_debug_strid) }

Besides the fact that HIDWORD and LODWORD (typo in LODDWORD) do not
exist, it looks fine as long as you don't actually compile it.

Writing those two and compiling yields the error "initializer element is
not constant".

Vincent

Temporary fix to trying to put a pointer in a DWORD

[Shachar Shemesh]

Vincent Béron wrote:
> Besides the fact that HIDWORD and LODWORD (typo in LODDWORD) do not
> exist,

Yes, I was extrapolating on existing macros for readability.
> it looks fine as long as you don't actually compile it.
>
> Writing those two and compiling yields the error "initializer element is
> not constant".

Yes. You are right. If you try to cast them to "unsigned long long", you 
get the compiler to reveal the true problem:
> keyboard.c:86: warning: initializer element is not computable at load time

Which is, I'm afraid, without solution. The compiler is not smart enough 
to understand that the cast (or a shift of 32 bits) is not really a 
mathematical operation, and will refuse to do it if it doesn't know the 
exact value at compile time. I tried doing the same thing with pointer 
arithmetics, but to no avail (the cast fails). I'm afraid this one 
bested me. I don't see a clean solution to this one.

Shachar