Hello, I've spoken with the wine-d3d people and noone is currently doing anything on directx9 support. Originally Raphael was trying to merge things into a new library, wined3d, using an interface which ddraw could also use. This has not happened, and as we stand there is no progress being made. Now, I know nothing about d3d9 support - I have started to see what would be the easiest way to implement this, and have come up with a couple of options, and am after some advice.... 1. (My preference) d3d8 and d3d9 are very similar in lots of respects. I would like to move all the GL code into the wined3d library, effectively factorizing d3d8 and d3d9. However, this would mean extra function call overhead for dx8 and I really dont know how common they will be. Obviously d3d8 will change during such a transition 2. I could implement d3d9 from scratch. This would have the advantage of being a standalone library and wont affect d3d8, but a disadvantage of having to fix anything twice, and probably they will get out of sync really quickly. Also, d3d8 still has parts missing, and I'd prefer a single implementation if possible. If we did this, wined3d could be deleted and a huge code duplication would be required (or 3.... Do nothing, and see if anyone else takes up the gauntlet.) Now, I am not a 3d graphics programmer - I learnt d3d8 as I implemented it (for wine) out of interest to see how things were done. I am happy to try to do the same for d3d9, and would prefer approach (1). I have a few concerns though - Mostly I havent done enough research to know if its possible, and I may end up having a shared library with 2 implementations anyway... I havent found any major stumbling block yet, but I havent researched it far enough either. My other concern is if I start doing it and have to give up due to work or other pressures, I could leave a half migrated setup. I assume its relavitevly easy with cvs to back out changes if this occurs, and I hope it wont, but it is a concern. I'd appreciate thoughts before I start (especially Lionels, AJ's etc) - I'm only just getting back into wine programming again hence my interest. Jason
My other concern is if I start doing it and have to give up due to work or other pressures, I could leave a half migrated setup. I assume its relavitevly easy with cvs to back out changes if this occurs, and I hope it wont, but it is a concern.
I'd appreciate thoughts before I start (especially Lionels, AJ's etc) - I'm only just getting back into wine programming again hence my interest.
This is the sort of thing we wanted arch for. Unfortunately, the way we use CVS means that we can't really do branching as only AJ commits. So, if it's not possible to do the migration without breaking things temporarily, there are three ways forward: 1) Have you set up arch or a local CVS repository and commit to that 2) Give you write access to WineHQ CVS and let you commit to a branch 3) Just have you submit a really huge patch which does the changes (2) is, as far as I can tell, unprecedented, but hey ... worth suggesting. (3) might not make Alexandre too happy but is the simplest. (1) is perhaps the best way forward, with the biggest disadvantage being that arch is rather cumbersome to learn for people new to it, and when I last used it was rather slow. But, it may work a lot better these days. thanks -mike
This is the sort of thing we wanted arch for. Unfortunately, the way we use CVS means that we can't really do branching as only AJ commits. So, if it's not possible to do the migration without breaking things temporarily, there are three ways forward:
Well, why could we not live with DX8 / DX9 breakage for some time ? At the time D3D was resurected, it was broken for most of the time (and probably still is :-) ). And if someone disappears from development, it's just more motivations for others to pick up the work and continue (which would be more problematic with branches as this branch, if unmaintained, could really wither away without anyone working on it). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Well, why could we not live with DX8 / DX9 breakage for some time ? At the time D3D was resurected, it was broken for most of the time (and probably still is :-) ).
And if someone disappears from development, it's just more motivations for others to pick up the work and continue (which would be more problematic with branches as this branch, if unmaintained, could really wither away without anyone working on it).
Yes, this is true. But I think this isn't the direction we want to go in. At *some* point we have to stop simply releasing CVS snapshots which may or may not work/run important apps/eat your hard disk and actually do proper releases that are, you know, tested'n'stuff. Trivial example that's causing people problems today: apparently winecfg eats your drive configuration. People install wine, encounter this suggestively named "winecfg" program, run it, and now they get the dreaded C:\\Windows is not accessible error. Anyway. Yes. Releases. If we as a project are committed to doing 0.9, 1.0+ releases it means we can't simply break code people are using to play their games for months at a time and shrug it off. What other projects do this? I can't think of any. For most projects CVS is CVS and is where stuff is broken then fixed, and releases are what users install. They are expected to not ship with important features missing. Other projects typically use branches to deal with this, or in the case of the kernel fork off into separate projects that just maintain huge differentials which are folded back in when complete. So what do we do? thanks -mike
On Mon, Sep 13, 2004 at 01:55:19PM +0100, Mike Hearn wrote:
At *some* point we have to stop simply releasing CVS snapshots which may or may not work/run important apps/eat your hard disk and actually do proper releases that are, you know, tested'n'stuff.
Yes, but what should I care about this ? I mean that doing branches, handling releases is the job of a 'release manager' who should decide when to freeze, what patches to accept in freezed code and stuff like that. In my case, I would expect to work 99.99 % of the case on the trunk, the instable branch (except, of course, if any game is in the 'supported by this release' list and would need some bugfixing there). For example, if DirectX is broken for 3 consecutive releases, I would expect the people doing the release to label the old 'working' version and branch from there if any bugs fixes are needed. I do not want to be my own release manager ('oh this will take X months to finish, I will branch'). Lionel -- Lionel Ulmer - http://www.bbrox.org/
On Mon, Sep 13, 2004 at 01:55:19PM +0100, Mike Hearn wrote:
At *some* point we have to stop simply releasing CVS snapshots which may or may not work/run important apps/eat your hard disk and actually do proper releases that are, you know, tested'n'stuff.
While this point will come eventually, it has not been reached: ANNOUNCE starts as follows:
This is release 20040813 of Wine, a free implementation of Windows on Unix. This is still a developers only release. There are many bugs and unimplemented features. Most applications still do not work correctly.
As long as it's "a developers only release", there is *absolutely no reason" why developers should not be allowed to break things for a while. Also, please consider how often Alexandre rejects patches not because they would not be an improvement, but because they should be improved even more. *That* would also have to change once you start talking about making releases that are truly intended for users. Honestly, I don't think that this time has come already - and from my point of view, this may remain for quite a while. Those users who feel differently currently have the option the use wine versions that have been developed/modified for user- use: Codewavers and Transgamings wine flavours. Once Wine is declared to be ready for "ordinary users", the development process should indeed change. A good example on how to continue is KDE: Currently, development is done in two different branches: HEAD and 3_3_BRANCH: In HEAD developers are free to develop things, add new things (and occasionally break things: HEAD doesn't even compile from time to time). 3_3_BRANCH must be stable, changes to it a reviewed etc. IMO, this would also be a good way for wine, once it's considered to be sufficiently stable and feature "complete". Ciao Joerg -- Joerg Mayer <jmayer(a)loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology.
While this point will come eventually, it has not been reached: ANNOUNCE starts as follows:
I'm reminded of the saying, "if not now then when? if not you then who?"
Once Wine is declared to be ready for "ordinary users", the development process should indeed change.
And when exactly is that? "Ready" is a mostly meaningless, arbitrary target. Many users are using Wine today despite its official alpha-ness.
A good example on how to continue is KDE:
KDE bears no resemblence to Wine, they have always done releases with release management.
Currently, development is done in two different branches: HEAD and 3_3_BRANCH: In HEAD developers are free to develop things, add new things (and occasionally break things: HEAD doesn't even compile from time to time). 3_3_BRANCH must be stable, changes to it a reviewed etc. IMO, this would also be a good way for wine, once it's considered to be sufficiently stable and feature "complete".
There's no such thing for Wine. There is only increasing accuracy in the emulation. The TODO lists that have been drawn up for 0.9 and 1.0 are themselves pretty arbitrary: 0.9 has a theme of tidying up the interfaces but still stuff like execshield support was in there, WM rewrite and so on. I don't think it makes any sense to put it off indefinately on the grounds that Wine is still a developers-only release. That's circular logic.
Mike Hearn wrote:
I don't think it makes any sense to put it off indefinately on the grounds that Wine is still a developers-only release. That's circular logic.
Hear hear. Also, I think the sooner we start treating wine as a mature product, the better. Declaring a making a product mature is a great step in making it one. Shachar
On Tue, Sep 14, 2004 at 12:35:21PM +0300, Shachar Shemesh wrote:
Also, I think the sooner we start treating wine as a mature product, the better. Declaring a making a product mature is a great step in making it one.
Well, if you are ready to pay the price of stability (i.e. spend at least 4 or 5 hours a week re-installing your 4 or 5 favourite applications to test for regression), fine :-) The problem I see is that we do not have the developper manpower to do that. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Lionel Ulmer wrote:
Well, if you are ready to pay the price of stability (i.e. spend at least 4 or 5 hours a week re-installing your 4 or 5 favourite applications to test for regression), fine :-) The problem I see is that we do not have the developper manpower to do that.
However, it would be nice if regressions wrt particular programs were detected, pinned down to particular patches and *reported* by people who are particularly interested in making those programs work. For example, people who support WINE installations for their employers or customers. Other people who are supporting the same applications could benefit from that, because they'd know which patches should be removed or fixed. I've noticed some people already do that, but if the practice described above was more widespread, we could end up with fewer regressions, easier support and (usually) less work for developers. Chris
Mike Hearn wrote:
While this point will come eventually, it has not been reached: ANNOUNCE starts as follows:
I'm reminded of the saying, "if not now then when? if not you then who?"
Since Lionel is doing the work on Direct X, then I think it's up to him to decide how it should work and how to move it forward. He's doing it because he's interested in it, not to make money or keep Wine users happy. He's doing it because it's interesting and fun. Fun, remember. Secondly, if we attempt to keep a stable branch the new code won't get any testing, and won't be moved along. If Lionel thinks it needs breaking to move it forward, I vote to break it. Mike
Since Lionel is doing the work on Direct X, then I think it's up to him to decide how it should work and how to move it forward. He's doing it because he's interested in it, not to make money or keep Wine users happy. He's doing it because it's interesting and fun. Fun, remember.
I wasn't talking about DirectX specifically. I'm sure Alexandre will let Jason and Lionel do what they want with this. I was talking more generally about the Wine project as a whole.
Secondly, if we attempt to keep a stable branch the new code won't get any testing, and won't be moved along. If Lionel thinks it needs breaking to move it forward, I vote to break it.
Having stable branches doesn't seem to hurt the kernel, X, gnome, kde, etc etc. Some people will use the stable branch, the rest will follow CVS and hack on that, same as always.
Hi, On Tue, Sep 14, 2004 at 11:29:25AM +0100, Mike Hearn wrote:
Having stable branches doesn't seem to hurt the kernel, X, gnome, kde, etc etc. Some people will use the stable branch, the rest will follow CVS and hack on that, same as always. I think that reasoning distracts from the real issue: creating a stable and an unstable branch incurs an administrative overhead, one which might simply be too much compared to the gain we'd have without that overhead because we could concentrate on other things (things which are still not implemented, such as a very large percentage of Win32 APIs).
Linux (and all the other projects mentioned above) doesn't have such issues at all, since it sets its own pace (and thus has a well-defined current set of capabilities that are ALL implemented at any point in time), so it's well-justified to have stable/unstable there. After all I don't think our Wine CVS is THAT broken/problematic (the test suite should help here, too! Why not improve that one for a change?), and if people want that extra bit of stability, then they're very well-advised to go with CXO (or do you want to deprive CodeWeavers of their well-earned money? ;-)). Even just thinking of the extra 700MB compiled code on my HDD resulting from two branches worries me a bit. ;-) Not to mention that I believe that the kernel and KDE projects have a drastically larger developer audience than Wine, so they can easily afford having some people do the branch maintenance. So at this point in time I still think that doing stable/unstable branching would be the entirely wrong thing to do. Andreas Mohr
I think that reasoning distracts from the real issue: creating a stable and an unstable branch incurs an administrative overhead, one which might simply be too much compared to the gain we'd have without that overhead because we could concentrate on other things (things which are still not implemented, such as a very large percentage of Win32 APIs).
I think people are overestimating the burden. The stable branch doesn't have to exist for long, it could even be for just a few weeks before a release so people can do testing, hunt down regressions and so on.
Linux (and all the other projects mentioned above) doesn't have such issues at all, since it sets its own pace (and thus has a well-defined current set of capabilities that are ALL implemented at any point in time), so it's well-justified to have stable/unstable there.
I don't think it's about features. It's more about buggyness, and having popular apps work. Having a stabilisation period where only regression fixes are allowed on a particular branch could help with that.
After all I don't think our Wine CVS is THAT broken/problematic (the test suite should help here, too! Why not improve that one for a change?), and if people want that extra bit of stability, then they're very well-advised to go with CXO (or do you want to deprive CodeWeavers of their well-earned money? ;-)).
Hehe, of course not :) I'm not volunteering to do any of this, at least not right now! If Jeremy wanted to push Wine 0.9/1.0 forward then yes I'd be happy to work on it but right now I don't have the time, and what time I do have all goes on bugfixes and stabilisation for CrossOver. Anyway. The fact that CrossOver is a successful product perhaps says something about the value of stable releases.
Even just thinking of the extra 700MB compiled code on my HDD resulting from two branches worries me a bit. ;-)
Nobody is saying you have to use it, I'm sure most kernel developers don't have both 2.4 and 2.6 installed at once.
Not to mention that I believe that the kernel and KDE projects have a drastically larger developer audience than Wine, so they can easily afford having some people do the branch maintenance.
No, it's just a matter of willpower. Even small projects can do stable/unstable releases. Indeed, KDE basically is just a collection of smaller projects.
So at this point in time I still think that doing stable/unstable branching would be the entirely wrong thing to do.
What point in time would it be the right thing to do? For me, the right time is "whenever Jeremy says it is" :) But, with my community hat on, it's something that should be addressed at some point.
On Tue, Sep 14, 2004 at 09:57:52AM +0100, Mike Hearn wrote:
I'm reminded of the saying, "if not now then when? if not you then who?"
I think that once the API and the internal infrastructure are stable, the preconditions for that change are in place.
Once Wine is declared to be ready for "ordinary users", the development process should indeed change.
And when exactly is that?
"Ready" is a mostly meaningless, arbitrary target. Many users are using Wine today despite its official alpha-ness.
When exactly: When Alexandre changes that line in the ANNOUNCE, so just guess who has the last word in this discussion :-)
A good example on how to continue is KDE:
KDE bears no resemblence to Wine, they have always done releases with release management.
I proposed to adapt the KDE release management to wine, once there is a "stable" branch. There are a lot of nice mechanisms that are worth evaluating.
There's no such thing for Wine. There is only increasing accuracy in the emulation. The TODO lists that have been drawn up for 0.9 and 1.0 are themselves pretty arbitrary: 0.9 has a theme of tidying up the interfaces but still stuff like execshield support was in there, WM rewrite and so on.
Right, there *is* no such thing, but as written above, there *should be*, once Wine is officially declared ready for the general public
I don't think it makes any sense to put it off indefinately on the grounds that Wine is still a developers-only release. That's circular logic.
You are right on this point - there are some things to do: 1) decide when this sort of change/release will be done 2) how it will be done (Head/stable branch or some other model) 3) up to that point: don't slow down development by treating the wine tree like it was a stable branch. ciao Joerg -- Joerg Mayer <jmayer(a)loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology.
I'd appreciate thoughts before I start (especially Lionels, AJ's etc) - I'm only just getting back into wine programming again hence my interest.
I would be for solution 1) even if it means breaking somewhat D3D8 for some time. Note that this was Raphael's plan (although his was even more ambitious as he wanted the D3D1/7 code to use that same library). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Simple solution... Announce Wine Release 2004mmdd will be the last "stable" release and future downloads are at your own risk until further notice then go ahead and break it. It saves parallel trees and/or branch maintenance and allows developers to have their way. I would speculate that Wine would probably not be broken all that long anyway (maybe periodically) but would permit you developers the latitude required to very likely accelerate the 0.9, 1.0 goal time tables. I am not a developer, I am a user and have been learning C and how Wine works in my own spare time for the past 3 - 4 months and starting to understand some of this. I do have a formal education with extensive experience in scientific/engineering experimentation techniques, quality assurance analysis, etc and direct customer relations as a result products manufactured and do know that progress, especially when expedited, requires good communication and sometimes breaking things when required (it's not released for production yet) to achieve the goal. I realize this is a philosophical discussion as of now and since I am not at developer caliber - yet, you will all probably take this writing with a grain of salt but my grain goes to the break it side of the scale with appropriate notification(s) and get this project to beta asap. If there is concern regarding user flack, run a test announcement, then reasses. Roger
participants (9)
-
Andreas Mohr -
Ann and Jason Edmeades -
Joerg Mayer -
Krzysztof Foltman -
Lionel Ulmer -
Mike Hearn -
Mike McCormack -
Roger Olson -
Shachar Shemesh