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.
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.
In my experience, some code paths are better optimized by cl.exe, some by gcc. Overall difference is negligible though.
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.
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:  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.'
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?
This project allows you to load (some) windows DLLs as-is.