> 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...
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. Cheers, Sean
