September 2004 - Wine-Devel

WineHQ Downloads Page

by Adam Schreiber

Could whoever is responsible for updating the website please change the Download page(http://winehq.com/site/download) to read: "Slackware binary .tgz for Slackware" or "Slackware binary .tgz for Slackware 10" The reference to Slackware 9 is confusing users. Thanks, Adam Schreiber -- Why isn't all of your email encrypted? http://gnupg.org http://enigmail.mozdev.org

Sept. 28, 2004

Re: Progress Bar: Fix Class Style & Repainting (resend2)

by Dimitrie O. Paun

On Tue, Sep 28, 2004 at 12:12:09PM -0700, Alexandre Julliard wrote: > Robert Shearman <rob(a)codeweavers.com> writes: > > > Changelog: > > - Fix class style to include the hbrBackground member. > > - Fix repainting issues introduced by this change. > > - Add WM_ERASEBKGND handler and remove background drawing code from > > the WM_PAINT handler. > > Isn't that going to cause a lot of flicker? This was the reason for > the existing code, because otherwise it looks really bad with apps > that update the progress bar a lot. Indeed, IIRC I've tried to have as optimum background drawing code as possible (in terms of overwriting areas, etc), as flicker in the progress bar would look rather ugly. We have to be careful with these sort of changes, in that there are some controls that work real hard to avoid flicker as much as possible. Yes, the code is bigger, more complicated, and maybe sometimes not 100% the way MS does it. But if it doesn't cause any problems, having a good looking control is important IMO. -- Dimi.

Sept. 28, 2004

Re: Moved some local variables from StartServiceCtrlDispatcherA/W to service environment block

by Alexandre Julliard

"Alexander Yaworsky" <yaworsky(a)migusoft.ru> writes: > ChangeLog: > > Moved some local variables from StartServiceCtrlDispatcherA/W to service environment block. > Introduced helper function service_ctrl_dispatcher. I don't think you want to pass ASCII strings across processes, there's no guarantee that both processes are using the same codepage. Inter-process communication should always be done in Unicode. -- Alexandre Julliard julliard(a)winehq.org

Sept. 28, 2004

Re: Progress Bar: Fix Class Style & Repainting (resend2)

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > Changelog: > - Fix class style to include the hbrBackground member. > - Fix repainting issues introduced by this change. > - Add WM_ERASEBKGND handler and remove background drawing code from > the WM_PAINT handler. Isn't that going to cause a lot of flicker? This was the reason for the existing code, because otherwise it looks really bad with apps that update the progress bar a lot. -- Alexandre Julliard julliard(a)winehq.org

Sept. 28, 2004

Re: Problems installing IE6

by Stefan Leichter

Am Montag, 27. September 2004 23:05 schrieb Joaquín Fernández: > Stefan Leichter wrote: > > Am Montag, 27. September 2004 20:03 schrieb Joaquín Fernández: > > > > Hello, > > > > try > > > > WINEDLLOVERRIDES="advapi32=builtin" > > > > (see http://www.winehq.org/hypermail/wine-devel/2004/08/0640.html) > > > > Bye Stefan > > Thanks Stefan, i tried but i can't install IE, the installer stay in > endless loop at the end of process. I tried with other WINEDLLOVERRIDES but > i was not able to install IE. > > Regards > > Joaquín Hello, i have installed ie6 (SP1)some minutes ago on completely fresh wine enviroment with installed dcom98 using cvs from 2 hours ago. I have a german version from a cdrom. Here is what i did: 1. mv ~/.wine ~/.wine-old 2. wine --version (create the new environment) 3. create ~/.wine/config with: -------------------------------------- WINE REGISTRY Version 2 [DllOverrides] "ole32" = "native" -------------------------------------- 4. wine dcom98.exe 5. change ~/.wine/config to: -------------------------------------- WINE REGISTRY Version 2 [DllOverrides] "advapi32" = "builtin" "comctl32" = "builtin" -------------------------------------- 6. wine ie6setup.exe Install Mozilla ActiveX Control then and run wineboot. (i did not check this two steps) Bye Stefan

Sept. 28, 2004

Re: Upgrade management

by Ben A L Jemmett

> I'm not sure we should design this system on the assumption that we suck > and will probably blow things up. I don't know of any other programs > that use such a mechanism when upgrading! Well, Service Packs on Windows have the option (on by default) to back up all changed files just in case Microsoft suck and blow things up; a Wine upgrade could be considered roughly equivalent to installing a SP if the gap between versions is big enough. Perhaps backing up the old wineprefix and telling the user that it's been upgraded would be a good idea. Will the wineprefix be upgraded with every new Wine release, or just when something actually has to be changed? -- Regards, Ben A L Jemmett. (http://web.ukonline.co.uk/ben.jemmett/, http://www.deltasoft.com/) ---------------------------------------------- This mail sent through http://www.ukonline.net

Sept. 28, 2004

Re: Upgrade management

by Boaz Harrosh

Mike Hearn wrote: > Wouldn't it be better to do good testing and have, ooh, I don't know, > a beta testing program? In other words, to ensure we *don't* mangle > the users data? > Yep that too. > I'm not sure we should design this system on the assumption that we > suck and will probably blow things up. I don't know of any other > programs that use such a mechanism when upgrading! > I am not saying that. I'm Just saying. Give me the --noupgrade potability. for checking out stuff. Some programs cannot survive side by side with multiple versions of them selfs. And the Installer will remove the old version. Those who do. take measures to protect users. Even new version of WORD will prompts you when you try to save an old version file. If wine was installed from rpm and is updated - it is one case. The old version is gone the new one is replacing it. But if the old version is still alive. The new one should not take hold. In my opinion you should have the upgrade option in wineprefixcreate by all means. Than it is the packager/Installer responsibility to run it when appropriate. But it should not be left to wine-run to decide, unless you keep some kind of reference count on installations which is hard and complicated. Any way sorry for this flame . I Just wanted for you to see the commonly used scenario of 2 version running side by side and to let us geeks have that possibility in the future. The Upgrade option is commendable and highly needed, Just not automatically, for me. thanks Boaz

Sept. 28, 2004

Re: Upgrade management

by Mike Hearn

> I don't know, better safe than sorry. You are touching users Data here. > they should have an informed choice. A message box, something? maybe > refuse to run, than he will notice. > > So a first time newbie installs wine and is very happy with it. After > 1/2 a year he feels more confident and the new release fixes a game he > likes or something, He tries it out and his old setup is broken. Than > what he think off wine? Unless we state it in bold letters in every > possible documentation (and have a cancel flag like --noupgrade) than > you must confirm with the user. Wouldn't it be better to do good testing and have, ooh, I don't know, a beta testing program? In other words, to ensure we *don't* mangle the users data? I'm not sure we should design this system on the assumption that we suck and will probably blow things up. I don't know of any other programs that use such a mechanism when upgrading! thanks -mike

Sept. 28, 2004

Re: Upgrade management

by Boaz Harrosh

Mike Hearn wrote: > There is evidence that users don't see or ignore such warnings :( > > If you aren't confident that an upgrade won't break stuff you can > always manually back up the wineprefix before running the new version, > I don't think we need to do anything ourselves. Most users won't be > administering production environments, and for them automatic upgrades > would be helpful. > I don't know, better safe than sorry. You are touching users Data here. they should have an informed choice. A message box, something? maybe refuse to run, than he will notice. So a first time newbie installs wine and is very happy with it. After 1/2 a year he feels more confident and the new release fixes a game he likes or something, He tries it out and his old setup is broken. Than what he think off wine? Unless we state it in bold letters in every possible documentation (and have a cancel flag like --noupgrade) than you must confirm with the user. > thanks -mike > > Thanks -Boaz

Sept. 28, 2004

Re: Upgrade management

by Mike Hearn

> 1. It is more than common to use more than one wine version on the same > prefix. So what will the older version do. is it always future compatible? Yes, hopefully. There are limits to what we can do here though, I suspect. > 2. Please do not silently touch a user's wineprefix. Users are used to > have their wineprefix untouched. It is common practice to have a good > solid production environment. And than try a new wine to see if a > particular issue was fixed. The last thing they need is to later see > that something was broken. What if the fix they need is actually a change to the wineprefix? > Just have the check in place. and do a big > FIXME. Than if the user uses a --upgrade command line switch. There is evidence that users don't see or ignore such warnings :( > The actual > upgrade is made. Or Just have the FIXME instruct the user to directly > use wineprefixcreate for the upgrade. This way the user knows he/she > needs to backup before running the new wine. If you aren't confident that an upgrade won't break stuff you can always manually back up the wineprefix before running the new version, I don't think we need to do anything ourselves. Most users won't be administering production environments, and for them automatic upgrades would be helpful. thanks -mike

Sept. 28, 2004