Same thing here. Wrote enough of a COM implementation that some software could be compiled native on Linux. The cool bit was that we automatically generated the Python bindings as well, so all the COM components were easily accessible for scripting.
Note that the author is Tavis Ormandy, the guy who (among many, many other things) discovered one of the worst Windows security vulns, that was patched last month -- and from the README it seems like this is part of the toolchest he used for this particular discovery.
To all people wondering why not wine or winelib - this is for ease of debugging and fuzzing DLLs, not for actually running software. Wine and Winelib bring way too much baggage for those uses.
This reminds me of a tool Jeff Roberts wrote at RAD Game Tools which would repackage libraries so they were loadable on Linux. At the time the motivation was that MSVC was generating much better code than GCC for Bink, so he'd compile on Windows with MSVC and cross-link to Linux with his custom tool.
Of things I have benchmarked in the past 5 or so years GCC has not been beaten by GCC for any of my workloads or benchmarks. I do mostly things related to 3d graphics and are heavy on the CPU, but what little IO I have done follows this pattern too.
As near as I can tell msvc is strictly inferior except for windows community adoption than gcc/mingw. Of course, benchmark your workload, I could be doing something odd that you are not.
This is cool and a lot lighter than WINE, though the important keyword is self-contained Windows libraries. I gather this won't work on DLLs that call any of the plethora of Windows APIs. I'm actually very surprised that any non-trivial DLLs are self-contained in this way, like his example of Windows Defender which I thought would call 1000 Windows API functions.
If you like this, you might also like the Witchcraft Compiler Collection[1] by Jonathan Brossard.
It approaches from a different angle (relinking), but (as far as I understand it) can help to solve the same problem Tavis tackles. In the end they both allow the dynamic analysis of PE files in Linux. Both tools only work if the architecture is the same in both worlds, I think.
EDIT: [2] is an intro to the Witchcraft Compiler Collection from Black Hat Europe 2016 which is probably more helpful than the link to the repo.
Winelib is used to port Windows C++ projects to Linux, and Wine is intended to run full Windows applications. This project is intended to allow native Linux code to load simple Windows DLLs.
The closest analogy would be ndiswrapper but for userspace.'
Yes, I've written a windows dll loader for linux based on wine myself. It's fairly simple to add support for LoadLibrary() and GetProcAddress() to a linux program using wine libraries.
There are stubs, or reimplementations on top of the C library, for a relatively small subset of functions: https://github.com/taviso/loadlibrary/tree/master/peloader/w... (see e.g. Files.c in there for an example of mapping Windows API functions to libc).
Very cool, to load .dll, so tests/builds/packaging can be run in Linux. There is also the possibility of signing .exe/.dll on Linux. AFAIK, the remaining stuff is to sign .msi files.
I read the readme, but i still can't understand how is different than winelib (and i don't know much of ndiswrapper internal).
I understand that since is a debugging oriented tool has a different scope than wine, but why don't use (at least partially) the already implemented windows function?
I am missing something? maybe this is more efficient o maybe wine is not enough modular?
While I agree the grandparent's comment doesn't add much to the conversation, and even has many obvious answers, why is a more interesting question.
You are basically questioning if there is a need to change the status quo, or put in physics terms, why do you want to expend energy to move from the local stable point? What is the point with higher stability you want to reach, and what are the characteristics that make this point desirable and justify the energy expenditure?
I don't know if I would like software ported to Linux in this way. I already have mixed feelings about WINE. My concern is really on the legal side of things. What if these things are patent protected and people start getting sued?
I implemented everything it needed. COM functions like CoCreateInstance, entry points like DllCanUnloadNow, Windows Sockets and whatnot.
The registry API! Ha. I mapped HKEY_CURRENT_USER to configuration files rooted in the user's home directory, and HKEY_LOCAL_MACHINE to /etc.
The lib's DllRegisterServer nicely registered its COM class inside the fake registry.
Don "COM is Love" Box would have teared up had he seen this.