Re: Resend: Re-implement MSVCRT *printf functions
Mike Hearn wrote: On Sat, 27 Nov 2004 20:37:21 +, Aneurin Price wrote: big snip Thanks for that; it's just the kind of comment I was looking for. It wasn't a full patch as I wasn't planning to get it applied, and a number of points were where I copied code from what was there already :), but you even caught a couple of places where I said to myself things like I'll remeber to remove that commented block. I'll get to work on this today with any luck.
Re: Changed IE6 install script to run IE6 completely out-of-box
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
Re: Fun desktop integration tasks
I'm sitting waiting for a couple of compiles to finish, so I thought I'd put together a list of fun/interesting tasks people might like to have a go at related to better integrating Wine with the native desktop. None of these should be especially hard, and so would provide a good intro to Wine development for anybody who has been lurking on the sidelines and wants to get involved. Another suggestion, probably a bigger task: Look for common native applications and write entries for them into the registry. For example, I manually added an entry for KMail in \\Machine\\software\\clients and now I can select Kmail as the default Mail application in the internet options control panel(Which is created when Internet Explorer is installed). My registry entries look like this: [Software\\Clients\\Mail\\Kmail] 1100110998 @=KMail [Software\\Clients\\Mail\\Kmail\\Protocols\\MailTo] 1100110998 @=URL:MailTo Protocol EditFlags=hex:02,00,00,00 URL Protocol= [Software\\Clients\\Mail\\Kmail\\Protocols\\MailTo\\DefaultIcon] 1100110998 @=C:\\Program Files\\Opera\\opera.exe,1 [Software\\Clients\\Mail\\Kmail\\Protocols\\MailTo\\shell\\open\\command] 1100110998 @=\Z:\\usr\\kde\\3.3\\bin\\kmail\ \%1\ With Z: mapped to / I selected KMail as the default Mail application, and when I open an Mail Address in MSIE kmail pops up. The same happens when I enter a maito: address in Task Manager-New task. Cheers, Stefan
Re: Adding debuginfo Support to Wine Makefiles
Robert Shearman [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Re: Moved dll list from DEVELOPERS-HINTS into separated file
Dimitrie O. Paun [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Re: Fun desktop integration tasks
On Sun, 28 Nov 2004 14:18:34 +0100, Stefan Dsinger 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
Re: Winecfg - browse for folder
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
Re: Winecfg - browse for folder
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.
Re: Fun desktop integration tasks
On Sun, 28 Nov 2004 15:56:37 +, Mike Hearn [EMAIL PROTECTED] 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
Re: ptrace single-stepping change breaks Wine
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: [EMAIL PROTECTED] ~]$ 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 0xe000 (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+
Re: Winecfg - browse for folder
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
Re: Winecfg - browse for folder
Never mind, doing a new make from the root directory of the wine source solved it... Robert Robert van Herk wrote: 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
Re: No RichEdit20A window class
Krzysztof Foltman wrote: Mike McCormack wrote: ... so long as you are the sole author. That's where part of the problem is: as long as someone sends me just a Ctrl-arrow patch, I can always be suspected of stealing that patch. It puts me in a very uncomfortable position. Perhaps a suggestion... ask that for some period of time, people who submit patches against your code do so under a BSD or X11 license. Wine itself was under an X11 style license for quite a few years, so that probably won't scare too many people off. Be specific (and reasonable) about the period of time, though.
Re: Winecfg - browse for folder
On Sun, 28 Nov 2004 18:47:18 +0100, Robert van Herk wrote: 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). I don't think we have a specific policy on extending Win32 like this, but it's probably a good idea to make it obvious this API is Wine specific, perhaps by using the GNU coding conventions, eg: wine_shell_browse_for_folder() thanks -mike
Re: Fun desktop integration tasks
On Sun, 2004-11-28 at 08:35 -0800, Mark Knecht wrote: 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'm afraid they nearly all involve patching Wine, so not with this set of suggestions no. 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. Right. Unfortunately finding bugs isn't too hard, it's fixing them that's the hard part. 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? It is possible. It is unlikely to help in most cases. 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? Sure, if you figure out how to make apps work feel free to post information somewhere explaining how, or you could write a little script to automate it as has been done with IE. thanks -mike
Re: Implement GetLayout
Rémi Assailly wrote: I added some things to my previous patch. Please tell me if something seems incorrect or is missing Thanks ;) Changelog: * implement GetLayout Thanks for spotting another one for my growing heap of BiDi TODOs http://bugs.winehq.org/show_bug.cgi?id=2584 Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Fun desktop integration tasks
Another task: Get xscreensaver to respect the registry LowPowerActive setting. Ivan. Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione. Abbonati subito su http://www.libero.it
Re: Winecfg - browse for folder
Also runned ldconfig (don't know if that is a must). It isn't, expecially if you run out of the source tree. Ivan. Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione. Abbonati subito su http://www.libero.it
automatic tests screwed up again
In the reports page the link to the tests points to http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/winetest-200411251000.exe and this is probably what the server tells winrash to download, but it returns a 404. The test actually is at http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/winetest-200411251000-paul-mingw.exe can someone please fix this? Ivan. Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione. Abbonati subito su http://www.libero.it
Re: working together on stdole.tlb and a end to dcom9x
Le dim 29/08/2004 à 14:31, Filip Navara a écrit : Huw D M Davies wrote: You're right, an MSFT stdole32 might work fine - I guess we should at least try it. So for fun I've attached the program we used to generate CrossOver's stdole32.tlb (Actually you need to take the generated file and wrap it up in a resource only dll, but that's a detail). Since it was designed to be compiled with MSVC, it uses the L construct for olestrings - you can hack around this by compiling with -fshort-wchar for now. I tried to change CreateTypeLib to CreateTypeLib2 and running it with Wine DLLs. It produced bunch of FIXMEs, but generated the type library in the end. The result is attached. Compared to the type library generated using the same executable with Windows DLL only two bytes differ. Is there some type library dump program that can be used to find out what are the differences or am I left alone and should I try to find out the actual differences other way? Was the resulting stdole32.tlb file (generated on Wine) a suitable replacement for Microsoft's? IE, does InstallShield works better with this file than without any stdole32.tlb file? Vincent
Re: Fun desktop integration tasks
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
Re: working together on stdole.tlb and a end to dcom9x
Hi Vincent, --- Vincent Béron [EMAIL PROTECTED] wrote: Was the resulting stdole32.tlb file (generated on Wine) a suitable replacement for Microsoft's? IE, does InstallShield works better with this file than without any stdole32.tlb file? I think it will work. One thing we have discussed in ReactOS was using the tools as part of our stage2 setup. If there is not a easy way to implement these tools in WIDL like Alexandre wanted maybe making them tools that are run via wineprefixcreate on first run is a acceptable solution? Thanks Steven __ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail
Re: working together on stdole.tlb and a end to dcom9x
No. I used the InstallShield program for Flash MX, and it didn't work. Without stdole32.tlb, it whined like a baby about OLE. With stdole32.tlb, it (not the whole system) froze up during the preparing stage when it hit 100% and left a phantom window that was blank when and after I quit Wine. I think, for InstallShield, someone has to implement a special trap(s) for OLE calls. Also, a stdole32.tlb copied from a real Windows system didn't work. Clearly, it isn't a hole in InstallShield, but in Wine's typelib support. Someone should develop a Wine testcase that tests typelibs. Does anyone know of a typelib testcase? Samuel Lauber - Original Message - From: Steven Edwards [EMAIL PROTECTED] To: Vincent Béron [EMAIL PROTECTED], Filip Navara [EMAIL PROTECTED] Subject: Re: working together on stdole.tlb and a end to dcom9x Date: Sun, 28 Nov 2004 17:54:48 -0800 (PST) Hi Vincent, --- Vincent Béron [EMAIL PROTECTED] wrote: Was the resulting stdole32.tlb file (generated on Wine) a suitable replacement for Microsoft's? IE, does InstallShield works better with this file than without any stdole32.tlb file? I think it will work. One thing we have discussed in ReactOS was using the tools as part of our stage2 setup. If there is not a easy way to implement these tools in WIDL like Alexandre wanted maybe making them tools that are run via wineprefixcreate on first run is a acceptable solution? Thanks Steven __ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail -- _ Web-based SMS services available at http://www.operamail.com. From your mailbox to local or overseas cell phones. Powered by Outblaze
Making the Documentation into help files
While making the Debian package, I had to do a special hack to compile wine's documentation because it's made seperately. This isn't a really big deal, but what I did realize is that Wine's documentation doesn't get installed to the help menu now coming standard on systems. When I select Applications-Help from the menu in Ubuntu, there's a whole list of documentation for available installed applications. I managed to get the install script to copy txt versions of the stuff in the documentation folder to the standard /usr/share/doc/wine, but this place remains bereft of wine documentation. So, how is this done? I presume there's a freedesktop.org standard for these things, as both Gnome and KDE have them in the same way, but currently we're not converting the documentation sgml files into these help files. Coincidentally, this might tie in very well to the desktop integration tasks suggested this week. Perhaps we should create a desktop integration tasklist or even append it onto the 1.0 todo? Trying to further improve usability, Scott Ritchie
