SMitchell at phoenix-interactive.com
Thu Nov 28 08:39:59 CST 2002
> 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
> 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...
Without SignalObjectAndWait() I imagine that many medium sized to large apps
would have to consider alternative threading libraries... the app I'm trying
to port uses it quite a bit to prevent race conditions. As an interested
party rather than a developer I'd suggest that the effort would be best
spent implementing SignalObjectAndWait() before worrying about pthread
compatibility, but I don't know the extent of the work involved.
For my own porting project I'm now considering at a "clean" port without any
Windows calls - fortunately we only use the thread calls and some file
system calls from the Win32 API - but I suspect that this might present a
roadblock to other projects hoping for a painless port.
In any case, you folks have done a great job with Wine and winelib, and I
thank you for it.
More information about the wine-devel