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

Re: Countering arguments against Wine

by Dan Kegel

Holly Bostick wrote: > I've got Wine running, and installed several programs I was familiar > with under Windows, mostly to perform tasks that I couldn't figure out > how to do under Linux, but which I either knew how to perform using > Windows apps, or could find HOW-TOs for that specified Windows apps. I > find that it doesn't necessarily "feel strange" or at least as strange > as I might have imagined. What mostly feels strange is the complications > of getting the program started in the first place (having to cd to the > application folder to run wine <program_name> from a terminal, or having > to write a little start script in order to make a panel shortcut to it). Man, oh, man is that strange for the average Windows user. > Once the program is running, though, it doesn't "feel" strange at all; > after all, the reason I'm running it is most likely because I'm familiar > with it. This of course, assumes that the program in question runs well > under Wine, which we will assume for the sake of this discussion, if you > don't mind ;-) . I suspect that the drive letters being different adds a bit of runtime strangeness. And then there's a good chance that integration between Windows apps and native Linux apps will suffer. Finally, in all but the best-supported apps, Wine still has problems with lesser-used corners, and has subtly different appearance, if I'm not mistaken. > Maybe that's what you (and I) mean by "feeling strange", but since I'm > not sure what causes this feeling, I am not certain that migrating XP > users, who are used to and have no complaints with XP functionality but > rather are migrating because they don't like the Windows security model > (or lack therof)-- meaning, for practical reasons such as increasing > cost for less value, rather than philosophical ones such as a deep > objection to Windows' design philosophy or business practices-- would > feel the same way after switching to Linux. The great majority of Windows people will hate the entire idea of switching. They don't care about Linux in the least. They aren't switching 'because of' anything other than a) the computer was cheaper with Linux, or b) their company is switching to Linux. In either case, they expect their computer to Just Work Like It Did Before, and my suspicion is that a mixed system of Linux and Windows apps running under Wine will always have more glitches of one sort or another than a full set of native Linux apps. > If I come up with a "better" reason #2, I'll let you know ;-) . Please do! - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

Oct. 30, 2004

Adminrights...

by Devils Cry

Hey there! I just had an app which i wanted to install, but when i started the setup it gave me an error about the uninstallshield being active and that it has to be turned off. I googled a bit around and found out that this error only occurs if the setup is started by a user without administration rights. I tried it out, after suing i had no problems anymore. I guess there are several risks connected to so my question simply is: how can this be ommited? Regards Nikolas

Oct. 30, 2004

Re: Countering arguments against Wine

by Brian Vincent

On Fri, 29 Oct 2004 23:40:38 -0700, Dan Kegel <dank(a)kegel.com> wrote: > I've run into people several times who dislike the > fact that I advocate or even work on the Wine project, > because they feel that it takes focus away from > working on the Linux desktop. I beg to differ, but > I've never had a really snappy comeback for them. > It happened again today, and this time it occurred > to me I should write a page on the topic to organize These aren't exactly buried, but they're not obvious either: http://www.winehq.com/site/myths http://www.winehq.com/site/why -Brian

Oct. 30, 2004

Countering arguments against Wine

by Dan Kegel

I've run into people several times who dislike the fact that I advocate or even work on the Wine project, because they feel that it takes focus away from working on the Linux desktop. I beg to differ, but I've never had a really snappy comeback for them. It happened again today, and this time it occurred to me I should write a page on the topic to organize my thoughts. Here it is: http://www.kegel.com/wine/why.html Comments welcome. Thanks, Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

Oct. 30, 2004

Re: Success Stories?

by Scott Ritchie

>Are there any plans to spotlight Wine-use success >stories on the WineHQ home page? I always think of >how Disney used Wine to run Photoshop 7 so they could >move to a Linux platform. I'm sure it could draw >additional attention/ support and provide additional >credibility to non-Wine users. This exact story is on the CodeWeavers page somewhere, as an advertisement for Crossover. At the least, read it first :) Regardless, good luck!

Oct. 30, 2004

Re: question about modal messageboxes.

by Alexandre Julliard

"Ivan Leo Puoti" <puoti(a)inwind.it> writes: >>WS_EX_TOPMOST does nothing on Wine anyway, so I wouldn't worry too >>much about it. We certainly don't want 2 different resources, but it >>would probably be cleaner to remove DS_SYSMODAL on the existing >>resource, since the default is MB_APPLMODAL. > So if I get WS_EX_TOPMOST to work should I use 2 resources? No, just do a SetWindowPos(HWND_TOPMOST) in the dialog init code. -- Alexandre Julliard julliard(a)winehq.org

Oct. 30, 2004

Re: SHDOCVW: download the Mozilla Active X control on demand (take 2)

by Alexandre Julliard

Mike McCormack <mike(a)codeweavers.com> writes: > This patch downloads the mozilla active control on demand. It needs > the following registry key to be present to function correctly: > > [Software\\Wine\\Mozilla Control] 1089668326 > "Url"="http://www.iol.ie/~locka/mozilla/MozillaControl16.exe" > "Prog"="%TEMP%\\MozillaControl16.exe" The user shouldn't have to specify the temp file name, we can clearly figure this out by ourselves. Also the registry entry should be under Software\Wine\shdocvw, config parameters specific to a dll should use the dll name as key to avoid namespace conflicts. -- Alexandre Julliard julliard(a)winehq.org

Oct. 30, 2004

Re: question about modal messageboxes.

by Ivan Leo Puoti

>WS_EX_TOPMOST does nothing on Wine anyway, so I wouldn't worry too >much about it. We certainly don't want 2 different resources, but it >would probably be cleaner to remove DS_SYSMODAL on the existing >resource, since the default is MB_APPLMODAL. So if I get WS_EX_TOPMOST to work should I use 2 resources? The only other solution I can think of is using an atom, that sounds quite ridiculous for such a trivial thing. AFAIK apart from this detail sysmodal boxes have no reason for being a fixme. Ivan. ____________________________________________________________ Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione. Abbonati subito su http://www.libero.it

Oct. 30, 2004

Re: question about modal messageboxes.

by Alexandre Julliard

"Ivan Leo Puoti" <puoti(a)inwind.it> writes: > I looked at MSDN docs for MessageBox > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winu… > and found that MB_SYSTEMMODAL is identical to MB_APPLMODAL, the only difference > is that the dialogue box is created with WS_EX_TOPMOST. > In Wine the window style is loaded from user32_En.rc, and STYLE contains, > amongst other things, DS_SYSMODAL. MSDN > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winu… > says that if this value is used the window will be created using the > WS_EX_TOPMOST style. But what this means is that in Wine a messagebox is > *always* created with this style, while, if MSDN is correct, this should only > happen when MB_SYSTEMMODAL is passed to MessageBox. Am I getting something wrong > or is this a bug? > If yes, would creating 2 resources, one for MB_APPLMODAL and one for > MB_SYSTEMMODAL be a good solution? WS_EX_TOPMOST does nothing on Wine anyway, so I wouldn't worry too much about it. We certainly don't want 2 different resources, but it would probably be cleaner to remove DS_SYSMODAL on the existing resource, since the default is MB_APPLMODAL. -- Alexandre Julliard julliard(a)winehq.org

Oct. 30, 2004

Re: signaling unix threads

by Alexandre Julliard

Jukka Heinonen <jhei(a)iki.fi> writes: > Now, I have tried this approach and it seems to work. I have > some prototype implementation lying around but I was thinking > about doing something more complicated at the time, > like using SIGUSR2 handler for doing Win32 remote operations > discussed earlier on wine-devel, because signal handler > is probably running in the correct context for doing > this kind of things but I guess locking issues are going to > be pretty complicated so it is probably better to just fix > dosvm issues with a simple mechanism and not worry about > anything else. It would certainly be nice if we could convince dosvm to stop using SIGUSR2, there are lots of other things that could make better use of it. I don't really have a good solution to offer though (except maybe getting rid of dosvm altogether ;-) -- Alexandre Julliard julliard(a)winehq.org

Oct. 30, 2004