First Time inpout32 user - basic question

[rfdes]

I like using MinGW writing 'C' programs for simple tool development. I have no legitimate experience with C++ so the whole name-mangling issues are foreign to me. The driver was successfully installed and I put together a simple program for testing to see if I can access the library functions. The library search path was properly set up in MinGW (using Codeblocks) and I get the unresolved external message to the IsXP64bit function due to name mangling. I have no idea how to resolve this so I would appreciate some help.
Thanks for any help you can offer
Jim

Code: Select all

#include <stdlib.h>
#include <stdio.h>
#include <stdbool.h>

bool _stdcall IsXP64Bit();

int main(int argc, char *argv[])
{
    if (IsXP64Bit() == true) printf("64 bit\n");
}

[phil]

Hi,

I'm not familiar with MiniGW so I cant really answer directly, but as far as I know, the functions names are exported without mangling (confirmed with depends.exe) so I don't understand why you would have a problem with that.

Can you confirm what version of inpout32.dll you are using (and/or inpoutx64.dll) - Are you using the correct one (32bit or 64bit - I dont know if MiniGW is available in both x86 and x64)

Thanks,
Phil

[rfdes]

Hi Phil -
I appreciate your response. I, too, am not familiar with MinGW so I am attempting to work through my issues.

• First off, please confirm that the *.lib files are 'import' libraries, is this correct?
  May I use a C compiler/Linker or must I use C++ tools?

The version of Mingw that I am using is the 32 bit version but I am attempting to link to the inpout32.lib file, which I always am showing: undefined reference to IsXP64Bit(ampersand)0


BTW: I am using your latest build, 1.5.
Boy, I am confused as to why this doesn't work. Any further assistance would be appreciated. Take care
Jim

[phil]

The .LIB files are "import" libraries for linking to the DLL.They dont contain any code/objects, just tells the linker how to link to the DLL - I don't see how they would be even relevant with MiniGW on the vary short things I have just been reading). They can be used with the C/C++ linker.
You shouldn't need the LIB files as the DLL exports the names untangled as I said.

In C++/C you can simply load the DLL (LoadLibrary (), get the address of the function by name, GetProcAddress() and call it.
In MinGW I dont know how you go about this - but either way, the only file you should need is the .DLL file (no libs and I cant see why the .h file would be any use either, other than looking at the definition of the functions to work out what to pass and get back!

Just to make sure the DLL actually works (Im sure that is not the problem here but hey!), have you tried the sample/test programs on my website? (I think there are compiled examples but its been a while since I looked at this - maybe they are all source code) Also, does the InstallDriver.exe report success?

If you cant get any further, then maybe I can grab a copy of MiniGW and try it myself, but have another stab first as I havn't really got the time to learn a whole new environment right now!

Thanks,
Phil

[phil]

Also, please confirm you used InpOut32.dll because it looks like MiniGW is 32bit only so will *need* to use the 32bit DLL (that still works on 63bit windows).

[phil]

OK so I didn't realize that codeblocks was just an IDE wrapping the minigw compiler.
I have downloaded it and re-written my C/C++ sample (on my website) in it - and it works pretty much as is.

Attached is said codeblocks sample (using runtime dynamic loading not compile time linking (i.e. without the.lib)!
Build/Run it and if you have a PC speaker it should make some noise (tested on a VM with VMWare Workstation and Windows 10 guest).

InpOut32Test-MiniGW.zip

For some reason, the function IsInpOutDriverOpen() seems to always return false from MiniGW - cant see why but it works from MS Visual C++ compiier (visual studio) I usually use. Odd!

[rfdes]

Phil -
Thanks for all of your effort setting up Codeblocks, etc. I tried your sample and although the dll was loaded and the library functions appeared to work, I was not able to get any sound from my laptop. So, not sure what's up with that.

I did have some success with my test app by linking not to the import lib but directly to the dll. Evidently that is OK with MinGW. That did work and I was able to get a proper link. So, the import lib is not in a format that makes MinGW happy. It appears that the MinGW is attempting to link symbols: func'ampersand'## with func. There is likely away around this with the linker options. I am also exploring how to create a usable import lib which is supposedly possible using the MingGW dlltool.exe app, although for what I am wanting to do, linking directly to the dll seems to work OK. I need to do more testing before declaring victory, however.

thanks again for you help, take care -
Jim

[phil]

Hi Jim,

I suspect the sound is from the traditional PC beeper (not the sound card) so probably your laptop does not have this legacy accessory?!
I tested with a VM (because it emulates the beeper over the normal sound card channels) so I knew it would make a noise of some sort (I know my PC does have a traditional beeper attached but that is rarer these days so for me the VM made sense (I also avoided loading any more onto my main dev machine )..

So, if you don't get nay error messages output from the program (command line) then it IS working - just you dont have the hardware Im poking around with to make the noise.

Linking to the DLL with LIBs is fine, until there is a new version of the DLL and you need to recompile your app. OK thats not all that likely given that I cant make any changes to the InpOut driver (as I cant re-sign it) but using my run-time loading method will work for ANY version of the DLL (so long as the function names don't change) without you having to rebuild your code, just drop in the different DLL. I don't believe that is the case if you use the LIB because the function addresses will be "hard coded" into the LIBs. Granted, LIBs will be a tad faster, but less portable. Thats why I have recommended using run-time dynamic loading rather than linking in all of my samples. Its also how you do things in general when using un-managed (C/C++) DLLs from .NET (which is my preferred environment these days).

Regards,
Phil

[rfdes]

Thanks again, Phil for the advice. I will work to understand how to build an import LIB that MinGW agrees with.
Take care -