Possible to call winlib function from native program ?

[Stefan Dösinger]

> Am 30.08.2018 um 23:56 schrieb Wilma Feuerstein <officedev at gmx.ch>:
> 
> I'll have to think about whether it might be easer ripping the respective code out of wine. 
You can try, but my guess is that you'll run into calls to lower-level Wine functions that will cause you the same pain as dlopen does.

> Writing a socket server for ~100 APIs with byref-arguments, with C and Windows-size datatypes on one side, and C# on Linux on the other, where the C# code runs inside a web-server, seems like a daunting task that might be more complex than writing a basic web server.  
You don't necessarily have to marshall the Win32 API. Do you have any internal APIs in your software (e.g. between your host process and a plugin) that is smaller?
> Is it not somehow possible to load the wine-server process inside the libtest.dll.so-constructor ? 
> #define LINUX_ATTACH_DLL __attribute__((constructor)) 
> whether that server process would be started inside the same process or outside wouldn't matter much. 
I don't know for sure. You could read through Wine's init code in loader/main.c, libwine and ntdll and see if you can reconstruct it elsewhere. It is certainly not a simple task.

> If I had to manually dlopen the dependencies between crypt32.dll, user32.dll, advapi32.dll and bcrypt.dll - and whatever - in the right order, that's something I could live with. 
The problem isn't just loading the libraries, you also have to resolve the imports. You might be able to dlopen ntdll.dll and then use LdrLoadDll to load the higher level DLLs.

But just looking at the first lines of LdrLoadDll brings up a call to NtCurrentTeb(), which will return NULL unless you also call the right ntdll init code.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20180904/7af3a2f9/attachment.html>