September 2002 - Wine-Devel

Re: Debugger no more starting

by Dimitrie O. Paun

On September 30, 2002 12:57 am, Alexandre Julliard wrote: > This will work fine, even if the script starts a Winelib app, > except if the app depends on inheriting handles from the parent > process, which is a *very* uncommon case. And I gather that winedbg is just such a case... > I believe the current behavior is a good compromise between being > Windows compatible and allowing to launch Unix apps. Some improvements > may be possible, but make sure you really understand how it works > first; the behavior is quite complex, precisely because we try to > always do the right thing. So it seems, thank you for the explanation. I have no intention of fiddling with this stuff, don't worry :). It just seemed that your explanation applied to all winelib apps, and that worried my a little. ;) -- Dimi.

Sept. 30, 2002

Re: Debugger no more starting

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > If I have a "Run command..." dialog which takes the command name, > why should I know (and how), that in one I should type winedbg, > and in another winedbg.exe? In fact, even DOS/Windows users are > used to be able to specify the probram name _without_ the > .exe/.bat/.cmd/.com/etc. extension. Why should they do any > different in Wine? They shouldn't. In almost all cases it will be completely transparent; BTW "winedbg" works the same as "winedbg.exe", it's the explicit path that is the problem. If you explicitly specify a full path to a Unix script it will be launched as a Unix script. This will work fine, even if the script starts a Winelib app, except if the app depends on inheriting handles from the parent process, which is a *very* uncommon case. I believe the current behavior is a good compromise between being Windows compatible and allowing to launch Unix apps. Some improvements may be possible, but make sure you really understand how it works first; the behavior is quite complex, precisely because we try to always do the right thing. -- Alexandre Julliard julliard(a)winehq.com

Sept. 30, 2002

Re: dlls/ completion nit

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > To fix this I had to do: > > [dimi(a)dimi wine.build]$ cp ../wine.src/tools/makedep tools/ > > (I had makedep built already in the source tree) > > This doesn't sound right, does it? You should do a make distclean in the source tree first. make gets confused if some objects already exist in the source tree. -- Alexandre Julliard julliard(a)winehq.com

Sept. 30, 2002

Re: CVS server broken ?

by Jeremy Newman

On Sat, 2002-09-28 at 01:45, Sylvain Petreolle wrote: > trying to do a cvs update I get nothing on screen today, even when > trying to do a simple cvs status (normally it would take seconds). > > cvs.winehq.com responds to ping though, could an admin look at it ? I just took a look at it, and everything appears normal. I even did a checkout of the cvs tree from my home pc to be sure. Double check to be sure you don't have anything blocking TCP port 2401 at your Firewall and/or NAT. -- __ _WebGeek/SysAdmin CodeWeavers -= http://www.codeweavers.com | \| |_____ __ ___ __ __ _ _ _ -= http://www.dracowulf.com | / -_) | | / ' \/ _` | ' \ -= jnewman(a)codeweavers.com |_|\_\___|\_/\_/|_|_|_\__,_|_||_| -= ICQ: 1842980 Yahoo: laxdragon

Sept. 30, 2002

Re: Debugger no more starting

by Dimitrie O. Paun

On September 29, 2002 10:25 pm, Alexandre Julliard wrote: > But that's exactly what it does. You have problems because you know > too much; with the new scheme a user doesn't even have to know that > there is a way to configure the debugger, it will just work. It's a good thing, granted. But my comment was referring more to this: >The winedbg script should be used only when starting from the >Unix command line, from inside Wine you need to specify a .exe or >.exe.so instead. This I don't like. I have to start the _same_ executable using different names! As a user, why should I even care, or know, that a window on my screen is a Unix window, or a Wine window? If I have a "Run command..." dialog which takes the command name, why should I know (and how), that in one I should type winedbg, and in another winedbg.exe? In fact, even DOS/Windows users are used to be able to specify the probram name _without_ the .exe/.bat/.cmd/.com/etc. extension. Why should they do any different in Wine? I haven't looked at the problem at all to understand the technical reasons behind this requirements, but I can say, as a user, that's quite counterintuitive... -- Dimi.

Sept. 30, 2002

Re: dlls/ completion nit

by Dimitrie O. Paun

On September 28, 2002 03:42 am, Dmitry Timoshkov wrote: > 1. copy WineHQ CVS tree to ~/wine_hq_src > 2. mkdir ~/wine; cd ~/wine > 3. ../wine_hq_src/configure; make depend; make Thanks! But this doesn't work quite right: [dimi(a)dimi wine]$ mv wine wine.src [dimi(a)dimi wine]$ mkdir wine.build [dimi(a)dimi wine]$ cd wine.build [dimi(a)dimi wine.build]$ ../wine.src/configure --silent [dimi(a)dimi wine.build]$ make depend cd `dirname dlls/__depend__` && make depend make[1]: Entering directory `/home/dimi/dev/wine/wine.build/dlls' cd `dirname advapi32/__depend__` && make depend make[2]: Entering directory `/home/dimi/dev/wine/wine.build/dlls/advapi32' cd `dirname tests/__depend__` && make depend make[3]: Entering directory `/home/dimi/dev/wine/wine.build/dlls/advapi32/tests' ../../../tools/makedep -I../../../../wine.src/dlls/advapi32/tests -I. -I../../../../wine.src/include -I../../../include -C../../../../wine.src/dlls/advapi32/tests registry.c make[3]: ../../../tools/makedep: Command not found make[3]: *** [depend] Error 127 make[3]: Leaving directory `/home/dimi/dev/wine/wine.build/dlls/advapi32/tests' make[2]: *** [tests/__depend__] Error 2 make[2]: Leaving directory `/home/dimi/dev/wine/wine.build/dlls/advapi32' make[1]: *** [advapi32/__depend__] Error 2 make[1]: Leaving directory `/home/dimi/dev/wine/wine.build/dlls' make: *** [dlls/__depend__] Error 2 To fix this I had to do: [dimi(a)dimi wine.build]$ cp ../wine.src/tools/makedep tools/ (I had makedep built already in the source tree) This doesn't sound right, does it? -- Dimi.

Sept. 30, 2002

Re: Debugger no more starting

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > That's very unfortunate, as it is extremely counterintuitive. To the > point where *I* gave up on using the debugger. A developer. What about > users? We'll have to explain weird technical reasons: that's a winelib > app, that's PE executable, etc. This sucks. Wine should seamlessly > integrate all these executables together. A user should not care about > the actual type of executable, it should just be able to run the dang > thing. But that's exactly what it does. You have problems because you know too much; with the new scheme a user doesn't even have to know that there is a way to configure the debugger, it will just work. The change only bites people who knew how it worked before and adapted their registry; so now you need to return your registry to the default state to make things work. -- Alexandre Julliard julliard(a)winehq.com

Sept. 30, 2002

Re: Debugger no more starting

by Dimitrie O. Paun

On September 29, 2002 01:54 pm, Alexandre Julliard wrote: > The problem is that your debugger path points to a Unix script, and > the new exe loadorder support no longer starts Winelib apps that way. That's very unfortunate, as it is extremely counterintuitive. To the point where *I* gave up on using the debugger. A developer. What about users? We'll have to explain weird technical reasons: that's a winelib app, that's PE executable, etc. This sucks. Wine should seamlessly integrate all these executables together. A user should not care about the actual type of executable, it should just be able to run the dang thing. -- Dimi.

Sept. 30, 2002

Re: Listview updates (G0)

by Dimitrie O. Paun

On September 29, 2002 03:42 pm, Sylvain Petreolle wrote: > Thus can we consider the result of : > grep ZeroMemory `find . -name '*.c'` and say "there are probably bugs > here " ? I would like to say that that's the case, but I'm a little worried that will not hold for notification messages. You see, notifications messages are special in that they go *to* the application, that is, to code we do not control. And if that code breaks because we push it to the limit, there's nothing we can do. So I think it's better to follow the network protocol: be very strict in what we send, and very liberal in what we receive. -- Dimi.

Sept. 30, 2002

Re: Fix to protect users from selves.

by Guy L. Albertelli

To all that answered: I also abhor the kludge that I wrote. I also recognize that the test would catch possible *valid* filenames. I will attempt to find the keys that cause the rename to occur. However, the point of the patch was to: 1. Provide the developers with a way not to have their Windows system (real or fake) be renamed during development. I got tired of renaming the directories back to what they should have been. 2. Protect the end users from destroying their Windows system during testing/playing. The last thing we should want is the impression that Wine is dangerous because of unexpected consequences due to simple appearing actions. "comp.emulators.ms-windows.wine" still gets complaints from user that have done this very action. Guy

Sept. 30, 2002