August 2005 - Wine-Devel - list.winehq.org

Re: [winedbg] Don't ever pass a NONCONTINUABLE exception

by Alexandre Julliard

Glenn Wurster <gwurster(a)scs.carleton.ca> writes: > In short, because we're never going to be able to continue, so there's > no point on trying to pass because that's going to fail. Not really, if the app handles the exception there's no reason it would fail. Not passing the exception will break things like IsBadReadPtr. > In long, because I've got another patch in the pipeline (it needs some > tweaking) that moves the calling of the debugger into the signal > handler. It allows the debugger to catch exceptions that would > previously have resulted in a total crash (non-continuable > exceptions), and it more accurately reflects how the Windows debugger > is called. Using a debugger will also no longer modify program memory > as it does currently. In all, it should allow the debugger to work in > more circumstances than it currently does. Well, I'll wait to see the patch, but I doubt we want to do that. The current way is pretty much identical to what Windows does, and it sounds like your way isn't. -- Alexandre Julliard julliard(a)winehq.org

Aug. 22, 2005

Re: Remove unnecessary #pragma code_page(xxxx) statements from winefile .rc files

by Martin Fuchs

> This is because 'LANGUAGE LANG_xxxx' statements don't actually change > code page specified by a previous '#pragma code_page(xxxx)', therefore > russian resources get translated to unicode using wrong code page. > I don't know whether it's an rc bug or a feature. We either need > to remove '#pragma code_page' statements altogether, or add them > to all included .rc files. I took the 1st approach. > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Remove unnecessary #pragma code_page(xxxx) statements from > winefile .rc files, they confuse the resource compiler. Please be carefull to remove the code page pragmas. IMHO this is not the correct way. When there is no other code page given, the resource compiler uses the current code page of the operating system. And I don't think, all of those language specific resource scripts will compile correct on all possible OS code pages. The reliable way would be to include the correct code page at the begin of all resource scripts. Please take in mind: Wine is compiled on many different environments: LANG_C, de_DE.ISO-8859-1, en_EN.UTF-8, swedish, or whatever... Removing the code page pragmas would require to test the correctness of the compilation results of all different languages on all possible platforms. Regards, Martin

Aug. 22, 2005

Re: Throwing in an idea (probably it was discussed before though)

by Jacek Caban

John Smith wrote: >> You can also set it yourselves in in your app. As configuration >> is in registry, every app can modify it. > > > I like this idea, thanks. There are still 2 issues with such a soultion: > a) most likely, it won't work until 2nd start of the application (we > will modify it on the first run, and it most likely won't be applied > until the second run); If you have an installer, you may configure Wine during installation. If not - just detect Wine at the beginning of the app and, if you have to configure Wine, do so and restart the app. It's a bit (very) hackish but it should work and it's not visible for user. > b) current WINE guides are discouraging us from detecting WINE - and > messing up with Windows Registry, especially HKEY_LOCAL_MACHINE, on > all the millions of non-WINE machines is not a thing I would really > like to do (the last thing we want is to be caught by some antivirus, > which monitors activity it considers suspicious and changing > HKEY_LOCAL_MACHINE can easily qualify). > You don't have to touch HKEY_LOCAL_MACHINE, Wine's configuration is in HKEY_CURRENT_USER. And you may use modified WGA (and millions of other) way to detect Wine:-) Note: I still think fixing Wine is better way to go. Jacek

Aug. 22, 2005

Re: [winedbg] Don't ever pass a NONCONTINUABLE exception

by Glenn Wurster

> > Changelog: > > Don't pass on non-continuable exceptions. > > Why do you want to do that? In short, because we're never going to be able to continue, so there's no point on trying to pass because that's going to fail. In long, because I've got another patch in the pipeline (it needs some tweaking) that moves the calling of the debugger into the signal handler. It allows the debugger to catch exceptions that would previously have resulted in a total crash (non-continuable exceptions), and it more accurately reflects how the Windows debugger is called. Using a debugger will also no longer modify program memory as it does currently. In all, it should allow the debugger to work in more circumstances than it currently does. Glenn

Aug. 22, 2005

Re: Throwing in an idea (probably it was discussed before though)

by Shachar Shemesh

John Smith wrote: >> Because it's a tedious and boring task to narrow down those unknown >> bugs in closed-source apps. And that's exactly why we ask you (since >> you got access to the sources) to tell us what the application is >> trying to do which doesn't work in Wine... > > Ahem. And how long it usually takes to fix the bug for not-top-10 > application? And please, don't suggest to fix it ourselves - it is not > going to happen in corporate environment. If you give a scenario that is easilly reproduceable, it is rare that problems go more than a couple of days unfixed. Sometimes you hit something that requires a rewirte of half the relevant subsystem, but usually it's just a small ommision, and is easilly fixed. The thing that takes so much time is tracking the exact behavior that goes wrong. > Also I remember you've just told that fixing bugs is easy - why does > it still exist then? Fixing bugs is easy. Finding them is not. It's exactly the same with proprietary software too, btw. If a user reports "this doesn't work", my experience is that you spend two weeks in QA trying to reproduce the problem, half a day fixing it, and a couple more weeks testing the solution. It's fairly rare that the relations are much different, but do let us in on your experience. All we are saying is "pin-point the problem for us". Shachar

Aug. 22, 2005

Re: Throwing in an idea (probably it was discussed before though)

by Stefan Dösinger

> Then just tell your users to set that in winecfg, AFAIK winecfg allows app > specific settings. I'm sure your great guys but any such mechanism could be > easily abuse by lazy programmers, also once it wasn't needed some sort of > backwards compatibility may even be needed, I don't think it's a great > idea. One simple solution would be to provide default settings for apps > that have known problems, Alexandre hasn't ruled that out if it helps some > apps to work out of the box. Isn't it possible that the App just writes some registry entries to HKCU/Software/Wine/AppDefaults/Filename.exe/ ??? Stefan

Aug. 22, 2005

Re: Throwing in an idea (probably it was discussed before though)

by Jacek Caban

Ivan Leo Puoti wrote: > John Smith wrote: > >> Situation is pretty simple. We have an application, which works Ok >> under WINE, provided that Managed=N specified > > > Then just tell your users to set that in winecfg, AFAIK winecfg allows > app specific settings. > You can also set it yourselves in in your app. As configuration is in registry, every app can modify it. Jacek

Aug. 22, 2005

Re: Throwing in an idea (probably it was discussed before though)

by Ivan Leo Puoti

John Smith wrote: > Ahem. And how long it usually takes to fix the bug for not-top-10 > application? And please, don't suggest to fix it ourselves - it is not > going to happen in corporate environment. Not that long if you provide a small testcase with source that triggers the bug > As it would fix the problem for 99% of our users, and won't affect those > who doesn't run our app, IMO it is still good enough. Then write the setting to the reg yourself, and hope the wine config key never moves. Ivan.

Aug. 22, 2005

Re: Throwing in an idea (probably it was discussed before though)

by Ivan Leo Puoti

John Smith wrote: > 1. It is still not 'out-of-the-box' - and from this point of view it > doesn't matter much whether it is hacking config file or using GUI; 80% > of end-users will try it and throw it away if it doesn't work without > hacking settings; 20% of others will ask questions, and will hack config > or run winecfg, but those 80% will be lost. As some have suggested you can write the settings to the registry yourself Ivan.

Aug. 22, 2005

UpdateWindow doesn't call XFlush

by Michael Kaufmann

Hi all, I've noticed that after an application calls UpdateWindow, the window contents doesn't get updated until the application requests the next event (GetMessage/PeekMessage). That's because UpdateWindow doesn't flush the X output queue (XFlush). I think the best approach would be that UpdateWindow calls GdiFlush, but this function is currently not implemented. The problem is that GdiFlush doesn't get a DC handle, it must figure out itself which DCs it has to flush. Can anyone implement GdiFlush or propose another mechanism on how to call XFlush in UpdateWindow? Regards Michael

Aug. 22, 2005