FWIW, my problem is the oft-asked How do I call functions in a Windows
DLL from an ELF process? I appreciate WineLib is an option, and have
run into a number of snarls along that path:
Well, see me discussing that with Bill a few days ago on the mailing
list archives. Basically you have to
Hi,
As we've been getting quite a few reports of glibc 2.3.x related
failures in bugzilla lately, it makes sense to mark them as dupes of a
bug, so I've started duping them against bug #1343
http://bugs.winehq.com/show_bug.cgi?id=1343
That way, when these problems are sorted out, we won't have
On Wed, 26 Mar 2003, Eric Pouech wrote:
Alexandre Julliard wrote:
I think the code is wrong, we shouldn't store a Linux-only define in a
Windows structure, we should use a Windows define. Any one knows what
the right value should be?
the code is wrong (evil cut paste IMO). we should use
On March 31, 2003 11:31 pm, Alexandre Julliard wrote:
Yes, it's just that I don't like to add non-Unix APIs to the
portability layer, but I guess there are good reasons for making
an exception here.
I agree -- adding non-Unix APIs is not a good idea. 100% with you.
But this one is one
I have some RedHat Notes
RedHat 8.0 out of the box
Wine compiles fine, no extra options are needed
RedHat 8.0 up2date with glibc-2.3.2-4.80
Wine compiles fine, no extra options are needed. But if wine has been built
on the RedHat 8.0 OTB, then you should download a clean
http://bugs.winehq.com/long_list.cgi?buglist=1349
I think bug 1349 is related to the below conversation.
http://www.winehq.com/hypermail/wine-devel/2003/03/0379.html
Robert Reif suggested I send in a note.
--
Rod Taylor [EMAIL PROTECTED]
PGP Key: http://www.rbt.ca/rbtpub.asc
signature.asc
How can you know which version of Windows, WIne is currently emulating ?
Thanks in advance. Stephan
RedHat 9
You need to set the environment variable LD_ASSUME_KERNEL=2.2.5 in the
shell
prior to running configure and prior to running wine.
after installing i suggest to add the line in your winelauncher script
(/usr/local/bin/winelauncher) and to launch associate the .exe extension
with
BiGgUn == BiGgUn [EMAIL PROTECTED] writes:
BiGgUn How can you know which version of Windows, WIne is currently
BiGgUn emulating ? Thanks in advance. Stephan
One posinility is a call to GetVersion().
Bye
--
Uwe Bonnes[EMAIL PROTECTED]
Institut fuer Kernphysik
Rolf Kalbermatter [EMAIL PROTECTED] writes:
While downloading and compiling the latest CVS sources I noticed that the
command line for each (most?) source files reads like
gcc -c -I. -I. -I../../include -I../../include . or similar
This is not a serious problem but the
On 1 Apr 2003, Alexandre Julliard wrote:
It's needed for out of tree builds, in that case the include paths are
all different.
True, but why do we need the -I.? Do we need to ever include anything
from the current build dir?
--
Dimi.
Dimitrie O. Paun [EMAIL PROTECTED] writes:
OK, here's a patch to add _spawnvp to the portability lib. There
are still a few questions:
-- Should we provide the entire family (I wouldn't, unless we
really need them, but that can wait for that need :))?
Yep that can wait.
-- What
Adam Gundy wrote:
a new version of the valgrind patch has been uploaded to sourceforge -
the only change is a small fix to the signal handling which should
prevent signal handler frame uninitialized errors.
http://sourceforge.net/tracker/index.php?func=detailaid=710006group_id=46268atid=445588
On 1 Apr 2003, Alexandre Julliard wrote:
If they link with msvcrt then they are not supposed to use
wine/port.h. To avoid trouble with process.c I'd suggest naming the
function spawnvp, without the underscore prefix, and making it call
the real _spawnvp on Windows.
Cool. Here it is again.
Dimitrie O. Paun [EMAIL PROTECTED] writes:
True, but why do we need the -I.? Do we need to ever include anything
from the current build dir?
Yes, some headers are generated, for instance the y.tab.h files.
--
Alexandre Julliard
[EMAIL PROTECTED]
Alexandre Julliard wrote:
The winsock.h issues should hopefully be fixed now. I'm not sure we
should disable 16-bit code by default, you will want to support that
at some point.
I added a fix for that, hope it will work. The ultimate goal is to use
winegcc etc. in the Wine build process, so it's
Adam Gundy [EMAIL PROTECTED] writes:
a new version of the valgrind patch has been uploaded to sourceforge -
the only change is a small fix to the signal handling which should
prevent signal handler frame uninitialized errors.
I will try to fix this sometime in the next week, depending on whether I
can get CVS access to take advantage of the work Eric Pouech has done.
Alexandre Julliard [EMAIL PROTECTED] 03/28/03 01:56 AM
Robert Shearman [EMAIL PROTECTED] writes:
+static int io_completion_send_data( struct thread
I crash when building an EXE in the new version of Visual Foxpro. Any ideas?
windows = nt351, all dlls built-in. Here's the output leading up to the crash:
fixme:hook:NotifyWinEvent (32769,0x50032,1,0)-stub!
fixme:pidl:SHLogILFromFSIL (pidl=0x4032b090)
fixme:dc:LockWindowUpdate (0x50033),
Andreas Mohr [EMAIL PROTECTED] writes:
[I don't know why this wasn't applied, without any comment;
resending it]
You don't really expect me to apply a patch that adds a #ifdef
FUBAR_CODE, do you?
--
Alexandre Julliard
[EMAIL PROTECTED]
Alexandre,
I am afraid the following patch
revision 1.52 date: 2003/03/31 23:56:35; author: julliard; state: Exp; lines: +63
-60
Try to make winsock.h more portable (based on a patch by Francois
Gouget).
actually caused a portability problem for FreeBSD.
/usr/bin/gcc -c -I. -I.
The problem Rod is seeing is caused by code that I added to
check the return value of an ioctl in OSS_RawOpenDevice.
The code now checks the return value and returns on failure
rather than ignoring it. I don't know if this is a BSD issue or
a hardware driver issue or something else.
Rod Taylor
On April 1, 2003 02:00 pm, Eric Pouech wrote:
another option would be to embed this support as an option
to the wine script (like --valgrind)
This one seems a lot nicer. I can modify winewrap to work
with such an option, if need be.
--
Dimi.
Gerald Pfeifer [EMAIL PROTECTED] writes:
I am afraid the following patch
revision 1.52 date: 2003/03/31 23:56:35; author: julliard; state: Exp; lines:
+63 -60
Try to make winsock.h more portable (based on a patch by Francois
Gouget).
actually caused a portability problem for
On 1 Apr 2003, Alexandre Julliard wrote:
Dimitrie O. Paun [EMAIL PROTECTED] writes:
True, but why do we need the -I.? Do we need to ever include anything
from the current build dir?
Yes, some headers are generated, for instance the y.tab.h files.
Shouldn't these be included with #include
On April 1, 2003 09:24 pm, Francois Gouget wrote:
Though it does not appear to be specified in the standard, all compilers
I know of first look for y.tab.h in the current directory if included
using quotes.
I don't have a standard handy, but AFAIK KR specifies this behaviour...
--
Dimi.
Francois Gouget [EMAIL PROTECTED] writes:
Though it does not appear to be specified in the standard, all compilers
I know of first look for y.tab.h in the current directory if included
using quotes.
At least gcc doesn't do that. It looks in the directory that the
source file came from, which
* )
lrwxrwxrwx1 kevin18 Apr 1 15:29 ntdll.dll.so - ntdll/ntdll.dll.so
lrwxrwxrwx1 kevin18 Apr 1 15:29 libntdll.dll.so - ntdll/ntdll.dll.so
$
That keeps configure happy, but I wonder what I'm doing wrong. This is
Wine built from CVS as of 20030401 (i.e. yesterday).
Suggestions
On April 2, 2003 12:15 am, Alexandre Julliard wrote:
At least gcc doesn't do that. It looks in the directory that the
source file came from, which is *not* the current directory for out of
tree builds. So the -I. is very much needed.
OK, but then we don't need to include the source dir g.
--
Kevin DeKorte [EMAIL PROTECTED] wrote:
RedHat 8.0 up2date with glibc-2.3.2-4.80
Wine compiles fine, no extra options are needed. But if wine has been built
on the RedHat 8.0 OTB, then you should download a clean source tarball or if
you use CVS, you should delete your working dir and
Paul == Paul McNett [EMAIL PROTECTED] writes:
Paul I crash when building an EXE in the new version of Visual Foxpro.
Paul Any ideas? windows = nt351, all dlls built-in. Here's the
Paul output leading up to the crash:
Paul fixme:hook:NotifyWinEvent (32769,0x50032,1,0)-stub!
31 matches
Mail list logo
