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.