Hello all,
thanks much for replies.
On Tuesday 02 of July 2013 18:15:28 Vincent Povirk wrote:
> > What others have suggested in similar situations is to build a Linux
> > application that speaks to the device driver directly, and provides a
> > socket interface, then use sockets from the Windows
> Do you mean by winelib dll that the wine/Liunux native .so style DLL
> is built which is linked/imported through fakedlib to the application?
> That looks like feasible solution and I would consider this solution
> if there is interrest in the application in Linux community
> and not enough resou
> What others have suggested in similar situations is to build a Linux
> application that speaks to the device driver directly, and provides a socket
> interface, then use sockets from the Windows program to talk to the device.
I didn't think of that. A winelib dll providing an API for directly
ac
Hi Vincent, Pavel,
On Tue, Jul 2, 2013 at 8:44 AM, Vincent Povirk wrote:
> Since you're not prepared to spend a lot of time improving Wine's
> driver support, it sounds like modifying core parts of Wine
> specifically to support your application is the best approach.
>
An alternative is to modif
I don't know much about this, but it sounds like a driver is the right
way to do this. It's probably just a case of Wine's driver support not
being good enough yet to support what you want to do. So the less
intrusive/hacky way to fix this would be to improve Wine's driver
support, ideally to a poi
Hello all Wine developers,
[the second attempt to send, is the list subscribers only?]
the firs I would like to express my respect to the work done.
Now to one of our application, we maintain open-source chromatographic
software CHROMuLAN
https://sourceforge.net/projects/chromulan/
Unfortuna
