Re: SoC 2009 / Application Test Suite Update
Austin English wrote: Howdy all, I've been working on the test suite. I've got a few basic tests set up with notepad, and I'm currently working on setting up the framework, using AutoHotKey to both run all the tests and parse the logs for failures/passing todo's. You may have already had this idea, but today I was just thinking of the concept of running performance tests alongside Wine's conformance tests. Your test suite would be a great place for that - just integrate scripts for the various benchmarking tools. Bonus points if you can put the output from the benchmark programs themselves into some sort of machine parseable format. Then we could have a rough chart of performance data on various things as development continues; in particular we'd catch bugs that still behave correctly but are drastically inefficient. Thanks, Scott Ritchie
WINE Intel
Dear WINE Developers, Good morning. A great journey to WINE's Direct3D support since the beginning of its life time. Now it is so mature that I can play big games like FIFA 2006-2009, Need For Speed ProStreet, Need For Speed Undercover, Hitman Blood Money and so many easily. It already has Shader Model 1, Shader Model 2, Shader Model 3 support. What is I am going to say is that all of the bits of 3D it has are only and fully supported on nVidia based graphics card due to their superior Linux driver. But nVidia is not alone in the graphics card building field. There are other manufacturer around them. Majority of the C.P.U comes up with the INTEL integrated graphics card. We all very well know that their Linux driver lack most of the modern 3D bits. But most of the user do not know about that. They just get frustrated with WINE. Some DirectX 7 games runs very well in nVidia graphics card but not in INTEL. Same thing is for some DirectX8, DirectX8.1. I do not know but I suspect that WINE's various Direct3D code utilizes OpenGL nVidia Extension or higher level OpenGL ARB Extension rather that lower one. That's why while INTEL OpenGL driver does support DirectX7, DirectX8 level 3D wine does not able to run many games on INTEL Linux graphics driver. While those many games run on nVidia Linux driver. I hope WINE will someday have better INTEL OpenGL support. Your sincerely, MD. IMAM HOSSAIN
Re: WINE Intel
2009/5/17 MD.IMAM HOSSAIN imamdxl8...@gmail.com: Majority of the C.P.U comes up with the INTEL integrated graphics card. No CPU comes with integrated GPU (yet). Most (all?) Intel-based motherboards (including those for laptops) that have integrated graphics use Intel-brand graphics. This does not constitute most motherboards, as there are no Intel-brand GPUs on AMD CPU-compatible motherboards, and there are even Intel CPU-compatible motherboards that have nVidia graphics chips. We all very well know that their Linux driver lack most of the modern 3D bits. But most of the user do not know about that. They just get frustrated with WINE. Also make sure the the hardware supports the missing features. Intel cards are designed to be integrated into motherboards, not to compete with high-end nVidia or AMD/ATI discrete cards. Some DirectX 7 games runs very well in nVidia graphics card but not in INTEL. Same thing is for some DirectX8, DirectX8.1. I do not know but I suspect that WINE's various Direct3D code utilizes OpenGL nVidia Extension or higher level OpenGL ARB Extension rather that lower one. You can (and should have) research this yourself. Wine is 100% opensource. That's why while INTEL OpenGL driver does support DirectX7, DirectX8 level 3D wine does not able to run many games on INTEL Linux graphics driver. While those many games run on nVidia Linux driver. Note that no Linux video driver supports any form of DirectX. Wine translates DirectX calls to OpenGL etc. calls. I hope WINE will someday have better INTEL OpenGL support. Most likely, improved drivers would fix this, however reporting bugs regarding Intel graphics and proposing patches to Wine (assuming they are well-formed and proper, and don't break support with other cards) are more than welcome.
Re: WINE Intel
I do not know but I suspect that WINE's various Direct3D code utilizes OpenGL nVidia Extension or higher level OpenGL ARB Extension rather that lower one. That's why while INTEL OpenGL driver does support DirectX7, DirectX8 level 3D wine does not able to run many games on INTEL Linux graphics driver. While those many games run on nVidia Linux driver. I hope WINE will someday have better INTEL OpenGL support. Wine is doing nothing wrong we use generic OpenGL extensions all through Wine. The issue is that the intel drivers don't offer all opengl extensions we need for decent d3d9 support, if the gl support isn't there we can't support it. Second the quality of the intel drivers still isn't very good, sure recent versions support GLSL, FBOs and other things but the drivers are first of all buggy and second very slow for those purposes. Further ATI works reasonably well with Wine as well these days (it used to be crap). Intel needs to fix their drivers. Roderick
Re: News on Wine 1.1.21/MacOSX/XQuartz 2.3.3
On Sat, May 16, 2009 at 11:23 PM, James McKenzie jjmckenzi...@earthlink.net wrote: BTW, the version of Wine for Mac that I used for testing was built using Mike Kronenberg's Build Environment 1.1.5. I tested this last night myself and am running winetest now. I still get a few d3d texture failures but that could be because my mini's a POS with the Intel GMA card. I'm interested in seeing other results so if you get a chance could you (or anyone else lurking with OS X) do a winetest run? Thanks -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
DIB Engine - Mostly fixed against test suite
Remaining bugs are related to : 1) Some color on monochrome bitmaps here I guess nobody knows how to do it right. I fixed some todo wine (most) but have 2 failures which wine does right. Seldom used anyways, and happens only on weird palettes. I guess not ever Microsoft knows what they did on this respect :-) 2) an AlphaBlend() call which should fail and doesn't. Here I really don't know why it should fail. Uninfluent, anyways. 3) GetDIBits on a source DIB with BPP = 8 fails to retrieve the original DIB palette, and synthesizes a new one instead. For the moment I found no simple way to grab the palette from inside GetDIBits without maintaining a linked list of HBITMAP -- internal bitmaps. Not worth the effort for the moment anyways. If somebody notices weird colors due to it, I'll try to fix. There are still some missing/buggy features rarely used that aren't spotted by testsuite; by now I've no time to fix them, anyways no one felt into them up to now :-) Austin, could you please retest it against test suite ? (code on Bug421 page) Ciao Max
SourceForge 2009 Community Choice Award
Last Year we got a funny award, lets nominate Wine for some serios things at http://sourceforge.net/community/cca09 ---BeginMessage--- Thank you for nominating a project for the 2009 SourceForge Community Choice Awards! You nominated: Tiny Core Linux for Best New Project To confirm your nomination(s), please visit this link: https://sourceforge.net/community/cca09/confirm/?hash=7069810012b50eee4271f23e1803fff0 Best wishes, The SourceForge.net Staff ---End Message---
Re: WINE Intel
Am Sonntag, 17. Mai 2009 13:16:01 schrieb Roderick Colenbrander: Intel needs to fix their drivers. Note that the intel drivers are open source, so you(The thread starter) can speed up this process by testing games, isolating the problems and filing bug reports in the Mesa or DRI bugzilla. I am pretty sure the developers could use extra manpower too.
Re: [shell32] Improve the Dutch 'about' message box
Yes, handling the translation of Wine's resource files would be really nice. It would let us leverage a lot of the po tools, especially the website based ones. This would make it much easier for users to contribute to the translations (right now it's pretty intimidating). I'm not sure how to handle the widget layout though. I also think I would be better to use po files (without them, our translations get out-of-sync - e.g. in start a new /Unix switch was intruduced, but only 7 out of 16 languages has it in the help message. For the users of the other 9 languages, we are providing an incorrect help message. This is adding a new line to an existing message, so wrc --verify-translation won't notice it). I was thinking about the widget layout that may need to be different in a translation and I think this can be solved by adding a possibility to add some transformations of controls relative to the English ones. Something like: msgid transform.dialog.133 msgstr control 12 resize by (10, 10) control 13 move by (10, 10) Making the transformations relative should make updating such resources not very common (and in most cases there will be even no need for this). There may still be cases when it looks ugly if e.g. one adds a new button to the English dialog while the localized ones are enlarged and takes a place where the new button is added, but we could be solved by adding to msgid e.g. a hash of the English resource with localizable stirngs removed, so that the translation will be fuzzy after a merge. I could try to look into po2rc and rc2po if they work and can be augmented with such a functionality, but I'm not sure if I will have time soon. Mikołaj
Re: News on Wine 1.1.21/MacOSX/XQuartz 2.3.3
On Sun, May 17, 2009 at 6:49 AM, Steven Edwards sedwa...@bordeauxgroup.com wrote: On Sat, May 16, 2009 at 11:23 PM, James McKenzie jjmckenzi...@earthlink.net wrote: BTW, the version of Wine for Mac that I used for testing was built using Mike Kronenberg's Build Environment 1.1.5. I tested this last night myself and am running winetest now. I still get a few d3d texture failures but that could be because my mini's a POS with the Intel GMA card. I'm interested in seeing other results so if you get a chance could you (or anyone else lurking with OS X) do a winetest run? Ideally, against a more recent wine version. Shameless plug: I've got a script to do it, but no one that I know of is testing it on OS X. If someone could test it, I'll add any needed fixes: http://winezeug.googlecode.com/svn/trunk/build_script/daily.sh -- -Austin
Re: SoC 2009 / Application Test Suite Update
On Sun, May 17, 2009 at 3:28 AM, Scott Ritchie sc...@open-vote.org wrote: Austin English wrote: Howdy all, I've been working on the test suite. I've got a few basic tests set up with notepad, and I'm currently working on setting up the framework, using AutoHotKey to both run all the tests and parse the logs for failures/passing todo's. You may have already had this idea, but today I was just thinking of the concept of running performance tests alongside Wine's conformance tests. Your test suite would be a great place for that - just integrate scripts for the various benchmarking tools. Bonus points if you can put the output from the benchmark programs themselves into some sort of machine parseable format. Then we could have a rough chart of performance data on various things as development continues; in particular we'd catch bugs that still behave correctly but are drastically inefficient. Possibly, I may look into doing that. My current plan is to gather all the low hanging fruit. Small, simple applications give us a large range of stuff to test, without adding much difficulty/complexity. Once all that is done, more complex stuff can be added. -- -Austin
Re: News on Wine 1.1.21/MacOSX/XQuartz 2.3.3
On May 17, 2009, at 3:45 PM, Austin English wrote: Ideally, against a more recent wine version. Shameless plug: I've got a script to do it, but no one that I know of is testing it on OS X. If someone could test it, I'll add any needed fixes: http://winezeug.googlecode.com/svn/trunk/build_script/daily.sh I have (yet another) build script, but OS X requires a number of deps to be compiled and installed as Apple doesn't ship some libraries, headers, or ships incomplete packages here and there. This is all pretty bare bones stuff. I can vouch for functionality with Mac OS X 10.5.7 + XQuartz 2.3.3.1 + Wine 1.1.21 (from source). If and when I can find some time IRL, I can get the entire Wine compile and install with deps scripted up. This of course depends on free time, which is always somewhat lacking. Your script looks good, Austin - lots of functionality there! ryan woodsmall rwoodsm...@mac.com Be well, do good work, and keep in touch. - Garrison Keillor
Re: DIB Engine - Mostly fixed against test suite
Massimo Del Fedele wrote: There are still some missing/buggy features rarely used that aren't spotted by testsuite; by now I've no time to fix them, anyways no one felt into them up to now :-) Hey Max, It sounds like you're in a better position than most to write a conformance test for these missing/buggy features, since you're aware of them. That might help everyone, and also make your DIB engine more attractive since it'll be passing even more tests that current Wine may not be. Keep up the good work :) Thanks, Scott Ritchie
[Article] WINE and the importance of application compatibility
WINE and the importance of application compatibility http://community.zdnet.co.uk/blog/0,100567,10012751o-2000630136b,00.htm Need a Holiday? Win a $10,000 Holiday of your choice. Enter now.http://us.lrd.yahoo.com/_ylc=X3oDMTJxN2x2ZmNpBF9zAzIwMjM2MTY2MTMEdG1fZG1lY2gDVGV4dCBMaW5rBHRtX2xuawNVMTEwMzk3NwR0bV9uZXQDWWFob28hBHRtX3BvcwN0YWdsaW5lBHRtX3BwdHkDYXVueg--/SIG=14600t3ni/**http%3A//au.rd.yahoo.com/mail/tagline/creativeholidays/*http%3A//au.docs.yahoo.com/homepageset/%3Fp1=other%26p2=au%26p3=mailtagline
Re: [Article] WINE and the importance of application compatibility
nn wrote: WINE and the importance of application compatibility http://community.zdnet.co.uk/blog/0,100567,10012751o-2000630136b,00.htm It's a good article, though it's sad to see a mention of WineX as a serious alternative to Wine. WineX was obsolete years ago (and the consensus about its successor Cedega on the various web forums seems to be that it's often substantially behind Crossover Games). Codeweavers, you need to do a better job letting people know Crossover Games exists. Thanks, Scott Ritchie
Re: News on Wine 1.1.21/MacOSX/XQuartz 2.3.3
Austin English wrote: On Sun, May 17, 2009 at 6:49 AM, Steven Edwards sedwa...@bordeauxgroup.com wrote: On Sat, May 16, 2009 at 11:23 PM, James McKenzie jjmckenzi...@earthlink.net wrote: BTW, the version of Wine for Mac that I used for testing was built using Mike Kronenberg's Build Environment 1.1.5. I tested this last night myself and am running winetest now. I still get a few d3d texture failures but that could be because my mini's a POS with the Intel GMA card. I'm interested in seeing other results so if you get a chance could you (or anyone else lurking with OS X) do a winetest run? Ideally, against a more recent wine version. Shameless plug: I've got a script to do it, but no one that I know of is testing it on OS X. If someone could test it, I'll add any needed fixes: http://winezeug.googlecode.com/svn/trunk/build_script/daily.sh Austin: Contact Mike Kronenberg or Zach Drayer and see what they currently have. I know that Mike's builds add all of the necessary libraries to the Application Object. That keeps the system clean and allows for 'Drag and Drop' installation/removal of Wine for MacOSX. Your script seems to be clean as well, but has no MacOSX functionality added to it. Would be nice if it were there. James McKenzie
Re: [Article] WINE and the importance of application compatibility
Scott Ritchie wrote: nn wrote: WINE and the importance of application compatibility http://community.zdnet.co.uk/blog/0,100567,10012751o-2000630136b,00.htm It's a good article, though it's sad to see a mention of WineX as a serious alternative to Wine. WineX was obsolete years ago (and the consensus about its successor Cedega on the various web forums seems to be that it's often substantially behind Crossover Games). The article stated that most of it was a few years old. Codeweavers, you need to do a better job letting people know Crossover Games exists. WE need to get to the point where most of the common business type applications will run in Wine without a bunch of twiddling and fixes. The average Joe user will not put up with this. I've been on this mantra for a long time. Build a better mousetrap built on an OS that is more robust and market it correctly and you will have the world at your fingertips. Witness the comparision between Windows and OS/2. OS/2 was technically superior but had problems running most of the current software. It 'died' and Windows lived on. The same could be said about Linux/Wine at its current state. I need Wine to run a few Windows applications, one of which will not be made for either Linux or Mac. Thus, I have to have Windows compatibility or Windows itself. I don't feel like 'polluting' my system, so I need API compatibilty. Wine delivers this for me. The problem is that I need another Windows program to run. I'm going to work on it and report bugs as they occur. I may also start running Winetest to see what works and what does not. Hopefully, with the recent release of XQuartz 2.3.3, most of the problems have gone away. James McKenzie Thanks, Scott Ritchie
re: [Article] WINE and the importance of application compatibility
James McKensie wrote: WE need to get to the point where most of the common business type applications will run in Wine without a bunch of twiddling and fixes. Well, yes. That was one of my goals during my big Wine push ( http://www.winehq.org/pipermail/wine-devel/2008-February/062550.html ), and I think we made a lot of progress. Still lots to do, as you know. Sure would be nice if we could convince the DoD they needed a second source for Windows :-) - Dan
Re: [Article] WINE and the importance of application compatibility
On Sun, May 17, 2009 at 8:09 PM, Dan Kegel d...@kegel.com wrote: Sure would be nice if we could convince the DoD they needed a second source for Windows :-) Maybe a big customer like the DoD would help but I am starting to doubt it. The situation I face with my day job, is that we can't even get support for certain applications in VMware. As soon as we say we have a virtualized cluster they balk. And we are talking about situations where we are spending millions of dollars on our software and are going to be supporting it in house. With that sort of reaction, it leads me to think we are never going to make major inroads except for the end users at home or the people buying Linux netbooks. Thanks -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: DIB Engine - Mostly fixed against test suite
On Sun, May 17, 2009 at 10:35 AM, Massimo Del Fedele m...@veneto.com wrote: Austin, could you please retest it against test suite ? I've ran it, but it doesn't appear to be showing up on test.winehq.org. I'll investigate why when I get a bit more time. P.S., there's now a crash in user32/cursoricon. -- -Austin
Re: News on Wine 1.1.21/MacOSX/XQuartz 2.3.3
On Sun, May 17, 2009 at 6:43 PM, James McKenzie jjmckenzi...@earthlink.net wrote: Austin English wrote: On Sun, May 17, 2009 at 6:49 AM, Steven Edwards sedwa...@bordeauxgroup.com wrote: On Sat, May 16, 2009 at 11:23 PM, James McKenzie jjmckenzi...@earthlink.net wrote: BTW, the version of Wine for Mac that I used for testing was built using Mike Kronenberg's Build Environment 1.1.5. I tested this last night myself and am running winetest now. I still get a few d3d texture failures but that could be because my mini's a POS with the Intel GMA card. I'm interested in seeing other results so if you get a chance could you (or anyone else lurking with OS X) do a winetest run? Ideally, against a more recent wine version. Shameless plug: I've got a script to do it, but no one that I know of is testing it on OS X. If someone could test it, I'll add any needed fixes: http://winezeug.googlecode.com/svn/trunk/build_script/daily.sh Austin: Contact Mike Kronenberg or Zach Drayer and see what they currently have. I know that Mike's builds add all of the necessary libraries to the Application Object. That keeps the system clean and allows for 'Drag and Drop' installation/removal of Wine for MacOSX. Your script seems to be clean as well, but has no MacOSX functionality added to it. Would be nice if it were there. It's not really made to install all the needed dependencies (there is install-wine-deps.sh for that). The Mac platform is so different in many ways that it's a bit hard to do. Does the user want to use fink/macports? Or install each from source? Do we install to /usr/local/bin? Or to a custom directory elsewhere? It's a big mess... There is an OS X code path in place, but it is untested. -- -Austin
Re: [Article] WINE and the importance of application compatibility
Steven Edwards wrote: On Sun, May 17, 2009 at 8:09 PM, Dan Kegel d...@kegel.com wrote: Sure would be nice if we could convince the DoD they needed a second source for Windows :-) Maybe a big customer like the DoD would help but I am starting to doubt it. The situation I face with my day job, is that we can't even get support for certain applications in VMware. As soon as we say we have a virtualized cluster they balk. And we are talking about situations where we are spending millions of dollars on our software and are going to be supporting it in house. With that sort of reaction, it leads me to think we are never going to make major inroads except for the end users at home or the people buying Linux netbooks. Stephen: Many companies don't trust Open Source. They just don't have the assets to do a proper code sweep and to see that we do not want to swipe their secrets, but give them something better. Of course, we all know the outcome of the Windows versus OS/2 wars: Windows won and the best product went home (it is still available by the way.) James McKenzie
Re: [Article] WINE and the importance of application compatibility
On Sun, May 17, 2009 at 9:53 PM, James McKenzie jjmckenzi...@earthlink.net wrote: Many companies don't trust Open Source. They just don't have the assets to do a proper code sweep and to see that we do not want to swipe their secrets, but give them something better. Of course, we all know the outcome of the Windows versus OS/2 wars: Windows won and the best product went home (it is still available by the way.) Its not even Open Source though, I mean that's another strike but the VMware example shows, any sort of legacy solution, virtualized or otherwise is a major show stopper. Hell, I have enough trouble with vendors and JVM versions. Try getting support for an application running under BEAs JVM verses Sun and the vendor balks. Wine problem is a chicken and egg problem. Most won't support Wine and so most won't run Wine. The vendors won't support it because most won't run Wine. And the cycle of life repeats. That compounded with the fact that as Linux gets better, there is no need for Wine as the vendor will just target apps directly. Facing both of these situations I've started to believe Wine won't ever become much more than it is. It's going to be hit or miss even if it installs, its always going to be playing catch up. That's not a bad thing, a niche market is fine as everything has its place. The wine project just needs to be a bit more flexible as far as integration goes. I think for a long time we've tried to be too generic, distro agnostic, etc. For Wine to get more adoption we need to do a better on that end. Scott and others have been working a lot to solve this problem with the associations, XDG stuff, etc. We need a lot more work on the OS X side and that will help us tremendously due to the size of the market. OK I'm done ranting. Thanks -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
