Re: Debuging Wine

As pointed out by Lionel this is a list for wine development; not WineX devel or support. I suggest followups to [EMAIL PROTECTED] and remove wine-devel. Jarmo wrote: Hi, I am trackin a weard bug and I would need a help a little. I am trying to run Orbiter in winex. Orbiter runs without

Re: wine-devel digest, Vol 1 #2004 - 15 msgs

On Thu, 12 Jun 2003 20:52:34 +1200, Sir Emmanuel Goldstein scribed thus: wIntegrate appears to use an internal, custom implementation of Winsock. That is, I cannot see it link winsock when i do -debugmsg +dll. I doubt that the correct channel is +loaddll, try with that. Ok, I've run

Windows 2000 winetest results from source release 20030508

I retrieved the wine source release of 20030508. I ran ./tools/winapi/msvcmaker --no-wine. Note: I did this in Cygwin, and I had to make some changes to the perl script to get it to run. I also created a wine subdirectory under each of the test subdirs, and copied test.h into it. The MSVC

couple of questions about pthreads (scheduler/pthread.c) in wine

Hi, I've ported an application which uses a library - let's call it aceutilities.so - which in turn uses ACE library (http://www.cs.wustl.edu/~schmidt/ACE.html). ACE uses libpthread.so library. So the dependency is like this: my_application - aceutilities.so -indirectly via ace library-

Re: couple of questions about pthreads (scheduler/pthread.c) in wine

My questions are: 1) Why Winelib uses it's own implementation of pthreads (at least it looks like this is intention)? Because Wine uses his own threading model to emulate the one used in real Windows. This means that pthread needs to be 'ported' to this model for it to integrate well with

Re: couple of questions about pthreads (scheduler/pthread.c) inwine

After loading application into memory, dynamic linker loads wine stuff first, then when loading aceutilities.so into memory, pthread symbols are defined in module ntdll.dll.so - already loaded into memory - and so it doesn't try to load libpthread.so, because pthread symbols are already

Re: couple of questions about pthreads (scheduler/pthread.c) inwine

This seems to be the case, otherwise we would have never noticed the pthread emulation. We didn't really dig into what the problem was yet though. It might be worth doing that. Is any of the pthread emulation necessary if we're only using winelib, not the native emulation? I read some

Re: couple of questions about pthreads (scheduler/pthread.c) inwine

Thanks, Mike and Lionel. Mike Hearn [EMAIL PROTECTED] wrote: Right. Really, you *want* aceutilities.so to use the Wine versions. In theory, it should all work fine except the threads that aceutilities creates are wine-aware. If it doesn't, that means the Wine pthreads emulation is not

Re: Process termination exit code

Eric Pouech [EMAIL PROTECTED] writes: as reported by Igor Sysoev on WD, exit process code wasn't properly implemented on *BSD it appeared (thanks Igor for all the testings and traces) that after terminate_process request was issued, the client/server pipe got closed because the running

Re: advapi32: added Ace/Acl functions

Could you resubmit your patch using cvs diff -u ? This would be great.

Re: wineconsole init

Could we have settings that avoid the error message about ncurses ? To have working non-buffered keyboard input in dos programs, I must disable curses support.

new compile problem - curses.c:790: conflicting types for `WCCURSES_InitBackend'

I was updating the cvs after the last commit rain from alexander and it does not compile to be sure I removed the tree and checked it out again and I still get the error: gcc -c -I. -I. -I../../include -I../../include -D_REENTRANT -fPIC -DUNICODE -Wall -mpreferred-stack-boundary=2 -gstabs+