Re: extern variable question

[Dan Kegel]

[e-mail] wrote:
> I'm trying to write a Direct Input regression test and I ran into a
> problem I can't resolve (and the linker too).  dinput.h defines an
> extern variable:
>
> extern const DIDATAFORMAT c_dfDIJoystick;
>
> I can't find this variable in dinput.dll ...

It looks like it was added about ten days ago:
http://www.winehq.org/hypermail/wine-patches/2004/08/0551.html
What date is your wine source tree?
- Dan

extern variable question

[Robert Reif]

Dan Kegel wrote:
> [e-mail] wrote:
> > I'm trying to write a Direct Input regression test and I ran into a
> > problem I can't resolve (and the linker too).  dinput.h defines an
> > extern variable:
> >
> > extern const DIDATAFORMAT c_dfDIJoystick;
> >
> > I can't find this variable in dinput.dll ...
>
> It looks like it was added about ten days ago:
> http://www.winehq.org/hypermail/wine-patches/2004/08/0551.html
> What date is your wine source tree?
> - Dan

I added it.  I can access it fine from within the dinput dll but I can't
access if from a winelib program.  The dll doesn't export it.  The lib
on windows does.

extern variable question

[Francois Gouget]

On Tue, 14 Sep 2004, Robert Reif wrote:
[...]
> > > extern variable:
> > >
> > > extern const DIDATAFORMAT c_dfDIJoystick;

[...]
> > It looks like it was added about ten days ago:
> > http://www.winehq.org/hypermail/wine-patches/2004/08/0551.html
> > What date is your wine source tree?
> > - Dan
>
> I added it.  I can access it fine from within the dinput dll but I can't
> access if from a winelib program.  The dll doesn't export it.  The lib
> on windows does.

Winelib does not support importing variables from other dlls.

My primitive understanding of it is that it's because for importing
functions we just add a small indirection by generating a small stub
that will jump to the right location, while you cannot use that trick
for variables as there is no possible indirection for them.

extern variable question

[Robert Reif]

Francois Gouget wrote:
> On Tue, 14 Sep 2004, Robert Reif wrote:
> [...]
> > > > extern variable:
> > > >
> > > > extern const DIDATAFORMAT c_dfDIJoystick;
>
> [...]
> > > It looks like it was added about ten days ago:
> > > http://www.winehq.org/hypermail/wine-patches/2004/08/0551.html
> > > What date is your wine source tree?
> > > - Dan
> >
> > I added it.  I can access it fine from within the dinput dll but I can't
> > access if from a winelib program.  The dll doesn't export it.  The lib
> > on windows does.
>
> Winelib does not support importing variables from other dlls.
>
> My primitive understanding of it is that it's because for importing
> functions we just add a small indirection by generating a small stub
> that will jump to the right location, while you cannot use that trick
> for variables as there is no possible indirection for them.

I need to generate a dinput.a to access the variables just like 
dinput.lib on
windows.  The problem is how do you generate a library and dll from the
same source code in the same directory?  The Makefiles only have a
single target (.a or .so).

extern variable question

[Alexandre Julliard]

Robert Reif  writes:
> I need to generate a dinput.a to access the variables just like
> dinput.lib on
> windows.  The problem is how do you generate a library and dll from the
> same source code in the same directory?  The Makefiles only have a
> single target (.a or .so).

This is not possible, Winelib doesn't use .a files as import
libraries, so even if you somehow generate that .a library it wouldn't
do what you expect.

extern variable question

[Robert Reif]

Alexandre Julliard wrote:
> This is not possible, Winelib doesn't use .a files as import
> libraries, so even if you somehow generate that .a library it wouldn't
> do what you expect.

OK.  Here is the beginnings of a joystick test.  I want to use  
c_dfDIJoystick2
which is defined as  extern in dinput.h and exists in dinput.dll.so but 
is not
exported.  It's also not exported in windows dinput.dll but it is in
dinput.lib.  This test (minus the wine hack) will compile, link (with 
dinput.lib)
and run fine in XP.   How do I get the same behavior in wine?  I don't
think the #include "../data_formats.c" hack is acceptable.

diff -u -N wine.cvs/dlls/dinput/tests/.cvsignore wine/dlls/dinput/tests/.cvsignore
--- wine.cvs/dlls/dinput/tests/.cvsignore	1969-12-31 19:00:00.000000000 -0500
+++ wine/dlls/dinput/tests/.cvsignore	2004-09-14 21:08:04.000000000 -0400
@@ -0,0 +1,3 @@
+Makefile
+dinput.ok
+testlist.c
diff -u -N wine.cvs/dlls/dinput/tests/dinput.c wine/dlls/dinput/tests/dinput.c
--- wine.cvs/dlls/dinput/tests/dinput.c	1969-12-31 19:00:00.000000000 -0500
+++ wine/dlls/dinput/tests/dinput.c	2004-09-14 21:14:58.000000000 -0400
@@ -0,0 +1,78 @@
+/*
+ * Copyright (c) 2004 Robert Reif
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#define STRICT
+#define DIRECTINPUT_VERSION 0x0700
+
+#define NONAMELESSSTRUCT
+#define NONAMELESSUNION
+#include <windows.h>
+
+#include <math.h>
+#include <stdlib.h>
+
+#include "wine/test.h"
+#include "windef.h"
+#include "wingdi.h"
+#include "dinput.h"
+#include "dxerr8.h"
+
+/* FIXME: in windows, you would link dinput.lib to get c_dfDIJoystick2 */
+#include "../data_formats.c"
+
+static BOOL CALLBACK EnumJoysticks(
+    LPCDIDEVICEINSTANCE lpddi,  
+    LPVOID pvRef)
+{
+    HRESULT hr;
+    LPDIRECTINPUT pDI = (LPDIRECTINPUT)pvRef;
+    LPDIRECTINPUTDEVICE pJoystick;
+
+    hr = IDirectInput_CreateDevice(pDI, &lpddi->guidInstance, &pJoystick, NULL);
+    ok(hr==DI_OK,"IDirectInput_CreateDevice() failed: %s\n", DXGetErrorString8(hr));
+    if (hr!=DI_OK)
+        return DIENUM_STOP;
+
+    trace("---- %s ----\n", lpddi->tszProductName);
+
+    hr = IDirectInputDevice_SetDataFormat(pJoystick, &c_dfDIJoystick2);
+    ok(hr==DI_OK,"IDirectInputDevice_SetDataFormat() failed: %s\n", DXGetErrorString8(hr));
+
+    /* FIXME: do a bunch more stuff here */
+
+    return DIENUM_CONTINUE;
+}
+
+static void dinput_joystick_tests()
+{
+    HRESULT hr;
+    LPDIRECTINPUT pDI;
+
+    hr = DirectInputCreate(GetModuleHandle(NULL), DIRECTINPUT_VERSION, &pDI, NULL);
+    ok(hr==DI_OK, "DirectInputCreate() failed: %s\n", DXGetErrorString8(hr));
+    if (hr!=DI_OK)
+        return;
+
+    hr = IDirectInput_EnumDevices(pDI, DIDEVTYPE_JOYSTICK, EnumJoysticks, pDI, DIEDFL_ALLDEVICES);
+    ok(hr==DI_OK,"IDirectInput_EnumDevices() failed: %s\n", DXGetErrorString8(hr));
+}
+
+START_TEST(dinput)
+{
+    dinput_joystick_tests();
+}
diff -u -N wine.cvs/dlls/dinput/tests/Makefile.in wine/dlls/dinput/tests/Makefile.in
--- wine.cvs/dlls/dinput/tests/Makefile.in	1969-12-31 19:00:00.000000000 -0500
+++ wine/dlls/dinput/tests/Makefile.in	2004-09-12 18:40:09.000000000 -0400
@@ -0,0 +1,14 @@
+TOPSRCDIR = @top_srcdir@
+TOPOBJDIR = ../../..
+SRCDIR    = @srcdir@
+VPATH     = @srcdir@
+TESTDLL   = dinput.dll
+IMPORTS   = dinput ole32 user32 kernel32
+EXTRALIBS = -ldxguid -luuid -ldxerr8
+
+CTESTS = \
+	dinput.c
+
+@MAKE_TEST_RULES@
+
+### Dependencies:

extern variable question

[Alexandre Julliard]

Robert Reif  writes:
> OK.  Here is the beginnings of a joystick test.  I want to use
> c_dfDIJoystick2
> which is defined as  extern in dinput.h and exists in dinput.dll.so
> but is not
> exported.  It's also not exported in windows dinput.dll but it is in
> dinput.lib.  This test (minus the wine hack) will compile, link (with
> dinput.lib)
> and run fine in XP.   How do I get the same behavior in wine?  I don't
> think the #include "../data_formats.c" hack is acceptable.

No, clearly not. I guess the best solution would be to put that data
in one of the existing static libraries, for instance in libdxguid.a.
It's not 100% compatible, but it should be close enough.

extern variable question

[Francois Gouget]

On Tue, 14 Sep 2004, Robert Reif wrote:
[...]
> OK.  Here is the beginnings of a joystick test.  I want to use
> c_dfDIJoystick2 which is defined as extern in dinput.h and exists in
> dinput.dll.so but is not exported.  It's also not exported in windows
> dinput.dll but it is in dinput.lib.

Are you really sure it is not exported by dinput.dll? The usual tools
list all the exported *functions* but I'm not sure they list exported
variables. You seem to think that dinput.lib is a static library which
is very doubtful.
> How do I get the same behavior in wine?

Given the current Winelib capabilities you cannot.

Even if you were to make a dinput.a it would be useless. It would solve
the link error, but you would end up with two c_dfDIJoystick2 variables:
 * one stored in dinput.dll.so
 * one stored in your own application and coming from dinput.a

Your application would read/write the latter variable which would
obviously have no effect whatsoever on the variable stored in
dinput.dll.so.

extern variable question

[Robert Reif]

Francois Gouget wrote:
> On Tue, 14 Sep 2004, Robert Reif wrote:
> [...]
> > OK.  Here is the beginnings of a joystick test.  I want to use
> > c_dfDIJoystick2 which is defined as extern in dinput.h and exists in
> > dinput.dll.so but is not exported.  It's also not exported in windows
> > dinput.dll but it is in dinput.lib.
>
> Are you really sure it is not exported by dinput.dll? The usual tools
> list all the exported *functions* but I'm not sure they list exported
> variables. You seem to think that dinput.lib is a static library which
> is very doubtful.

c_dfDIJoystick2 is a const data structure defined by microsoft and is 
used in
dinput code to initialize the joystick data format.

http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dx8_c/direc...

I did a strings on dinput.dll and dinput.lib.  It's not in in the dll 
but it is in the lib.
What is dinput.lib?  It is not a dll and winedump doesn't recognize it 
but running
nm on it reports that it contains dinput.dll stuff.

Download the DirectX SDK from Microsoft and look at the files in the lib 
directory.

extern variable question

[Filip Navara]

Francois Gouget wrote:
> On Tue, 14 Sep 2004, Robert Reif wrote:
> [...]
> > OK.  Here is the beginnings of a joystick test.  I want to use
> > c_dfDIJoystick2 which is defined as extern in dinput.h and exists in
> > dinput.dll.so but is not exported.  It's also not exported in windows
> > dinput.dll but it is in dinput.lib.
>
> Are you really sure it is not exported by dinput.dll? The usual tools
> list all the exported *functions* but I'm not sure they list exported
> variables. You seem to think that dinput.lib is a static library which
> is very doubtful.

In PSDK/MinGW W32API the [lib]dinput[8].[a/lib] is really a combination 
of static and export library. It contains the 
DIDATAFORMAT/DIOBJECTDATAFORMAT defintions for joystick (c_dfDIJoystick, 
c_dfDIJoystick2), keyboard (c_dfDIKeyboard) and mouse (c_dfDIMouse, 
c_dfDIMouse2) that are compiled to every application using it.

- Filip

extern variable question

[Ove Kaaven]

tor, 16.09.2004 kl. 01.47 skrev Francois Gouget:
> On Tue, 14 Sep 2004, Robert Reif wrote:
> [...]
> > OK.  Here is the beginnings of a joystick test.  I want to use
> > c_dfDIJoystick2 which is defined as extern in dinput.h and exists in
> > dinput.dll.so but is not exported.  It's also not exported in windows
> > dinput.dll but it is in dinput.lib.
>
> Are you really sure it is not exported by dinput.dll? The usual tools
> list all the exported *functions* but I'm not sure they list exported
> variables. You seem to think that dinput.lib is a static library which
> is very doubtful.

He is right. The problem has occurred at TransGaming too, while doing
winelib ports (for Mac); the dinput.lib import library also contains
static structures not exported by dinput.dll. Since this means the
required structures are statically linked into the games, we haven't had
to export the data structure in question before we needed to do winelib
ports. But once we started, though, we've had to create some file
containing them and explicitly link it into the game when porting with
winelib. I'm not sure what solution the Mac guys settled on, but since
they probably couldn't do it Right, that's probably not important to
this discussion.
> Even if you were to make a dinput.a it would be useless. It would solve
> the link error, but you would end up with two c_dfDIJoystick2 variables:
> - one stored in dinput.dll.so

1) Even if you needed to have two copies, what's wrong with that, since
that's obviously how Windows does it? Do we absolutely need to be more
storage-efficient than Windows?

2) You don't need to store one in dinput.dll.so, actually. The data
format is supplied by the application (which usually supplies the
structure linked into it), and dinput just needs to compare it with its
internal format, which does not have to be identical to the official
structure (and in TransGaming's dinput, isn't).
> - one stored in your own application and coming from dinput.a
>
> Your application would read/write the latter variable which would
> obviously have no effect whatsoever on the variable stored in
> dinput.dll.so.

The structure is const and read-only.