Sent a patch to wine-patches for this one and the _set_error_mode() constants. With the patch applied your application should compile fine.
However note that _set_error_mode() and SignalObjectAndWait() are both stubs currently, which means that functionality is not implemented. So if your application calls either of them it will crash...
Ah... gotcha. I may just port the thread object to pthreads and be done with anyway.
Thanks.
Sean
On Wed, 27 Nov 2002, Sean Mitchell wrote:
Sent a patch to wine-patches for this one and the _set_error_mode() constants. With the patch applied your application should compile fine.
However note that _set_error_mode() and SignalObjectAndWait() are both stubs currently, which means that functionality is not implemented. So if your application calls either of them it will crash...
Ah... gotcha. I may just port the thread object to pthreads and be done with anyway.
Wine and pthreads don't play well together. You are quite likely to get into trouble if you try to use pthreads from a Winelib application.
On November 27, 2002 03:44 pm, Francois Gouget wrote:
Wine and pthreads don't play well together. You are quite likely to get into trouble if you try to use pthreads from a Winelib application.
I've heard this several times. Now, without looking into the probelm, can't we integrate (for Winelib apps) with pthreads, the same way we do with glibc locks? Anyone know the issues? Is it impossible, just difficult, or simply nobody bothered?
On Wed, 27 Nov 2002, Dimitrie O. Paun wrote:
On November 27, 2002 03:44 pm, Francois Gouget wrote:
Wine and pthreads don't play well together. You are quite likely to get into trouble if you try to use pthreads from a Winelib application.
I've heard this several times. Now, without looking into the probelm, can't we integrate (for Winelib apps) with pthreads, the same way we do with glibc locks? Anyone know the issues? Is it impossible, just difficult, or simply nobody bothered?
I think that the first problem is that if foo.exe.so links with libpthread.so, then libpthread.so gets loaded and initialized before ntdll.dll.so is loaded and overrides the pthread functions in the C library -> big trouble.
This migh conceivable be worked around using a wrapper like I described for libmfc.so except this time the wrapper would just load libntdll.so and the wrapped executable would link with libpthread.so.
Then I guess it should work since threaded opengl libraries are supposed to work.
But is there really an advantage to using pthread rather than the Win32 threading functions when porting a Windows application? After all one should not have to change the code when porting with Winelib...
On November 27, 2002 08:17 pm, Francois Gouget wrote:
But is there really an advantage to using pthread rather than the Win32 threading functions when porting a Windows application? After all one should not have to change the code when porting with Winelib...
Not for pure Winelib apps of course. But there is huge advantage for libwine apps. That is, Unix apps that just want to make use of some Windows stuff. Like mplayer, or xmms, or what have you. These programs are all multithreaded, and have to jump through big hoops to get to use Wine.
Not mixing well with pthreads is a big no-no from the Principle of Least Surprise point of view. I think we need to fix this for 1.0, and would be real nice if we have a solution for 0.9.
In a perfect world, people would just be able to link -lwine to make use of Win32 DLLs (or what have you).
-
Dimitrie O. Paun -
Francois Gouget -
Sean Mitchell