How to use a windows .lib on linux using WINE
I have been using Qt (uses c++ code + Qt libraries) on the windows platform and am in the process of porting my project onto the Linux platform. Using Qt this has been a very simple process and my project works on the Linux platform with barely any changes required. However, we need to use a 3rd party windows compiled .lib with an associated header file. Clearly this file cannot work under Linux, but I have been reading posts that suggest I could use Wine to do this. So in general my project will work as a normal Linux (Ubuntu) project, but I would like to include this .lib file using Wine . I have not been able to find a definitive answer «how to do this». I am not sure if you use Wine to translate the .lib into a .so file or if you have to statically link it in with some «Wine-like» convention. Can anyone help point me in the right direction? Thanks 🙂
3 Answers 3
AFAIK, you can’t make hybrid applications with Wine (i.e. link C++ Linux executable with some Linux static libraries and Windows static libraries).
One of the solution I suggest is to encapsulate you Windows library in a Windows program that act as some network service, then you make your Linux application talk to your Windows library through the network.
However, it adds complexity to your software, requires you know how to do some network programing (however, these days it is quite easy to do) and is not suitable to every kind of library, especially if your library has some kind of GUI.
Hmm. I like your thinking on the «stand-alone» app, it does add complexity but is a potential solution. Though I am starting to come to terms with the prospect of just making the solution in Windows and running it in this Wine environment. I guess a general question is «is there any disadvantages to using wine». like time costs, reliability, etc? My program only requires very basic things (threads, IP sockets, timers, file IO, and that’s about it!).
I you think about performance penalty, I cannot say. I does not know sufficiently about Wine for that.
Have you tried compiling under Windows and running the entire program under Wine?
I’m not sure you can splice Wine and Linux programs.
Hi RobbieE. I have not tried this, this is (in my mind) a last resort! I would really prefer to develop it in linux if possible. However your point is very valid about if you can «splice wine and linux programs». I have no idea about that either!
Is there any particular reason you want your main program to be native linux and not windows on wine?
Well, the target for my project is a linux (ubuntu) box. Ideally everything would be linux based just so that we don’t need a Windows PC. But other then that.. no there is not 🙂 I mentioned in my comment to Matthieu that I am starting to think this is the way forward. Are there any dis-advantages to running via wine? (same question in my other comment)
I cannot imagine that a hybrid approach would work. In any case, running part of your program as a native application and the other part inside WINE will not give you much advantage over the complete program running in WINE. In either case, WINE is needed.
The main disadvantage of running the complete program in WINE is the look and feel of the GUI which might look a little alien to the system. However, using a proper setup for WINE will minimize the problem. And as a side note, most Linux users are used to different GUI concepts due to the different desktop environments available. Personally I have a lot of GNOME applications running in my KDE desktop.
I would personally try running your program in WINE. It makes development much easier. A circuit simulation tool that is quite famous with electrical engineers uses this approach. It is called LTSpice. While only Windows binaries are available, the developers test it with WINE to ensure that it runs on Linux. Admitted, it is a tool offered for free but the community accepts this approach.
Using Windows DLL from Linux
We need to interface to 3rd party app, but company behind the app doesn’t disclose message protocol and provides only Windows DLL to interface to. Our application is Linux-based so I cannot directly communicate with DLL. I couldn’t find any existing solution so I’m considering writing socket-based bridge between Linux and Windows, however I’m sure it is not such a unique problem and somebody should have done it before. Are you aware of any solution that allows to call Windows DDL functions from C app on Linux? It can use Wine or separate Windows PC — doesn’t matter. Many thanks in advance.
7 Answers 7
I wrote a small Python module for calling into Windows DLLs from Python on Linux. It is based on IPC between a regular Linux/Unix Python process and a Wine-based Python process. Because I have needed it in too many different use-cases / scenarios myself, I designed it as a «generic» ctypes module drop-in replacement, which does most of the required plumbing automatically in the background.
Example: Assume you’re in Python on Linux, you have Wine installed, and you want to call into msvcrt.dll (the Microsoft C runtime library). You can do the following:
from zugbruecke import ctypes dll_pow = ctypes.cdll.msvcrt.pow dll_pow.argtypes = (ctypes.c_double, ctypes.c_double) dll_pow.restype = ctypes.c_double print('You should expect "1024.0" to show up here: "%.1f".' % dll_pow(2.0, 10.0)) It’s still a bit rough around the edges (i.e. alpha and insecure), but it does handle most types of parameters (including pointers).
Any solution is going to need a TCP/IP-based «remoting» layer between the DLL which is running in a «windows-like» environment, and your linux app.
You’ll need to write a simple PC app to expose the DLL functions, either using a homebrew protocol, or maybe XML-RPC, SOAP or JSON protocols. The RemObjects SDK might help you — but could be overkill.
I’d stick with a ‘real’ or virtualized PC. If you use Wine, the DLL developers are unlikely to offer any support.
MONO is also unlikely to be any help, because your DLL is probably NOT a .NET assembly.
This is a common problem. Fortunately, it now has a solution. Meet LoadLibrary, developed by Tavis Ormandy:
I first stumbled across LoadLibrary in an article on Phoronix by Michael Larabel:
A Google researcher has been developing «LoadLibrary» as a means of being able to load Windows Dynamic Link Libraries (DLLs) that in turn can be used by native Linux code.
LoadLibrary isn’t a replacement for Wine or the like but is intended to allow Windows DLL libraries to be loaded that can then be accessed by native Linux code, not trying to run Windows programs and the like on Linux but simply loading the libraries.
This project is being developed by Tavis Ormandy, a well known Google employee focused on vulnerability research. He worked on a custom PE/COFF loader based on old ndiswrapper code, the project that was about allowing Windows networking drivers to function on Linux. LoadLibrary will handle relocations and imports and offers an API inspired by dlopen. LoadLibrary at this stage appears to be working well with self-contained Windows libraries and Tavis is using the project in part for fuzzing Windows libraries on Linux.
Tavis noted, «Distributed, scalable fuzzing on Windows can be challenging and inefficient. This is especially true for endpoint security products, which use complex interconnected components that span across kernel and user space. This often requires spinning up an entire virtualized Windows environment to fuzz them or collect coverage data. This is less of a problem on Linux, and I’ve found that porting components of Windows Antivirus products to Linux is often possible. This allows me to run the code I’m testing in minimal containers with very little overhead, and easily scale up testing.»
More details on LoadLibrary for loading Windows DLLs on Linux via GitHub where he also demonstrated porting Windows Defender libraries to Linux.
Compile Windows C console applications in Linux
Best answer so far, and yes, there was a dupe 😀 Also nice to post the needed packages. Straight answer, to the punch.
Thanks for the answer. Also sorry for the duplicate question, I didn’t spot it. 🙂 Keep up the good work! Thanks again.
On Fedora, we also have resources for learning about compiling for win32 using mingw, an irc channel, the mingw32 utilities and a bunch of pre-built libraries for windows — for more info, see: fedoraproject.org/wiki/SIGs/MinGW .
You can if it’s standard C, and doesn’t use Windows libraries.
C code itself is very portable, and the standard C libraries (libc) are available pretty much everywhere. If your code does printf() and sscanf() and fopen() and so on, then it will just compile and run on another platform. Windows, Linux, BSD, etc.
It’s the libraries other than libc that introduce portability challenges.
Anything that links with Windows-specific platform libraries is trouble. Kernel32.lib, user32.lib, etc etc.
There are third-party libs, too, that, if written in C, should be available across Linux and Windows. PCRE is a good example here — it’s a Regular Expression library written in C, and it’s available on Windows as well as on Linux. there are literally hundreds of libraries in this set.
If you confine yourself to libc and library calls into portable libs, then you will have a portable C application.
Equivalent of import libraries in Linux
In Windows C++ when you want to link against a DLL you must supply an import library. But in GNU build system when you want to link against .so files which are the equivalent of dll you don’t. Why is this? Is there an equivalent of Windows import libraries. Note: I don’t speak about the case where you use GNU C++ in Windows where you have to use import libraries as well. The splitting line is between Windows C++ and Linux C++.
You simply link against the library. For example to link against libssl.so , you would include -lssl in your command string (the lib portion is not included in your option (e.g. -lssl ). If the libraries are not within your standard search path you add -L/path/to/lib to add that directory to the search path. (and that library must know where it resides if additional pieces are needed. When building the library the linker -rpath option can help there.
(Note: this question has nothing to do with C++ language) Well, import libraries only contain code that can be automatically generated linkage-time. Actually, that’s what gcc-for-windows (mingw) does: it can link against *.dll-files without using *.lib files. A note: never use *.lib files that contain ordinals: you might end up with executables that don’t run on a different version of Windows.
2 Answers 2
The linking model is different in Windows and in Linux. Read Levine’s book Linkers and loaders (on Linux, every public symbol of a library is exported, unless you play visibility tricks; on Windows, that is not the case, and exported symbols need to be explicited).
The C++11 standard (read n3337) don’t mention dynamic linking. It is an implementation detail.
There is no «import libraries» in Linux.
On Linux, plugins are loaded (and handled differently than on Windows) by the dynamic loader. See ld-linux(8), dlopen(3), dlsym(3), elf(5)
See also C++ dlopen mini howto. Read also about the Visibility function attribute. See also this question.
.so files which are the equivalent of dll
A Linux shared object (ELF .so file) is not exactly equivalent to a Windows DLL. Read the references given above.
I also recommend reading Operating Systems: Three Easy Pieces and the old Advanced Linux Programming (both are freely downloadable). Later read syscalls(2) and the pages referenced from there.
Be also aware that Linux is free software, so you can download and study the source code of most of its components.
PS. Linux and Windows are really different. Don’t expect to find in Linux the exact equivalent of every Windows feature. Look into Linux with fresh eyes. Take advantage that Linux is made of free software, and consider studying the source code e.g. of the kernel, binutils, GNU libc or musl-libc (both providing some ld-linux.so and libc.so , so a C standard library), GCC or Clang (both providing a C++ standard library above the libc.so ).