Re: Road to 1.0
Hi, On Sunday 25 March 2007 16:39:01 Dan Kegel wrote: > Here's a try at a 1.0 wish list: > - Safedisc support > - OpenGL child window problem solved for most common cards at least > - Adobe CS2/8 era apps installing and working > - Dragon Naturally Speaking 9 working (I'm selfish, I need that one :-) Just a late /me too for DNS9. Yours, -- René Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name +49 (0)30 / 255 897 45
Re: Road to 1.0
Hans Leidekker wrote: > On Sunday 25 March 2007 16:39:01 Dan Kegel wrote: > > >> Here's a try at a 1.0 wish list: >> > > I would like to see Wine 1.0 'fake' some suitable version > of Internet Explorer, say 6. > We almost have it. The main missing bit that causes apps not to find our IE is lack of registry keys. The problem with it is that some installers check these registries and if they don't find IE, they install it. Alexandre wants to make sure these apps work with builtin IE before setting them by default (as we would prevent such apps from installing IE). Currently we don't really know which apps need more work as we don't have any list of them... ATM there are much more apps that would benefit from these registries than those that would be broken IMO. Also we may always tell users to remove registries/install IE - that's something exactly inversed to what we do now for other apps. Jacek
Re: Road to 1.0
Better yet to be able to set what version it fakes. On 3/26/07, Hans Leidekker <[EMAIL PROTECTED]> wrote: On Sunday 25 March 2007 16:39:01 Dan Kegel wrote: > Here's a try at a 1.0 wish list: I would like to see Wine 1.0 'fake' some suitable version of Internet Explorer, say 6. -Hans
Re: Road to 1.0
On Sunday 25 March 2007 16:39:01 Dan Kegel wrote: > Here's a try at a 1.0 wish list: I would like to see Wine 1.0 'fake' some suitable version of Internet Explorer, say 6. -Hans
Re: Safedisc support (was: Road to 1.0)
Stefan Dösinger wrote: > Am Sonntag 25 März 2007 17:33 schrieb Phil Costin: >> Also, just out of interest, would a working safedisc implementation >> provide the necessary underpinnings to support the hexalock copy >> protection system? (http://hexalock.co.il/) > I think the needed infrastructure is the same, but of course we will have > to do extra bugfixing for each copy protection scheme. > > That hexalock thing sounds pretty rootkitish. I suspect that the real > content of the cd is encrypted, with an unencrypted decryption program. > That decryption program installs a rootkit which catches and blocks copy > operations on the source files and hacks MS IE 6 to prevent copy and > paste. > > If they were not completely stupid I am afraid that thing will not work > unless we load the driver into the Linux kernel. If the same driver that > prevents copy operations does the decryption it will have to be hooked > into the Linux cdrom driver. Maybe with raw access the decryption can be > done to allow programs in wine to access the cd, but not Linux programs. > There is a wikipedia page about it, but it is only a copy of the website. > > Of course if they are stupid enough to store the protected content > unencrypted, then we only have to make the rootkit happy enough to give > the app its OK. > > Personally I cannot see how their copy protected CDRs can resist a simple > dd if=/dev/cdrom of=copy.iso You're right, the hexalock disc content is mostly encrypted. It's pretty nasty stuff really. -Phil
Re: Road to 1.0
On 3/25/07, Alexandre Julliard <[EMAIL PROTECTED]> wrote: Clearly there will always be "office" apps that don't work, the question for the code freeze is whether we have all the pieces we need; I don't think there's a major feature at this point that would prevent typical office apps from working. COM has enough problems still to prevent a lot of big apps from installing, I think. I'd like to see that more solid before we declare 1.0. How about msvcr80 / sxs support? There seem to be a number of office apps that need that feature now. (Anything 2007-ish from Microsoft, probably.) I haven't been following it to see what's up there, but I do know I bump into apps that don't work yet because of it. Does .net support count? About ten apps in Bugzilla don't install because of that, including some fairly big-name ones. Don't know if any of them are office apps offhand, though. - Dan
Re: Game road to 1.0
> Essentially, they completely broke the rendering engine by hard-coding > assumptions about where the camera would be into the driver. Move the > camera slightly (such as in the developer version of 3D Mark), and > everything is a garbled mess. OK, I take the optimizations back, I didn't know what exactly they were doing. What I was thinking about when I talked about a performance slider a few days ago was playing around with some glHint parameters, or the worst thing, giving the user the ability to force drawStridedFast instead of drawStridedSlow, but that would be close to what nvidia was doing here(if the story is true). pgpD8kgZRMCsN.pgp Description: PGP signature
Re: Game road to 1.0
> > OpenGL: I don't really know of the windowed opengl state, and the wined3d > -> > wgl move. Still planned? > OpenGL needs to get proper windowed opengl rendering support. The best route to that seems to be by using opengl child windows. There's a patch for it but it needs cleanups and then AJ needs to accept it .. After that the rest of OpenGL can be cleaned up. For instance the pixelformat limitation can be lifted and because of that various things can be done in a proper way. Second multisampling will be possible as well. After OpenGL is stable, WineD3D can be moved over to WGL. Regards, Roderick -- "Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ... Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-in
Re: Road to 1.0
"Dan Kegel" <[EMAIL PROTECTED]> writes: > Alexandre wrote: >> That's still the plan, yes. I'm mostly waiting for the games >> support to stabilize; the other main areas, office apps and >> installers, both seem in good enough shape at this point. > > I suppose it depends on your definition of "office apps". > Adobe Acrobat Pro and Quicken don't work yet, and > they get used in a lot of offices. Clearly there will always be "office" apps that don't work, the question for the code freeze is whether we have all the pieces we need; I don't think there's a major feature at this point that would prevent typical office apps from working. Now, whether a specific app works is a different question, but as long as it only requires bug fixes it can be addressed after the freeze, or on the stable branch after 1.0. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Game road to 1.0
On Sun, 2007-03-25 at 18:43 +0200, Stefan Dösinger wrote: > > Does anyone here know if the NVIDIA Windows drivers are still rigged > > with regards to the various 3DMark suite of benchmarks? There was a > > scandal a while back, and the company claimed to pull their special > > hacks out, but then they were caught again later doing the same thing. > > It'd be a shame if we were testing rigged Windows drivers vs unrigged > > Linux ones. > I think the windows driver has a huge game Database with per game > optimizations. I think I saw it in their control applet, you can even change > the settings. (I don't have a access to a Windows nvidia machine atm). > > Last I knew the Linux driver allows similar tuning. And if someone wants to > he > can write a specialized wine patch and put a per game hack collection > somewhere. I personally don't think theres anything wrong if nvidia provides > me with fine-tuned per game settings. Honestly I wouldn't put hundreds of > hacks into my own code, but if nvidia thinks they can manage that, ok with > me :-) "Optimizations" aren't the issue here - hacks that break the application but still make the benchmark appear to render fine are. Here is an article discussing the issue: http://www.extremetech.com/article2/0,3973,1086025,00.asp Essentially, they completely broke the rendering engine by hard-coding assumptions about where the camera would be into the driver. Move the camera slightly (such as in the developer version of 3D Mark), and everything is a garbled mess. This defeats the entire purpose of a benchmark as a real-application performance test, since the benchmark is converted from a simulation of real game rendering calculations to instead be a glorified movie. Thanks, Scott Ritchie
Re: Road to 1.0
On 3/25/07, Scott Ritchie <[EMAIL PROTECTED]> wrote: On Sun, 2007-03-25 at 07:39 -0700, Dan Kegel wrote: > - Mono integration working for non-toy apps So, when do we need to start including mono as a build/install dependency for Wine in our packages? Once it works better. Right now it's really not ready to use. (And mono doesn't yet have a silent install mode, which would be nice.) If you want to try it out, easiest way is to do wget kegel.com/wine/winetricks sh winetricks mono12 Winetricks will then download mono, install it, and set the registry keys needed to make Wine use it. You can then try running simple .net apps, e.g. a trivial tile game http://www.codeproject.com/vb/net/tile.asp It uses gdiplus, so I think you have to install that first. I tried sh winetricks gdiplus corefonts and then wine TileGame.exe but it doesn't run... it dies deep within System.Windows.Forms.Control.get_DefaultFont () which doesn't seem like a good sign :-( Same problem with another trivial game, http://www.codeproject.com/useritems/8_Queen_Solution_New.asp Beyond those problems, there must be some other registry key we need to set. Installing e.g. http://www.dbautotrack.com/products/richtexteditor.html fails saying "This setup requires the .NET Framework. Please install the .NET Framework and run this setup again." - Dan
Re: Road to 1.0 (graphics driver architecture)
"Rolf Kalbermatter" <[EMAIL PROTECTED]> writes: > While the current apporach certainly works fine as far as invoking the > DC specific functions without a lot of checking about the type of DC > that is involved and therefore has a straightforward interface in GDI32 > I think the matching of the actual driver interface with the actual GDI > functions adds a lot of overhead into the driver itself that could much > more easily be done once in GDI and left out of the driver completely. > > However changing the driver interface to match the let's say W2K driver > would be quite a bit of work although it would seem to me at least an > idea. Coming up with yet a different Wine specific interface would first > require some architectural design work too but maybe you have done > something in that direction already. No, I don't have any plans to change the GDI interface, and I don't think any changes are necessary, the DC interface works fine for our needs. The area that really needs refactoring for the quartz driver is the user32 interface. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Game road to 1.0
From: Stefan Dösinger <[EMAIL PROTECTED]> To: Scott Ritchie <[EMAIL PROTECTED]> CC: Tom Wickline <[EMAIL PROTECTED]>, wine-devel@winehq.org Subject: Re: Game road to 1.0 Date: Sun, 25 Mar 2007 18:43:06 +0200 > Does anyone here know if the NVIDIA Windows drivers are still rigged > with regards to the various 3DMark suite of benchmarks? There was a > scandal a while back, and the company claimed to pull their special > hacks out, but then they were caught again later doing the same thing. > It'd be a shame if we were testing rigged Windows drivers vs unrigged > Linux ones. I think the windows driver has a huge game Database with per game optimizations. I think I saw it in their control applet, you can even change the settings. (I don't have a access to a Windows nvidia machine atm). Last I knew the Linux driver allows similar tuning. And if someone wants to he can write a specialized wine patch and put a per game hack collection somewhere. I personally don't think theres anything wrong if nvidia provides me with fine-tuned per game settings. Honestly I wouldn't put hundreds of hacks into my own code, but if nvidia thinks they can manage that, ok with me :-) I haven't seen those settings in the linux driver on a per application basis. The windows driver does offer per game/application settings, mostly for how it is handled if you have a SLI enabled system, whether you want the application to be rendered by one video card, or vertical sync SLI etc. It also has options to enable/disable anti-aliasing and anisotropic filtering. As far as I know you can only specify a global SLI setting in xorg.conf under linux.
Re: Safedisc support (was: Road to 1.0)
Am Sonntag 25 März 2007 17:33 schrieb Phil Costin: > Also, just out of interest, would a working safedisc implementation provide > the necessary underpinnings to support the hexalock copy protection system? > (http://hexalock.co.il/) I think the needed infrastructure is the same, but of course we will have to do extra bugfixing for each copy protection scheme. That hexalock thing sounds pretty rootkitish. I suspect that the real content of the cd is encrypted, with an unencrypted decryption program. That decryption program installs a rootkit which catches and blocks copy operations on the source files and hacks MS IE 6 to prevent copy and paste. If they were not completely stupid I am afraid that thing will not work unless we load the driver into the Linux kernel. If the same driver that prevents copy operations does the decryption it will have to be hooked into the Linux cdrom driver. Maybe with raw access the decryption can be done to allow programs in wine to access the cd, but not Linux programs. There is a wikipedia page about it, but it is only a copy of the website. Of course if they are stupid enough to store the protected content unencrypted, then we only have to make the rootkit happy enough to give the app its OK. Personally I cannot see how their copy protected CDRs can resist a simple dd if=/dev/cdrom of=copy.iso pgpznJNmUYPKD.pgp Description: PGP signature
Re: Road to 1.0
Am Sonntag 25 März 2007 18:17 schrieb Scott Ritchie: > On Sun, 2007-03-25 at 07:39 -0700, Dan Kegel wrote: > > - Mono integration working for non-toy apps > > So, when do we need to start including mono as a build/install > dependency for Wine in our packages? Or should we be doing that > already? It'd be nice to have it all working together by default. I think it is a dependency for using mscoree.dll. You don't need it to build or install wine, but when you want to use .NET it will ask you for mono(or thats the plan). Simmilar to shdocvw asking for wine-gecko. pgp9FKeYSddjr.pgp Description: PGP signature
Re: Game road to 1.0
> Does anyone here know if the NVIDIA Windows drivers are still rigged > with regards to the various 3DMark suite of benchmarks? There was a > scandal a while back, and the company claimed to pull their special > hacks out, but then they were caught again later doing the same thing. > It'd be a shame if we were testing rigged Windows drivers vs unrigged > Linux ones. I think the windows driver has a huge game Database with per game optimizations. I think I saw it in their control applet, you can even change the settings. (I don't have a access to a Windows nvidia machine atm). Last I knew the Linux driver allows similar tuning. And if someone wants to he can write a specialized wine patch and put a per game hack collection somewhere. I personally don't think theres anything wrong if nvidia provides me with fine-tuned per game settings. Honestly I wouldn't put hundreds of hacks into my own code, but if nvidia thinks they can manage that, ok with me :-) pgphz5m7YPaPk.pgp Description: PGP signature
Re: Game road to 1.0
On Sun, 2007-03-25 at 10:17 -0400, Tom Wickline wrote: > On 3/25/07, H. Verbeet <[EMAIL PROTECTED]> wrote: > > On 25/03/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: > > > So which of the following things do we want for 1.0? > > While nice to have, I don't think d3d10 or some of the more advanced > > SM 3.0 features should block 1.0. You already know my opinion on > > broken drivers. > > > > Things that aren't there, but IMO should be: > > - Make GLSL default > > Well from my test GLSL is just about on par with ARB's performance at this > time. > > http://wiki.winehq.org/BenchMark-0.9.33 > and > http://wiki.winehq.org/BenchMark-0.9.6 > > I still need to run PCMark04 and file a bug report and 0.9.33 will be > complete. > > I am aware there are a couple remaining task that need completed > before GLSL is set as default, just thought I would share the > performance state at this time. > > Tom Does anyone here know if the NVIDIA Windows drivers are still rigged with regards to the various 3DMark suite of benchmarks? There was a scandal a while back, and the company claimed to pull their special hacks out, but then they were caught again later doing the same thing. It'd be a shame if we were testing rigged Windows drivers vs unrigged Linux ones. Thanks, Scott Ritchie
re: Road to 1.0
On Sun, 2007-03-25 at 07:39 -0700, Dan Kegel wrote: > - Mono integration working for non-toy apps So, when do we need to start including mono as a build/install dependency for Wine in our packages? Or should we be doing that already? It'd be nice to have it all working together by default. Thanks, Scott Ritchie
Re: Safedisc support (was: Road to 1.0)
On Sun, Mar 25, 2007 at 05:31:03PM +0300, Timo Jyrinki wrote: > Alexandre Julliard wrote: > >And if we delay it a bit more maybe we can slip in Safedisc > >support too... > > Regarding which, does anyone have more up-to-date code and/or > information regarding Safedisc support, than what is currently > on the brand new Wine wiki page: http://wiki.winehq.org/SafeDisc ? No. > Safedisc support seems to be a topic that is hacked upon by various > people every now and then, but it does not seem very coordinated. It'd > be great if the wiki page would help to report on who's working on what > etc., and maybe even provide usable patches for users to try. No, the people stopped hacking on it. Basically it needs: - virtual objects served by a windows kernel driver - access to these objects must work as to any other object It is likely that a large rewrite of the whole object handling in the Wine Server is necessary to accomplish a Alexandre accepted solution. Ciao, Marcus
re: Road to 1.0
Alexandre wrote: That's still the plan, yes. I'm mostly waiting for the games support to stabilize; the other main areas, office apps and installers, both seem in good enough shape at this point. And if we delay it a bit more maybe we can slip in Safedisc support too... I would consider Safedisc an integral part of games support. Without copy protection support most games don't work.
Re: Safedisc support (was: Road to 1.0)
Also, just out of interest, would a working safedisc implementation provide the necessary underpinnings to support the hexalock copy protection system? (http://hexalock.co.il/) Timo Jyrinki wrote: > Alexandre Julliard wrote: >> And if we delay it a bit more maybe we can slip in Safedisc >> support too... > > Regarding which, does anyone have more up-to-date code and/or > information regarding Safedisc support, than what is currently > on the brand new Wine wiki page: http://wiki.winehq.org/SafeDisc ? > > Safedisc support seems to be a topic that is hacked upon by various > people every now and then, but it does not seem very coordinated. It'd > be great if the wiki page would help to report on who's working on what > etc., and maybe even provide usable patches for users to try. > > -Timo
Re: Road to 1.0
On Sun, Mar 25, 2007 at 07:39:01AM -0700, Dan Kegel wrote: > Alexandre wrote: [removed list of many features wanted for 1.0] Not that it matters, but it doesn't seem important to me what features go into a 1.0 release. But something like a stable branch could be something realy usefull for many users no matter what new features 1.0 brings. I'm not sure to what extend this was already answered or decided, but do we get a stable branch and a no known regressions policy for release and that branch? Jan
Re: Game road to 1.0
Actually, something else that affects quite a few games is support for .ani cursors.
re: Road to 1.0
Alexandre wrote: That's still the plan, yes. I'm mostly waiting for the games support to stabilize; the other main areas, office apps and installers, both seem in good enough shape at this point. I suppose it depends on your definition of "office apps". Adobe Acrobat Pro and Quicken don't work yet, and they get used in a lot of offices. I'm also hoping we can make some progress on the x11drv factorisation before the freeze, so that we don't need to change the interface too much to add the quartz driver later on, we'll see how that goes. And if we delay it a bit more maybe we can slip in Safedisc support too... Oh, yes, please. Here's a try at a 1.0 wish list: - Safedisc support - OpenGL child window problem solved for most common cards at least - Adobe CS2/8 era apps installing and working - Dragon Naturally Speaking 9 working (I'm selfish, I need that one :-) - Quicken 2006 installing/working (including online banking that requires 128 bits) - Mono integration working for non-toy apps - At least some of Munich's VB6 and/or databasey apps working (Hans just submitted a bunch of patches to fix most of the install issues in one) - Better application regression test suite (cxtest, yawt) October is looking about right for the start of the freeze, given that huge list. And my 1.1 wish list (i.e. hard things we can let slip past 1.0): - Activation context support - Quicken 2007 (which requires activation context support?) ... - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: Safedisc support (was: Road to 1.0)
Alexandre Julliard wrote: And if we delay it a bit more maybe we can slip in Safedisc support too... Regarding which, does anyone have more up-to-date code and/or information regarding Safedisc support, than what is currently on the brand new Wine wiki page: http://wiki.winehq.org/SafeDisc ? Safedisc support seems to be a topic that is hacked upon by various people every now and then, but it does not seem very coordinated. It'd be great if the wiki page would help to report on who's working on what etc., and maybe even provide usable patches for users to try. -Timo
Re: Game road to 1.0
Am Sonntag 25 März 2007 15:13 schrieb H. Verbeet: > On 25/03/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: > > So which of the following things do we want for 1.0? > > While nice to have, I don't think d3d10 or some of the more advanced > SM 3.0 features should block 1.0. Agreed. Those features won't be really relevant for a long time(Except Microsoft's exclusive Vista games). My concern is that with SoC we may get some extra boost in that area which we would kill prematurely if we freeze at an unfortune moment. Getting new developers is more important than shipping 1.0 IMO > Things that aren't there, but IMO should be: > - Make GLSL default > - Make FBOs default > - Support HDR / float textures Agreed. Those should be the minimum for 1.0. Appart of flipping the GLSL and FBO switch those are mainly bugfixes for me. > There are various cleanups that should be done as well (eg, getting > rid of FVFs completely), but I'm not sure if those should block 1.0 or > not. Yeah, various areas could need some cleanup(as usual). The surface / texture handling is a bit limited too. pgpES2SehZTIb.pgp Description: PGP signature
Re: Game road to 1.0
On 3/25/07, H. Verbeet <[EMAIL PROTECTED]> wrote: On 25/03/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: > So which of the following things do we want for 1.0? While nice to have, I don't think d3d10 or some of the more advanced SM 3.0 features should block 1.0. You already know my opinion on broken drivers. Things that aren't there, but IMO should be: - Make GLSL default Well from my test GLSL is just about on par with ARB's performance at this time. http://wiki.winehq.org/BenchMark-0.9.33 and http://wiki.winehq.org/BenchMark-0.9.6 I still need to run PCMark04 and file a bug report and 0.9.33 will be complete. I am aware there are a couple remaining task that need completed before GLSL is set as default, just thought I would share the performance state at this time. Tom
Re: Game road to 1.0
On 3/25/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: Hi, In another thread Alexandre has mentioned to wait for game stuff to stabilize before the 1.0 freeze. I think its time for another brainstorm of what features are still missing which we want in 1.0. The DirectX Todo has a long list but it tends to be useless to me. And I see that it can use some more cleanup( /me blames Tom-W for not nagging me enough :-) ) Hi Stefan, Ahh, nothing like a kind invite to nagg someone about the area of Wine that im most interested in. To be serious, if there is something that's missing or that can be added to the DX-ToDo that would be of real world usejust let me know and ill try my best to do what I can or nagg ;) someone into helping me get it on that page or another page if needed. My wish list in no particular order: SM 3.0 / HDR support Improved CAPS support GLSL / FBO,s as default Multithreading support Tom
Re: Game road to 1.0
Hi, I'm actually working on DirectPlay implmentation, i'm first fixing a bit of thing around dplayx, so that we can use native dpwsockx (the dplay service provider) with builtin dplayx. After that i'm going to reimplement dpwsockx from scratch using the info from Kai Blins work on the protocol. Regards, Alessandro Pignotti -- Vi Veri Veniversum Vivus Vici -Dr. Faustus - Marlowe Public GPG Key ID 0x650B3ED9 on subkeys.gpg.net Key Fingerprint 6243 AAD3 E3EC 52D8 DFAA 2A2F 9FCD 0457 650B 3ED9 Encrypted mails are welcome pgpQmQ3qF6ZEr.pgp Description: PGP signature
Re: Game road to 1.0
On 25/03/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: So which of the following things do we want for 1.0? While nice to have, I don't think d3d10 or some of the more advanced SM 3.0 features should block 1.0. You already know my opinion on broken drivers. Things that aren't there, but IMO should be: - Make GLSL default - Make FBOs default - Support HDR / float textures There are various cleanups that should be done as well (eg, getting rid of FVFs completely), but I'm not sure if those should block 1.0 or not.
Game road to 1.0
Hi, In another thread Alexandre has mentioned to wait for game stuff to stabilize before the 1.0 freeze. I think its time for another brainstorm of what features are still missing which we want in 1.0. The DirectX Todo has a long list but it tends to be useless to me. And I see that it can use some more cleanup( /me blames Tom-W for not nagging me enough :-) ) It also sounds like AJ takes games as an excuse to delay the freeze for the display driver cleanup, and I was tempted to take the display driver cleanup as an excuse to get more dx stuff in. So which of the following things do we want for 1.0? Direct3D: * Some SM 3.0 features are still missing. Instancing is now in, vertex textures and some other stuff still missing. Not widely used among games yet. * Multithreading. OpenGL part done(except of 3 patches which I'll NOT send for now (*) ), but needs synchronisation. Will take a lot of time. * OpenGL ddraw. Render target locking improvements, multithreading. * Many games to not run yet, problems on MacOS drivers and fglrx. For the D3D part I see that as bugfixes which can happen after the freeze as far as I understand things. * Direct3D10. Will see if someone applies for my SoC proposal. (*) The patches that do the context selection. I won't send them because with my testing patches people started hunting phantom bugs which were the result of missing synchronisation. DirectSound: Maarten plans to work on that for SoC I think. Freezing now would make that difficult. Would mean to delay the freeze until September / October most at least. I'd personally really apprechiate dsound and alsa working better in 1.0. OpenGL: I don't really know of the windowed opengl state, and the wined3d -> wgl move. Still planned? DirectPlay: Kai works on the protocol, but I think he doesn't plan to implement it anytime soon. It seems the current idea is to improve our networking libs to get native dplay working. pgpxupffOTmGI.pgp Description: PGP signature
Road to 1.0 (graphics driver architecture)
Alexandre Julliard wrote: >I'm also hoping we can make some progress on the x11drv factorisation >before the freeze, so that we don't need to change the interface too >much to add the quartz driver later on, we'll see how that goes. Have you some specific ideas about what you want to do in that area? While the current apporach certainly works fine as far as invoking the DC specific functions without a lot of checking about the type of DC that is involved and therefore has a straightforward interface in GDI32 I think the matching of the actual driver interface with the actual GDI functions adds a lot of overhead into the driver itself that could much more easily be done once in GDI and left out of the driver completely. However changing the driver interface to match the let's say W2K driver would be quite a bit of work although it would seem to me at least an idea. Coming up with yet a different Wine specific interface would first require some architectural design work too but maybe you have done something in that direction already. Rolf Kalbermatter
Re: Road to 1.0
Yea, I agree with what you said, I didn't mean for my message to sound like people were doing anything blatantly wrong, the fact is though, if we like them or hate them from a development standpoint, people love these work arounds as users, and, it's just the evolution of the community that will make things like this. For the user it's make it make it work quick, more so than get fixes into the tree. Since we can't just stop the projects, which I don't think we would *really* want to, working aorund them is the best bet. Maybe talk with the maintainers of these so called Wine GUIs, and have them implement methods of sending in reports. Not to mention that we could have some kind of an unexpected kill catch to compile bugreports automatically, and tell the user how to go about submitting it, or even do it for them, to some degree we could have information on individual fix mes sent as well, you could imagine seeing which 'fixme' was spit out the most, then focusing on it. Things like that would not only help users get to the devs, but help the devs stay on track of whats best needed, for those that focus on the general need, rather than the "this doesn't work for me, I'll fix it" way, which isn't so bad in itself. I don't know... I'm an idealist =] On 3/23/07, James Hawkins <[EMAIL PROTECTED]> wrote: On 3/22/07, Bryan Haskins <[EMAIL PROTECTED]> wrote: > > > > > If you are making it extremely easy for users to run with native dlls > > and hacky workarounds, then you are hurting Wine. Wine is still beta, > > That's true... and people technically should only be using wine for the pure > sake of testing and helping fix usage. LEt's be honest, very few use it for > that, they just want it to work, they use wine for the use the Devs want out > of 1.0. Saying to someone that because it doesn't work by default, we're not > going to let you use it, or in general make it hard for them defeats the > goal of the *actual program*, > No one here says they can't use Wine if their app doesn't work, and we're certainly not trying to make it harder for them if that is the case. The argument is irrelevant though, as it doesn't follow the original question, "Does my development of Wine-Doors hurt Wine." >Joe XYZ wants to play Oblivion, He Finds it > doesn't work! He looks around and sees that if he does a lot of various > things it will work *okay*, Joe XYZ does them. Joe XYZ had no intention of > ever submitting bugs at all, is this bad? Hell yes it is. We should educate > at how important it is for a program like Wine to have nice detailed Bug > Tracking, but at the same time, can you blame him for just wanting it to > work, easily? As long as the user, at some point, realized, hey this doesn't > work out of the box, the job is done to some degree. > The optimal outcome of this scenario is that Joe XYZ reports his problems running Oblivion to the Wine development community using bugzilla. The Wine development community then fixes these bugs, leaving Joe XYZ very satisfied with Wine. The next possible outcome is that it takes a little while for the bugs to be fixed, though they'll be fixed at some point, but we do try our hardest. If developers working on projects such as Wine-Doors contributed to Wine, then the bugs would be fixed even faster. > To summarize, If a user never was going to report things, that's bad, he > should be educated, but at the same time, if he still wouldn't, shouldn't it > be our job as the community to make it easy for him? > Make it easy for him to report the bugs? Yea we should make it as easy as possible. > This goes back to the WineTools thing... that was bad though, even though at > face it seems the same... in reality people were starting to just say > Install Wine, then you *need* to install winetools and run the base install > thing, without ever actually saying "HEY! Newbs! This wont work so you > should install zyx to make it work as a temporary solution until such a time > as it's fixed in the wine tree." OR something similar. > Wine-Doors is the exact same thing as WineTools from the perspective of the Wine developers. > I guess my point is two fold: > -The user needs to know about bug reporting. Definitely, and we're doing a good job at it so far. > -The user needs to know what it means for something to not work > 'out-of-the-box', and what exactly a 'dirty little hack' or the like is. > Users know when things don't work out-of-the-box, whether they know what the term means or not, and we wouldn't have to worry about a user knowing what a 'dirty little hack' is if projects like Wine-Doors didn't exist. -- James Hawkins -- Cheers, Bryan
Re: Road to 1.0
On Friday 23 March 2007 20:26, Alexandre Julliard wrote: > "Tom Wickline" <[EMAIL PROTECTED]> writes: > > I see Wine 1.0 as a set of features that AJ has decided upon, once the > > feature set is in the tree then a feature freeze will go onto effect.. > > Then one to six months of only bug fixes. Then wala 1.0 is born. > > That's still the plan, yes. I'm mostly waiting for the games support > to stabilize; the other main areas, office apps and installers, both > seem in good enough shape at this point. I'm also hoping we can make > some progress on the x11drv factorisation before the freeze, so that > we don't need to change the interface too much to add the quartz > driver later on, we'll see how that goes. And if we delay it a bit > more maybe we can slip in Safedisc support too... Just please don't freeze during Summer of Code. I had that while trying to get my 2005 work in, and that's really depressing. Cheers, Kai -- Kai Blin, WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. pgpQHJA2pDjPm.pgp Description: PGP signature
Re: Road to 1.0
"Tom Wickline" <[EMAIL PROTECTED]> writes: > I see Wine 1.0 as a set of features that AJ has decided upon, once the > feature set is in the tree then a feature freeze will go onto effect.. > Then one to six months of only bug fixes. Then wala 1.0 is born. > > At the last Conf if memory serves me correctly there was mention of a > feature freeze happening sometime early this year. And I would only > guess to say the release notes after the freeze would read "X" amount > of bugs were fixed in this release, as no new features would be > implemented. That's still the plan, yes. I'm mostly waiting for the games support to stabilize; the other main areas, office apps and installers, both seem in good enough shape at this point. I'm also hoping we can make some progress on the x11drv factorisation before the freeze, so that we don't need to change the interface too much to add the quartz driver later on, we'll see how that goes. And if we delay it a bit more maybe we can slip in Safedisc support too... -- Alexandre Julliard [EMAIL PROTECTED]
Re: Road to 1.0
On Thu, 2007-03-22 at 23:38 -0400, Tom Wickline wrote: > Hello all, > > Just thought I would through in my $.02 > > I see Wine 1.0 as a set of features that AJ has decided upon, once the > feature set is in the tree then a feature freeze will go onto effect.. > Then one to six months of only bug fixes. Then wala 1.0 is born. > > At the last Conf if memory serves me correctly there was mention of a > feature freeze happening sometime early this year. And I would only > guess to say the release notes after the freeze would read "X" amount > of bugs were fixed in this release, as no new features would be > implemented. > > So the question is not when will 1.0 be released but when will the > freeze go into effect? > If we do this right, we could time the release of Wine 1.0 to barely precede the next wave of Linux distributions (eg, Ubuntu Feisty + 1), putting them in a very good position to face Vista. Thanks, Scott Ritchie
Re: Road to 1.0
On Thu, 2007-03-22 at 16:25 +0100, Vit Hrachovy wrote: > However, usage scenarios for automated SW installer applications offer far > more. > > First, it somehow mirrors info from AppDB. It can display application > usability for > range of WINE versions and also make available application on older WINE > versions. > > For example Ubuntu Dapper Drake (6.06) will distribute and support Wine > 0.9.9 for four years from now. I'm going to be providing packages for new Wine releases in Dapper (and later Ubuntu long term support versions) for the next few years, so there's no real need for targeted installations at this point. Maybe, once Wine is a little more mature we can put a stabilized "1.0-like" release into distributions and then target that. At this point, however, it's not a real important goal compared with just fixing Wine, as most users keep current with Wine (such as from the Apt repository). Thanks, Scott Ritchie
Re: Winebot / Wine-Doors Was: Road to 1.0
I have a request of these third party tool developers Please add a link on your front page to the WineHQ PayPal account for Donations! Thank You! Tom Wickline
Winebot / Wine-Doors Was: Road to 1.0
On Thu, Mar 22, 2007 at 10:03:46PM -0600, James Hawkins wrote: > If developers working on projects such as Wine-Doors > contributed to Wine, then the bugs would be fixed even faster. I think that this is not necessarily (always) true, probably not even most of the time. Does a developer of e.g. Wine-Doors even has the skill to fix these bugs? It's at least not the same skill set. (I think one can say that some good amount of Wine bugs are harder to fix than coding something like Wine-Doors.) See another mail by me in this thread, sent somewhat earlier, for some provisions that if followed would make something like Wine-Doors IMHO useful to wine (not only for users but also for developers). However if those provisions are not met, it would probably only result in another winetools and I don't want that either. Do you think that with those provisions it would still not help wine? I think it's somewhat similar to: "If all the work on coding those debuggers is spend on writing proper code, we would get bug free much sooner." It's the "work on tools for project" vs "work on project" trade-off. Jan
Re: Winebot / Wine-Doors Was: Road to 1.0
On 3/22/07, Jan Zerebecki <[EMAIL PROTECTED]> wrote: I Cc-ed Karl Lattimer from Wine-Doors to also ask him if the provisions detailed here are also compatible with his views of Wine-Doors. Something like Winebot could possibly save me much time while testing and developing. I reinstalled certain applications or workarounds countless times, automating it thus would make working on Wine less tedious. So I really want something like Winebot to be compatible with developing on Wine and to be something we could safely recommend to users and developers. It could make it easier to check if a bug is valid: Imagine there may be a command like: WINEPREFIX=~/apps/wine-foo winebot install --clean foo The argument --clean makes sure that the wineprefix does not exist before the install starts (refuses to proceed otherwise). It then would print to stdout that the wineprefix does not exist, the wine version, the winedoors version and the URL and possible other identification of the Winebot recipe (and probably other things during the install). So if the user saves the output and attaches it one can instantly rule out many possible errors on the part of the user. On Thu, Mar 22, 2007 at 10:42:20AM -0700, Dan Kegel wrote: > * My goal in writing Winebot is to help Wine succeed > * I pledge to use only the bare minimum of native DLLs in any Winebot recipe > * I pledge to remove native DLLs from Winebot recipes as soon as Wine > fixes the bugs that keep Wine's DLLs from being sufficient for that app > * I will report bugs to the Wine project in the course of working on Winebot Having a bugreport for every hack that is used is very important. In my view these points would certainly fix most of the possible problems with something like Winebot. > * I will help Wine by writing not just Winebot recipes, but also > basic application regression test scripts This would be really nice and would give you much credibility with Wine developers, but it is IMHO not a must. I mean we don't say all patches must be accompanied by tests either. There are two other possible problems with something like Winebot: Hacks for one application can interfere with hacks for another application. Setting dll overrides or other hacks only per application might be a good idea, but is error prone (missing some part that need the hack and not properly restricting the hack). The best solution is to have one WINEPREFIX for each application. This can simply be done by needing the environment variable WINEPREFIX set (not defaulting to ~/.wine ) and warning if it is set to ~/.wine . http://winebot.sandbox.cz/tracker says under "Typical usage scenario": * User runs winebot first time. Winebot asks user for his name, his company name and proceeds to download and install the basic Windows compatibility programs into ~/.wine (or other WINE bottle directory) * After bottle initialization (installation of basic compatibility programs) user is then capable of using winebot to install the packages from winebot repository Installation of "basic compatibility programs" sounds like it would clash with "only use the bare minimum of native DLLs / hacks in any Winebot recipe". Winebot shouldn't install anything that the application does not need. Do you think these provisions are compatible with your idea of Winebot (same question for Karl Lattimer and Wine-Doors)? Please keep Winebot (or any non-Wine project) development discussion on the appropriate Winebot mailing list. -- James Hawkins
Re: Road to 1.0
On 3/22/07, Bryan Haskins <[EMAIL PROTECTED]> wrote: > > If you are making it extremely easy for users to run with native dlls > and hacky workarounds, then you are hurting Wine. Wine is still beta, That's true... and people technically should only be using wine for the pure sake of testing and helping fix usage. LEt's be honest, very few use it for that, they just want it to work, they use wine for the use the Devs want out of 1.0. Saying to someone that because it doesn't work by default, we're not going to let you use it, or in general make it hard for them defeats the goal of the *actual program*, No one here says they can't use Wine if their app doesn't work, and we're certainly not trying to make it harder for them if that is the case. The argument is irrelevant though, as it doesn't follow the original question, "Does my development of Wine-Doors hurt Wine." Joe XYZ wants to play Oblivion, He Finds it doesn't work! He looks around and sees that if he does a lot of various things it will work *okay*, Joe XYZ does them. Joe XYZ had no intention of ever submitting bugs at all, is this bad? Hell yes it is. We should educate at how important it is for a program like Wine to have nice detailed Bug Tracking, but at the same time, can you blame him for just wanting it to work, easily? As long as the user, at some point, realized, hey this doesn't work out of the box, the job is done to some degree. The optimal outcome of this scenario is that Joe XYZ reports his problems running Oblivion to the Wine development community using bugzilla. The Wine development community then fixes these bugs, leaving Joe XYZ very satisfied with Wine. The next possible outcome is that it takes a little while for the bugs to be fixed, though they'll be fixed at some point, but we do try our hardest. If developers working on projects such as Wine-Doors contributed to Wine, then the bugs would be fixed even faster. To summarize, If a user never was going to report things, that's bad, he should be educated, but at the same time, if he still wouldn't, shouldn't it be our job as the community to make it easy for him? Make it easy for him to report the bugs? Yea we should make it as easy as possible. This goes back to the WineTools thing... that was bad though, even though at face it seems the same... in reality people were starting to just say Install Wine, then you *need* to install winetools and run the base install thing, without ever actually saying "HEY! Newbs! This wont work so you should install zyx to make it work as a temporary solution until such a time as it's fixed in the wine tree." OR something similar. Wine-Doors is the exact same thing as WineTools from the perspective of the Wine developers. I guess my point is two fold: -The user needs to know about bug reporting. Definitely, and we're doing a good job at it so far. -The user needs to know what it means for something to not work 'out-of-the-box', and what exactly a 'dirty little hack' or the like is. Users know when things don't work out-of-the-box, whether they know what the term means or not, and we wouldn't have to worry about a user knowing what a 'dirty little hack' is if projects like Wine-Doors didn't exist. -- James Hawkins
Re: Road to 1.0
Hello all, Just thought I would through in my $.02 I see Wine 1.0 as a set of features that AJ has decided upon, once the feature set is in the tree then a feature freeze will go onto effect.. Then one to six months of only bug fixes. Then wala 1.0 is born. At the last Conf if memory serves me correctly there was mention of a feature freeze happening sometime early this year. And I would only guess to say the release notes after the freeze would read "X" amount of bugs were fixed in this release, as no new features would be implemented. So the question is not when will 1.0 be released but when will the freeze go into effect?
Winebot / Wine-Doors Was: Road to 1.0
I Cc-ed Karl Lattimer from Wine-Doors to also ask him if the provisions detailed here are also compatible with his views of Wine-Doors. Something like Winebot could possibly save me much time while testing and developing. I reinstalled certain applications or workarounds countless times, automating it thus would make working on Wine less tedious. So I really want something like Winebot to be compatible with developing on Wine and to be something we could safely recommend to users and developers. It could make it easier to check if a bug is valid: Imagine there may be a command like: WINEPREFIX=~/apps/wine-foo winebot install --clean foo The argument --clean makes sure that the wineprefix does not exist before the install starts (refuses to proceed otherwise). It then would print to stdout that the wineprefix does not exist, the wine version, the winedoors version and the URL and possible other identification of the Winebot recipe (and probably other things during the install). So if the user saves the output and attaches it one can instantly rule out many possible errors on the part of the user. On Thu, Mar 22, 2007 at 10:42:20AM -0700, Dan Kegel wrote: > * My goal in writing Winebot is to help Wine succeed > * I pledge to use only the bare minimum of native DLLs in any Winebot recipe > * I pledge to remove native DLLs from Winebot recipes as soon as Wine > fixes the bugs that keep Wine's DLLs from being sufficient for that app > * I will report bugs to the Wine project in the course of working on Winebot Having a bugreport for every hack that is used is very important. In my view these points would certainly fix most of the possible problems with something like Winebot. > * I will help Wine by writing not just Winebot recipes, but also > basic application regression test scripts This would be really nice and would give you much credibility with Wine developers, but it is IMHO not a must. I mean we don't say all patches must be accompanied by tests either. There are two other possible problems with something like Winebot: Hacks for one application can interfere with hacks for another application. Setting dll overrides or other hacks only per application might be a good idea, but is error prone (missing some part that need the hack and not properly restricting the hack). The best solution is to have one WINEPREFIX for each application. This can simply be done by needing the environment variable WINEPREFIX set (not defaulting to ~/.wine ) and warning if it is set to ~/.wine . http://winebot.sandbox.cz/tracker says under "Typical usage scenario": * User runs winebot first time. Winebot asks user for his name, his company name and proceeds to download and install the basic Windows compatibility programs into ~/.wine (or other WINE bottle directory) * After bottle initialization (installation of basic compatibility programs) user is then capable of using winebot to install the packages from winebot repository Installation of "basic compatibility programs" sounds like it would clash with "only use the bare minimum of native DLLs / hacks in any Winebot recipe". Winebot shouldn't install anything that the application does not need. Do you think these provisions are compatible with your idea of Winebot (same question for Karl Lattimer and Wine-Doors)? Jan PS: The link to wine-doors.org on the top of http://winebot.sandbox.cz/tracker is missing the "s".
Re: Road to 1.0
If you are making it extremely easy for users to run with native dlls and hacky workarounds, then you are hurting Wine. Wine is still beta, That's true... and people technically should only be using wine for the pure sake of testing and helping fix usage. LEt's be honest, very few use it for that, they just want it to work, they use wine for the use the Devs want out of 1.0. Saying to someone that because it doesn't work by default, we're not going to let you use it, or in general make it hard for them defeats the goal of the *actual program*, Joe XYZ wants to play Oblivion, He Finds it doesn't work! He looks around and sees that if he does a lot of various things it will work *okay*, Joe XYZ does them. Joe XYZ had no intention of ever submitting bugs at all, is this bad? Hell yes it is. We should educate at how important it is for a program like Wine to have nice detailed Bug Tracking, but at the same time, can you blame him for just wanting it to work, easily? As long as the user, at some point, realized, hey this doesn't work out of the box, the job is done to some degree. To summarize, If a user never was going to report things, that's bad, he should be educated, but at the same time, if he still wouldn't, shouldn't it be our job as the community to make it easy for him? This goes back to the WineTools thing... that was bad though, even though at face it seems the same... in reality people were starting to just say Install Wine, then you *need* to install winetools and run the base install thing, without ever actually saying "HEY! Newbs! This wont work so you should install zyx to make it work as a temporary solution until such a time as it's fixed in the wine tree." OR something similar. I guess my point is two fold: -The user needs to know about bug reporting. -The user needs to know what it means for something to not work 'out-of-the-box', and what exactly a 'dirty little hack' or the like is. end rant and we need as much testing and bug reporting as possible. You take away users that help the development process, and attach them to your project so that when they have a problem with app xyz, they file a report with your project, not Wine, and you add the necessary hack to make it work for them. In short, you leech off the hard work of all the Wine developers and give nothing back in return (quite the opposite in fact). If you have any reason to believe that you are helping Wine, I'd sure love to hear it. -- James Hawkins -- Cheers, Bryan
Re: Road to 1.0
On 3/22/07, Vit Hrachovy <[EMAIL PROTECTED]> wrote: For example Ubuntu Dapper Drake (6.06) will distribute and support Wine 0.9.9 for four years from now. I suspect they will be willing to update Drake to wine-1.0 when we release it, since it will be far, far superior to wine-0.9.9. Automated regression testing could be a big plus of these solutions. WINE would profit greatly from this. That's certainly true, but only for installers. We can probably handle scripting the installers ourselves. The real work will be in scripting tests of the full apps, which you're not contemplating doing. Third, having list of 'hacks' stored in 'unified' manner within repository simplifies access to 'fixups' for outstanding issues. At least they will be at one place (similar to AppDB now). Pragmatically, I understand where you're coming from. What's missing is for you to declare things like: * My goal in writing Winebot is to help Wine succeed * I pledge to use only the bare minimum of native DLLs in any Winebot recipe * I pledge to remove native DLLs from Winebot recipes as soon as Wine fixes the bugs that keep Wine's DLLs from being sufficient for that app * I will report bugs to the Wine project in the course of working on Winebot * I will help Wine by writing not just Winebot recipes, but also basic application regression test scripts That last one especially would endear you to the Wine community. Cheers, Dan
Re: Road to 1.0
On 3/22/07, Vit Hrachovy <[EMAIL PROTECTED]> wrote: On Tue, Mar 20, 2007 at 03:32:14PM -0700, Dan Kegel wrote: > >Given list of manual steps required to install Oblivion > >http://www.uesp.net/wiki/Oblivion:Linux > >this can be automated easily ... > > The problem that wine developers have with recipies > like the one you cite is that most of the steps in > the recipe are there to work around bugs in Wine. > We would prefer to fix the bugs. For instance, > the steps related to sound and winecfg should just > go away, hopefully this summer. Likewise with directx > and registry settings. > > That said, I'm certainly in favor of helping users, > as long as it's done 'right', for some hard to pin down > definition of 'right'. > - Dan Hi Dan, I understand the WINE developers' attitude for such temporary fixups as listed above in Oblivion in Linux Wiki. However, usage scenarios for automated SW installer applications offer far more. First, it somehow mirrors info from AppDB. It can display application usability for range of WINE versions and also make available application on older WINE versions. For example Ubuntu Dapper Drake (6.06) will distribute and support Wine 0.9.9 for four years from now. Second, using automated tools, regression tests can be fully automated, so building a repository of free game demos or applications is just a matter of time. Packages can be suited to fit specific WINE versions or made generic. Install scripts can fully automate / simulate 'normal' Windows installation process. Creating regression testing DB is going hand in hand with package installer creation, so costs are low to nothing. Automated regression testing could be a big plus of these solutions. WINE would profit greatly from this. Third, having list of 'hacks' stored in 'unified' manner within repository simplifies access to 'fixups' for outstanding issues. At least they will be at one place (similar to AppDB now). - I've been thinking heavily before I've started participating on Wine-Doors and coding on Winebot. I've made conclusion that I cannot hurt WINE, given the potential of these automation tools. If you are making it extremely easy for users to run with native dlls and hacky workarounds, then you are hurting Wine. Wine is still beta, and we need as much testing and bug reporting as possible. You take away users that help the development process, and attach them to your project so that when they have a problem with app xyz, they file a report with your project, not Wine, and you add the necessary hack to make it work for them. In short, you leech off the hard work of all the Wine developers and give nothing back in return (quite the opposite in fact). If you have any reason to believe that you are helping Wine, I'd sure love to hear it. -- James Hawkins
Re: Road to 1.0
On Thursday 22 March 2007 16:25, Vit Hrachovy wrote: > First, it somehow mirrors info from AppDB. It can display application > usability for range of WINE versions and also make available application on > older WINE versions. > > For example Ubuntu Dapper Drake (6.06) will distribute and support Wine > 0.9.9 for four years from now. I'm not sure if that's a valid point. Breaking your system by installing proprietary dlls and system hacks or breaking your system by installing a more current wine version doesn't look too different to me. (Especially I'd like to question this logic for software that still calls itself beta. ;) ) > > Second, using automated tools, regression tests can be fully automated, > so building a repository of free game demos or applications is just a > matter of time. Packages can be suited to fit specific WINE versions > or made generic. Install scripts can fully automate / simulate 'normal' > Windows installation process. I'm not entirely sure how making sure the package installs qualifies as a full regression test. > > Creating regression testing DB is going hand in hand with package > installer creation, so costs are low to nothing. In fact, they have to be well-maintained or they are worthless. Alessandro Pignotti is working on dplayx.dll currently. However, it's not 100% useful yet, so the current tests would all use native dplayx.dll. Once Alessandro fixes dplayx.dll, someone needs to disable the override, or Alessandro's code is never tested. Looking at appdb, only the most popular apps have some sort of frequent testing. > Automated regression testing could be a big plus of these solutions. > WINE would profit greatly from this. If the problem of e.g. dll overrides is correctly handled, maybe. If the same man hours went into writing regression tests, the same would apply, I guess. :) Of course it would take nothing but a working, maintained regression test suite to prove me wrong. Cheers, Kai -- Kai Blin, WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. pgpuTfR7tSXZW.pgp Description: PGP signature
Re: Road to 1.0
On Tue, Mar 20, 2007 at 03:32:14PM -0700, Dan Kegel wrote: > >Given list of manual steps required to install Oblivion > >http://www.uesp.net/wiki/Oblivion:Linux > >this can be automated easily ... > > The problem that wine developers have with recipies > like the one you cite is that most of the steps in > the recipe are there to work around bugs in Wine. > We would prefer to fix the bugs. For instance, > the steps related to sound and winecfg should just > go away, hopefully this summer. Likewise with directx > and registry settings. > > That said, I'm certainly in favor of helping users, > as long as it's done 'right', for some hard to pin down > definition of 'right'. > - Dan Hi Dan, I understand the WINE developers' attitude for such temporary fixups as listed above in Oblivion in Linux Wiki. However, usage scenarios for automated SW installer applications offer far more. First, it somehow mirrors info from AppDB. It can display application usability for range of WINE versions and also make available application on older WINE versions. For example Ubuntu Dapper Drake (6.06) will distribute and support Wine 0.9.9 for four years from now. Second, using automated tools, regression tests can be fully automated, so building a repository of free game demos or applications is just a matter of time. Packages can be suited to fit specific WINE versions or made generic. Install scripts can fully automate / simulate 'normal' Windows installation process. Creating regression testing DB is going hand in hand with package installer creation, so costs are low to nothing. Automated regression testing could be a big plus of these solutions. WINE would profit greatly from this. Third, having list of 'hacks' stored in 'unified' manner within repository simplifies access to 'fixups' for outstanding issues. At least they will be at one place (similar to AppDB now). - I've been thinking heavily before I've started participating on Wine-Doors and coding on Winebot. I've made conclusion that I cannot hurt WINE, given the potential of these automation tools. However, in future it may cause trouble for commercial WINE implementations, that are selling nice GUI and 'easy installation'. Regards Vit
Re: Road to 1.0
On 3/20/07, Kai Blin <[EMAIL PROTECTED]> wrote: http://code.google.com/soc/wine/about.html Like that? Yeah. That was me attempting something resembling humor. GSoC is exactly what I meant. --tim
Re: Road to 1.0
On Wednesday 21 March 2007 00:08, Tim Schmidt wrote: > On 3/20/07, Dan Kegel <[EMAIL PROTECTED]> wrote: > > The problem that wine developers have with recipies > > like the one you cite is that most of the steps in > > the recipe are there to work around bugs in Wine. > > > > ... > > > > That said, I'm certainly in favor of helping users, > > as long as it's done 'right', for some hard to pin down > > definition of 'right'. > > Pay students $4500 to interest themselves in the Wine codebase over > the summer and to make some well defined and useful contribution... http://code.google.com/soc/wine/about.html Like that? Kai -- Kai Blin, WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. pgpzus9rXPmMk.pgp Description: PGP signature
Re: Road to 1.0
On 3/20/07, Dan Kegel <[EMAIL PROTECTED]> wrote: The problem that wine developers have with recipies like the one you cite is that most of the steps in the recipe are there to work around bugs in Wine. ... That said, I'm certainly in favor of helping users, as long as it's done 'right', for some hard to pin down definition of 'right'. Pay students $4500 to interest themselves in the Wine codebase over the summer and to make some well defined and useful contribution... ... ... until all the bugs are fixed? Just a thought. :) --tim
Re: Road to 1.0
Vit wrote: WineBot (http://winebot.sandbox.cz) is a sort of lightweight implementation of some core thoughts, but with command line based interface and less dependencies. Both projects share some core ideas and data file formats. WineBot goals are much smaller in scope than Wine-Doors ones, going in smaller steps. The main goal is to replace obsolete and almost unmaintainable winetools project. You've got my attention. That sounds like it fixes almost all the problems I have with Wine-doors. Given list of manual steps required to install Oblivion http://www.uesp.net/wiki/Oblivion:Linux this can be automated easily ... The problem that wine developers have with recipies like the one you cite is that most of the steps in the recipe are there to work around bugs in Wine. We would prefer to fix the bugs. For instance, the steps related to sound and winecfg should just go away, hopefully this summer. Likewise with directx and registry settings. That said, I'm certainly in favor of helping users, as long as it's done 'right', for some hard to pin down definition of 'right'. - Dan
Re: Road to 1.0
Dan Kegel wrote: In fact complete Wine-Doors / Winebot projects can serve for this purpose too - as a repository of automated WINE tests. Yes, when I heard that Wine-Doors used autohotkey, I realized the same thing. (I gather winebot is part of wine-doors, http://www.wine-doors.org/trac/browser/sandbox/contrib/prototype/winebot.pl) I am quite skeptical of wine-doors, though, for various reasons. (For instance, the web site is both overdesigned and amateurish, the project was founded with way too much self-promotion, and the goals were both grandiose and poorly explained. Doesn't mean they'll fail, but it does mean I find it painful to interact with them.) - Dan WineBot (http://winebot.sandbox.cz) is a sort of lightweight implementation of some core thoughts, but with command line based interface and less dependencies. Both projects share some core ideas and data file formats. WineBot goals are much smaller in scope than Wine-Doors ones, going in smaller steps. The main goal is to replace obsolete and almost unmaintainable winetools project. Main idea is to make repositories of supported application packages, both installed from CD, HDD or downloaded from net. For example to install Oblivion by placing CD into tray and entering winebot install tes_oblivion-1.1.511uk Or in case of Wine-Doors - insert CD, run wine-doors, select Games repository, click to add Oblivion to install queue. Given list of manual steps required to install Oblivion http://www.uesp.net/wiki/Oblivion:Linux this can be automated easily and comfort would be similar to using Loki installers. Regards Vit
Re: Road to 1.0
Vit wrote: Dan Kegel wrote: FWIW, a couple of us have been puttering away on a scheme to make writing application regression testers easier. AutoHotkey (http://www.autohotkey.com) seems to do very well. I'm using it for automated installation of lots of Windows programs into WINE bottles as an initialization Yes, that's what we're using. We drive it with a 'small' python script that verifyies a list of registry keys and files were installed, downloads the app to install, etc. (something similar to winetricks). Nah, winetricks is by design never going to use anything like autohotkey, it's much smaller and crappier than that. It's meant to be a little tool that does one thing (install redistributable runtime libraries) and does it with a minimum of code and glitz. Writing a series of batch scripts for automated testing is very easy. In fact complete Wine-Doors / Winebot projects can serve for this purpose too - as a repository of automated WINE tests. Yes, when I heard that Wine-Doors used autohotkey, I realized the same thing. (I gather winebot is part of wine-doors, http://www.wine-doors.org/trac/browser/sandbox/contrib/prototype/winebot.pl) I am quite skeptical of wine-doors, though, for various reasons. (For instance, the web site is both overdesigned and amateurish, the project was founded with way too much self-promotion, and the goals were both grandiose and poorly explained. Doesn't mean they'll fail, but it does mean I find it painful to interact with them.) - Dan
Re: Road to 1.0
Dan Kegel wrote: Rob wrote: I think the only viable way to drive for 1.0 is feature or applications targets, with applications compatibility driving test cases and bug fixing. Yes indeedy. And the only reason I haven't jumped up and posted a proposed list of applications to support for 1.0 is that real app testing is gobs of work, more than we have resources for. The tests at http://cxtest.org could be an important part of the equation. FWIW, a couple of us have been puttering away on a scheme to make writing application regression testers easier. No promises, though. - Dan AutoHotkey (http://www.autohotkey.com) seems to do very well. I'm using it for automated installation of lots of Windows programs into WINE bottles as an initialization (something similar to winetricks). It's very well documented, too. Writing a series of batch scripts for automated testing is very easy. In fact complete Wine-Doors / Winebot projects can serve for this purpose too - as a repository of automated WINE tests. Regards Vit
re: Road to 1.0
Rob wrote: I think the only viable way to drive for 1.0 is feature or applications targets, with applications compatibility driving test cases and bug fixing. Yes indeedy. And the only reason I haven't jumped up and posted a proposed list of applications to support for 1.0 is that real app testing is gobs of work, more than we have resources for. The tests at http://cxtest.org could be an important part of the equation. FWIW, a couple of us have been puttering away on a scheme to make writing application regression testers easier. No promises, though. - Dan
Re: Road to 1.0
I kind of agree with him too, Since we can't really just test every single API, obviously, the best thing to do is setup a 1.0 test quite of sorts, where you have either a ton of little applications trying things whether theyre known to work or not, or one big wine made ap which tests as much as we can, which gives nice detailed output or something, and reaching 100% compatibility with this "Toolbox" of sorts would let them drop the 1.0 down. Or we could say in a few years have some kind of huge community event, where everyone goes through alll the possible appdb aps they can and give updated test results, when say 75%+ hit platinum you could call it a mile stone. On 3/20/07, Robert Shearman <[EMAIL PROTECTED]> wrote: Dave Bialac wrote: > My personal thought is that Wine should head in the direction of 100% > compatibility with a particular version of Windows. Anything that ran > on that version should run on Wine 1.0 with no problems. Any thoughts? That just isn't going to happen any time soon. If we were 100% compatible with one version of Windows then we would be 99% compatible with other versions too. That would be really nice, but due to the way we implement Wine using black-box testing there are always going to be implementation differences and there are known bugs in many areas that we simply don't have the developer resources to fix at the moment. I think the only viable way to drive for 1.0 is feature or applications targets, with applications compatibility driving test cases and bug fixing. -- Rob Shearman -- Cheers, Bryan
Re: Road to 1.0
Dave Bialac wrote: My personal thought is that Wine should head in the direction of 100% compatibility with a particular version of Windows. Anything that ran on that version should run on Wine 1.0 with no problems. Any thoughts? That just isn't going to happen any time soon. If we were 100% compatible with one version of Windows then we would be 99% compatible with other versions too. That would be really nice, but due to the way we implement Wine using black-box testing there are always going to be implementation differences and there are known bugs in many areas that we simply don't have the developer resources to fix at the moment. I think the only viable way to drive for 1.0 is feature or applications targets, with applications compatibility driving test cases and bug fixing. -- Rob Shearman
Road to 1.0
Hi All I've been following the list for about a year now, just reading and learning. Through this process, I've come to wonder about the following question -- what should be the goal for Wine 1.0? I know a lot of development is focused around getting one particular application or another to work, especially from the folks over at Code Weavers, but with version numbers approaching 1.0, should there not be a set goal of functionality? My personal thought is that Wine should head in the direction of 100% compatibility with a particular version of Windows. Anything that ran on that version should run on Wine 1.0 with no problems. Any thoughts? Dave
