SetupApi.DLL or how does Wine work.

[Gerold]

Hello,

this is my first post. I am using Wine and CrossOver since a few months and now I have a problem with a program.

The Windows program is using a HID device and needs the SetupApi.DLL to run. It does not run under Wine or CrossOver and I found out that it uses
GetProcAddress()
to get the address of the function SetupDiInstallDeviceInterfaces and GetProcAddress does not find the address cause it's not in SetupApi.DLL.so (as I think, see below)

I found SetupDiInstallDeviceInterfaces in SetupApi.h in
Wine 2.8
Wine 3.0.3 stable
Wine 3.17 development
sources, but not somewhere else.

If I search for other functions like SetupDiGetSelectedDevice, I do find it in SetupApi.h AND SetupApi.spec.

So why SetupDiInstallDeviceInterfaces is not defined in SetupApi.spec?


Do I understand it correctly when I see (as example) in SetupApi.spec

@ stdcall SetupDiLoadClassIcon(ptr ptr ptr)
This means the function is supported in Wine

@ stub SetupDiInstallDevice
This means the function is NOT supported in Wine and will show a "fixme" message

But what is when the function is completely missing? As for SetupDiInstallDeviceInterfaces.

Thanks for an answer.
Gerold

BTW:
It's the same problem for another function: SetupDiRegisterCoDeviceInstallers

[qwertymnb]

Do I understand it correctly when I see (as example) in SetupApi.spec

@ stdcall SetupDiLoadClassIcon(ptr ptr ptr)
This means the function is supported in Wine

@ stub SetupDiInstallDevice
This means the function is NOT supported in Wine and will show a "fixme" message

But what is when the function is completely missing? As for SetupDiInstallDeviceInterfaces.

stdcall --> ``supported in wine`` as you call it, is more or less correct, the function has some kind of implementation but that also could be a complete stub (printing a fixme)

stub--> Calling this function will not print a fixme but rather a `` call to unimplemented function.@name_of_function@.`` and a nice crash... GetProcAddress wil return NULL.

completely missing --> same as stub, but apparently the spec file also should be updated. Some spec files were written long time ago, maybe when win2000 was brand new. I guess this spec file needs an update....

I suggest you open a bugreport, if the program has a free download please provide ,so testing would be easier.

[Gerold]

stdcall --> ``supported in wine`` as you call it, is more or less correct, the function has some kind of implementation but that also could be a complete stub (printing a fixme)

stub--> Calling this function will not print a fixme but rather a `` call to unimplemented function.@name_of_function@.`` and a nice crash... GetProcAddress wil return NULL.

completely missing --> same as stub, but apparently the spec file also should be updated. Some spec files were written long time ago, maybe when win2000 was brand new. I guess this spec file needs an update....

I made a test and it looks like it's a bit different (used the "setupapi.spec" file from Wine 2.8 to check if the function name is declared)

Examples:

SetupDiGetDeviceInterfaceDetail
Declared in the spec file as:
@ stdcall SetupDiGetDeviceInterfaceDetail...
GetProcAddress returns an address

SetupDiInstallDevice
Declared in the spec file as:
@ stub SetupDiInstallDevice
GetProcAddress also returns an address when stub is defined

SetupDiInstallDeviceInterfaces or SetupDiRegisterCoDeviceInstallers
NOT Declared in the spec file
GetProcAddress also returns NIL (or NULL)

The spec file from 3.17 is the same as for 2.8, so I guess best is to create my own so file or report the missing functions.

[DarkShadow44]

stub--> Calling this function will not print a fixme but rather a `` call to unimplemented function.@name_of_function@.`` and a nice crash... GetProcAddress wil return NULL.

GetProcAddrss won't return null, it will return that address of a function that will give you the crash when it's called.

completely missing --> same as stub, but apparently the spec file also should be updated. Some spec files were written long time ago, maybe when win2000 was brand new. I guess this spec file needs an update....

Completely missing makes GetProcAddress return NULL. And no, not always is a stub wanted - With NULL programs can run a fallback, with a stub they think a function exists and will crash trying to call it.