wine-devel

wine-devel@winehq.org

9 participants
84458 discussions

Re: VirtualProtect() fixup
by Alexandre Julliard 08 Jun '01

08 Jun '01

520053692817-0001(a)t-online.de (Andreas Mohr) writes: > What isn't the case ? Both fixups ? Or only one of these ? The return value: NT returns a BOOL, 0 or 1. I haven't checked the old protection behavior; but anyway this doesn't belong in VirtualProtect, if we have to ignore the execute permission it must be done consistently throughout the code. > Well, to be exact, no application. > I just found this out by accident. That's what I suspected ;-) > IMHO the probability that some applications exist that are too lazy > to supply their own old_prot variable and that check the return value instead > is rather high, so I think that patch is necessary. We can't start breaking things based only on your suspicion that someone somewhere will have used a feature that isn't documented at all (plus there is a documented way of doing exactly the same thing). If you have an app that needs it sure, otherwise we'll just keep returning a BOOL, as the function is documented to do. > Maybe we should add a winver check, though. No thanks. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: wcmd fix
by Francois Gouget 08 Jun '01

08 Jun '01

On Fri, 8 Jun 2001, Andreas Mohr wrote: > Hi all, > > file_size.XXXPart should be file_size.s.XXXPart. > > Thanks to Lasse Melsaeter for spotting this. That's the 'Dummy struct name problem in wcmd' I sent this morning. But actually whether there should an 's.' depends on the compiler (for Winelib applications) so you should test for NONAMELESSSTRUCT as I did in my patch. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, It's computer science.

1 0

Re: VirtualProtect() fixup
by Alexandre Julliard 08 Jun '01

08 Jun '01

Andreas Mohr <a.mohr(a)mailto.de> writes: > VirtualProtect had two big problems: > > - undocumented return value > - should return protection flags only instead of whole flag setting This isn't the case under NT. Which application depends on that? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Fwd: Re: WINE fix for HOMM3 [bluefire@zauberwald.net]
by Uwe Bonnes 07 Jun '01

07 Jun '01

>>>>> "BlueFire" == BlueFire <bluefire(a)zauberwald.net> writes: BlueFire> Now with the missing diff..... sorry... On Thu, 07 Jun 2001 BlueFire> 11:37:14 BlueFire wrote: >> This is messed up (totally unreadable) formatting. Anyway, how about >> doing a diff -u of your change, and then submitting that patch (in >> more readable form) either to Debian's BTS, or directly to >> wine-patches(a)winehq.com? BlueFire> Sorry, I'm not familiar with either diff or the debian BlueFire> bts. That's why I tried mailing the stuff to you (and to BlueFire> wine-patches). I did a BlueFire> diff /tmp/dos_fs.c dos_fs.c > dos_fs.c.diff Hallo, find some help at http://www.winehq.com/dev.shtml BlueFire> diff -u is preferred due to it's better readability. Appending the plain file makes it easier for others to read your patch. But don't " cut and paste", as that will ofter reformat and make the patch a pain to apply. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Question about the new window design
by Gerard Patel 07 Jun '01

07 Jun '01

Since the patch of 4 June, all windows are created as X windows. This makes one of my test apps to crash; it's creating a child window in the WM_NCCREATE event handling of a window. When the child window is created, X bombs because the X window parent does not exist yet - Wine is trying to call XCreateWindow with parent = 0. What is the best way of fixing this ? Gerard

1 0

Re: stack limit
by Alexandre Julliard 06 Jun '01

06 Jun '01

Stephen Crowley <stephenc(a)placemark.com> writes: > Works like a charm! Thanks. I'm curious though.. I set the stack size > to 64 megs and the application immediately uses up that much ram. Is > that the default behaviour on windows? What stops it from behaving > like a normal stack and just allocating what's needed from the heap? The ram isn't actually used, it's only reserved from the address space with an anonymous mapping. Only the pages that are really accessed will use physical memory/swap, so it doesn't use any more ram than a normal stack. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: stack limit
by Alexandre Julliard 06 Jun '01

06 Jun '01

Stephen Crowley <stephenc(a)placemark.com> writes: > On Mon, Jun 04, 2001 at 12:02:09PM -0700, Alexandre Julliard wrote: > > There is no way to do this at the moment; but it shouldn't be too hard > > to add support for a 'stack' statement in the application spec file. > > Thanks. Where would I look to change this in the source? I'm using some linear > regression DLLs under linux and we have to deal with some fairly large > matrices. Try this: Index: scheduler/process.c =================================================================== RCS file: /opt/cvs-commit/wine/scheduler/process.c,v retrieving revision 1.154 diff -u -r1.154 process.c --- scheduler/process.c 2001/06/06 20:24:13 1.154 +++ scheduler/process.c 2001/06/06 22:46:20 @@ -319,12 +319,6 @@ LPTHREAD_START_ROUTINE entry; WINE_MODREF *wm; - /* build command line */ - if (!ENV_BuildCommandLine( main_exe_argv )) goto error; - - /* create 32-bit module for main exe */ - if (!(current_process.module = BUILTIN32_LoadExeModule( current_process.module ))) goto error; - /* use original argv[0] as name for the main module */ if (!main_exe_name[0]) { @@ -498,7 +492,6 @@ { if (PE_HEADER(current_process.module)->FileHeader.Characteristics & IMAGE_FILE_DLL) ExitProcess( ERROR_BAD_EXE_FORMAT ); - stack_size = PE_HEADER(current_process.module)->OptionalHeader.SizeOfStackReserve; goto found; } @@ -512,6 +505,13 @@ _EnterWin16Lock(); found: + /* build command line */ + if (!ENV_BuildCommandLine( main_exe_argv )) goto error; + + /* create 32-bit module for main exe */ + if (!(current_process.module = BUILTIN32_LoadExeModule( current_process.module ))) goto error; + stack_size = PE_HEADER(current_process.module)->OptionalHeader.SizeOfStackReserve; + /* allocate main thread stack */ if (!THREAD_InitStack( NtCurrentTeb(), stack_size )) goto error; Index: tools/winebuild/README =================================================================== RCS file: /opt/cvs-commit/wine/tools/winebuild/README,v retrieving revision 1.4 diff -u -r1.4 README --- tools/winebuild/README 2000/12/26 01:22:34 1.4 +++ tools/winebuild/README 2001/06/06 22:46:21 @@ -6,6 +6,7 @@ [file WINFILENAME] [mode dll|cuiexe|guiexe|cuiexe_unicode|guiexe_unicode] [heap SIZE] +[stack SIZE] [init FUNCTION] [import [IMP_FLAGS] DLL] [rsrc RESFILE] @@ -39,6 +40,9 @@ "heap" is the size of the module local heap (only valid for Win16 modules); default is no local heap. + +"stack" is the stack size for Win32 exe modules, in kilobytes; default +size is 1024 (1Mb stack). "file" gives the name of the Windows file that is replaced by the builtin. <name>.DLL is assumed if none is given. (This is important Index: tools/winebuild/build.h =================================================================== RCS file: /opt/cvs-commit/wine/tools/winebuild/build.h,v retrieving revision 1.17 diff -u -r1.17 build.h --- tools/winebuild/build.h 2001/05/22 19:55:51 1.17 +++ tools/winebuild/build.h 2001/06/06 22:46:21 @@ -161,6 +161,7 @@ extern int DLLHeapSize; extern int UsePIC; extern int debugging; +extern int stack_size; extern int nb_debug_channels; extern int nb_lib_paths; Index: tools/winebuild/main.c =================================================================== RCS file: /opt/cvs-commit/wine/tools/winebuild/main.c,v retrieving revision 1.17 diff -u -r1.17 main.c --- tools/winebuild/main.c 2001/05/22 19:55:51 1.17 +++ tools/winebuild/main.c 2001/06/06 22:46:21 @@ -27,6 +27,7 @@ int Limit = 0; int DLLHeapSize = 0; int UsePIC = 0; +int stack_size = 0; int nb_entry_points = 0; int nb_names = 0; int nb_debug_channels = 0; Index: tools/winebuild/parser.c =================================================================== RCS file: /opt/cvs-commit/wine/tools/winebuild/parser.c,v retrieving revision 1.18 diff -u -r1.18 parser.c --- tools/winebuild/parser.c 2001/05/22 19:55:51 1.18 +++ tools/winebuild/parser.c 2001/06/06 22:46:21 @@ -559,6 +559,12 @@ if (!IsNumberString(token)) fatal_error( "Expected number after heap\n" ); DLLHeapSize = atoi(token); } + else if (strcmp(token, "stack") == 0) + { + token = GetToken(0); + if (!IsNumberString(token)) fatal_error( "Expected number after stack\n" ); + stack_size = atoi(token); + } else if (strcmp(token, "init") == 0) { if (SpecType == SPEC_WIN16) Index: tools/winebuild/spec32.c =================================================================== RCS file: /opt/cvs-commit/wine/tools/winebuild/spec32.c,v retrieving revision 1.28 diff -u -r1.28 spec32.c --- tools/winebuild/spec32.c 2001/05/22 19:55:51 1.28 +++ tools/winebuild/spec32.c 2001/06/06 22:46:21 @@ -656,7 +656,10 @@ fprintf( outfile, " %ld,\n", page_size ); /* SizeOfHeaders */ fprintf( outfile, " 0,\n" ); /* CheckSum */ fprintf( outfile, " 0x%04x,\n", subsystem ); /* Subsystem */ - fprintf( outfile, " 0, 0, 0, 0, 0, 0,\n" ); + fprintf( outfile, " 0,\n" ); /* DllCharacteristics */ + fprintf( outfile, " %d, 0,\n", stack_size*1024 ); /* SizeOfStackReserve/Commit */ + fprintf( outfile, " %d, 0,\n", DLLHeapSize*1024 );/* SizeOfHeapReserve/Commit */ + fprintf( outfile, " 0,\n" ); /* LoaderFlags */ fprintf( outfile, " %d,\n", IMAGE_NUMBEROF_DIRECTORY_ENTRIES ); /* NumberOfRvaAndSizes */ fprintf( outfile, " {\n" ); fprintf( outfile, " { %s, %d },\n", /* IMAGE_DIRECTORY_ENTRY_EXPORT */ -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Question about the new window design
by Alexandre Julliard 06 Jun '01

06 Jun '01

Gerard Patel <gerard.patel(a)nerim.net> writes: > This makes one of my test apps to crash; it's creating a child window > in the WM_NCCREATE event handling of a window. When the > child window is created, X bombs because the X window parent > does not exist yet - Wine is trying to call XCreateWindow with > parent = 0. > > What is the best way of fixing this ? The X window should be created before the WM_NCCREATE. I'm planning to fix it, but it needs to correctly handle style changes happening in WM_NCCREATE (otherwise we get the managed tooltips bug), and this needs a bit more work. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: uname(1) on UnixWare (Solaris)
by Alexandre Julliard 06 Jun '01

06 Jun '01

Bang Jun-Young <bjy(a)mogua.org> writes: > I've nearly completed new DLL configuration code in configure.in. > Before making it available, I need to know what uname(1) command > prints out on UnixWare (and Solaris?). Why do you need that? Using uname(1) in a configure script is almost certainly the wrong thing to do. -- Alexandre Julliard julliard(a)winehq.com

4 9

Re: [PATCH] Flag unicode structure for user create window
by Uwe Bonnes 06 Jun '01

06 Jun '01

>>>>> "Gerard" == Gerard Patel <gerard.patel(a)nerim.net> writes: Gerard> In the CreateWindow user driver function, it is not enough to Gerard> test the window procedure to know if the cs structure is unicode Gerard> or not : the window can be subclassed, in the cbt hook, for Gerard> example. Gerard> ChangeLog: Hallo, yesterday I tried to find why the findfile95 dialog only displayed the first character ( "o" versus "open"). Your patch fixed it :-) Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

RE: uname(1) on UnixWare (Solaris)
by Patrik Stridvall 06 Jun '01

06 Jun '01

> On Tue, Jun 05, 2001 at 12:18:00AM -0700, Francois Gouget wrote: > > On Tue, 5 Jun 2001, Bang Jun-Young wrote: > > > 1. Configure message is wrong: > > > checking whether we can build a Linux dll... yes > > > I see this even on FreeBSD and NetBSD. :( It's not a > Linux dll, > > > but an FreeBSD/NetBSD dll. > > > > Maybe this message should be changed, yes. But I don't think you > > should put a `uname` there. > > Could you explain me a bit further why we shouldn't do that? As far as the question above is concerned see Francois's reply. I fully agree with him. However regardless of this, uname shouldn't be used (at least not directly). Autoconf provides a standard way to do this (which BTW happends to use uname). It can be used as below. AC_CANONICAL_HOST case $host_os in *cygwin* ) CYGWIN=yes;; * ) CYGWIN=no;; esac It requires two files config.sub and config.guess be distribute along with Wine but that is not really a problem. Perhaps we need to do this anyway. Autoconf 2.50 has discontinued AC_CYGWIN so CYGWIN support seems to require it regardless. Actually the code above is how this is done with Autoconf 2.50. However making CYGWIN an exception is one thing, doing it in other cases is quite another thing. IMHO you will need to provide a _really_ convincing argument that we should make another exception assuming of course we make the first one for CYGWIN which we haven't done yet either.

2 1

RE: uname(1) on UnixWare (Solaris)
by Patrik Stridvall 06 Jun '01

06 Jun '01

> On Tue, Jun 05, 2001 at 11:51:19PM -0700, Francois Gouget wrote: > > Maybe it was not your intention but I was afraid that we > would end up > > with something like: > > "checking whether we can build a `uname` dll..." > > and then a few lines down: > > "checking whether we can build a `uname` dll..." > > > > The problem is then you don't know exactly where the > message comes > > from. > > Sorry but I don't catch what you mean quite well. It's obvious which > message is printed on the screen, isn't it? Yes, but this means that the text no longer describes what it is trying to check. If somebody runs it on a OS called Foo it might trick the him/her into thinking that we know about and have added special handling for OS Foo, which we haven't. > What do you think about replacing "Linux dll" with "GNU style > ELF dll"? Acceptable, but it is not my decision.

1 0

Is this a bug?
by Ian Pilcher 06 Jun '01

06 Jun '01

While poking around in gdi.h, I came upon the following: static inline INT WINE_UNUSED INTERNAL_XWSTODS(DC *dc, INT width) { FLOAT floatWidth; /* Perform operation with floating point */ floatWidth = (FLOAT)width; INTERNAL_XWSTODS_FLOAT(dc, &floatWidth); /* Round to integers */ return GDI_ROUND(floatWidth); } ... and a little later ... static inline INT WINE_UNUSED INTERNAL_YWSTODS(DC *dc, INT height) { FLOAT floatHeight; /* Perform operation with floating point */ floatHeight = (FLOAT)height; INTERNAL_XWSTODS_FLOAT(dc, &floatHeight); /* Round to integers */ return GDI_ROUND(floatHeight); } Shouldn't one of these (probably INTERNAL_YWSTODS) be calling INTERNAL_YWSTODS_FLOAT instead of INTERNAL_XWSTODS_FLOAT? -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

2 1

Re: PATCH: set_thread_buffer fixed
by Gerard Patel 05 Jun '01

05 Jun '01

At 10:43 AM 05/06/2001 +0200, you wrote: >> This calls fails because glibc detects that the value at (esp+28) >> is different of 0 - the real system call is never done, with your >> test app and Wine. > >Well, note that the second version is only pushing a 32bit offset, so >mmap64 accesses random stack space! Yes :-/ <snip> >Yes, check the sys/mman.h header, it should have __off64_t as argument >to the mmap ... asm("mmap64") not __off_t. Yes, it is __off_t and that is the problem; but how this header has come to be in this state is part of what I don't understand. It's marked as part of the glibc, but there is nothing like it in the glibc source that I used to compile. The mman.h in my glibc source is much shorter and the declaration of mmap64 seems correct. I guess that the file in my /usr/include/sys/mman.h is a generated file. I don't even want to count the number of 'mman.h' files on my system :-/ >So I think I can use this test program as check for mmap64 brokeness... Btw, the reference on large files http://www.suse.de/~aj/linux_lfs.html says that locking will never be supported on 64 bits files with glibc 2.1.3 so I don't see why it's necessary to support this case. Gerard

1 0

RE: Stanford Checker
by Patrik Stridvall 05 Jun '01

05 Jun '01

> On Tue, 5 Jun 2001 David.Goodenough(a)dga.co.uk wrote: > > but has anyone thought of running these against Wine? > > I'm not sure if it'd do that much good. They're currently working on > checking the XFree86 tree (see the Xpert mailing list archives on > www.XFree86.org if you want), without a lot of big results > yet. From what > I gather, this tool has very limited and context-dependent > intelligence, Perhaps. But see below. > and is not conceptually very different from what a glorified > version of > Patrik's tools/winapi_check script might be, if given enough people > working on it. Not quite. winapi_check is 1. Specifically written for Wine 2. A syntax analyzer 3. Mostly ad hoc. The Stanford checker on the other hand is 1. Generalized for all C/C++ applications 2. A semantic analyzer 3. Formalized with a script language The way I choose when designing winapi_check was the one of the easiest ways and the way they choose is one of the hardest. So just calling it is glorified winapi_check gives the Stanford people too little credit. Anyway the way Stanford choose is really _very_ hard so what I fear is that they had to make some limiting decisions that makes their tool much less useful. That said regardless of how good the Stanford checker really will be I'm pretty there will be a lot of things that will be _much_ easier checked by writting a script for the Stanford checker than by extending winapi_check, because they have fundamentally different design philosofies. However don't underestimate winapi_check either. There is a lot of things that can quite easilt be checked by adding some clever perl pattern, if:s and a little state. Syntax level matching is not that bad just a little more crude. If somebody have something that he want to be automatically checked, please post it on the list and I will see what I can do.

1 0

Stanford Checker
by David.Goodenough＠dga.co.uk 05 Jun '01

05 Jun '01

On the kernel list and in Alan Cox's patches for the kernel there are a lot of references to some logic checking tools being generated by Stanford. I do not know if these are generally available but has anyone thought of running these against Wine?

2 1

RE: Stanford Checker
by Patrik Stridvall 05 Jun '01

05 Jun '01

> Maybe we have to ask them to check our code, rather than the other way > around? I think it far to much to ask. As Eric said, while it is AFAIK highly configurable with specific scripts, for each kind of check it is currently seems to be very much focused on the Linux kernel. I also believe, like Eric, that it is currently very buggy and that even if they have a powerful enough scripting language to be usable for Wine it will probably need some serious debugging to make the scripts we need to actually work in practise not only in theory. No, as I said, I think it is to much to ask. We will have to wait until they release it whenever that will be.

1 0

Re:Stanford Checker
by Eric Pouech 05 Jun '01

05 Jun '01

last time I checked (a month ago), the tool wasn't freely available (nor finished), so nothing can be done for now when the tool is finished (<put here your date estimation>), one could be able to configure the tool for use in Wine (read: write the scripts for the things we want to check, like windows locks...) but, the tool is (as of today) configured for Linux, and check can only be done agains the Linux tree (AFAIU, they check for specific constructs like getting a spin lock, enabling / disabling IRQ... so highly dependent on Linux source...) however, I don't know (yet) the power of the script language they use for configuring, and whether it could be used for Wine... you'll have to wait until the tool is released... (I suspect, the tool is still buggy *AND* still requires lots of processing by hand - you get a 100 warnings from where only a few are real issues). A+ > On the kernel list and in Alan Cox's patches for the kernel there are a lot > of references to some logic checking tools being generated by Stanford. I > do not know if these are generally available but has anyone thought of > running these against Wine? --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________ Voila vous propose une boite aux lettres gratuite sur Voila Mail: http://mail.voila.fr

1 0

RE: Stanford Checker
by David.Goodenough＠dga.co.uk 05 Jun '01

05 Jun '01

Maybe we have to ask them to check our code, rather than the other way around? Patrik Stridvall <ps(a)leissner.se> on 05-06-2001 12:31:25 PM To: David Goodenough/DGA/GB cc: wine-devel(a)winehq.com Subject: RE: Stanford Checker [Forgot to include list. Trying again.] > On the kernel list and in Alan Cox's patches for the kernel > there are a lot > of references to some logic checking tools being generated by > Stanford. I > do not know if these are generally available but has anyone thought of > running these against Wine? Yes, I have. However the problem is that it is not publicly available (yet) and I read somewhere (don't remember where) that it is no use trying to get copy even if you promise not to distribute it further. I will probably look into it when it is released. I have no idea when that will be though.

1 0

RE: Stanford Checker
by Patrik Stridvall 05 Jun '01

05 Jun '01

[Forgot to include list. Trying again.] > On the kernel list and in Alan Cox's patches for the kernel > there are a lot > of references to some logic checking tools being generated by > Stanford. I > do not know if these are generally available but has anyone thought of > running these against Wine? Yes, I have. However the problem is that it is not publicly available (yet) and I read somewhere (don't remember where) that it is no use trying to get copy even if you promise not to distribute it further. I will probably look into it when it is released. I have no idea when that will be though.

1 0

CVS compilation problem: XvSelectNotify
by Heiko Nardmann 05 Jun '01

05 Jun '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just compiled CVS wine using ./configure --prefix=/opt/wine-20010605 --enable-dll --with-x and get the following error message starting Word: err:module:BUILTIN32_dlopen failed to load .so lib for builtin x11drv.dll: /opt/wine-20010510/lib/libwine_tsx11.so: undefined symbol: XvSelectPortNotify Could not load graphics driver 'x11drv' - -- Heiko Nardmann (Dipl.-Ing.), h.nardmann(a)secunet.de, Software Development secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de), Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7HJ2Opm53PRScYygRAkZsAKCXRyt3ncR7sFRNatc7/6Bls3+eywCg9sO5 7oombEYBU9llG4o8Gp7LeyA= =a8Qa -----END PGP SIGNATURE-----

1 0

Re: PATCH: set_thread_buffer fixed
by Gerard Patel 05 Jun '01

05 Jun '01

At 07:20 AM 05/06/2001 +0200, you wrote: >Not really, as Alexandre said. > >Could you please test the attached small test program? It fails (of course). Here is the call with my working computer (glibc2.2, linux 2.4) 0x8048668 <main+72>: call 0x8048464 <write> 0x804866d <main+77>: add $0xc,%esp 0x8048670 <main+80>: push $0x0 0x8048672 <main+82>: push $0x0 0x8048674 <main+84>: push %ebx 0x8048675 <main+85>: push $0x1 0x8048677 <main+87>: push $0x3 0x8048679 <main+89>: push $0x4 0x804867b <main+91>: push $0x0 0x804867d <main+93>: call 0x80484a4 <mmap64>p For the failing one : 0x80486c8 <main+72>: call 0x80484dc <write> 0x80486cd <main+77>: addl $0x20,%esp 0x80486d0 <main+80>: addl $0xfffffff8,%esp 0x80486d3 <main+83>: pushl $0x0 0x80486d5 <main+85>: pushl %ebx 0x80486d6 <main+86>: pushl $0x1 0x80486d8 <main+88>: pushl $0x3 0x80486da <main+90>: pushl $0x4 0x80486dc <main+92>: pushl $0x0 0x80486de <main+94>: call 0x804851c <mmap64> This calls fails because glibc detects that the value at (esp+28) is different of 0 - the real system call is never done, with your test app and Wine. In the glibc 2.1.3 source, this test is not explained; in the 2.2.2 source, there is a comment saying that the offset is 'too large'. I understand that the app is calling mmap64 on an operating system that is not supporting it (it's perfectly correct in this case, the failing box having 2.2.5 kernel), and glibc tests if the call can be mapped to standard mmap. I think that the problem is in the compilation; pushing only 6 dwords on the stack to call mmap64 is wrong. I have not yet figured out why, though (I have never been any good with C header problems) Gerard

2 1

Re: PATCH: set_thread_buffer fixed
by Gerard Patel 05 Jun '01

05 Jun '01

At 08:12 AM 03/06/2001 +0200, you wrote: >> After applying your patch to current cvs, rm config.cache, ./configure, >> make depend && make Wine crashes as before. > >You need to run 'autoheader -l include' if any change to acconfig.h >is submitted. Thanks, it worked. Problem solved IMO. Gerard

1 0

mIRC crash when processing large files.
by rpbrown＠xtra.co.nz 05 Jun '01

05 Jun '01

Details how to replicate the crash. (yes its time consuming, but it shows the crash) Ok, this is what I do to crash mIRC in wine. I install the mp3-script for mIRC. http://welcome.to/autoget load the script according to the readme..and join IRC Undernet, any Undernet server will do. /join #mpthree the person we're looking for is SuperServ (an Op) right mouse on the nick, and grab there mp3 list.. you can try other ppls lists, but SuperServ has a rather big list (8Mb) which at the end of the download the script keeps on loading (processing the txt file) ..and then crashes mIRC. Loading _this_ list itself into mIRC under windows normally, mIRC is locked for a 3-4 minutes (processing the list).. maybe wine gives up too soon, since its not getting a response within X amount of time. Or the list is too big for wine to handle? thats my guesses.. I hope this helps. -mdew

1 0

uname(1) on UnixWare (Solaris)
by Bang Jun-Young 05 Jun '01

05 Jun '01

Hi, I've nearly completed new DLL configuration code in configure.in. Before making it available, I need to know what uname(1) command prints out on UnixWare (and Solaris?). As in NetBSD, it's: $ uname NetBSD I guess it would be $ uname UnixWare on UnixWare. I also wonder if UnixWare and Solaris refer to the same. Jun-Young -- Bang Jun-Young <bjy(a)mogua.org>

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel