On Sat, Dec 23, 2000 at 01:23:05AM +0100, Gerald Pfeifer wrote:
Current CVS sources cannot be built with BSD make (FreeBSD 4.2) any
longer.
The first error I get is the following, though I'm afraid there may
be further ones hidden:
/usr/bin/gcc -shared -Wl,-soname,libkernel32.so
On Fri, 29 Dec 2000, Marcus Meissner wrote:
The first error I get is the following, though I'm afraid there may
be further ones hidden:
/usr/bin/gcc -shared -Wl,-soname,libkernel32.so
-Wl,-rpath,/usr/local/WINE/lib kernel32.spec.o comm.spec.o
kernel.spec.o stress.spec.o system.spec.o
Eric Pouech wrote:
sigh... this should finally solve all the recent issues (from yesterday commits)
I really wonder if the patches have been tested before being applied...
that should be done by now... a couple of losted hours...
Sorry for the unaligned access patch typos :-( I tested
Hello,
as Alexandre said, we should not include "config.h" in any of
the standard Windows header files. Unfortunately, this makes
a problem in winsock.h rather difficult to fix.
The basic problem is that winsock.h currently tries to use
the system's standard types / defines like sockaddr,
On Fri, 29 Dec 2000, Ove Kaaven wrote:
[...]
Why do we have to put up with that? We know why (because X autorepeat
isn't detectable). So this patch goes to the root of the problem...
Is there a chance that this could help (or even is related) with bug
39: "PrgWin95: Wrong message sequence
On Fri, 29 Dec 2000, Ulrich Weigand wrote:
[...]
It simply means that we will always have problems when we try to
use either OS-dependent or CPU specific features in Windows headers.
See e.g. my other mail on the winsock.h problems ...
It seems I missed your other mail. But anyway, 'we'
I tried accessing CVS Web today and it is broken. Actually I think
it's been broken for some time because I remember trying to access it
last week and failing to do so (but I forgot to report it so it's my
fault).
Here's the message:
Error
Error: Unexpected output from cvs co: cvs
Ulrich Weigand [EMAIL PROTECTED] writes:
Well, the IMO most important configure checks are CPU architecture
and OS specific (e.g. location of system headers / libraries and the
like). While there are of course also compiler / toolchain dependent
checks, those should matter only to the build
Alexandre Julliard wrote:
Ulrich Weigand [EMAIL PROTECTED] writes:
Well, the IMO most important configure checks are CPU architecture
and OS specific (e.g. location of system headers / libraries and the
like). While there are of course also compiler / toolchain dependent
checks, those
Francois Gouget wrote:
On Fri, 29 Dec 2000, Ulrich Weigand wrote:
[...]
It simply means that we will always have problems when we try to
use either OS-dependent or CPU specific features in Windows headers.
See e.g. my other mail on the winsock.h problems ...
It seems I missed your
On Fri, 29 Dec 2000, Ulrich Weigand wrote:
[...]
Basically the is to rewrite 'winsock.h' like we will for all the
msvcrt headers.
Are you already working on this?
No, not yet. I'm not sure when I'll have time to start working on it.
This is currently one of the remaining
issues
Ulrich Weigand [EMAIL PROTECTED] writes:
Would you prefer, then, to have things like endianness be decided
by explicit check for certain, named, architectures instead of
via a generic configure check? We could have a section in, say,
windef.h setting those defines, e.g.
#if
On Fri, 29 Dec 2000, Francois Gouget wrote:
On Fri, 29 Dec 2000, Ove Kaaven wrote:
[...]
Why do we have to put up with that? We know why (because X autorepeat
isn't detectable). So this patch goes to the root of the problem...
Is there a chance that this could help (or even is
On 29 Dec 2000, Alexandre Julliard wrote:
Ove Kaaven [EMAIL PROTECTED] writes:
Seems Alexandre applied my first signal_i386 patch. So here's something
slightly less likely to attract cheers... blocking of all signals until
the %fs is set in the signal handler. If an async signal occurs
François Gouget [EMAIL PROTECTED] writes:
The current way to do it (i.e. the one that does not generate
warnings) is to write:
HWND hNullHandle = 0;
but when HANDLE becomes a pointer it should become:
HWND hNullHandle = NULL;
IMNSHO it might just as well remain as 0. There is
Ove Kaaven [EMAIL PROTECTED] writes:
Not unblock them? But wouldn't that cause problems when some signal
handlers throw exceptions, and the exception handler decides to take the
exception and thus force a stack unwind? I assumed that if that happened,
then the normal sigaction mechanism
On 29 Dec 2000, Alexandre Julliard wrote:
François Gouget [EMAIL PROTECTED] writes:
The current way to do it (i.e. the one that does not generate
warnings) is to write:
HWND hNullHandle = 0;
but when HANDLE becomes a pointer it should become:
HWND hNullHandle = NULL;
-Original Message-
From: Eric Pouech [EMAIL PROTECTED]
To: Guy L. Albertelli [EMAIL PROTECTED]
Cc: Wine Devel [EMAIL PROTECTED]
Date: Friday, December 29, 2000 2:03 AM
Subject: Re: Problem with Winedbg
"Guy L. Albertelli" wrote:
Pardon me for being stupid in public, but after changes
"Guy L. Albertelli" wrote:
I understand, but Wine does not seem to attempt to load the winedbg.so. The
attached trace (+module,+dosfs,+seh) shows the exception being caught and
the debugger started (format was "H:debugger/winedbg %ld %dl"). The debugger
process gets created and wine (via the
19 matches
Mail list logo
