From the desk of Jeremy White (who is at LinuxWorld ATM).
Hey folks,
We've just launched a major new initiative, the CodeWeavers CrossOver Compatibility Center.
You can check it out at http://www.codeweavers.com/site/compatibility/ but I think it's fair to describe it as the appdb on steroids.
I wanted to announce it here to give folks a sense of what we're up to, and to apologize a bit in advance for stepping on the toes of folks that have been doing good work within the appdb.
However, the #1 problem we have had over the past year or so is how to handle all the many, many requests we get for applications not on our 'supported' list.
We've basically ended up sending people away, which has been pretty unsatisfying. Further, we haven't had any good way of determining what our priorities should be; we follow major paying clients, but beyond that, we mostly just follow our gut hunches in establishing priorities.
We hope to end that; this new center lets our customers vote for apps, and lets non customers make pledges. We can hopefully follow those pledges to get apps running (and we'd probably be open to having wine hackers committing to support apps in exchange for a piece of the pledges, but we haven't gotten there yet).
We've also, we hope, set the stage for a major new Wine related initiative - we hope to encourage lots of ISVs to certify their apps against Wine.
The rationale for this is pretty simple - apps won't run on Wine as well as they do on Windows until developers start testing against Wine. They've got to start somewhere - we're trying to give them that beginning.
We're obviously also hoping that this will help us to continue funding the work we've been able to do on Wine so far. As much of a struggle as it's been at times, we really feel lucky that we've been able to do so much. We hope that these initiatives will give us an extra little boost so we can help push Wine over the hump.
I sincerely believe that the day when we can honestly tell people "It will most likely work nicely on Wine" is not long off.
I also believe in the tooth fairy and Santa Claus, so make what you will of that <grin>.
At any rate, this is a brand new initiative for us; call it an 0.1.7 release. We're very open to comments and thoughts and suggestions, so I would greatly appreciate any public or private comments you have to make.
Cheers,
Jeremy
On Tue, 20 Jan 2004 08:05:32 -0600, Jeremy Newman wrote:
We've also, we hope, set the stage for a major new Wine related initiative - we hope to encourage lots of ISVs to certify their apps against Wine.
Cool! But.....
"We are confident that Wine has matured to the point that CrossOver will run 95% of all Windows applications by the end of 2005."
Uh, guys, are you sure that isn't over-optimistic? I mean, it seems that Wine is moving faster than ever before and that's great, but do you have any hard facts or statistics to back up that claim?
It's been over a decade now, and Wine still crashes and burns with most Windows apps, in my experience.
Only two years to implement all the random stuff apps want? MSHTML, MSI, DCOM, get all the bugs out of window management, make installers rock solid .... I mean the list of things that we need to do in order to reach that target just boggles my mind.
I'm also a tiny bit concerned that the site seems to blur its focus a bit - it seems to be positioned as a replacement for the appdb, despite the fact that it's CrossOver specific: I think there's enough forkage between CX Office and Wine now to make them basically separate products.
For instance, on the front page, there is this paragraph:
Up to this point, the perception has been that Wine only runs a limited number of Windows applications. For instance, CodeWeavers' CrossOver Office only officially supports about a dozen applications. However, the truth is that CrossOver runs many Windows applications quite well, although they may not be officially supported. Now, we're raising the bar. We are confident that Wine has matured to the point that CrossOver will run 95% of all Windows applications by the end of 2005. This Compatibility Center has been established in order to document that progress as Wine makes the next great leap forward. This piece of text seems to use the names Wine and CrossOver interchangably, when they are clearly different.
As for the database itself, well, it seems that it duplicates a lot of stuff needlessly - take "Alone in the dark". In the appdb there is only one comment which is basically "Works great!", but there is no indication the game works in C4. There's also no indication in either database whether it actually works as of Jan 2004.
Worst of all, there's no way to verify this except for a Wine developer buying a copy of the game, checking it, and possibly fixing regressions. So I'm not sure that an appdb type thing is even a good idea - a dedicated application maintainer who brings the app up to scratch, periodically checks it still works and so on is easily more valuable than a hundred appdb entries saying "This app doesn't work June 1998" or whatever, even if you have far fewer of them.
The idea of advocates is a turn off for me. It sounds like a revival of the old application owners idea, except that (again) it's crossover specific. It also feels a bit misleading. I think we'd all agree that the following phrases:
"Here at the Compatibility Center, we're looking for similarly talented individuals who have a passion to see their favorite Windows applications running on Linux under CrossOver."
"Volunteer your time to get an application working."
... makes it sound like all you have to do to get foo-app working is download CXO nightlies and report back the results. We already have this in effect, it's called bugzilla, and we all know that getting tester feedback of sufficiently high quality to fix the bug is while not rare, not the expected outcome. Bugzilla and the appdb are littered with comments like, "The app starts but then I get a message about flat scrollbars which crashes wine".
Is the CrossOver team going to trawl through C4 looking for feedback from the Advocates fixing bugs given (at best) a stack trace and a logfile? It'd be nice but the incoming workload scales much better than the workforce does.
Possibly there's something I'm missing here, like CXTest. Something like that sounds invaluable for tracking regressions if it works well, and maybe it's the secret sauce. I'm not sure.
Finally (sorry guys! :) the FAQ lists the first advantage of C4 over the appdb as the fact that it's maintained, but the cynic in me can't help noting that if you're capable of maintaining C4 you'd be capable of doing the same for the appdb ;)
I know I'm giving you a hard time here, and while I really appreciate all you're doing I thought I'd better air my concerns.
thanks -mike
"We are confident that Wine has matured to the point that CrossOver will run 95% of all Windows applications by the end of 2005."
Uh, guys, are you sure that isn't over-optimistic? I mean, it seems that Wine is moving faster than ever before and that's great, but do you have any hard facts or statistics to back up that claim?
Uh oh. I knew someone would call me on that <grin>.
Actually, this did seem to be a bit over the top, but if you think about it, it doesn't seem all that unreasonable. Wine right now runs a pretty amazing number of applications, and it runs many genuinely hard ones. Further, note that I didn't say it would run 95% of all apps *perfectly*. That, I think, is too much.
I think back to 23 months ago when Wine barely could run MS Office, and where we've come to from there, and I think it's doable. I think it's particularly doable if Desktop Linux continues to accelerate and we get a bunch more help to make it happen...
I also have a crazy dream of buying thousands of MS Windows titles, locking Aric in room until they all install, and then nailing them all to the floor with CXTest. I think this is conceivable (except for the part where Aric goes crazy and bludgeons his way out of the room with his laptop <grin>). And, I would argue, if were to truly make an effort to get every application to install and come to the main menu, we could make my prediction come true. I just need a bit more money, and a secure enough room to hold Aric...
I'm also a tiny bit concerned that the site seems to blur its focus a bit
- it seems to be positioned as a replacement for the appdb, despite the
fact that it's CrossOver specific: I think there's enough forkage between CX Office and Wine now to make them basically separate products.
Yah. This is a tricky one. We're genuinely motivated primarily by a desire to see Wine fly. However, we are also required by our spouses and physical law to make enough money to eat.
C4 is intended as a community primarily surrounding CrossOver, although the carry over to Wine is obvious. Essentially, the C4 community becomes another benefit of buying Wine from us, rather than simply downloading it for free.
So, yes, it is intentional that C4 is focused around CrossOver.
But I am concerned about the impact this will have on the appdb. I didn't really want to step on the toes of anyone that has been working on the appdb; that's a hard and largely thankless job. But I still believe in the original vision of the appdb (that's why I paid Jer to build it); I just think its going to work better in a context where it has a chance to pay for itself, so I can afford to pay someone the dirty job of keeping it up to date.
[snip]
Possibly there's something I'm missing here, like CXTest. Something like that sounds invaluable for tracking regressions if it works well, and maybe it's the secret sauce. I'm not sure.
Well, we're just making this up as we go <grin>, so I expect things to evolve and grow. Further, we do think that CXTest is going to add a meaningful and useful component to this. If nothing else, I'm hoping that CXTest will let us 'lock' applications in so that once they start working right, we can prevent them from regressing.
Again, the primary purpose of C4 is to give our customers somewhere meaningful to go when they want to work on an app that is outside of our 'supported' list. People can either put their money or their time where their mouth is, or stop bugging me <grin>.
As an aside, we have started working on a new policy of patch submission. We had always held an internal tree, worked against it, and then submitted a delta after a release. The merging started to become unmanageable, and so we've switched policy so that (ostensibly) all of our guys submit patches here first, and then we merge into CrossOver frequently. Once we get going with C4 and CXTest, this should have the nice side effect that Wine will get a regression testing tool and a company to run said regression tests every night. (Our goal is to be able to pinpoint the exact patch that breaks half-life <grin>).
Finally (sorry guys! :) the FAQ lists the first advantage of C4 over the appdb as the fact that it's maintained, but the cynic in me can't help noting that if you're capable of maintaining C4 you'd be capable of doing the same for the appdb ;)
But we don't get paid to maintain the appdb, and if we did maintain it, we'd encourage people to *not* buy CrossOver, imho. We do get paid by people who buy CrossOver, and we've hopefully given them a reason to be glad that they chose to give us their dollars.
I know I'm giving you a hard time here, and while I really appreciate all you're doing I thought I'd better air my concerns.
I appreciate the concerns; I really appreciate that you looked it over carefully and took the time to raise your concerns.
We're genuinely trying to figure out the best way forward, and we want to do what's best for everyone involved.
As a result, we're very open to suggested changes.
Cheers,
Jeremy
On Tue, 2004-01-20 at 19:56, Jeremy White wrote:
Further, note that I didn't say it would run 95% of all apps *perfectly*. That, I think, is too much.
Ah. The small print comes out ;)
I think back to 23 months ago when Wine barely could run MS Office,
Was it really only two years ago? Amazing. I once read that reports of MS Word working came in first around 1995, and naively assumed that meant it actually worked, the rest of office at least started etc. Clearly not.
and where we've come to from there, and I think it's doable. I think it's particularly doable if Desktop Linux continues to accelerate and we get a bunch more help to make it happen...
Ah yes, exponentially scalable growth. Let's hope so. Graphs of cvs commits/patch sizes would be neat. I might stick that on my (long) todo list :)
But I am concerned about the impact this will have on the appdb. I didn't really want to step on the toes of anyone that has been working on the appdb; that's a hard and largely thankless job. But I still believe in the original vision of the appdb (that's why I paid Jer to build it); I just think its going to work better in a context where it has a chance to pay for itself, so I can afford to pay someone the dirty job of keeping it up to date.
OK, I understand now. Glad that's cleared up.
We're genuinely trying to figure out the best way forward, and we want to do what's best for everyone involved.
As a result, we're very open to suggested changes.
I've not got any suggested changes really, I was just being difficult :)
thanks -mike
Mike Hearn wrote:
Ah yes, exponentially scalable growth. Let's hope so. Graphs of cvs commits/patch sizes would be neat. I might stick that on my (long) todo list :)
Here is one, http://www.winehq.org/hypermail/wine-devel/2001/11/0149.html (Wine source code size) its two years old but it's still nice to look at from time to time :)
Andreas any plans to update it?
Tom
On Tue, 20 Jan 2004 20:24:54 +0000, you wrote:
and where we've come to from there, and I think it's doable. I think it's particularly doable if Desktop Linux continues to accelerate and we get a bunch more help to make it happen...
Ah yes, exponentially scalable growth. Let's hope so. Graphs of cvs commits/patch sizes would be neat. I might stick that on my (long) todo list :)
A quick awk script on my cvs in box produced monthly number of cvs commits. That includes the commits to winehq.
Output attached, a graph produced with gnumeric is on http://home.wanadoo.nl/~wijn/wine/cvs.png
Rein.
Output attached, a graph produced with gnumeric is on http://home.wanadoo.nl/~wijn/wine/cvs.png
Hmm, there doesn't seem to be any particular trend upwards, does there, except perhaps a slight one towards the end. 1998 was a busy year, I wonder what was going on then.
On Wed, 21 Jan 2004 09:36:02 +0000, you wrote:
Output attached, a graph produced with gnumeric is on http://home.wanadoo.nl/~wijn/wine/cvs.png
Hmm, there doesn't seem to be any particular trend upwards, does there, except perhaps a slight one towards the end. 1998 was a busy year, I wonder what was going on then.
Looking through the email list, you may as well forget the first data point (October 1998). CVS did then send several messages for the same commit, I did include a "sort|uniq" in the script to prevent doubles, but these have slightly different send date/time's. November and later should be OK
At the time Corel was actively involved in Wine development, that might account for the activity that you observe.
Rein.
Hiya,
We've also, we hope, set the stage for a major new Wine related initiative - we hope to encourage lots of ISVs to certify their apps against Wine.
Yes this is REALLY needed but.....
The rationale for this is pretty simple - apps won't run on Wine as well as they do on Windows until developers start testing against Wine. They've got to start somewhere - we're trying to give them that beginning.
We're obviously also hoping that this will help us to continue funding the work we've been able to do on Wine so far. As much of a struggle as it's been at times, we really feel lucky that we've been able to do so much. We hope that these initiatives will give us an extra little boost so we can help push Wine over the hump.
I sincerely believe that the day when we can honestly tell people "It will most likely work nicely on Wine" is not long off.
.....depends on what happens at Wineconf.....
At any rate, this is a brand new initiative for us; call it an 0.1.7 release. We're very open to comments and thoughts and suggestions, so I would greatly appreciate any public or private comments you have to make.
For all of this to happen WINE Must....Be....Stable. Are we going to see 0.9 tagged as the main event at Wineconf 2004? Until we have a WINE 1.x I dont think we are going to see this in large numbers. Once 1.x happens and our regression testing system is filled with unit tests it will make vendors jump on board.
All in all I think its a great idea from the ReactOS side as I have been putting out feelers to ISVs Q&A people and they have no problem adding ReactOS to the already bloated list of Windows versions they have to test apps for. If this is going to really happen though we must have a stable WINE sooner rather than later.
Thanks Steven
PS. The goal 95% of all Windows apps on crossover is nice but I am afraid I am seeing more and more .Nyet apps out in the real world. For this to happen anytime soon we have to get on the ball with Mono and Windows.Forms.
__________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
Steven Edwards wrote:
.....depends on what happens at Wineconf.....
PS. The goal 95% of all Windows apps on crossover is nice but I am afraid I am seeing more and more .Nyet apps out in the real world. For this to happen anytime soon we have to get on the ball with Mono and Windows.Forms.
Jeremy
Did any one contact Xaim to see if they can send any MONO people to wineconf? Is there any vision on how these 2 integrate? I haven't even touched MONO yet (& .NET for that mater), but from the look of it they better use wine for some areas of .NET. Like .Forms. And certainly Wine Loader should have an hook ready for sending .NET code the MONO way.
Free Life Boaz
Did any one contact Xaim to see if they can send any MONO people to wineconf? Is there any vision on how these 2 integrate? I haven't even touched MONO yet (& .NET for that mater), but from the look of it they better use wine for some areas of .NET. Like .Forms. And certainly Wine Loader should have an hook ready for sending .NET code the MONO way.
I haven't asked them directly, but I know that Alexandre chatted directly with some of the Mono guys (who, afaik, promptly disregarded his advice and hacked Wine to their own ends <grin>).
Cheers,
Jer
Jeremy White wrote:
Did any one contact Xaim to see if they can send any MONO people to wineconf? Is there any vision on how these 2 integrate? I haven't even touched MONO yet (& .NET for that mater), but from the look of it they better use wine for some areas of .NET. Like .Forms. And certainly Wine Loader should have an hook ready for sending .NET code the MONO way.
I haven't asked them directly, but I know that Alexandre chatted directly with some of the Mono guys (who, afaik, promptly disregarded his advice and hacked Wine to their own ends <grin>).
Cheers,
Jer
They can re patch to their harts content every wine release. Stupid but doable. But are they releasing their wine source code ? They have to. So that means we have yet another fork of wine on the net? Nu well! Life!
Free Life Boaz
On Thursday 22 January 2004 12:05 am, Boaz Harrosh wrote:
Jeremy White wrote:
Did any one contact Xaim to see if they can send any MONO people to wineconf? Is there any vision on how these 2 integrate? I haven't even touched MONO yet (& .NET for that mater), but from the look of it they better use wine for some areas of .NET. Like .Forms. And certainly Wine Loader should have an hook ready for sending .NET code the MONO way.
I haven't asked them directly, but I know that Alexandre chatted directly with some of the Mono guys (who, afaik, promptly disregarded his advice and hacked Wine to their own ends <grin>).
Cheers,
Jer
They can re patch to their harts content every wine release. Stupid but doable. But are they releasing their wine source code ? They have to. So that means we have yet another fork of wine on the net? Nu well! Life!
Free Life Boaz
Mono is LGPL/X11 (except the compiler) so we could beat them at their own game by forking /their/ code, turning it into a winelib app, and implementing Windows.Forms properly ;)
If you're serious, here's where to start implementing your .NET hooks in wine:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/ht...
I think CorBindToRuntimeEx is the standard entry-point API to the CLR.
On Thu, 22 Jan 2004 11:17:55 -0600, Gregory M. Turner wrote:
Mono is LGPL/X11 (except the compiler) so we could beat them at their own game by forking /their/ code, turning it into a winelib app, and implementing Windows.Forms properly ;)
It's not that simple. Unsurprisingly they don't want a hard dependency on Wine when many .NET apps they write don't use SWF, so they need to be able to use wine without being a winelib app. We simply don't support that.
On Thu, 22 Jan 2004, Mike Hearn wrote:
On Thu, 22 Jan 2004 11:17:55 -0600, Gregory M. Turner wrote:
Mono is LGPL/X11 (except the compiler) so we could beat them at their own game by forking /their/ code, turning it into a winelib app, and implementing Windows.Forms properly ;)
It's not that simple. Unsurprisingly they don't want a hard dependency on Wine when many .NET apps they write don't use SWF, so they need to be able to use wine without being a winelib app. We simply don't support that.
I believe that's why Gregory proposed to fork their code: because he just wants a 100% open-source way to run .Net apps in Wine and thus for him the hard-dependency on Wine is not an issue.
Can Mono work on Windows? Or, in other words, is there an open-source .Net implementation on Windows? If yes we could try to make that work in Wine (as a PE binary first, then via a MinGW + Winelib port).
On Fri, 2004-01-23 at 10:54, Francois Gouget wrote:
I believe that's why Gregory proposed to fork their code: because he just wants a 100% open-source way to run .Net apps in Wine and thus for him the hard-dependency on Wine is not an issue.
Can Mono work on Windows? Or, in other words, is there an open-source .Net implementation on Windows? If yes we could try to make that work in Wine (as a PE binary first, then via a MinGW + Winelib port).
It can yes, I can imagine that you'd be able to build Mono as a winelib app.
We really need to think about this carefully. The situation is a bit sticky:
* Sometimes Wine will require Mono to run apps (for instance you can have normal Win32 apps that link against the .NET runtime or use COM activation to get .NET components at runtime)
* Sometimes Mono will require Wine to run apps, for programs that require System.Windows.Forms, but also for IJW binaries and for when .NET apps depend on unmanaged win32 COM components.
So it goes both ways. This is really tricky. One way to do is to fork each others code and merge them into each other but that just makes me feel dirty :)
There has to be a better way..... I'm not sure what it is yet though. We could probably implement our own mscorlib.dll which does the unmanaged setup then relays to libmscorlib.so or whatever it is mono uses.
On Tuesday 20 January 2004 08:05 am, Jeremy Newman wrote:
From the desk of Jeremy White (who is at LinuxWorld ATM).
Hey folks,
We've just launched a major new initiative, the CodeWeavers CrossOver Compatibility Center.
You can check it out at http://www.codeweavers.com/site/compatibility/ but I think it's fair to describe it as the appdb on steroids.
Looks great to me; although there are not any discussions yet (or are there?) in the "forums" area to demonstrate the quality of the forum interface, if it's something along the lines of phpBB, then it's perfect.
In my mind, the appdb is great, but better, threaded, discussion areas were needed for people to really get serious about it.
As for wine vs Crossover -- I presume that "plain old wine" users are welcome to participate? If so, then there really isn't a problem.
One layout nit: the images on the top don't line up right in Konqy 3.1.5. Looks pretty interesting, I hope it catches on.
On Wed, 2004-01-21 at 10:55, Gregory M. Turner wrote:
Looks great to me; although there are not any discussions yet (or are there?) in the "forums" area to demonstrate the quality of the forum interface, if it's something along the lines of phpBB, then it's perfect.
It's hard to compete with a package that has had years of devel like phpBB, but I will be expanding the forums as time goes on. I'm currently working on a moderation system for it. Right now, as they stand, the forums I am using here are only slightly better than the WineHQ version. I did add prev/next links when more than 50 posts are displayed. And I added the goofy profile icons everyone seems to like so much.
As for wine vs Crossover -- I presume that "plain old wine" users are welcome to participate? If so, then there really isn't a problem.
As long as they are talking about usage under CrossOver. We really don't want to confuse our customers.
One layout nit: the images on the top don't line up right in Konqy 3.1.5.
I recently updated the site to W3C HTML 4 compliance, but in doing so it broke how it displays in Konq. Ugh. Why bother being compliant if it breaks on some browsers out there.
As for wine vs Crossover -- I presume that "plain old wine" users are welcome to participate? If so, then there really isn't a problem.
As long as they are talking about usage under CrossOver. We really don't want to confuse our customers.
That's a bit stronger than I would put it, Jer. Our main emphasis is going to be on CrossOver, because we can quantify and control it. But we'll absolutely welcome general Wine conversations and users (but the version drop down boxes will all be CrossOver versions, for example).
Cheers,
Jer
-
Boaz Harrosh -
Francois Gouget -
Gregory M. Turner -
Jeremy Newman -
Jeremy White -
Mike Hearn -
Rein Klazes -
Steven Edwards -
Tom