Possible to Use a .Dll on Linux

Possible to use a .dll on Linux

You could try extracting the ar file (Debian packages are ar files, fwiw) and run file on the contents.

You're not going to be able to use Windows DLLs without translation. The only DLL files that I know of that work natively on Linux are compiled with Mono.

If someone gave you a proprietary binary library to code against, you should verify it's compiled for the target architecture (nothing like trying to use am ARM binary on an x86 system) and that it's compiled for Linux.

That being said...good luck. I hate programming against third-party libraries where I have the documentation and the source.

Using Windows DLL from Linux

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.

Something like .dll on Linux - how to get them?

Better yet, use the package system of the distribution[s] you want to target, e.g. .deb packaging on Debian/Ubuntu/Mint (with aptitude or apt-get, themselves using dpkg), Yum/Rpm on Redhat/Fedora, etc etc.

DLL-s are called shared libraries (files named *.so) on Linux (in ELF format, use objdump, nm ... to explore them, and gcc -fPIC -shared to build them). They can be programmatically loaded with dlopen & dlsym. Beware that there are important differences between windows DLL-s & Linux *.so (dynamic linking don't have the same meaning on Windows & Linux)

How use correctly a .dll file in python on linux and mac

As hoefling explained, *.dll libraries are only for Windows.
At the site you've specified, there already are libraries built for and Linux.

The static lib propa64.a definitely should work on Linux, and I guess if it's for x86 64-bit platform, it should also work on MacOS.

Golang, load Windows DLL in Linux

The short answer is "no": when you "load" a dynamic-linked library, it's not only actually loaded (as in read from the file) but linked into the address space of your running program — by the special means provided by the OS (on Linux-based systems, at least on x86/amd64 platforms that's an external process; on Windows, it's an in-kernel facility, AFAIK).
In other words, loading a dynamic-linked library involves quite a lot of complexity happening behind your back.

Another complication, is whether the DLL is "self-contained" in the sense it only contains "pure" functions — which only perform computations on their input data to provide their output data, — or they call out to the operating system to perform activities such as I/O on files.
The way operating systems provide ways to do these kinds of activities to the running processes are drastically different between Windows and Linux.

The last complication I can think of is dependency of this library on others.
If the library's code is written in C or C++, it quite likely depends on the C library used by the compiler which compiled the library (on Windows, it's typically that MSVCRxx.DLL thing). (A simple example is calling malloc() or printf() or something like this in a library's code.)

All this means that most of a DLL written on Windows for Windows depends both on Windows and the C or C++ standard library associated with the compiler used to build that library.

That's not to mention that Windows DLL uses PE (Portable Executable) format for its modules while GNU/Linux-based systems natively use the ELF format for its shared object files.

Can I call a windows DLL from a linux client?

I have a suspicion that you're not actually trying to ask what you asked.

The .dll file in your example is just a shared library. You can link against shared libraries with GCC. The only question is what you call your library:

// Stage 1: Build and link the library:

gcc -c -o mylib.o mylib.c           // Compile

gcc -shared -o mylib.dll mylib.o    // on Windows
gcc -shared -o libmylib.so mylib.o  // on Linux etc.

The naming convention is really just a convention. Now to link your program:

// Stage 2: Build and link your application:
gcc -c o main.c main.cpp                           // Compile

gcc -o main main.o mylib.dll -lm -lfoo -lgdi32     // Windows
gcc -o main main.o libmylib.so -lm -lfoo           // Linux
gcc -o main main.o -lmylib -lm -lfoo -L/opt/mylibs // Alternatively

So if the code is entirely in your hands, you just build the library first and then link against your project.

If you really mean that the library source code is unavailable and you only have a Windows binary, then the situation is a lot trickier. For instance, the binary formats aren't even compatible.

---

Related Topics