Re: VST wrapper
On Jun 25, 2007, at 6:01 AM, Dan Kegel wrote: Hi N8, [How can I write a shared library that uses Wine and can be called from a non-winelib app?] This is a somewhat frequently asked question. I did try to find the answer in the documentation before posting here but couldn't find anything. As Stephan explained, wine's code requires that the process have been set up somewhat specially. This is taken care of by the sources in the loader subdirectory. In a perfect world, some of that code would move into the operating system's process loader... then one could mix and match win32 and unix calls more easily. Anyway, knowing about the code in that directory is key to understanding why what you ask is hard, and in finding a workaround. Ok, I guess it's not simple, which is what I wanted to know. I don't have time to become an expert in loading/linking windows programs, so I suppose I can live with an IPC-based solution. Thanks for the help, and thanks to Stefan and Tom as well. -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science --> >>>-- Mojave Project -- http://mojave.cs.caltech.edu -->
re: VST wrapper
Hi N8, [How can I write a shared library that uses Wine and can be called from a non-winelib app?] This is a somewhat frequently asked question. As Stephan explained, wine's code requires that the process have been set up somewhat specially. This is taken care of by the sources in the loader subdirectory. In a perfect world, some of that code would move into the operating system's process loader... then one could mix and match win32 and unix calls more easily. Anyway, knowing about the code in that directory is key to understanding why what you ask is hard, and in finding a workaround. - Dan
Re: VST wrapper
Hi, > In case I'm being unclear, here's how it breaks down. There's a host > application that's native OS X and knows nothing about Wine. I'd > like to write a plugin that, when it's loaded, will load a windows > dll. The host will call into the plugin, which will call into the > dll. The dll will make upcalls to the plugin, which will in turn > call up to the host. The dll will probably be running a windows gui > as well and making calls to various windows APIs. > > So is this possible? I'm pretty new to Wine and Windows programming > so forgive me if the answer to this question is obvious. Yes, this is possible. I wanted to build a wrapper from Palm Desktop to pilot-link some time ago to use Documents To Go with pilot-link, but I gave up on the lack of time(and re-entered wine with d3d some time later). The main issue you have is that your plugin, that loads the dll, needs to run in Wine's environment in order to be able to load the dll. So you have to write a winelib dll. If the plugin is loaded as a library in your host app, the whole host app would have to be a winelib app. Not good :-( So you can split your plugin into two parts, one is the plugin that runs in the host app, the other one is a seperate winelib application that runs in a seperate process and loads the win32 dll. That way the dll gets the virtual memory setup it needs. The two parts of your plugin can use any Unix IPC techniques you feel like using - sockets, pipes, shared memory, semaphores, whatever. You could forward function calls using pipes, transport bigger blobs using shared memory, and synchronise everything using semaphores(and implicit pipe synchronisation).
Re: VST wrapper
On 6/25/07, Nathaniel Gray <[EMAIL PROTECTED]> wrote: By the way, please CC me with replies. I'm not set up to receive mail from the list. Might want to look into Codeweavers Crossover or Crossover Office. One of those handles IE plugins in linux firefox quite nicely. Should be a good starting point. Other people may have suggestions on how to achieve what you are looking for with standard wine, but I'm not sure. -- Thanks Tom
Re: VST wrapper
By the way, please CC me with replies. I'm not set up to receive mail from the list. Thanks, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science --> >>>-- Mojave Project -- http://mojave.cs.caltech.edu -->