wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

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

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