November 2004 - Wine-Devel - list.winehq.org

Re: Winecfg -> browse for folder

by Robert van Herk

Mike Hearn wrote: >On Sun, 28 Nov 2004 17:02:05 +0100, Robert van Herk wrote: > > >>Ofcourse, but the api call SHBrowseForFolder returns a pidl. So making >>unix browsing an extra flag wouldn't be useful, if I couldn't return a >>valid pidl in the unix case. >> >>Hmm, I guess perhaps it is best to make an extra api function for unix >>browsing anyway. >> >> > >Ah OK, I didn't realise that. You could always just cast the result, a >PIDL is a pointer at the end of the day, but I agree that's rather ugly. A >new Wine API seems like the best route. > > > OK! Currently I am trying to add some functionality for this in brsfolder.c. However, I ran into a (probably small) problem: I added a new function SHBrowseForUNIXDirectory in brsfolder.c and added it to shlobj.h. Reinstalled the shlobj.h, compiled the shell32.dll, and installed that new one too. Also runned ldconfig (don't know if that is a must). Though, when I try to compile winecfg (with the SHBrowseForUNIXDirectory call) I get: make ../../tools/winegcc/winegcc -B../../tools/winebuild -mwindows appdefaults.o audio.o drive.o drivedetect.o driveui.o libraries.o main.o properties.o winecfg.o x11drvdlg.o winecfg.exe.dbg.o winecfg.res -o winecfg.exe.so -L../../dlls -lcomdlg32 -lcomctl32 -luser32 -ladvapi32 -lkernel32 -lshell32 -L../../libs/wine -lwine -L../../libs/port -lwine_port /usr/lib/gcc-lib/i586-suse-linux/3.3.3/../../../../i586-suse-linux/bin/ld: cannot find -lshell32 collect2: ld returned 1 exit status winegcc: gcc failed. make: *** [winecfg.exe.so] Error 2 I haved checked that the new version is actually in /usr/local/lib/wine/shell32.dll.so. What am I doing wrong? Robert

Nov. 28, 2004

Re: ptrace single-stepping change breaks Wine

by Eric Pouech

Jesse Allen a écrit : > On Sun, Nov 21, 2004 at 10:23:41PM -0800, Linus Torvalds wrote: > >>Ok, how about this patch? >> >>It does basically two things: >> >> - it makes the x86 version of ptrace be a lot more careful about the TF >> bit in eflags, and in particular it never touches it _unless_ the >> tracer has explicitly asked for it (ie we set TF only when doing a >> PTRACE_SINGESTEP, and we clear it only when it has been set by us, not >> if it has been set by the program itself). >> >> This patch also cleans up the codepaths by doing all the common stuff >> in set_singlestep()/clear_singlestep(). >> >> - It clarifies signal handling, and makes it clear that we always push >> the full eflags onto the signal stack, _except_ if the TF bit was set >> by an external ptrace user, in which case we hide it so that the tracee >> doesn't see it when it looks at its stack contents. >> >> It also adds a few comments, and makes it clear that the signal handler >> itself is always set up with TF _clear_. But if we were single-stepped >> into it, we will have notified the debugger, so the debugger obviously >> can (and often will) decide to continue single-stepping. >> >>IMHO, this is a nice cleanup, and it also means that I can actually debug >>my "program from hell": >> >> [torvalds(a)evo ~]$ gdb ./a.out >> GNU gdb Red Hat Linux (6.1post-1.20040607.41rh) >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and you are >> welcome to change it and/or distribute copies of it under certain conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for details. >> This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols >> found)...Using host libthread_db library "/lib/tls/libthread_db.so.1". >> >> (gdb) run >> Starting program: /home/torvalds/a.out >> Reading symbols from shared object read from target memory...(no debugging >> symbols found)...done. >> Loaded system supplied DSO at 0xffffe000 >> (no debugging symbols found)...(no debugging symbols found)... >> Program received signal SIGTRAP, Trace/breakpoint trap. >> 0x08048480 in main () >> (gdb) signal SIGTRAP >> Continuing with signal SIGTRAP. >> >> Program received signal SIGTRAP, Trace/breakpoint trap. >> 0x08048487 in main () >> (gdb) signal SIGTRAP >> Continuing with signal SIGTRAP. >> >> Program received signal SIGTRAP, Trace/breakpoint trap. >> 0x08048488 in smc () >> (gdb) signal SIGTRAP >> Continuing with signal SIGTRAP. >> Copy protected: ok >> >> Program exited with code 01. >> (gdb) >> >>which I think is a sign that this patch actually fixes ptrace. >> >>Does this help with wine? I dunno. Maybe some wine people can comment.. >> > > > > For the wine app in question, it does make a difference. However, there is > a new problem. The program gets stuck at the loading screen at 100% CPU. > It's making a call to select, timing out, and then tries select again, > repeats. It's waiting for something that seems to never happen. > > I've captured a log, "loop.log.bz2", and shortened to have only the relevent > information after the CMS32_MUTEX is created. Look for occurances of > "select()" -- I think the second one is where it starts. It's on my ftp if > anyone wants to take a look. It probably can be compared to the working- > version log where this doesn't occur, but it might be a pain to spot the > working particular instance. Hi Jesse Any network issue on your side? I tried to traceroute resnet.disp.net, but no avail. So I cannot have a look to you newest trace. A+

Nov. 28, 2004

Re: Fun desktop integration tasks

by Mark Knecht

On Sun, 28 Nov 2004 15:56:37 +0000, Mike Hearn <mh(a)codeweavers.com> wrote: > On Sun, 28 Nov 2004 14:18:34 +0100, Stefan Dösinger wrote: > > Another suggestion, probably a bigger task: Look for common native > > applications and write entries for them into the registry. > > Yep! Here's another suggestion. Keep them coming guys! :) > Hi - probably my first comment after lurking here for a few weeks. Is there anything that a user type (I'm not a developer in any sense) can do in this area? I run Windows and have lots of apps I want to run under Wine. I've been entering info as I figue it out in the Wine bug database, but so far that isn't helping me get my programs running. I've wondered a number of times about installing Windows programs under Windows and extracting all of the changed registry entries and then reporting them somehow. Is this possible? I'm not sure the apps I want to run are the ones you all would all 'common', but they are common to follks doing audio work. (recording, writing, etc.) In the end would this be helpful? Thanks, Mark

Nov. 28, 2004

Re: Winecfg -> browse for folder

by Mike Hearn

On Sun, 28 Nov 2004 17:02:05 +0100, Robert van Herk wrote: > Ofcourse, but the api call SHBrowseForFolder returns a pidl. So making > unix browsing an extra flag wouldn't be useful, if I couldn't return a > valid pidl in the unix case. > > Hmm, I guess perhaps it is best to make an extra api function for unix > browsing anyway. Ah OK, I didn't realise that. You could always just cast the result, a PIDL is a pointer at the end of the day, but I agree that's rather ugly. A new Wine API seems like the best route.

Nov. 28, 2004

Re: Winecfg -> browse for folder

by Robert van Herk

Mike Hearn wrote: >On Sat, 27 Nov 2004 10:37:10 +0100, Robert van Herk wrote: > > >>Thus, if I'd make an extra flag in the dialog, I would have to extent >>pidls to, so that they can hold unix paths. Is that a wise thing to do? >>Or should I take another approach? >> >> > >Hmm, I'm not sure you want to do that. You may wish to abstract that out, >eg replace the parts where PIDLs are passed around with a > >struct path >{ > PIDL pidl; > char *path; >} > > Ofcourse, but the api call SHBrowseForFolder returns a pidl. So making unix browsing an extra flag wouldn't be useful, if I couldn't return a valid pidl in the unix case. Hmm, I guess perhaps it is best to make an extra api function for unix browsing anyway. Robert

Nov. 28, 2004

Re: Fun desktop integration tasks

by Mike Hearn

On Sun, 28 Nov 2004 14:18:34 +0100, Stefan Dösinger wrote: > Another suggestion, probably a bigger task: Look for common native > applications and write entries for them into the registry. Yep! Here's another suggestion. Keep them coming guys! :) - Implement a bridge between the Windows registry and the GNOME/KDE configuration systems. If you set the wallpaper in a Windows app it should reflect on your real desktop. This is useful for programs like the WebShots desktop. Actually I already have the code for such a "wineshell" program in a local tree, for the system tray integration. I'll see if I can get it submitted soon. We could put all this integration stuff there once it's integrated into Wine. thanks -mike

Nov. 28, 2004

Re: Fun desktop integration tasks

by Alban Browaeys

> Task 4: > Try updating the menu mapping code to support the new XDG menu > specification. Don't bother trying to make this work everywhere, it's a > total nightmare. Just try supporting the new standards. Be warned: not > every desktop/distro supports this yet! > > This one might be quite hard. wineshelllink support update-menu which itself build xdg complient menu (via /etc/menu-methos/menu-xdg). I know mandrake and debian distro use "menu", need confirmation for RH/Novell newest releases. It would be more elegant to let menu manage gnome/kde/xgd/wmaker ... than reimplementing them in wineshellink . The strongest point is that menu build menu via methods which are tweakable by distro builder. Thus it will avoid to upgrade wineshellink whenever we want ot support gnustep xdg version 12 and the like . Cheers Alban

Nov. 28, 2004

Re: Moved dll list from DEVELOPERS-HINTS into separated file

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > On Fri, Nov 26, 2004 at 10:04:49PM -0500, Jacek Caban wrote: > > I saw in TODO list "Get rid of the list of DLLs, it's too big, and adds > > too little information", > > so I thought it could be moved into separated file dlls/DLL-LIST. > > I think this is a good idea: while I agree that the list is a bit > much for DEVELOPERS-HINTS, it's still a nice overview of the dlls > we have, and it would be a real pitty to lose. I personally don't think it's really useful without more detailed information on each dll, but in any case this belongs to one of the sgml documents, not a stand-alone ASCII file. -- Alexandre Julliard julliard(a)winehq.org

Nov. 28, 2004

Re: Adding debuginfo Support to Wine Makefiles

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > "make install && make install_debuginfo" will install the debugging > info both embedded and separate. > "make install_debuginfo && make install" will only install the separate. > This is one of the quirks I would like some feedback on and no doubt > some people will have opinions on the best way to solve this. That's not the right approach, make install should never modify the existing build tree. I think this would be more appropriate as part of a packaging script rather than as a makefile target. -- Alexandre Julliard julliard(a)winehq.org

Nov. 28, 2004

Re: Changed IE6 install script to run IE6 completely out-of-box

by Mike Hearn

On Sun, 28 Nov 2004 11:54:47 +0900, Hajime Segawa wrote: > I changed the install script a bit and it does not depend on DCOM98, > MFC4.0, etc... anymore. > So, you can run IE6 completely out-of-box. > > New script is here : > http://sidenet.ddo.jp/winetips/files/wine-config-sidenet-1.5.3.tgz Quick tip: if you grab the IEBATCH file from my IE installer script: http://bylands.dur.ac.uk/~mh/wine-ie and put it in your script then the IE installer won't prompt the user for any information when installing. This is good as not all the things it would otherwise install work yet. Also it makes it a fully automatic hands-free install which I quite like. thanks -mike

Nov. 28, 2004