February 2003 - Wine-Devel - list.winehq.org

Re: Handle invalid export table

by Eric Pouech

Pavel Lapin wrote: > Running an installer for FAR file manager with turned on win32 debug channel > leads to crash due to invalid address of export table. > This installer can be downloaded at http://www.rarlab.com/download.htm, the > executable file seems compressed with RAR archiver. this is a compressed executable (with the infamous UPX0 & UPX1 sections) basically, your patch is not the right way of solving the problem (look at previous posts on winedevel, and read Wine Cousin or WWN editions 107 108) basically, we need to better detect RVA pointing out of sections to circumvent bogus informations in UPX header A+ -- Eric Pouech

Feb. 27, 2003

Re: Adding shmserver

by Stefan Jones

On Thu, 2003-02-27 at 19:02, Alexandre Julliard wrote: > Boris Reisig <boris(a)boris.ca> writes: > > > I saw previous posts about the shmserver solution. Its an excellent idea but > > will it be included in wine? > > No it won't. It's a neat hack, but it doesn't preserve the core idea > behind the server design, which is that processes are properly > isolated. With the shm server you basically go back to the Win9x days > where any buggy process can trash the system structures; and I don't > think that this is where we want to go. Is this because you cannot have a single wineserver per main process, but a global one for all applications? This would be so because of various functions like, I guess, IPC and message passing. If a windows program under wine does a faulty Win32 call, it it should cause an error, and possibly crash; I take it you are referring to knock on effects to other processes using the same wineserver. But I would hazard a guess that *some* Win32 functions which only effect that process can use the shm thing, the memory only being shared between the threads in the process. Just wondering, Stefan -- Stefan Jones <cretin(a)gentoo.org> Gentoo Linux

Feb. 27, 2003

Re: Consoles (3/3)

by Eric Pouech

> Well in that case you have to use a separate console. It would be nice > to have the possibility to detect that the Unix tty is not available > and automatically pop up a console in that case; but unconditionally > creating a console is wrong, there are many cases where you don't want > that. well, if you really want to do that, you have to decide on what you want winedbg to use as input / output streams : 1/ the unix stdin / stdout that winedbg will get upon startup => those would be inherited from the offending app (of course those streams could be redirected to something else than the controlling console) 2/ the current windows-console (if any) of the offending process note that of course 1/ and 2/ could happen at the same time the nasty thing, for example, for implementing one would be to do something like (whithout error handling): if in jit mode { if (!isatty(0) || !isatty(1)) { /* restart debugger so that it'll get the right console hooked to 0/1 */ the steps here are: create a new event relaunch dbg with something like * wineconsole -- %argv[0] --pid=<cur_pid> --evt=<new event> wait on <new event> signal old event terminate this process, now that the child has attached } } which I find particulary ugly A+ -- Eric Pouech

Feb. 27, 2003

Re: POSIX / pthreads / wineserver - can I help?

by Stefan Jones

On Thu, 2003-02-27 at 18:56, Alexandre Julliard wrote: > That's not really the right comparison, the wineserver is not an > equivalent of the linuxthreads manager; it's more an equivalent of the > Windows kernel. But at least the majority of the thread related functions can be moved to pthreads as per the old pthreads-wine patch. That should cut down on the number of wineserver calls. > You can't really do that; generic pthreads simply doesn't offer the > functionality we need. It's possible to use the glibc nptl pthreads, > but that's only because of the way they are implemented on top of > kernel threads; this isn't a general property of pthreads, so a 100% > POSIX threaded Wine is not possible. I looked at some of the windows API and I saw the extra non-POSIX functions, like GetProcessHandleCount etc. which make wine's life difficult. > Once I get the nptl support working there will probably be a number of > things that can be done to take better advantage of the new threading > support, and any help with that is welcome. But in all cases such code > can only be added as an option, it can't replace the existing code > since we have to run on older kernels as well as on other systems. Well I was only suggesting replacing the custom thread syscall wrappers, where possible, with pthread calls. Doing so will be compatible with older systems, you just will not gain much performance. Anyway, thanks for replying, I'll get on with seeing where wine stops working on my system. Stefan -- Stefan Jones <cretin(a)gentoo.org> Gentoo Linux

Feb. 27, 2003

Re: Adding shmserver

by Alexandre Julliard

Boris Reisig <boris(a)boris.ca> writes: > I saw previous posts about the shmserver solution. Its an excellent idea but > will it be included in wine? No it won't. It's a neat hack, but it doesn't preserve the core idea behind the server design, which is that processes are properly isolated. With the shm server you basically go back to the Win9x days where any buggy process can trash the system structures; and I don't think that this is where we want to go. -- Alexandre Julliard julliard(a)winehq.com

Feb. 27, 2003

Re: POSIX / pthreads / wineserver - can I help?

by Alexandre Julliard

"Stefan Jones" <cretin(a)gentoo.org> writes: > I have been following for a few months now the recent glibc and nptl > changes. How glibc now eliminated it's own version of wineserver in it's > thread implementation with nptl. That's not really the right comparison, the wineserver is not an equivalent of the linuxthreads manager; it's more an equivalent of the Windows kernel. > My idea is to alter wine so that it runs on any 100% ish POSIX threading > system, aka glibc, and thus offload many tasks to the system library and > solve the difficulties for good. You can't really do that; generic pthreads simply doesn't offer the functionality we need. It's possible to use the glibc nptl pthreads, but that's only because of the way they are implemented on top of kernel threads; this isn't a general property of pthreads, so a 100% POSIX threaded Wine is not possible. Once I get the nptl support working there will probably be a number of things that can be done to take better advantage of the new threading support, and any help with that is welcome. But in all cases such code can only be added as an option, it can't replace the existing code since we have to run on older kernels as well as on other systems. -- Alexandre Julliard julliard(a)winehq.com

Feb. 27, 2003

Re: Adding shmserver

by Mike Hearn

Well, really that's up to Alexandre I suppose. One thing to bear in mind is that a higher performance WineServer is mostly useful for stuff like games, most desktop apps don't do the wierd things with mutexes that started transgaming off on this project. As the current support for DirectX in wine isn't fully there yet, I think getting to the point where this is actually a problem might be a better use of resources first. Obviously in that time the patch will have bitrotted :( On Thu, 2003-02-27 at 17:42, Boris Reisig wrote: > I saw previous posts about the shmserver solution. Its an excellent idea but > will it be included in wine? > > http://www.transgaming.com/papers/shmserver.html > >

Feb. 27, 2003

Re: A window size/move fix (repost)

by Paul McNett

On Tuesday 18 February 2003 02:47 pm, Alexandre Julliard wrote: > > Changelog: > > Before changing window size/pos, handle pending ConfigureNotify > > events. > > That's only hiding the problem, and only in some cases. There is no > guarantee that the ConfigureNotify has arrived by the time we do the > resize, so we need to cope with a ConfigureNotify arriving at any > time. Given that resolving this problem in the correct way will be complex and happen over the long term, and that Duane's very simple patch does indeed resolve the bugs in question: http://bugs.winehq.com/show_bug.cgi?id=1265 http://bugs.winehq.com/show_bug.cgi?id=1266 while not adversely affecting other applications, would you consider committing this patch anyway? In the future, when ConfigureNotify events are properly handled and the Wine code is being optimized, this code can be removed as it will be redundant. Until then, it does make Visual FoxPro appear to behave correctly, which is an important selling point for me in trying to convince other VFP developers to move to Linux/Wine. Thanks for your time and consideration Alexandre, and kudos to you and all the other Wine developers for bringing the product to its current quite usable and functional state! For your reference, here is a link to the patch in question: http://www.winehq.com/hypermail/wine-patches/2003/02/0159.html And here is a text copy of the actual patch: Changelog: Before changing window size/pos, handle pending ConfigureNotify events. Index: dlls/x11drv/winpos.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/winpos.c,v retrieving revision 1.63 diff -u -r1.63 winpos.c --- dlls/x11drv/winpos.c 8 Jan 2003 21:09:26 -0000 1.63 +++ dlls/x11drv/winpos.c 10 Feb 2003 22:33:20 -0000 @@ -887,6 +887,9 @@ UINT wvrFlags = 0; BOOL bChangePos; + /* This is needed to flush pending X ConfigureNotify events on this window */ + MsgWaitForMultipleObjectsEx( 0, NULL, 0, 0, 0 ); + TRACE( "hwnd %p, swp (%i,%i)-(%i,%i) flags %08x\n", winpos->hwnd, winpos->x, winpos->y, winpos->x + winpos->cx, winpos->y + winpos->cy, winpos->flags); -- Paul McNett - p(a)ulmcnett.com Hollister, California, USA

Feb. 27, 2003

Re: Adding shmserver

by Dan Kegel

Boris Reisig wrote: > I saw previous posts about the shmserver solution. Its an excellent idea but > will it be included in wine? > > http://www.transgaming.com/papers/shmserver.html See http://www.winehq.com/news/?view=154#Kernel%20Module%20/%20Shared%20Memory%… for a summary of past discussions. In short: it's a little too Win9x-like in stability for my taste. I can understand people wanting it for the short term, but long-term a kernel module is the way to go. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Feb. 27, 2003

Re: Consoles (3/3)

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > What happens in this context? > > User starts Program A. > Program A starts Program B > Program A terminates normal > Program B crashes. > > On my setup, the debugger starts in that circumstance, loads all dlls and > then immediate terminates, as the there is no xterm connected to Program B > any more. Well in that case you have to use a separate console. It would be nice to have the possibility to detect that the Unix tty is not available and automatically pop up a console in that case; but unconditionally creating a console is wrong, there are many cases where you don't want that. -- Alexandre Julliard julliard(a)winehq.com

Feb. 27, 2003