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

Re: Mandrake RPMs

by Ivan

> It turns out the reason they don't work on Fedora is because they don't > work at all No, wine segfaulted, so it probably wasn't a packaging related problem. > wine.inf is in /usr/share/doc/wine-20040615 which is wrong, > it needs to be in /usr/share/wine. This is strange because I tested both RPMs on multiple versions of Mandrake before releasing them. Anyway, new RPMs will be up soon. Ivan.

June 29, 2004

Re: A wine magic trace key

by Mike Hearn

On Tue, 29 Jun 2004 12:02:26 -0400, Andrei Barbu wrote: > Is there another way, possibly existing, to do this? > Is this a really bad idea? I already implemented this some time ago. You'll need to use -p1 to patch. To use it set WINEDELAY=1 in the environment. You can then toggle tracing with the F12 key - it starts as being off. thanks -mike --- orig/dlls/ntdll/debugtools.c +++ mod/dlls/ntdll/debugtools.c @@ -244,6 +244,7 @@ return res; } + /*********************************************************************** * NTDLL_dbg_vprintf */ @@ -300,7 +301,7 @@ ret += wine_dbg_printf( "%s:%s:%s ", classes[cls], channel + 1, function ); } if (format) - ret += NTDLL_dbg_vprintf( format, args ); + ret += __wine_dbg_vprintf( format, args ); return ret; } @@ -313,5 +314,6 @@ __wine_dbgstr_wn = NTDLL_dbgstr_wn; __wine_dbg_vsprintf = NTDLL_dbg_vsprintf; __wine_dbg_vprintf = NTDLL_dbg_vprintf; + if (getenv("WINEDELAY")) wine_dbg_toggle_block(); __wine_dbg_vlog = NTDLL_dbg_vlog; } --- orig/dlls/x11drv/keyboard.c +++ mod/dlls/x11drv/keyboard.c @@ -1171,6 +1171,11 @@ KEYBOARD_GenerateMsg( VK_CAPITAL, 0x3A, event->type, event_time ); TRACE("State after : %#.2x\n",pKeyStateTable[vkey]); break; + case VK_F12: + if ((event->type == KeyPress) && getenv("WINEDELAY")) { + /* we get this event repeatedly if we hold down the key (keyboard repeat) */ + wine_dbg_toggle_block(); + } default: /* Adjust the NUMLOCK state if it has been changed outside wine */ if (!(pKeyStateTable[VK_NUMLOCK] & 0x01) != !(event->state & NumLockMask)) --- orig/include/wine/debug.h +++ mod/include/wine/debug.h @@ -145,6 +145,7 @@ extern int wine_dbg_printf( const char *format, ... ) __WINE_PRINTF_ATTR(1,2); extern int wine_dbg_log( unsigned int cls, const char *ch, const char *func, const char *format, ... ) __WINE_PRINTF_ATTR(4,5); +extern void wine_dbg_toggle_block(); static inline const char *wine_dbgstr_guid( const GUID *id ) { --- orig/libs/wine/debug.c +++ mod/libs/wine/debug.c @@ -54,6 +54,9 @@ static const char * const debug_classes[] = { "fixme", "err", "warn", "trace" }; +static int disabled_dbg_vprintf( const char *format, va_list args ); +static void* old_vprintf = &disabled_dbg_vprintf; /* used when blocking debug output */ + static int cmp_name( const void *p1, const void *p2 ) { const char *name = p1; @@ -140,6 +143,16 @@ } } +static int disabled_dbg_vprintf( const char *format, va_list args ) { + return 0; +} + +/* prevents printing of debug messages temporarily */ +void wine_dbg_toggle_block() { + fprintf(stderr, "wine: toggling tracing\n"); + old_vprintf = interlocked_xchg_ptr((void**)&__wine_dbg_vprintf, old_vprintf); /* fixme: is this thread safe? */ +} + /* parse a set of debugging option specifications and add them to the option list */ int wine_dbg_parse_options( const char *str ) { @@ -412,3 +425,4 @@ { return __wine_dbgstr_wn( s, -1 ); } + --- orig/libs/wine/wine.def +++ mod/libs/wine/wine.def @@ -9,6 +9,7 @@ __wine_dbgstr_an __wine_dbgstr_wn __wine_dll_register + wine_dbg_toggle_block __wine_main_argc __wine_main_argv __wine_main_environ --- orig/libs/wine/wine.map +++ mod/libs/wine/wine.map @@ -6,6 +6,7 @@ __wine_dbg_vlog; __wine_dbg_vprintf; __wine_dbg_vsprintf; + wine_dbg_toggle_block; __wine_dbgstr_an; __wine_dbgstr_wn; __wine_dll_register;

June 29, 2004

Mandrake RPMs

by Mike Hearn

Hi, Ivans comment that the Mandrake RPMs didn't work on Red Hat/Fedora surprised me, so after encountering a stuck Mandrake user for whom the RPMs weren't working either on IRC I decided to check them out. It turns out the reason they don't work on Fedora is because they don't work at all - wine.inf is in /usr/share/doc/wine-20040615 which is wrong, it needs to be in /usr/share/wine. As this file is in the wrong place Wine refuses to start on a new users account. Once I manually copied the file to the right place Wine worked just fine. Could somebody please fix the Mandrake RPMs, and maintainers of other packages please ensure you have details like this right. thanks -mike

June 29, 2004

Re: [RFC] Wine upgrade procedure (spec)

by Dimitrie O. Paun

On Tue, Jun 29, 2004 at 11:49:12AM +0100, Mike Hearn wrote: > Short of copying the entire codebase into the users account when they > explicitly choose to upgrade (ew, no other program does this) I can't see I agree, I personally hate this too, but Alexandre has a point in that this may be the most compatible setup, so at least in theory we should be able to support it just in case we need to employ it later. However, I'm fairly sure we don't need to actually get a working version for it at this time, we just need to make sure we could, if we wanted to, without replacing the entire upgrade mechanism. > a good way of upgrading Wine while it's running that's free of race > conditions. For instance, you could be in the middle of upgrading when a > program you're running starts a new process: the wineserver may be using a > different protocol to what the DLLs expect. > > I really don't think for now we should try and support upgrades while > running. It should probably be up to the packages/install scripts to alert > the user if they try that. Agreed. I think the most important thing is for Wine to integrate nicely with the system where it's running, so that rpm -U / yum update works as expected. If we go overboard with these sort of things, we may screw up the OS integration (remember, rpm -U must be able to run unattended for example), and this is a greater evil. Also, we have to be careful to not be more catholics than the Pope: I really doubt that any significant number of apps out there support 100% upgradability when they are running. In other words, an app that has more than one config/data file, would need to do locking to make sure that the data set that's spread around the files is treated atomically during upgrade. I personally think we can live with the race when we read in the registry files, but if that causes problems, we can add some locking so that we can read them in atomically. Maybe Alexandre can comment on this, he seems to have thought of this scenario already. > > We can also look at some important use-cases that we need to support, > > but before we do, the following must hold true in all cases: > > -- administrators should be able to install a new Wine on the > > system easily with "rpm -U" (or equivalent). > > This is a use case we should definitely support but perhaps only in a > special configuration where wine is a script which checks for a new > version and copies it across next time it's started, or something like > that. That will not work, we install as root, we run it as a regular user. Really, I see no difference between this and option (B) from the upgrade mechanism point of view, I think the challange here is to simply get the apps to run in this environment. We may need scripts that create fake directories with a bunch of symlinks, etc. but this is another matter. > > In all of the above, there is always state in the user directory. Thus, > > it is imperative that the upgrade process makes sure that after the > > upgrade, the user-private state is consistent with the new code base. > > Also, any solution must take into account that the registry must be > > created on the fly, as it is created when registering the DLLs. > > One possible solution here is a new wineserver request that switches the > registry files in use, so to update the registry in a way that doesn't > disturb currently running programs you can connect to a new wineserver > instance (separate socket), switch registry files to "system.reg.new" or > whatever, run wine.inf and then have another request which does an atomic > rename of the registry files over the new ones once merged. This means the > old wineserver instance is still using the old registry file inodes, but > next time the Wine session is started up it'll be using the new registry. Right, I was thinking along the same lines, but I'm not sure we can work with the same wineserver. For one, we will have one wineserver instance per user, running as the user, whereas for global install we need one that runs as root. But we do need to create these files at runtime, so we may need a special operation mode to achive it. -- Dimi.

June 29, 2004

Re: fix typo in wwn

by Fabian Cenedese

>(from South Africa, where we have lions roaming the streets, no computers or electricity, and Zimbabwe is like, as far as you can throw a stone to the north from here) I was just wondering how you wrote that email... :) bye Fabi

June 29, 2004

Delayed breakpoints in winedbg

by Adrian Rees

Hi all, Apologies in advance for what is probably a dumb question... I'm trying to debug a windows application by breaking on a call to a DLL function - in fact it's the NtCreateKey function within the ntdll library. I must be missing something fundamental because the debugger indicates that it has set a delayed breakpoint, but the breakpoint is never reached, although turning on debugging messages clearly indicates that the function is being called. Here's a typical attempt: $ WINDEBUG=reg winedbg MSMONEY.EXE ... (lots of startup calls to reg) ... In 32 bit mode. Wine-dbg>break NtCreateKey fixme:dbghelp:elf_new_wine_thunks Duplicate in midimap.drv<elf>: _edata<5b828a10 -00000000> completed.1<5b828a10-00000000> ... (snip) ... No symbols found for NtCreateKey Unable to add breakpoint, will check again when a new DLL is loaded Wine-dbg>info break No breakpoints No watchpoints Delayed breakpoints: 0: NtCreateKey Wine-dbg>cont trace:reg:NtCreateKey(0x28,L"Software\\Microsoft\\Windows\\CurrentVersion\\AppPaths\\MSMONEY.EXE",L"",1,1,0xb9fd04) trace:reg:NtCreateKey <- 0x50 trace:reg:RegQueryValueExA(0x50,"Path",(nil),0xb9fcf8,0xb9f318,0xb9fd00=260) ... (etc till program ends) ... I've spent a couple of hours searching for more information on how to use this capability of the debugger, but with no luck - can anyone tell me what I'm doing wrong? Thanks, Adrian

June 29, 2004

Re: [RFC] Wine upgrade procedure (spec)

by Mike Hearn

On Tue, 29 Jun 2004 02:33:15 -0400, Dimitrie O. Paun wrote: > Intuitively, upgrading wine is simple to understand: once a new version > is installed, we need to get users in a state where they can use it. > While simple to state, this problem is complicated by the various corner > cases that can appear in Real Life (TM): > -- native vs. builtin DLLs handling > -- multiple Wine installations on a box > -- updating only some DLLs > -- integrating into the Unix environment > -- dealing with Windows software Short of copying the entire codebase into the users account when they explicitly choose to upgrade (ew, no other program does this) I can't see a good way of upgrading Wine while it's running that's free of race conditions. For instance, you could be in the middle of upgrading when a program you're running starts a new process: the wineserver may be using a different protocol to what the DLLs expect. I really don't think for now we should try and support upgrades while running. It should probably be up to the packages/install scripts to alert the user if they try that. > We can also look at some important use-cases that we need to support, > but before we do, the following must hold true in all cases: > -- administrators should be able to install a new Wine on the > system easily with "rpm -U" (or equivalent). This is a use case we should definitely support but perhaps only in a special configuration where wine is a script which checks for a new version and copies it across next time it's started, or something like that. > B. Mixed Install This is almost certainly the most common amongst our userbase today. > Here, Wine code is installed globally, but applications are > installed in the user's account. In a way is like (A) but with some > additional applications installed directly into the user's account. > Same requirements apply to this case as well. > > C. Local Install > Both Wine code, as well as applications are installed locally, into > the user's account. The Wine code is still installed globally by > the administrator (as in A & B), but it is copied locally before > it's being used. An upgrade in this case may require an explicit > action by the user, so the upgrade can happen at a controlled time, > when the user desires it. > > In all of the above, there is always state in the user directory. Thus, > it is imperative that the upgrade process makes sure that after the > upgrade, the user-private state is consistent with the new code base. > Also, any solution must take into account that the registry must be > created on the fly, as it is created when registering the DLLs. One possible solution here is a new wineserver request that switches the registry files in use, so to update the registry in a way that doesn't disturb currently running programs you can connect to a new wineserver instance (separate socket), switch registry files to "system.reg.new" or whatever, run wine.inf and then have another request which does an atomic rename of the registry files over the new ones once merged. This means the old wineserver instance is still using the old registry file inodes, but next time the Wine session is started up it'll be using the new registry. thanks -mike

June 29, 2004

Re: Scrollbars, an application bug or a wine regression ? (#2314)

by George Marshall

Gabriele Giorgetti wrote: <snip> > Trying to describe the problem: > The application show up with a bottom scrollbar and > a right scrollbar even if they are not needed. When > executing the very same application, with the very > same settings and size with wine 20040505 the scrollbars > are not there. I've also noticed that some unresizable windows are drawn with the scrollbars.

June 29, 2004

[RFC] Wine upgrade procedure (spec)

by Dimitrie O. Paun

Hi folks, It seems that we are getting ever so closer to 0.9. Slow, but steady. Looking at the TODO, it looks like upgrading is one of the big showstoppers, in that it will affect (1) the end-user experience, and (2) how we deal with the configuration. So this seems like a good time to start discussing this topic, as we need to eventually reach the elusive 0.9. This seems to be a difficult topic, so we need to approach the problem well prepared. That is, we need to first define (and agree) on what we need to solve here. So after a tumultuous discussion on IRC, I decided to get the ball rolling. Intuitively, upgrading wine is simple to understand: once a new version is installed, we need to get users in a state where they can use it. While simple to state, this problem is complicated by the various corner cases that can appear in Real Life (TM): -- native vs. builtin DLLs handling -- multiple Wine installations on a box -- updating only some DLLs -- integrating into the Unix environment -- dealing with Windows software We can also look at some important use-cases that we need to support, but before we do, the following must hold true in all cases: -- administrators should be able to install a new Wine on the system easily with "rpm -U" (or equivalent). -- the upgrade should not erase registry settings that are managed by the user Let's look at the use-cases: A. Global Install In this case, both Wine code, as well as applications are installed globally, for all users to access. This is the most Unix-like setup, but unfortunately the most difficult to support, due to the fact that Win32 apps simply expect a different environment. Since we can't control application's code, this setup may present some limitations, but it may be sufficient for sites that need a limited set of applications. For this to work, it is acceptable that we ship special scripts that know about the applications that are supported, so that they can work around inherent limitations in the applications themselves. Users should transparently be able to use the new version of wine, the next time they start wine. B. Mixed Install Here, Wine code is installed globally, but applications are installed in the user's account. In a way is like (A) but with some additional applications installed directly into the user's account. Same requirements apply to this case as well. C. Local Install Both Wine code, as well as applications are installed locally, into the user's account. The Wine code is still installed globally by the administrator (as in A & B), but it is copied locally before it's being used. An upgrade in this case may require an explicit action by the user, so the upgrade can happen at a controlled time, when the user desires it. In all of the above, there is always state in the user directory. Thus, it is imperative that the upgrade process makes sure that after the upgrade, the user-private state is consistent with the new code base. Also, any solution must take into account that the registry must be created on the fly, as it is created when registering the DLLs. Before we go any further, I'd like to ask everybody to contribute their thoughts/requirements/desires so that we get a conprehensive view of the problem we are trying to solve. Thanks for reading this far! -- Dimi.

June 29, 2004

Re: How to handle odbc/registry

by Alexandre Julliard

Bill Medland <billmedland(a)mercuryspeed.com> writes: > So should we have code within the registry code that recognises access to the > ODBC tree when odbc32 is builtin and redirects it to the corresponding calls > to the unix ODBC manager? No, but probably the builtin odbc32 should create the registry keys on startup if necessary. -- Alexandre Julliard julliard(a)winehq.org

June 29, 2004