On Fri, Jun 06, 2003 at 06:36:36PM +0300, Shachar Shemesh wrote:
Stefan Sperling wrote:
Will this affect my whole app or can I tuck the winelib dependency away in a seperate module? Again, I bet there's a lot of documentation on that in the sheer amount of wine docs, is there?
Stefan
This will, in fact, affect your entire app. You can, however, create a stub utility. This stub will be the winelib. You should be able to use it from a regular ELF exec, and communicate with the PE DLL that way. Not sure what the implications be in your case, however.
I thought about creating a class (I'm in C++) that will create a subprocess loading dlls via winelib (ie just as you would in windows). It shall do the forking and inter-process-communication involved itself, and the code using the class shall be able to handle the dll just like a "normal" shared object:
LoadLibraryA GetProcAddress FreeLibrary
or whatever I'll call them...
As for implications, there is the story with the memory layout of structs I'll be passing to the dlls... will they have to be linked with the winelib too? But that design is about according to what you were saying, isn't it?
I cannot figure out yet to what extend my program will have to be dipped into the winelib. Mmmh... Looking at it now it might even be easier to just write the whole thing as if it was to run under windows and compile it against the winelib. But I'd actually rather not get my hands too dirty on the windows API ;-)
Any suggestions?
thanks a lot stefan