People,
I think everybody here agrees that Wine's biggest problem is the lack of developers. No developers, slow progress, no users, back to no developers. We are in this vicious circle for a while, spinning our wheels like crazy. We've achieved great progress lately, but I hope we all agree that Wine is a vast project that can succeed only with a mass appeal similar to the fueling the development of the Linux Kernel.
Why are we in this position? For reasons I will not go into right now, it seems painfully obvious to me that we are suffering from a severe case of Bad Public Image (tm). Whenever I talk to people not intimately familiar with Wine, about our beloved project, I am _always_ treated with the same reaction: a surprised "Really, it works? Hmmm, I thought it was only running Freecell...". Translation: people consider Wine a huge hack that can run (by some strange happenings) some apps, sometimes. It is viewed as unreliable, "freak of nature sideshow"; something (maybe) cool to talk about, but utterly useless.
THIS IS OUR PROBLEM. The lack of users follows trivially. We know the above opinion is not true. *I* get constantly amazed by how much progress we've made. Something must be done, and I think there is something to be done.
How do we change this state of affairs? Well, people need major events to reevaluate their opinions. Being major, they are by definition few, and so we don't have too many chances. For Wine, these events are the upcoming x.y releases. What I'm trying to say is that we have to prepare properly for them.
Here's my concrete proposal for releases: 0.8.x : Wine is usable, we don't guarantee binary compatibility 0.9.x : Wine is usable, and we kinda guarantee binary compatibility 1.0.x : Wine is quite usable, we guarantee binary compatibility
I'll define these things more precisely later, but before that, let me explain why we should introduce the 0.8.x series: -- a chance to attract more users into the fold -- Wine is approaching that stage fast -- it's a logical, interim step to 0.9 -- will help us focus Whatever the reason, it's a _logical_ step that we must go through in our journey to 0.9, and from a user's perspective, it makes sense to make it public. There's no point in robbing us of the userbase for a abstract techy goal of binary compatibility. That's the next stage.
Criteria for these releases:
0.8.0 -- Wine runs several popular apps well (we're close) -- Web site is updated (e.g. Who's Who, etc) -- Existing docs are up-to-date -- Utilities are close to final form (winebuild, etc.)
0.9.0 -- DLL separation complete -- Server protocol complete
1.0.0 -- Major bugs squashed -- Flawless UI -- Complete docs
I'll leave it at that. Comments, flames?
Why are we in this position? For reasons I will not go into right now, it seems painfully obvious to me that we are suffering from a severe case of Bad Public Image (tm). Whenever I talk to people not intimately familiar with Wine, about our beloved project, I am _always_ treated with the same reaction: a surprised "Really, it works? Hmmm, I thought it was only running Freecell...". Translation: people consider Wine a huge hack that can run (by some strange happenings) some apps, sometimes. It is viewed as unreliable, "freak of nature sideshow"; something (maybe) cool to talk about, but utterly useless.
Well, here's my views on the situation. Most people who are AWARE of Wine get those opinions for several reasons:
- No users, because of two things: - Many apps do not work without Desktop enabled. This is far worse than it sounds, because most newbies try managed non-desktop first. People think WINE should be able to do seemless intergration. Then when an application hangs, they think it's incompatible and give up. However in many cases the Application will work fine in Desktop mode. BAD, these apps should either be made to work... or non-desktop mode should be removed!
- Getting the right set of dlloverrides and registry entries correct for a large portion of software is irritating. Most of this comes down to the lack of WINE being able to dynamically run RunOnce and wininit.ini entries. Doing this manually is far beyond your average user who just wants to install a reasonably complex program. Something like Crossover's reboot.so is needed.
- No developers, because of two other issues: - The amount of cross-dependency in WINE code makes it very hard for a newbie developer to try and debug a problem in an application he uses. This also means that to trace most of this inter-dependency you need to debug so many parts that the amount if debug info becomes pretty difficult to work with. So to begin with, you need a good idea of WINEs internal structure and DLL cross-calling before you even start to play with it.
- There is no real decent debugging documentation, just a heap of skeleton documents on WineHQ. And any debugging situation a NEW developer is going to start on, is almost certainly going to be a difficult one.
Let's take the average example of a new developer trying to break into WINE. I try to run Paint Shop Pro 7, and it crashes. "Alright," I think; "This debugger looks like GDB.. I wonder if I can find the problem myself! Let's look at the backtrace..."
0x00778170 (psp.exe.?Default@CSubclassWnd@@IAEJXZ+0x35ef0 in C:\Program Files\Jasc Software Inc\Paint Shop Pro 7\psp.exe): movl 0x20(%eax),%edx
=>0 0x00778170 (psp.exe.?Default@CSubclassWnd@@IAEJXZ+0x35ef0 in C:\Program Files\Jasc Software Inc\Paint Shop Pro 7\psp.exe) (ebp=406928ac) 1 0x5f401cea (MFC42.DLL.6374+0x22 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=406928cc) 2 0x4098f0c8 (JCONTROLS.DLL.?WindowProc@CJascDialogBar@@MAEJIIJ@Z+0x28 in C:\PROGRAM FILES\JASC SOFTWARE INC\PAINT SHOP PRO 7\JCONTROLS.DLL) (ebp=4069293c) 3 0x5f401bfb (MFC42.DLL.1578+0x2a in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=40692958) 4 0x5f401bba (MFC42.DLL.1579+0x39 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=40692984) 5 0x407ef457 (WINPROC_wrapper+0x17 in user32.dll.so) (ebp=406929a8) 6 0x407ef4ed (WINPROC_CallWndProc+0x8d(proc=0x5f401b81, hwnd=0x20038, msg=0x18, wParam=0x1, lParam=0x0) [winproc.c:183] in user32.dll.so) (ebp=406929d8)
"Oh wow, that doesn't mean much to me.. I know enough Windows Programming to know that Paint Shop Pro is trying to subclass a window... but what's wrong with that? WINE is calling back into the program.. I can't find any information to help me work this out! Oh, I give up."
The thing to keep in mind is Developers are Users, but not all Users are Developers. A user who is going to turn into a developer is going to start by tackling a problem he experiences, and these are generally going to be the more complex issues. So without a good set of pointers on how to debug problems like this, they will jus tget frustrated and give up completely.
- James 'Ender' Brown ------------------------ Project Leader: http://www.scummvm.org/ Site Founder: http://www.quakesrc.org/ Lead Programmer: http://www.collectivedetective.org/
Ender wrote:
- Getting the right set of dlloverrides and registry entries correctfor a large portion of software is irritating. Most of this comes down to the lack of WINE being able to dynamically run RunOnce and wininit.ini entries. Doing this manually is far beyond your average user who just wants to install a reasonably complex program. Something like Crossover's reboot.so is needed.
I'm willing to tackle that (the BiDi stuff is only slowly going, and there may be some unexpected development coming that is outside my hands, so I have SOME free resources available).
Where do I get reboot.so to have a look? Either that, or can someone answer a few questions regarding it? - When are the boot time activities taking place? On wine start? On wineserver start? - When are login time activities taking place? - How should a reboot request be treated? Should it be an indication that all these operations should start now, and let other wine programs carry on as usual?
Shachar
Shachar Shemesh wrote:
Where do I get reboot.so to have a look? Either that, or can someone answer a few questions regarding it?
If we ask CodeWeavers nicely, I'm sure they might be willing to donate the reboot stuff? Otherwise you will just be re-inventing the wheel.
Greetings, Jaco
Hi,
I've done a lot of testing different applications that I have (and checking on their progress with new wine versions) and I was wondering:
Should I report every application that doesn't work as a separate bug?
Thanks, Kye Lewis Lew01@mcsc.vic.edu.au kyethespy@liquid2k.com
Kye Lewis wrote:
Hi,
I've done a lot of testing different applications that I have (and checking on their progress with new wine versions) and I was wondering:
Should I report every application that doesn't work as a separate bug?
Yes, a seperate bug report for each program is nessesary. It is possible that there are more than one bug report per program. For example the program crashes when I open a certain menu. and there is a display problem with one of the other menus.
A couple of things I would suggest before you submitt any bug report. Do I actually use this program on a regular basis? If this is the case then can I reproduce the bug and do I understand the steps that it takes to reproduce it and am I willing and able to do the followup to ensure that the bug is fixed? If the answer is yes then search bugzilla to see if the bug is already reported. If it is then add to the existing bug report. If not then start a new one.
<rant> At this point I have limited time to spend with wine and I have to be selective about where I spend it. I have seen a recent set of bug reports that simply list a fixme that a program has hit without any indication that the program behaved in an incorrect manner. When I see a bug report like that I want to yell at the reporter for wasting my time with a useless bug report. </rant>
Simply taking a program at random and seeing if it will run is fine in itself I suppose but submitting a bug report implies a certain commitment to getting it fixed.
Tony Lambregts
On Wed, Oct 30, 2002 at 12:21:51PM +0200, Shachar Shemesh wrote:
Ender wrote:
- Getting the right set of dlloverrides and registry entries correct
for a large portion of software is irritating. Most of this comes down to the lack of WINE being able to dynamically run RunOnce and wininit.ini entries. Doing this manually is far beyond your average user who just wants to install a reasonably complex program. Something like Crossover's reboot.so is needed.
I'm willing to tackle that (the BiDi stuff is only slowly going, and there may be some unexpected development coming that is outside my hands, so I have SOME free resources available).
Where do I get reboot.so to have a look? Either that, or can someone answer a few questions regarding it?
I've been having a finished implementation of wineboot in my tree for ages. I guess it's about time to get it submitted...
- When are the boot time activities taking place? On wine start? On
wineserver start?
Good question. I guess we once agreed on it being done on winelauncher script startup. (or alternatively really on user desktop login, but I'm not sure whether this is what we want) winelauncher should probably check whether any of the places that register reboot activities need processing, and if this is the case, then first finish a wineboot process, *then* start regular wine apps. All this would have to be resistant against race conditions, of course :-\
- When are login time activities taking place?
- How should a reboot request be treated? Should it be an indication
that all these operations should start now, and let other wine programs carry on as usual?
IMO we need to make sure we only do this when no other wine process is running. Optionally there could be some way to tell Wine to do it immediately, even during a session, though.
Sounds like nobody ever watched the wineconf2002 streams, since nobody ever knows about wineboot...
Andreas Mohr wrote:
On Wed, Oct 30, 2002 at 12:21:51PM +0200, Shachar Shemesh wrote:
Ender wrote:
- Getting the right set of dlloverrides and registry entries correct
for a large portion of software is irritating. Most of this comes down to the lack of WINE being able to dynamically run RunOnce and wininit.ini entries. Doing this manually is far beyond your average user who just wants to install a reasonably complex program. Something like Crossover's reboot.so is needed.
I'm willing to tackle that (the BiDi stuff is only slowly going, and there may be some unexpected development coming that is outside my hands, so I have SOME free resources available).
Where do I get reboot.so to have a look? Either that, or can someone answer a few questions regarding it?
I've been having a finished implementation of wineboot in my tree for ages. I guess it's about time to get it submitted...
I downloaded it once (you did the fatal mistake of mentioning it in one of your emails, and went and searched the archives for it). I couldn't get it to work, though, and I did not delve deep enough. If you have it, please submit it. I'm willing to take ownership of it if you don't want to.
- When are the boot time activities taking place? On wine start? On
wineserver start?
Good question. I guess we once agreed on it being done on winelauncher script startup.
Not familiar enough - is that the first startup of wine?
(or alternatively really on user desktop login, but I'm not sure whether this is what we want)
No, that would require nasty stuff we really don't want.
winelauncher should probably check whether any of the places that register reboot activities need processing, and if this is the case, then first finish a wineboot process, *then* start regular wine apps.
That's the way Windows does that for SOME of the stuff (most noteably - wininit.ini). Also, NT does it differently (register in the registry etc.). I used to know all that stuff off the top of my head (I did the "GTFormat" system that installed all of Packard Bell's machines, and I believe still installs all of NEC's - moved on myself) (before mentioning that PB's systems were no good - that was before GTFormat was introduced).
All this would have to be resistant against race conditions, of course :-\
- When are login time activities taking place?
- How should a reboot request be treated? Should it be an indication
that all these operations should start now, and let other wine programs carry on as usual?
IMO we need to make sure we only do this when no other wine process is running.
Either that, or start sending "WM_QUERYENDSESSION"s, the way the original does.
Optionally there could be some way to tell Wine to do it immediately, even during a session, though.
Sounds like nobody ever watched the wineconf2002 streams, since nobody ever knows about wineboot...
I didn't watch the stream. I'm also having some hand problems as well (though am taking care of them, so far rather succesfully - Dimi, call me if you want some tips... ).
Shachar
On Wednesday 30 October 2002 12:57 am, Ender wrote:
- No users, because of two things:
- Many apps do not work without Desktop enabled. This is far
worse than it sounds, because most newbies try managed non-desktop first. People think WINE should be able to do seemless intergration. Then when an application hangs, they think it's incompatible and give up. However in many cases the Application will work fine in Desktop mode. BAD, these apps should either be made to work... or non-desktop mode should be removed!
wierd, I basically never have theese problems, even in cases where the AppDB says it's an issue... what apps need this right now?
- Getting the right set of dlloverrides and registry entriescorrect for a large portion of software is irritating.
yes. perhaps we should include a much larger default config with usable defaults for several popular programs (or two config files, one for shared installs, one for wine-only installs)? I'd be happy to contribute my config file, for one, which runs quite a bit of junk.
Most of this comes down to the lack of WINE being able to dynamically run RunOnce and wininit.ini entries. Doing this manually is far beyond your average user who just wants to install a reasonably complex program. Something like Crossover's reboot.so is needed.
this is a relatively simple task, isn't it? wininit.ini is especially easy; RunOnce is a little trickier, because some RunOnce stuff should probably be censored. Another issue I see is the appearance of certain 8.3 filenames in the registry and the filesystem when running certain installers; this is kind of tricky to fix programmatically, but it could be done as part of a reboot.so-type program, I guess. Another (simpler) option would be to make a log of such problems during registry and filesystem operations, and notify the user to process the log during "reboot."
Also, during "reboots" that I've done using "explorer.exe", I notice some regsvr32's tend to fail; usually, they can be fixed using various dll overrides to regsvr32; a registry of special per-dll-to-register regsvr dll overrides, and a wrapper to invoke regsvr32 with the appropriate overrides from this registry, could go a long way towards eliminating this. Again, this will only help those doing mixed installations.
- No users, because of two things:
- Many apps do not work without Desktop enabled. This is far
worse than it sounds, because most newbies try managed non-desktop first. People think WINE should be able to do seemless intergration. Then when an application hangs, they think it's incompatible and give up. However in many cases the Application will work fine in Desktop mode. BAD, these apps should either be made to work... or non-desktop mode should be removed!
wierd, I basically never have theese problems, even in cases where the AppDB says it's an issue... what apps need this right now?
One example is the Australian E-Tax program mentioned recently - it'll hang on the splashscreen when no Desktop window exists (download: http://www.enderboi.com/misc/etax2002_1.exe)
Another example is setup programs for things like Internet Explorer, Microsoft Visual Studio. They'll crash out or just generally not work if various programs (_INSxxx._MP for example) are not set to use Desktop. I believe the QuickTimeInstaller suffers from the same problem, as well as several other bits of software I've tried using recently..
- James 'Ender' Brown ------------------------ Project Leader: http://www.scummvm.org/ Site Founder: http://www.quakesrc.org/ Lead Programmer: http://www.collectivedetective.org/
Ender wrote:
- No developers, because of two other issues:
Don't forget our friend, the Win32 API. Most people with an incentive to work on Wine are familiar with C, POSIX, etc. The first time they look at Win32 code, the get a splitting headache and decide it's not worth it. People who think that the Win32 API is a thing of beauty (I suppose there must be some) tend to use Windows.
"Ian" == Ian Pilcher pilchman@attbi.com writes:
Ian> Ender wrote: >> - No developers, because of two other issues:
Ian> Don't forget our friend, the Win32 API. Most people with an Ian> incentive to work on Wine are familiar with C, POSIX, etc. The Ian> first time they look at Win32 code, the get a splitting headache Ian> and decide it's not worth it. People who think that the Win32 API Ian> is a thing of beauty (I suppose there must be some) tend to use Ian> Windows.
Well,
think of Win32 as a user library, just like Motif or QT. So the "thing of beauty" ( or missing beauty) gets relative...
Bye
On October 30, 2002 09:11 am, Uwe Bonnes wrote:
think of Win32 as a user library, just like Motif or QT. So the "thing of beauty" ( or missing beauty) gets relative...
Very good point. This is another angle I wanted to approach: we are currently perceived by some as a 'evil thing' which allows MS-stuff to creep into Linux.
We should make it clear that Wine is:
1) a PE loader This is good! PE is a valid format, just like ELF. There are advantages to have it supported in Linux.
2) A (large) toolkit/lib/etc. There, we are in the same bucket as Lesstif, Qt, GTK, etc.
We are a Unix thing as much as all the other cherished libs.
On October 30, 2002 01:57 am, Ender wrote:
- Many apps do not work without Desktop enabled. This is far worsethan it sounds, because most newbies try managed non-desktop first. People think WINE should be able to do seemless intergration. Then when an application hangs, they think it's incompatible and give up. However in many cases the Application will work fine in Desktop mode. BAD, these apps should either be made to work... or non-desktop mode should be removed!
IMO desktop mode exists only because our integration is not very good. It should die sooner, rather than later, it's just a big hack. So we should rather focus on getting apps to work in non-desktop more, rather then resurrecting the silly desktop option.
- Getting the right set of dlloverrides and registry entries correctfor a large portion of software is irritating. [snip]
We should aim at delivering a 0.8/0.9/1.0 that does not require native DLLs to run apps. And so, there should be no need for dlloverrides...
- The amount of cross-dependency in WINE code makes it very hard fora newbie developer to try and debug a problem in an application he uses. This also means that to trace most of this inter-dependency you need to debug so many parts that the amount if debug info becomes pretty difficult to work with. So to begin with, you need a good idea of WINEs internal structure and DLL cross-calling before you even start to play with it.
That is true, but we're much better than 5 years ago. MUCH, MUCH BETTER. The DLL separation, and sticking t Win32 API have simplified Wine programming enormously, to the point where most Windows programmers can help on Wine right off the bat. The project is huge, what do you expect? :)
IMO desktop mode exists only because our integration is not very good. It should die sooner, rather than later, it's just a big hack. So we should rather focus on getting apps to work in non-desktop more, rather then resurrecting the silly desktop option.
I wholeheartedly disagree here.. I only use (and only ever will) use Desktop mode in Wine. It's the same (for me) as using Tabbed browsing in Mozilla : you have all the related mess in one window :-)
I agree that it seems to be a hack for now because of the one application <=> one desktop window 'feature' but well, Alexandre promised this to be fixed for 1.1 :-))
Lionel
On October 30, 2002 04:50 pm, Lionel Ulmer wrote:
I wholeheartedly disagree here.. I only use (and only ever will) use Desktop mode in Wine. It's the same (for me) as using Tabbed browsing in Mozilla : you have all the related mess in one window :-)
Sorry Lionel, but You Are Wrong (tm)! :) By your rationale, all KDE apps should start up their own desktop, all GTK apps another desktop, and so on. This way lies madness.
An app, is an app, is an app. I don't give a flying !@#$ if it's a Qt, Gtk, Python, Perl, Java, Wine, wxWindows, you-name-it app. I don't want every toolkit, library, etc. to invent their own universe with their own little desktop. It would be crazy. You feel the need to group apps to cleanup your workspace: fine, instruct your WM to do it! This does not belong in the toolkit!
An app, is an app, is an app. I don't give a flying !@#$ if it's a Qt, Gtk, Python, Perl, Java, Wine, wxWindows, you-name-it app. I don't want every toolkit, library, etc. to invent their own universe with their own little desktop. It would be crazy. You feel the need to group apps to cleanup your workspace: fine, instruct your WM to do it! This does not belong in the toolkit!
Well, you and I seem to have very different opinion on Wine. For you, it's a way to run a particular application. For me, it's like a virtual PC running Windows on my Linux box (ie more like a VMWare or a terminal server / Metaframe approach).
For me, running 'explorer' (or whatever is called the Windows WM) in a desktopped Windows session and actually have the 'Start' button in the lower right corner of the window to start Windows applications would be the way I would prefer running Wine.
Lionel
On October 30, 2002 05:12 pm, Lionel Ulmer wrote:
For me, running 'explorer' (or whatever is called the Windows WM) in a desktopped Windows session and actually have the 'Start' button in the lower right corner of the window to start Windows applications would be the way I would prefer running Wine.
That I understand. But still the fucntionallity does not belong in Wine. You should start a new desktop environment around Wine (say WDE), just like Qt, and GTK have their own DEs.
That I understand. But still the fucntionallity does not belong in Wine. You should start a new desktop environment around Wine (say WDE), just like Qt, and GTK have their own DEs.
Well, yes, if I wanted to ONLY use Windows applications I could do something like that. But a part from using Xnest or hacks like that (VNC comes to my mind too) I do not see how I could do what I want to do without support in Wine itself.
And well, what exactly is your problem with Desktop ? That it complexifies Wine too much ? From what I know from the code, it does not add that much complexity.
I would even agree from removing it from the docs / man pages if it pleases you as long as it is kept in the code :-)
Lionel
On October 30, 2002 05:27 pm, Lionel Ulmer wrote:
Well, yes, if I wanted to ONLY use Windows applications I could do something like that. But a part from using Xnest or hacks like that (VNC comes to my mind too) I do not see how I could do what I want to do without support in Wine itself.
So you consider Xnest and VNC hacks, but Wine's desktop mode OK?!? This is very strange, in the Unix spirit I would have thought those are the right approach for what you want to accomplish (pseudo-virtual machine).
So you consider Xnest and VNC hacks, but Wine's desktop mode OK?!? This is very strange, in the Unix spirit I would have thought those are the right approach for what you want to accomplish (pseudo-virtual machine).
Well, I said 'hacks' because for VNC it's not really what it was meant to do (except, of course, if one would write a VNC-protocol driver for Wine to be able to connect directly to a VNC server). This is less true for Xnest, but it is relatively unacceptable for performance reasons (for one, you add yet another process that needs to be scheduled in the equation plus it certainly will never run OpenGL in direct rendering mode).
Basically, you mean that you consider Tabbed browsing in Mozilla a 'hack' too because it should be your WM's job to do that for you ?
P.S. And no, there is no reason for WDE to be restricted to Windows apps only.
But I would want it to be. I do not want to change WM for my Linux applications, only for my Windows one. I do *NOT* want *ANY* integration between the Windows application run with Wine and my Linux applications (so I may be completely at odds with what CodeWeavers is trying to do, but oh well, I am used to have strange ideas :-) ).
Lionel
Well, you and I seem to have very different opinion on Wine. For you, it's a way to run a particular application. For me, it's like a virtual PC running Windows on my Linux box (ie more like a VMWare or a terminal server / Metaframe approach).
*cough* Wine Is Not an Emulator :)
- Ender
On Wed, 30 Oct 2002, Dimitrie O. Paun wrote:
On October 30, 2002 01:57 am, Ender wrote:
- Many apps do not work without Desktop enabled. This is far worsethan it sounds, because most newbies try managed non-desktop first. People think WINE should be able to do seemless intergration. Then when an application hangs, they think it's incompatible and give up. However in many cases the Application will work fine in Desktop mode. BAD, these apps should either be made to work... or non-desktop mode should be removed!
IMO desktop mode exists only because our integration is not very good. It should die sooner, rather than later, it's just a big hack. So we should rather focus on getting apps to work in non-desktop more, rather then resurrecting the silly desktop option.
I think desktop mode is useful in some circumstances like when you want to prevent an application from taking over the whole screen (typically installers or the PowerPoint viewer). Unfortunately it is currently broken in that if a process runs in a desktop and calls CreateProcess, the new process is run in a new desktop. That's really not the way it should work. But I would rather see this fixed than scrap desktop mode entirely.
Of course desktop mode is much less important than good behavior in managed mode. But getting managed mode to work really well will require some cooperation from the window manager which means we need the people who understand the issue to contribute to the window manager standards.
On October 30, 2002 05:01 pm, Francois Gouget wrote:
I think desktop mode is useful in some circumstances like when you want to prevent an application from taking over the whole screen (typically installers or the PowerPoint viewer).
While it may be useful in strange circumstances, it's not the right thing to do. How would you invoke it? What about other non-Wine apps that are taking over the screen? Should they have a desktop mode? And if we go down this path, what next: use ptrace to enhance Wine's security?!?
On Wed, Oct 30, 2002 at 05:27:48PM -0500, Dimitrie O. Paun wrote:
On October 30, 2002 05:01 pm, Francois Gouget wrote:
I think desktop mode is useful in some circumstances like when you want to prevent an application from taking over the whole screen (typically installers or the PowerPoint viewer).
While it may be useful in strange circumstances, it's not the right thing to do. How would you invoke it? What about other non-Wine apps that are taking over the screen? Should they have a desktop mode? And if we go down this path, what next: use ptrace to enhance Wine's security?!?
Since apps going 'full screen' is much more common in W$ than unix, maybe wine should have an option to lie about the screen size?
That way an app that requests 'full screen' (probably in order to get 800x600 pixels) won't grab the entire 1600x1200 (or larger) X display.
David
"Dimitrie" == Dimitrie O Paun dpaun@rogers.com writes:
Dimitrie> On October 30, 2002 01:57 am, Ender wrote: >> - Many apps do not work without Desktop enabled. This is far worse >> than it sounds, because most newbies try managed non-desktop >> first. People think WINE should be able to do seemless >> intergration. Then when an application hangs, they think it's >> incompatible and give up. However in many cases the Application will >> work fine in Desktop mode. BAD, these apps should either be made to >> work... or non-desktop mode should be removed!
Dimitrie> IMO desktop mode exists only because our integration is not Dimitrie> very good. It should die sooner, rather than later, it's just Dimitrie> a big hack. So we should rather focus on getting apps to work Dimitrie> in non-desktop more, rather then resurrecting the silly Dimitrie> desktop option.
Well,
my opinion on desktop mode is another one. It's not silly. Two examples: - any program in non-desktop mode switching to full screen (hey, a lot of programs like installer do that) and crashing later without a proper setup of the debugger. No most users are left in a situation they can't easily solve, as they don't know that they still can switch consoles and kill wine... - any application poping up endless series of new processes, each process grabbing keyboard focus. In a good desktop mode I would expect the real focus not to switch from the outside to the desktop. As now each process spawns it's own new desktop, focus is switched anyways.
Bye
On October 30, 2002 05:05 pm, Uwe Bonnes wrote:
- any program in non-desktop mode switching to full screen
- any application poping up endless series of new processes
This focuses on the wrong problem. A Wine app is just that: an app. If this is a problem, the WM must allow you to deal with them. You solve this way a general problem in an elegant way, not only a Wine-specific hack.
Uwe Bonnes wrote:
"Dimitrie" == Dimitrie O Paun dpaun@rogers.com writes:
Dimitrie> On October 30, 2002 01:57 am, Ender wrote:
- Many apps do not work without Desktop enabled. This is far worse
than it sounds, because most newbies try managed non-desktop first. People think WINE should be able to do seemless intergration. Then when an application hangs, they think it's incompatible and give up. However in many cases the Application will work fine in Desktop mode. BAD, these apps should either be made to work... or non-desktop mode should be removed!
Dimitrie> IMO desktop mode exists only because our integration is not Dimitrie> very good. It should die sooner, rather than later, it's just Dimitrie> a big hack. So we should rather focus on getting apps to work Dimitrie> in non-desktop more, rather then resurrecting the silly Dimitrie> desktop option.
Well,
my opinion on desktop mode is another one. It's not silly. Two examples:
- any program in non-desktop mode switching to full screen (hey, a lot of
programs like installer do that) and crashing later without a proper setup of the debugger. No most users are left in a situation they can't easily solve, as they don't know that they still can switch consoles and kill wine...
- any application poping up endless series of new processes, each process
grabbing keyboard focus. In a good desktop mode I would expect the real focus not to switch from the outside to the desktop. As now each process spawns it's own new desktop, focus is switched anyways.
Yes desktop is broken but it is the best way that I have to debug programs. Without desktop a lot of programs want to take over the whole screen and although there may be other ways of debuging these programs this is the best way that I know of. It need to be fixed not gotten rid of.
My 2 bits
Tony Lambregts.
On Wed, 2002-10-30 at 15:35, Dimitrie O. Paun wrote:
On October 30, 2002 01:57 am, Ender wrote:
- Many apps do not work without Desktop enabled. This is far worsethan it sounds, because most newbies try managed non-desktop first. People think WINE should be able to do seemless intergration. Then when an application hangs, they think it's incompatible and give up. However in many cases the Application will work fine in Desktop mode. BAD, these apps should either be made to work... or non-desktop mode should be removed!
IMO desktop mode exists only because our integration is not very good. It should die sooner, rather than later, it's just a big hack. So we should rather focus on getting apps to work in non-desktop more, rather then resurrecting the silly desktop option.
My understanding is that there still remain some fairly serious issues with Z-order processing in the window management code. I know that Mike and Alexandre have looked into it extensively; Alexandre mostly just shakes his head in despair when I ask about it <grin..
At some point, though, I think Alexandre is going to break down and fix it. Unless some fairly senior Wine hacker wants to step up first...
Mike is also starting to communicate with some of the freedesktop guys about WM standards; he has some ideas of ways the WMs can be tweaked to make our lives easier. If anyone else wants to kibitz/raise a voice with Mike, I think it'd be appreciated.
Finally, and this is purely a 'me-too' comment: I agree with Dimi - Wine should be run in its default case totally without the desktop mode. However, I strongly agree with Lionel - since we have desktop mode, we should keep it as an option. Free software is all about choice.
Cheers,
Jer
On October 30, 2002 10:34 pm, Jeremy White wrote:
However, I strongly agree with Lionel - since we have desktop mode, we should keep it as an option. Free software is all about choice.
Yes, but that choice does not refer to to the choice of cramming every feature together. :) Virtually all reasonable uses of the desktop thing that I heard of is just to limit the size of the window. For that, it's way better to support a --maxsize option, which is per wine invocation. Only Lionel has this strange desire to run Wine as a virtual machine, which is fine, but it's not where Wine is going. If you are really big on the VM idea (why, beats me), we should separate that functionality out as a winedesktop executable.
"Dimitrie O. Paun" dpaun@rogers.com writes:
If you are really big on the VM idea (why, beats me), we should separate that functionality out as a winedesktop executable.
Don't tell anyone, but that's exactly how the desktop option will have to be implemented to work with multiple processes.
On Wed, 30 Oct 2002, Dimitrie O. Paun wrote:
- Getting the right set of dlloverrides and registry entries correctfor a large portion of software is irritating. [snip]
We should aim at delivering a 0.8/0.9/1.0 that does not require native DLLs to run apps. And so, there should be no need for dlloverrides...
Even with perfectly working builtin dlls, one needs overrides for the native dlls that are proprietary, or the loading will fail. Or is this a bug?
/Johan Gill, johane@lysator.liu.se
Johan Gill wrote:
Even with perfectly working builtin dlls, one needs overrides for the native dlls that are proprietary, or the loading will fail. Or is this a bug?
/Johan Gill, johane@lysator.liu.se
The way I see it, no windows installs of wine should have dll load order set to "native, builtin" for all DLLs.
The rational is that, as no DLL originally came from a native windows environment, all dlls present in the system are from various installs. It was therefor the application's install decision to override the dll available at the time of install with a new version. For that to properly work, it must be possible to query the builtin DLLs version with the APIs available to standard installers, and have the version reported for our DLLs be comparable to DLLs of same functionality available on Windows. I am not sure where that stands at the moment, however.
Shachar
On Thu, 31 Oct 2002, Shachar Shemesh wrote:
The way I see it, no windows installs of wine should have dll load order set to "native, builtin" for all DLLs.
The rational is that, as no DLL originally came from a native windows environment, all dlls present in the system are from various installs. It was therefor the application's install decision to override the dll available at the time of install with a new version. For that to properly work, it must be possible to query the builtin DLLs version with the APIs available to standard installers, and have the version reported for our DLLs be comparable to DLLs of same functionality available on Windows. I am not sure where that stands at the moment, however. Shachar
I'm not sure that we are talking about the same thing here... Just to be safe, what I mean is that if I want to run an application which has its own *non-system* dlls I have to tell wine to load them natively, or they won't get loaded at all. If you meant the same thing as I did, I need some reading practice.
/Johan Gill, johane@lysator.liu.se
Johan Gill wrote:
On Thu, 31 Oct 2002, Shachar Shemesh wrote:
The way I see it, no windows installs of wine should have dll load order set to "native, builtin" for all DLLs.
I'm not sure that we are talking about the same thing here... Just to be safe, what I mean is that if I want to run an application which has its own *non-system* dlls I have to tell wine to load them natively, or they won't get loaded at all.
But if it's a non-system DLL, why should it have a Wine version at all? If it doesn't, then ANY load order that has native somewhere in it will load the DLLs in the system. The only place where that comes into play is when a certain program ships with a new version of MFC42.DLL, for example.
That is, at least, my understanding of this issue.
If you meant the same thing as I did, I need some reading practice.
What makes you think (besides being polite, and I'm not saying there is anything wrong with that) that it isn't me that need writing practice? I will note that, judging from geographical location alone, English is not a mother tongue for either of us.
/Johan Gill, johane@lysator.liu.se
Shachar P.S. In case anyone is wondering, I have other indications that English is not a mother tongue for me. There is the fact that I had to look up how to spell "tongue" for one, and that thing that makes sure that you keep knowing something once you knew it once, now how do you call it.....
Oh yes, "memory".
Sh.
On October 31, 2002 03:35 am, Johan Gill wrote:
Even with perfectly working builtin dlls, one needs overrides for the native dlls that are proprietary, or the loading will fail. Or is this a bug?
This doesn't sound right. Can you give some examples of that happening?
On Thu, 31 Oct 2002, Dimitrie O. Paun wrote:
On October 31, 2002 03:35 am, Johan Gill wrote:
Even with perfectly working builtin dlls, one needs overrides for the native dlls that are proprietary, or the loading will fail. Or is this a bug?
This doesn't sound right. Can you give some examples of that happening?
Sure. Sid Meier's Alpha Centauri uses sound.dll, which contains some convenience sound stuff. If I keep the default loadorder, "builtin","native", Wine tries to load sound.dll as builtin and fails, but does not try to treat the file as native.
/Johan Gill, johane@lysator.liu.se
Dimi,
For somebody with a sore hand, you type an amazing amount. I seem to have caught your "my-right-hand-is-hurting" bug. Well, actually it is my arm - utterly useless at anything at present, altough I can type if I position it at exactly the right angle...
I think everybody here agrees that Wine's biggest problem is the lack of developers. No developers, slow progress, no users, back to no developers.
James had an interresting reply to your mail around the time it takes for new developers to break into Wine. As a newbie myself, I have some thoughts on this... Ok, let's face it, Wine is damn hard. I have around 7 years experience in C++/C mostly on the Windows platform, altough I have done quite a number of personal projects under Linux, eg. XML interface into RPM, etc. I suppose Wine falls into this category, altough my contibution is not quite there, yet.
The reason why I like Wine so much is because it is extremely challenging. The beast is complex but (as I've read Jeremy White said before) things do take longer than anticipated. You need good understanding of Windows system calls plus Linux coding experience - a difficult combination to find. I think that a lot of people will look at the code, browse the web/bugzilla, be unable to find anything quick to break into the fold and give up.
Why are we in this position? For reasons I will not go into right now, it seems painfully obvious to me that we are suffering from a severe case of Bad Public Image (tm).
I personally think this is changing with CodeWeavers delivering commercial products based on Wine. As an example: the last time I played with wine was back in 96/97, I decided to take a serious look again after buying CXOffice and really seeing and reading and starting to believe... (Well, I must admit that I have been reading WWN since it's inception as well, just to get some sort of idea, so I haven't been completely out of touch.) So, yes, potentially you are right, but this is definately changing for the better.
How do we change this state of affairs? Well, people need major events to reevaluate their opinions. Being major, they are by definition few, and so we don't have too many chances. For Wine, these events are the upcoming x.y releases.
What both you and James are referring to is making the process more transparent. People need clear deliverables to be able to focus and redirect their engergy towards something. With my newbie hat on, I can say that we don't provide that. Unless you have been around for a longish period of time, you have no real idea as to the state of affairs.
I like both your and James' suggestions, in addition I would like to see the following:
1. Making sure that all tasks, big or small are in BugZilla. Make it easy to find - for instance, if I want to implement a DLL next, which one should it be? If you are not very, very familiar with Windows you wouldn't even know which DLL's on a Windows box are supposed to be replaced.
2. Making sure BugZilla is always updated anbd used in the right fashion. If something gets done, close the bug and make a comment. You need a record ort what has been happening. Remember that this is a real usefull developers-only (???) externtion to the website and makes their lives easier.
3. Better developers documentation, especially to get new guys onboard. (Erm, I think that was mentioned...)
I have quite a bit more to say, but I seem to have gottent the angle of the arm to the keyboard wrong at this point... So, that is it for now.
Greetings, Jaco
You need good understanding of Windows system calls plus Linux coding experience - a difficult combination to find.
IMO one is enough to get started. Solid Linux experience + access to MSDN gives a you good start. I had no Windows programming experience whatsoever before I started working on wine's winsock.
I think that a lot of people will look at the code, browse the web/bugzilla, be unable to find anything quick to break into the fold and give up.
There are such things, but most of them are of course boring. The "sexy" parts are hard to get started with. But that's no different than with other larger projects.
I personally think this is changing with CodeWeavers delivering commercial products based on Wine.
Yes, Codeweavers got brilliant reviews. Transgaming is also doing quite a good job. This may encourage users, but does it encourage developers?
What both you and James are referring to is making the process more transparent. People need clear deliverables to be able to focus and redirect their engergy towards something. With my newbie hat on, I can say that we don't provide that. Unless you have been around for a longish period of time, you have no real idea as to the state of affairs.
What is most urgently needed IMHO is more up-to-date documentation. Wine is changing very rapidly and the docs, even on WineHQ itself, more often than not don't reflect the changes.
And the most important part of the docs would be an easy-to-understand, up-to-date and in-depth tutorial of how to debug wine crashes, failures, etc. using different techniques (trace, winedbg, ..).
I know there are docs on that but we must make sure that they are up-to-date. It has happened to myself that I ran into some wine problem, wanted to produce a meaningful bug report, and than gave up because the debugger wouldn't run as expected (or described in the docs I had). Setting up wine such that you can do meaningful debugging currently almost requires "wine guru" capabilities.
The wine Wiki is great but there are far too many empty "New Item" entries.
- Making sure BugZilla is always updated anbd used in the right
fashion. If something gets done, close the bug and make a comment
A problem is that many reporters don't know how to use it. (Report bug, receive request for more information, never answer back - this has happened to me with a bug reporter employed in a wine-related company!). The only way to deal with that is to close the bug if it happens. For such situations I'd appreciate clear guidelines for maintainers.
Martin
On Wed, 2002-10-30 at 00:12, Dimitrie O. Paun wrote:
Why are we in this position? For reasons I will not go into right now, it seems painfully obvious to me that we are suffering from a severe case of Bad Public Image (tm). Whenever I talk to people not intimately familiar with Wine, about our beloved project, I am _always_ treated with the same reaction: a surprised "Really, it works? Hmmm, I thought it was only running Freecell...". Translation: people consider Wine a huge hack that can run (by some strange happenings) some apps, sometimes. It is viewed as unreliable, "freak of nature sideshow"; something (maybe) cool to talk about, but utterly useless.
Being a long time troll and admittedly bad problem reporter, my lack of experience tends to send me down the wrong path, I can tell you what MY impressions of Wine are.
My first success with Wine was quite a few years ago, running Agent .99. At that time, it seemed Win16 programs would have a chance, but Win32 wouldn't make it.
Since then, I've purchased Crossover products, and been pleasantly surprised by the applications that run under it. I was astonished to see GetRight work 100%, and almost taken aback to see Delta Force (and it's funky Voxtel engine) running under wine. (Ok DF3 doesn't QUITE make it, but DF1 and DF2 are more than I ever expected. Hmm Maybe desktop mode would work..)
I would love to convert my desktops to Linux + Wine, but one 'little' thing keeps nagging at me (even if my apps did work perfectly). I haven't seen it uttered in a while, but the phrase, "Wine is ALPHA software" sticks in my head.
People know what beta software is, and when someone see's "Alpha", they're not even going to attempt do debug it. Alpha (at least to me) conjures up such a raw state of affairs, that whatever problem is occurring, is happening because "Alpha" is seen as horribly broken.
I realize this isn't the case. I'm also sure that a lot of people DON'T realize that. I think CodeWeavers has greatly helped Wine's image by giving it a version number.
I wonder if people think CodeWeaver's Wine is THAT much of a different product than WineHQ's Wine..
Just another perspective, I'll be quiet now :)
Oh, and www.winehq.com seems to be down (can't connect from RoadRunner or Savvis networks)
Rick
Rick Romero wrote:
On Wed, 2002-10-30 at 00:12, Dimitrie O. Paun wrote:
Why are we in this position? For reasons I will not go into right now, it seems painfully obvious to me that we are suffering from a severe case of Bad Public Image (tm). Whenever I talk to people not intimately familiar with Wine, about our beloved project, I am _always_ treated with the same reaction: a surprised "Really, it works? Hmmm, I thought it was only running Freecell...". Translation: people consider Wine a huge hack that can run (by some strange happenings) some apps, sometimes. It is viewed as unreliable, "freak of nature sideshow"; something (maybe) cool to talk about, but utterly useless.
Being a long time troll and admittedly bad problem reporter, my lack of experience tends to send me down the wrong path, I can tell you what MY impressions of Wine are.
My first success with Wine was quite a few years ago, running Agent .99. At that time, it seemed Win16 programs would have a chance, but Win32 wouldn't make it.
Since then, I've purchased Crossover products, and been pleasantly surprised by the applications that run under it. I was astonished to see GetRight work 100%, and almost taken aback to see Delta Force (and it's funky Voxtel engine) running under wine. (Ok DF3 doesn't QUITE make it, but DF1 and DF2 are more than I ever expected. Hmm Maybe desktop mode would work..)
I would love to convert my desktops to Linux + Wine, but one 'little' thing keeps nagging at me (even if my apps did work perfectly). I haven't seen it uttered in a while, but the phrase, "Wine is ALPHA software" sticks in my head.
People know what beta software is, and when someone see's "Alpha", they're not even going to attempt do debug it. Alpha (at least to me) conjures up such a raw state of affairs, that whatever problem is occurring, is happening because "Alpha" is seen as horribly broken.
I am beginning to believe that wine is not very alpha anymore. It is more likely to run the program than crash and in some situations can be used in a production environment. So while I do not suggest that we immediately drop the alpha designation I would seriously ask what remains to be done to get rid of it.
I realize this isn't the case. I'm also sure that a lot of people DON'T realize that. I think CodeWeavers has greatly helped Wine's image by giving it a version number.
I wonder if people think CodeWeaver's Wine is THAT much of a different product than WineHQ's Wine..
I think that for mass appeal branding works better. These products are worth the money to the end user and provide a way for them to contribute to wine development. For those users that are willing and able to contribute to the project I welcome them. However most users will simply want it to work and for them the best way is to use one of these products.
Just another perspective, I'll be quiet now :)
Oh, and www.winehq.com seems to be down (can't connect from RoadRunner or Savvis networks)
I also cannot connect.
Tony Lambregts
On Wed, Oct 30, 2002 at 07:08:08AM -0600, Rick Romero wrote:
I would love to convert my desktops to Linux + Wine, but one 'little' thing keeps nagging at me (even if my apps did work perfectly). I haven't seen it uttered in a while, but the phrase, "Wine is ALPHA software" sticks in my head.
People know what beta software is, and when someone see's "Alpha", they're not even going to attempt do debug it. Alpha (at least to me) conjures up such a raw state of affairs, that whatever problem is occurring, is happening because "Alpha" is seen as horribly broken.
I realize this isn't the case. I'm also sure that a lot of people DON'T realize that. I think CodeWeavers has greatly helped Wine's image by giving it a version number.
Well, but I'd still insist that Wine IS Alpha software.
After all we've got about 15000 Windows functions, and of course we only implement about 4000 to 5000, and of those that we do support, a ridiculously small number is entirely bug-free.
Thus you could encounter an app which manages to trash your whole filesystem ANY DAY; this app simply needs to use a very rarely used function that we barely implemented... BOOM.
That this doesn't happen every day can be attributed... well... to the fact that Wine maybe is not entirely Alpha any more, but by no means does that mean it's Beta or even almost finished.
Wine is *not* a standard boring John Doe program, it's got a massively more difficult way to reach final stability. With an ordinary program, every little sub-version can easily be implemented to reach utter stability within its sometimes totally negligible goals. Not to mention that with a standard program, *you* define (and *know* !) what this program is supposed to do and how, whereas with Wine... you know the story ;-)
On October 30, 2002 08:56 am, Andreas Mohr wrote:
Thus you could encounter an app which manages to trash your whole filesystem ANY DAY; this app simply needs to use a very rarely used function that we barely implemented... BOOM.
Andy, this is just crap, and it's the type of crap that we should not perpetuate. There are tons of reasons why this _never_ happens, and you know them. So let's not propagate this type of misinformation that we have already too much out there, and which hurts us undoubtedly.
On Wed, Oct 30, 2002 at 10:00:08AM -0400, Dimitrie O. Paun wrote:
On October 30, 2002 08:56 am, Andreas Mohr wrote:
Thus you could encounter an app which manages to trash your whole filesystem ANY DAY; this app simply needs to use a very rarely used function that we barely implemented... BOOM.
Andy, this is just crap, and it's the type of crap that we should not perpetuate. There are tons of reasons why this _never_ happens, and you know them. So let's not propagate this type of misinformation that we have already too much out there, and which hurts us undoubtedly.
"Never" ? Never is never a perfectly fitting word...
I for one *have* heard in some admittedly rather *rare* cases of data corruption due to Wine (something like deleting the parent directory instead of the program directory due to skipping one level in directory hierarchy in some function due to a problem). -- oops, whole Wine drive content gone (in a worst-case scenario). (also, there's that well-known Explorer renaming issue, which is *not* a Wine problem but happens on Wine due to braindead Microsoft programming)
Crap is also a rather bold word (which admittedly I also use quite often - shame on me :). I'd say almost all of my text was based on facts that may happen sometimes, thus it could hardly be called crap.
I don't want to spread the perception that Wine is unsafe - in by far almost all cases it's definitely not. But people should keep in mind that for every new program that they install, there might still be a bug lurking in some rarely used function that this program uses, which could in some cases cause some... err... problems with data.
But most well-known programs have been tested quite a lot already, so the chance something like that happens with a well-known program is pretty slim to none, of course.
And given that even W2K or XP have strange filesystem problems when used with an excessive amount of files sometimes, this leads me to believe that Wine isn't that bad after all...
After all: Software == Heap o' Bugs :)
On October 30, 2002 09:20 am, Andreas Mohr wrote:
I don't want to spread the perception that Wine is unsafe - in by far almost all cases it's definitely not. But people should keep in mind that for every new program that they install, there might still be a bug lurking in some rarely used function that this program uses, which could in some cases cause some... err... problems with data.
But this is tautology. Wine is no different from any other program. We had SourceSafe corrupt the entire company reporsiotry (before I installed CVS) multiple times, and people use it. And believe me, it's MUCH worse than Wine in corrupting your data.
Single out Wine, and saying it can ANYDAY, ANYTIME corrupt your DATA is (1) untrue, as a practical matter, (2) helps no one, hurts us badly. Why say this in a public forum, so clueless Slashdoters can read, and link to it?
On Wed, 2002-10-30 at 07:56, Andreas Mohr wrote:
On Wed, Oct 30, 2002 at 07:08:08AM -0600, Rick Romero wrote:
I would love to convert my desktops to Linux + Wine, but one 'little' thing keeps nagging at me (even if my apps did work perfectly). I haven't seen it uttered in a while, but the phrase, "Wine is ALPHA software" sticks in my head.
People know what beta software is, and when someone see's "Alpha", they're not even going to attempt do debug it. Alpha (at least to me) conjures up such a raw state of affairs, that whatever problem is occurring, is happening because "Alpha" is seen as horribly broken.
I realize this isn't the case. I'm also sure that a lot of people DON'T realize that. I think CodeWeavers has greatly helped Wine's image by giving it a version number.
Well, but I'd still insist that Wine IS Alpha software.
After all we've got about 15000 Windows functions, and of course we only implement about 4000 to 5000, and of those that we do support, a ridiculously small number is entirely bug-free.
But how many apps use 15000 Windows functions? I think it's closer to Beta than Alpha.
Thus you could encounter an app which manages to trash your whole filesystem ANY DAY; this app simply needs to use a very rarely used function that we barely implemented... BOOM.
The same could be said for anyone opening an email. We all saw the article on the Kmail/Wine user. I don't think it's a good idea to put that info out in the world. Any application can trash your system, to specifically say it can happen with Wine just targets Wine as a poor program. Hence, less users. At some point Wine/Linux needs to break out of the tech community, it's not going to happen if all technically possible 'bad things' are presented right out front.
Sometimes you gotta keep your mouth shut :) (Believe me, I have a hard time doing that myself.)
Wine is *not* a standard boring John Doe program, it's got a massively more difficult way to reach final stability.
I think Wine is about where OS/2's Win16 support was. There were a lot of apps that worked, and a lot that didn't. And yes, OS/2's Win16 would take out the rest of OS/2 too.
With an ordinary program, every little sub-version can easily be implemented to reach utter stability within its sometimes totally negligible goals. Not to mention that with a standard program, *you* define (and *know* !) what this program is supposed to do and how, whereas with Wine... you know the story ;-)
I thought each API was a little sub-version :P
Rick
-
Alexandre Julliard -
Andreas Mohr -
David Laight -
Dimitrie O. Paun -
Ender -
Francois Gouget -
Greg Turner -
Ian Pilcher -
Jaco Greeff -
Jeremy White -
Johan Gill -
Kye Lewis -
Lionel Ulmer -
Martin Wilck -
Rick Romero -
Shachar Shemesh -
Tony Lambregts -
Uwe Bonnes