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
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
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
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-
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
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
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
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
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
Could you resubmit your patch using cvs diff -u ?
This would be great.
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.
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+
12 matches
Mail list logo