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

Re: [lostwages] Remove winetools from download page

by wino＠piments.com

On Fri, 23 Dec 2005 06:58:03 +0100, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > >>> 6. "Version"="win98" - that is wrong. Wine's default _is_ win2k. >> It is right for the goal of the winetools. Again, this is why it's >> titled "3rd Party Tools". > No, it's not. Some major changes have been made to low level code that > makes Wine much more like with winNT then win9x. If you enforce win9x for > each program - you creating potential problems. And again, most programs > with do things differently on win9x then winNT. Like disabling some > features. So that again means that we never getting feedback from users. Maybe this highlights the fundemental issue here. There is a divergence between the needs of the developers to improve Wine and the needs of the users who want to use an albeit it imperfect tool to run windoze applications on Linux. I just installed an linux system for a freind and included wine. The next day I got a call: she had no idea how to use it or where to go, so I started to explain..... I quickly realised that it was too much and too complicated to explain. May I suggest that anyone involved in the wine project gets an "ordinary user" to install and use wine. The dev must be gagged and bound for this test !! This is what I do with my software. When a user installs the demo in my presence I tell him to pretend I'm not there and I watch. Sometimes I ask him to explain why he did/didnot do something. It's amazing how many things seem obvious to me but do not even exist in the world of the user. A technically excellent tool that is unusable is useless. If winetools and/or sidenet help many user to get going they are a valuable asset to Wine and Linux. Far from removing the winetools link I would prefer to see sidenet added. If devs can demonstrate that win2k default now _works_ better that win98 for most apps, that would be grounds to suggest a change to winetools. For the app I use on wine I started with win2k and had to revert to 98. If some things on winetools could be updated I'm sure suggestions will be welcome as long as not accompanied by veiled threats like "do this or we may decide we dont want the link". We all have the same goal but what is good for one is not good for all. Let's insure that different paths can coexist productively. Linux desktop is taking off NOW. Wine will play whatever contribution it makes to the future of Linux now, not in 6mths a year or ten years when it hits 1.0 Stop tweeking the dlls , take a deep breath and look around. I think user access needs to be the number one dev objective at this time. I hope all these comments and suggestions can be taken in a positive vein. I really want to see wine succeed. Best regards to all involved. Peter.

Dec. 23, 2005

Re: SPARC assembly won't compile, problems with NT headers

by Alexandre Julliard

Troy Rollo <wine(a)troy.rollo.name> writes: > This will work if (and only if) the value of SizeOfImage is unimportant for > Winelib executables. Of course in that case there is probably some merit in > setting it to zero anyway since at least that would make it obvious that it > has no meaningful value if somebody reads it later. Some apps do read it. It doesn't have to be exact, but it has to make sense (like being beyond the last section, things like that), so setting it to zero won't work. -- Alexandre Julliard julliard(a)winehq.org

Dec. 23, 2005

Re: [lostwages] Remove winetools from download page

by Sven Paschukat

Vitaliy Margolen schrieb: > I do not have Wine installed. All I have is wine symlink in my ~/bin dir. > And winetools could not find wine nor winecfg. So when I ran wt it > complained about that. That's a situation we don't have expected. I will try to make a fix. > Mm looking at those checks I would say 95% of them are invalid and/or not > as flexible as wine itself is. I will take a look. > findwine - 95% bogus. winetools - should be split into separate scripts > for each installed app. Makes it cleaner and more flexible. All the > scripts in scripts/ dir what are they for? Most seems to be 100% > redundant to what "wine" or "wine prog.exe && wineserver -w" do. Winetools code is manageable by us and the wine users out there creating patches. It's not needed to be splitten into 110 separate files. One of the intention of the scripts dir is a simple possibility to start the installad apps. When you e.g. install the Internet Explorer, there comes different apps like IE, Outlook Express, Windows Media Player. Each of it bas an own script with the correct path and executable. >>Using as much native dlls as possible makes chances best to install >>windows software, of course not user32.dll and such. > > No that's not the case at all. And this part specifically defeats the > whole propose of developing new dlls. Why would anyone in their right > mind start new dll, if you can use native? But the question is "can you?" > Most people DO NOT own Windows 98 licence. That means that each such > person should not even attempt to download or run winetools. Hm, there must be a way to become both - new users which don't have problems with there windows apps and also the wanted feedback from users using builtin dlls. What if I create a new feature into winetools which allows the users itself to choice between stability and using as few natives as possible. I believe winetools makes still sense without using native windows components. It allows easy download and installation of about 110 freely downloadable windows apps. The downloadable fonts are always nice. Furthermore some native windows components are currently not implemented in wine. > No, it's not. Some major changes have been made to low level code that > makes Wine much more like with winNT then win9x. If you enforce win9x for > each program - you creating potential problems. And again, most programs > with do things differently on win9x then winNT. Like disabling some > features. So that again means that we never getting feedback from users. It is one of my future Todos to change the windows version from win98 to win2000. But until now it doesn't seem to make real problems. All of the > 110 apps have been tested. Most of them are running good in win98, the ones which doesn't have a special win2000 configuration. Sven

Dec. 23, 2005

Re: [lostwages] Remove winetools from download page

by James Hawkins

On 12/22/05, Joseph Garvin <k04jg02(a)kzoo.edu> wrote: > > What usability? I've been reading the mailing list for a few months now, > and the only extent of 'usability' discussions for wine has been over > whether or not experienced linux geeks will be confused by options in > winecfg. That's not usability. That just means it's easy for hardcore > users to figure things out without having to look for docs. The work > being done in winecfg is both good and necessary, but it's still a long > ways away from wine being 'usable' to non-geeks. Wine is an open source project, and as such, the developers of wine encourage peer review. We value bug reports, comments, suggestions, and criticisms, whether good or bad, so that we can make wine a better application. Your comments infer that the developers aren't interested in making wine easier for the end user, or that we are too 'hardcore' to realize that wine may be hard to use. The latter is possible, but the former is completely untrue. We take usability reports very seriously, and increasing usability is a top priority. The only problem is that we don't get those types of reports as often as we should. One reason why we don't get these reports is because users have winetools to make wine easier. They don't run wine directly, configure wine with winecfg, and stumble over any usability issues. That is why this issue began in the first place. Speaking specifically to you Joseph, I've checked through the wine-devel and wine-users mailing list archives for reports of usability issues from you, but this is the first one. The constructive thing to do would be to politely report your problems on the wine-devel list, or even file bug reports for them. > When all of the binary packages (heck, any) on winehq.org have .Desktop files so that winecfg > is at least accessible without the use of a terminal, On at least KDE and Gnome, alt-f2 will bring up a run dialog, type winecfg and press enter. Even if winecfg was only usable from the command line, that doesn't count against usability. If that were the case, many well-known command line applications would be considered to have poor usability. > and you can launch a wine application that asks the user what windows > app they would like to run or make shortcut to so they don't have to use > terminal there either, /then/ maybe there can be some usability discussion. winefile > > And then maybe it would be appropriate to remove winetools. > Please re-read the posts. No one is advocating removing winetools, only the link to the winetool's download from winehq.org. -- James Hawkins

Dec. 23, 2005

Re: [lostwages] Remove winetools from download page

by Vitaliy Margolen

Thursday, December 22, 2005, 12:04:52 PM, Robert Shearman wrote: > Vitaliy Margolen wrote: >>5. It adds some extra needless overrides to the registry, like >> DLLOVERRIDES="*=native, builtin". Is there a reason for this? That >> _is exactly_ what we, developers, trying to avoid. >> >> > Actually, this makes sense for apps that install executables that are > coincidently named like programs that Wine has, e.g. calc.exe or user.exe. Then this is Wine's bug and has to be fixed as such. There is no reason to hide it. Not in Wine at least. > > On a slightly related note, in CrossOver we force a whole bunch of DLLs > to be builtin, like ole32, oleaut32, rpcrt4 and msi. Maybe we should do > the same for Wine? Well we could add them to the override list I guess. But I think it's the part of the same problem. We seems not doing it the same as windows does. We went from one extreme (using as much native dlls as possible) to another extreme (use builtins only). Vitaliy

Dec. 23, 2005

Re: [lostwages] Remove winetools from download page

by Vitaliy Margolen

Thursday, December 22, 2005, 4:16:54 PM, Sven Paschukat wrote: > Vitaliy Margolen schrieb: >> 2. It can't use wine from the source tree (again for testing). > It should. What were your problems? I do not have Wine installed. All I have is wine symlink in my ~/bin dir. And winetools could not find wine nor winecfg. So when I ran wt it complained about that. >> 3. It's using redundant scripts to like findwine. For what purpose? > It makes some checks to avoid problems. It was not our goal to write Mm looking at those checks I would say 95% of them are invalid and/or not as flexible as wine itself is. > perfect code like wine. So it is titled "3rd Party Tools". No one talks about "perfect code" here. We are talking about "entitlement" to be listed in the same line as Wine itself. >> 4. Those scripts override environment variables that wine and wine parts, >> depend on. Why? > Can you say more precisely what code fragment do you mean? findwine - 95% bogus. winetools - should be split into separate scripts for each installed app. Makes it cleaner and more flexible. All the scripts in scripts/ dir what are they for? Most seems to be 100% redundant to what "wine" or "wine prog.exe && wineserver -w" do. >> 5. It adds some extra needless overrides to the registry, like >> DLLOVERRIDES="*=native, builtin". Is there a reason for this? That >> _is exactly_ what we, developers, trying to avoid. > Using as much native dlls as possible makes chances best to install > windows software, of course not user32.dll and such. No that's not the case at all. And this part specifically defeats the whole propose of developing new dlls. Why would anyone in their right mind start new dll, if you can use native? But the question is "can you?" Most people DO NOT own Windows 98 licence. That means that each such person should not even attempt to download or run winetools. >> 6. "Version"="win98" - that is wrong. Wine's default _is_ win2k. > It is right for the goal of the winetools. Again, this is why it's > titled "3rd Party Tools". No, it's not. Some major changes have been made to low level code that makes Wine much more like with winNT then win9x. If you enforce win9x for each program - you creating potential problems. And again, most programs with do things differently on win9x then winNT. Like disabling some features. So that again means that we never getting feedback from users.

Dec. 23, 2005

Re: [lostwages] Remove winetools from download page

by Joseph Garvin

James Hawkins wrote: > >> >>Usability is another rapidly progressing area of wine. >> What usability? I've been reading the mailing list for a few months now, and the only extent of 'usability' discussions for wine has been over whether or not experienced linux geeks will be confused by options in winecfg. That's not usability. That just means it's easy for hardcore users to figure things out without having to look for docs. The work being done in winecfg is both good and necessary, but it's still a long ways away from wine being 'usable' to non-geeks. When all of the binary packages (heck, any) on winehq.org have .Desktop files so that winecfg is at least accessible without the use of a terminal, and you can launch a wine application that asks the user what windows app they would like to run or make shortcut to so they don't have to use terminal there either, /then/ maybe there can be some usability discussion. And then maybe it would be appropriate to remove winetools.

Dec. 23, 2005

Re: Wine IE6 and JVM

by Dominic Wise

On Thu, 2005-12-15 at 17:38 +0200, Adrian Munteanu wrote: > Hi guys, > > I am trying to use wine with IE 6. > Most of the pages are displaying fine, however the problem is with pages > requesting JVM running. > So could you please help me find away, if available, to make IE use > installed JVM? > > Thanks and best regards > Adrian > > > Have you tried latest winetools? I ask because it worked for me with IE6 .It has been updated to the 0.9 wine version. Hope this helps, Dom

Dec. 23, 2005

Re: msiexec null reference

by Bill Medland

On December 22, 2005 06:15 pm, Mike McCormack wrote: > Bill Medland wrote: > > + static const WCHAR dfv[] = { > > + 'M','S',' ','S','h','e','l','l',' ','D','l','g',0 > > }; > > > > > > + if (!dialog->default_font) > > + { > > + DWORD len = strlenW (dfv) + 1; > > + dialog->default_font = > > msi_alloc(len*sizeof(WCHAR)); + if > > (!dialog->default_font) return -1; > > + memcpy (dialog->default_font, dfv, > > len*sizeof(WCHAR)); + } > > How about this? > > if (!dialog->default_font) > dialog->default_font = msi_strdupW( dfv ); > > Mike 1. Alexandre has already committed it, using strdupW. (I am a little uncomfortable with the asymmetry but heck!) 2. Basically that was what I wanted to do but I couldn't (can't) find an msi_strdupW anywhere. I suppose I could have written it as such but seeing as how there wasn't one yet I presumed that there was insufficient demand. -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

Dec. 23, 2005

Re: [lostwages] Remove winetools from download page

by Dominic Wise

On Thu, 2005-12-22 at 09:43 +0100, wino(a)piments.com wrote: > On Thu, 22 Dec 2005 02:59:57 +0100, Tom Wickline <twickline(a)gmail.com> > wrote: > > > On 12/21/05, James Hawkins <truiken(a)gmail.com> wrote: > >> > >> As much as I appreciate the work you, Joachim, and others have put > >> into winetools, we're getting closer to the point in time when > >> winetools needs to be phased out by a better, more functional wine. > > Getting closer, sure, but it's not for tommorow As someone coming from a Windows (professionally at least, Linux at home) background I have to say that making it harder to install programs by dropping the link to winetools, given the known, current limitations of Wine, could completely undo all of the efforts of the last 10 years. One thing to remember is that 'Windows users are stupid'. Of course, I don't mean that literally; rather, anyone considering a switch to Linux is going to want to see some hard proof that their Windows programs might work. If they just get a crash (or a 'go to irc at etc....') they will give up immediately. I have seen some very sensible comments suggesting that once Wine reaches 1.0 then THAT is the time to drop references to winetools. > >> Part of this process is removing it from the official download page. > > Part of this process "will be" removing winetool link. "is" implies the > present and we are not at this stage with wine yet. > Agreed > > > > Shouldn't Wine be fixed before it's removed? Isn't it kind of backwards > > to say > > we need to have Wine run everything out of the box and to accomplish > > this were > > going to remove a link to a user friendly tool that currently helps our > > users. I agree completely > > > I agree, I think there has to be an easy start method with at least half a > chance of getting things running. > > Most new users , many probably new to linux as well will NOT even be aware > of what an IRC channel is an probably never met a maiing list either. > > It seems some of the ppl posting on this thread dont even realise that > they are living on a different plane to those actually using wine. > > If new users cant get some positive result quickly they will just conclude > that wine is unusable, and from an average user point , they would be > right. > See above > If they can be hooked by getting somethings to work they _may just_ go a > bit further with some things that dont. Hell , they may even read the doc > if they can find it. > As for argueing that bugs wont get reported. I was not aware that there > was a shortage of things to do in fixing Wine. > ing 'please look here > > If Wine scares off new users by expecting everyone to be a software > developer it will fail in it's primary role of helping users to migrate to > Linux. Could not agree more. Wine needs to 'get it right for the users ', even if that involves occasionally saying 'please look here; we like you and we want to keep you here'. Fixing bugs is the devs job, not the end user's job, yes? > > regards. > > > > >

Dec. 23, 2005