AppDB Error, must enter to the what didn't work section?
The following errors were found* Please enter what did not work. I understand the mechanics of why it says that, but realistically, should it for this field, be required to have data? For example, with me running WoW, it's flawless for me. Absolutely no problems, and I'm rating it platinum. If we're rating it platinum should this at least not be required then? Conversely, it should be required as a field, when it is rated anything but platinum, by definition. Just something I noticed.
Re: Pulse Audio -- Wine should have instructions on this web site
I would totally agree with that, James. If ALSA worked perfectly, it's really no problem getting it working OOB with Pulse, no specific sound system needed. On Wed, Apr 2, 2008 at 2:59 PM, James Hawkins [EMAIL PROTECTED] wrote: On Wed, Apr 2, 2008 at 1:52 PM, Michael Stefaniuc [EMAIL PROTECTED] wrote: James Hawkins wrote: On Wed, Apr 2, 2008 at 1:05 PM, Austin English [EMAIL PROTECTED] wrote: On Wed, Apr 2, 2008 at 10:08 AM, Bryan Haskins [EMAIL PROTECTED] wrote: I'm more interested in a direct pulseaudio gateway for Wine... since by application sound control is the biggest thing here for most people wine is treated as one big audio blob. Pulse sees it as one thing. In effect, wine handles it's own audio (by talking with ALSA or OSS) then passes that through to the outside sound server... which in most cases would simply be ALSA or OSS itself, but in this case it gets passed to ALSA/OSS and through this talks to pulse. I call that pretty messy when we could just directly talk to pulse audio (easily, too) and have by applications control. Pulse is going to be in pretty much every distro soon. For a 1.0 release, no one wants to go out of their way to accomodate the shortcomings of our audio control. Even directly sending the blobof output to pulse directly at first would simplify things. I know this means yet asnother audio output method to maintain, and for various reasons many are against it. But this is similar to us needing to improve ALSA support rather recently. Pulseaudio does directly support ALSA, but it's a bit demanding on how it need to work to be perfect. ALSA, Pulseaudio, and OSS are probably the big three we need support for. Pulse is a drop in replacement for things like Network Sound, and way easier to configure and use. Sorry for expanding the topic so much. This has been brought up before, and it's quite a bit of work. You can't just simply forward everything to pulse call it a day, you'd need to implement a full structure/drivers/etc., which would require quite a bit of time/work and is likely outside of the scope of 1.0. And I believe Julliard rejected the idea of adding a pulseaudio driver. Nope! He isn't against a pulseaudio driver. He is against yet another broken and half implemented driver for the desktop sound system that happens to be en vogue at the moment. I think he would love to see a clean, full implemented pulseaudio driver; presented in a nice easy review-able patch series which cleans up the wineaudio driver mess en passant. No, the right answer is to make the Alsa driver work right. We need to stop rushing out to write a new driver every time there's a problem with an existing one, all it leads to is more broken drivers. -Julliard http://winehq.org/pipermail/wine-devel/2008-March/063755.html -- James Hawkins
Re: Pulse Audio -- Wine should have instructions on this web site
Sorry for the double post. But further on that point, at the sound system neutral level, naming eahc app individually as a sound item would rock. In such a way that each app perhaps talks to ALSA directly, which results in self identification, and further Pulse via ALSA recognizing things individually. For me, the only way to get it working properly with pulse is padsp, meaning using oss and prefixing all wine commands with padsp. On Wed, Apr 2, 2008 at 5:20 PM, Bryan Haskins [EMAIL PROTECTED] wrote: I would totally agree with that, James. If ALSA worked perfectly, it's really no problem getting it working OOB with Pulse, no specific sound system needed. On Wed, Apr 2, 2008 at 2:59 PM, James Hawkins [EMAIL PROTECTED] wrote: On Wed, Apr 2, 2008 at 1:52 PM, Michael Stefaniuc [EMAIL PROTECTED] wrote: James Hawkins wrote: On Wed, Apr 2, 2008 at 1:05 PM, Austin English [EMAIL PROTECTED] wrote: On Wed, Apr 2, 2008 at 10:08 AM, Bryan Haskins [EMAIL PROTECTED] wrote: I'm more interested in a direct pulseaudio gateway for Wine... since by application sound control is the biggest thing here for most people wine is treated as one big audio blob. Pulse sees it as one thing. In effect, wine handles it's own audio (by talking with ALSA or OSS) then passes that through to the outside sound server... which in most cases would simply be ALSA or OSS itself, but in this case it gets passed to ALSA/OSS and through this talks to pulse. I call that pretty messy when we could just directly talk to pulse audio (easily, too) and have by applications control. Pulse is going to be in pretty much every distro soon. For a 1.0 release, no one wants to go out of their way to accomodate the shortcomings of our audio control. Even directly sending the blobof output to pulse directly at first would simplify things. I know this means yet asnother audio output method to maintain, and for various reasons many are against it. But this is similar to us needing to improve ALSA support rather recently. Pulseaudio does directly support ALSA, but it's a bit demanding on how it need to work to be perfect. ALSA, Pulseaudio, and OSS are probably the big three we need support for. Pulse is a drop in replacement for things like Network Sound, and way easier to configure and use. Sorry for expanding the topic so much. This has been brought up before, and it's quite a bit of work. You can't just simply forward everything to pulse call it a day, you'd need to implement a full structure/drivers/etc., which would require quite a bit of time/work and is likely outside of the scope of 1.0. And I believe Julliard rejected the idea of adding a pulseaudio driver. Nope! He isn't against a pulseaudio driver. He is against yet another broken and half implemented driver for the desktop sound system that happens to be en vogue at the moment. I think he would love to see a clean, full implemented pulseaudio driver; presented in a nice easy review-able patch series which cleans up the wineaudio driver mess en passant. No, the right answer is to make the Alsa driver work right. We need to stop rushing out to write a new driver every time there's a problem with an existing one, all it leads to is more broken drivers. -Julliard http://winehq.org/pipermail/wine-devel/2008-March/063755.html -- James Hawkins
Re: Pulse Audio -- Wine should have instructions on this web site
I'm more interested in a direct pulseaudio gateway for Wine... since by application sound control is the biggest thing here for most people wine is treated as one big audio blob. Pulse sees it as one thing. In effect, wine handles it's own audio (by talking with ALSA or OSS) then passes that through to the outside sound server... which in most cases would simply be ALSA or OSS itself, but in this case it gets passed to ALSA/OSS and through this talks to pulse. I call that pretty messy when we could just directly talk to pulse audio (easily, too) and have by applications control. Pulse is going to be in pretty much every distro soon. For a 1.0 release, no one wants to go out of their way to accomodate the shortcomings of our audio control. Even directly sending the blobof output to pulse directly at first would simplify things. I know this means yet asnother audio output method to maintain, and for various reasons many are against it. But this is similar to us needing to improve ALSA support rather recently. Pulseaudio does directly support ALSA, but it's a bit demanding on how it need to work to be perfect. ALSA, Pulseaudio, and OSS are probably the big three we need support for. Pulse is a drop in replacement for things like Network Sound, and way easier to configure and use. Sorry for expanding the topic so much. On 4/2/08, Susan Cragin [EMAIL PROTECTED] wrote: This site purports to give instructions on how to run certain applications, including Skype (which is 32-bit). I think wine should have instructions here too. http://www.pulseaudio.org/wiki/PerfectSetup It doesn't look like pulseaudio is going away from Ubuntu anytime soon. https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/198453
Re: deleting AppDB deleted
It really depends on the case, if a program is entirely superseded by another version, ie you can't use the old version at all anymore, totally. If it's still entirely possible to use an older version, and people have a reason too, I would personally not delete it. However it really is up to the management of the maintainers, and how they want to handle things. On Dec 10, 2007 4:53 AM, Richard S [EMAIL PROTECTED] wrote: Hi Im one of the maintainers of the iTunes 6.x (was) On Saturday I received this email ' Subject:[AppDB] Version '6.x' of 'iTunes' deleted Date: Sat, 08 Dec 2007 12:15:45 -0600 (18:15 GMT) Version '6.x' of 'iTunes' deleted --- The action was performed by Wesley Hamel Reasons given Cleanup ' Is it standard practice to remove all old versions of a program except for the most recent? IF this is true, WHY? Rich -- Cheers, Bryan
Re: [press] Phoronix compares 7 versions of Wine
Phoronix often uses the 8 series cards when not testing things like driver versions, we can probably assume they did use an 8 series. On Dec 9, 2007 10:54 AM, Stefan Dösinger [EMAIL PROTECTED] wrote: Am Sonntag, 9. Dezember 2007 14:10:33 schrieb Jonathan Ernst: On dim, 2007-12-09 at 14:07 +0100, Jonathan Ernst wrote: Hello, What do you think about their tests and results ? http://www.phoronix.com/vr.php?view=11539 I guess it's linked with http://bugs.winehq.org/show_bug.cgi?id=10631 No, it doesn't look like they are hit by the 3dmark2k1 bug, which is strange. They are hit by the stencil test slowness in 3dmark2k3 though, which we resolved as a driver bug on geforce 8 cards, since we couldn't reproduce it elsewhere. I didn't find any info what card they used, so it is a bit hard to say what might be wrong. -- Cheers, Bryan
Re: Asking Valve for Steam Survey Results
That is pretty fricking cool. It's not an astronomical figure and realistically could be contended from many directions but still some idea of the userbase, I call that significant. =] On Nov 14, 2007 11:52 AM, Brian Vincent [EMAIL PROTECTED] wrote: On Nov 13, 2007 4:45 PM, Scott Ritchie [EMAIL PROTECTED] wrote: Does anyone know whom we can contact at Valve for more specific results? Here's the answer from Valve to your question: Hey Brian, we would be more than happy to help. I just did a quick query for the audio device and found 12 out of 8566 results to contain wine in the name of the driver. I did the same for video card and found zero, if you can give me more details on specific strings or signatures for a wine user I could have a look for. We just started this survey today so I can run the queries again once we have a larger sample set. Our crash reporting system also collects information about the existence of wine, about 0.4% of the reports are from Wine users (this is for a couple months of data so a statistically significant sample). We have around 3 million unique users in a month so that is around 12k wine users. Given the large majority of crashes are game code related (and not OS dependant) I suspect this is a fair measure for you. -Brian -- Cheers, Bryan
Re: Status regarding the recent Appdb vandalism
Also, in respect to World of Warcraft (Only notify list I'm on), I saw another deleting quite a bit, as I was saying this morning in #winehq, I recorded deletions by Roop, no clue if they might actually be legit, but there was a lot deleted, so I thought I might throw that out there, On 5/23/07, Jan Zerebecki [EMAIL PROTECTED] wrote: Please do _only_ address replies to this email to wine-devel@winehq.org ! Remove all other recipients from To and Cc ! Work is currently underway to restore the state of the Appdb to the backup of May 22 07:00 CST. This morning ( TZ +0200 ) someone used the account Molle Bestefich to vandalize the Appdb. He was also seen on IRC and on the wiki. His IP was identified on all three, logs are available. See towards the end of this mail for IRC log snippet and whois on his IP. Please contact me first if you intend to contact abuse or police personal regarding this, so we don't cause headaches or duplicate work. We do not yet know how this person got access to Molle Bestefich his account. I received 4454 emails about deletes or other actions by the account Molle Bestefich. Send between Date: Tue, 22 May 2007 21:43:46 -0500 and Date: Tue, 22 May 2007 22:18:55 -0500. (2 mails sent by the Appdb in that date range were legit actions.) I don't know if these are all, because admin-accounts were explicitly deleted and thus the notification to them stopped. The following applications where mentioned in these notification emails: Adobe Illustrator Battlefield 1942 Battlefield 2 Battlefield 2142 Call of Duty 2 Call of Duty Checkpoint Firewall-1 Policy editor Command Conquer 3: Tiberium Wars Counter-Strike: Source Day of Defeat: Source Deus Ex Diablo II EVE Online F.E.A.R.: First Encounter Assault Recon Final Fantasy XI Online Guild Wars IDA Pro Photoshop S.T.A.L.K.E.R. : Shadow of Chernobyl Soldat Steam Supreme Commander The Elder Scrolls IV: Oblivion Trillian World of Warcraft PunkBuster Rune Igowin Age of Empires Age of Mythology Black White Brothers in Arms Flash FlatOut .NET Framework Lotus Notes Some notifcations didn't contain a application of version, here the Message-Id-s of some examples (this is probably a bug in the Appdb code): screen shot Message-Id: [EMAIL PROTECTED] test result Message-Id: [EMAIL PROTECTED] monitor Message-Id: [EMAIL PROTECTED] bug Message-Id: [EMAIL PROTECTED] One message about a rejected bug link seemed like these type of message don't contain any information: Message-Id: [EMAIL PROTECTED] On IRC from the #winehq channel: Mai 23 05:27:14 -- noerrorsfound_ ([EMAIL PROTECTED] ) has joined #winehq [unrelated stuff deleted] Mai 23 06:21:37 --- noerrorsfound_ is now known as molle-molle-moll Mai 23 06:21:41 molle-molle-moll molle molle molle Mai 23 06:21:42 molle-molle-moll molle Mai 23 06:21:51 molle-molle-moll molle Mai 23 06:22:03 molle-molle-moll mole string Mai 23 06:22:18 molle-molle-moll hello give thank Mai 23 06:22:18 -- Amorphous has kicked molle-molle-moll from #winehq (Amorphous) /whois output: [06:22:38] --- [molle-molle-moll] ([EMAIL PROTECTED]) : Nicholas [06:22:38] --- [whoismolle-molle-moll] irc.freenode.net : http://freenode.net/ [06:22:38] --- [molle-molle-moll] End of WHOIS list. 2007-05-23T06:50:15+0200 $ whois 64.119.66.10 OrgName:Windstream Communications Inc OrgID: WINDS-6 Address:4001 Rodney Parham Rd City: Little Rock StateProv: AR PostalCode: 72212 Country:US NetRange: 64.119.64.0 - 64.119.79.255 CIDR: 64.119.64.0/20 NetName:WINDSTREAM-COMMUNICATIONS NetHandle: NET-64-119-64-0-1 Parent: NET-64-0-0-0-0 NetType:Direct Allocation NameServer: NS1-AUTH.WINDSTREAM.NET NameServer: NS2-AUTH.WINDSTREAM.NET NameServer: NS3-AUTH.WINDSTREAM.NET NameServer: NS4-AUTH.WINDSTREAM.NET Comment:ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE RegDate:2001-08-24 Updated:2007-02-26 OrgAbuseHandle: WINDS1-ARIN OrgAbuseName: Windstream Abuse OrgAbusePhone: +1-888-292-3827 OrgAbuseEmail: [EMAIL PROTECTED] OrgTechHandle: WINDS-ARIN OrgTechName: Windstream Communications Inc OrgTechPhone: +1-800-990-4449 OrgTechEmail: [EMAIL PROTECTED] # ARIN WHOIS database, last updated 2007-05-22 19:10 # Enter ? for additional hints on searching ARIN's WHOIS database. -- Cheers, Bryan
Re: blizzard conference
Oi, If only I could go =[ I would like to point out to any players who would go there on the behald of the wine project wink wink nudge nudge, that they generally give away some sick in game prizes! If you go and arent a player, you could easily sell the codes they give out (at least last time) for a heap of cash to go towards the project in some form. On 5/7/07, Robert Millan [EMAIL PROTECTED] wrote: Sorry for the OT, but I thought this might be of your interest, considering some of the Blizzard game developers will attend: http://www.blizzard.com/press/070412.shtml Maybe someone in California feels like dropping by to do some lobbying about that itchy /etc/hosts bug? :-) -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- Cheers, Bryan
Re: Towards getting the top ten requested apps running...
They might of meant the flash development environment. On 4/14/07, Maarten Lankhorst [EMAIL PROTECTED] wrote: 2007/4/14, Martin Owens [EMAIL PROTECTED]: but we have a flash 9 player... At the time of the survey there wasn't a sign of it. I remember that, flash player has been only added recently. Flash 7.0 was horrible Maarten -- Cheers, Bryan
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: Winebot
Wow You rpetty much leave us with nothing to complain about... if you truly stick to that, and help users, while still making sure you give the Devs word in their stead... It sounds like a sweet deal. On 3/23/07, Vit Hrachovy [EMAIL PROTECTED] wrote: Hi all, first thanks for a lot of comments. I interpret this as a creative discussion helping to shape WINE project attitude to Winebot and Winebot project itself. I'll let Karl Lattimer to state his attitude with his Wine-Doors project. In the following words, I'm going to discuss my personal point of view, as I'm representing Winebot project. I'll first summarize some points extracted from the previous discussion: -- 1. My goal in writing Winebot is to help Wine succeed 2. I pledge to use only the bare minimum of native DLLs in any Winebot recipe 3. 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 4. I will report bugs to the Wine project in the course of working on Winebot 5. 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. 6. I will help Wine by writing not just Winebot recipes, but also basic application regression test scripts 7. If developers working on projects such as Wine-Doors contributed to Wine, then the bugs would be fixed even faster. 8. 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. In short, you leech off the hard work of all the Wine developers and give nothing back in return (quite the opposite in fact). -- Analyzing the objections written in discussion, I've found that you are missing the following: a) Clear statement, which will specify Winebot project's goals and attitude to its parent project - WINE. Sort of manifest. b) Results - working and actively supported regression testing scripts suite. c) Forwarding bugs and list of 'unclean' fixes to bugs.winehq.org. As I'm Debian and Ubuntu user I actively borrow knowledge from the Debian project. Each Winebot package shall have a maintainer responsible for package quality and for interfacing with WINE project(AppDb, Bugzilla, Testing, Fixing). Every official Winebot maintainer will be bound by sort of Winebot manifest stating the Winebot project's attitude to WINE project. I'll write the manifest (a),(c) and post it onto Winebot Wiki. To create (b) I gladly accept any input to create a regression test repository, would You be so kind and point me to some list of programs / test miniprograms to make a reference implementation? -- 1. My goal _is_ to help Wine succeed. Hours I'm investing in Winebot are hours I'm spending on learning Wine. Recent discussion about missing reg.exe implementation originated from work on Winebot. I'm application maintainer on AppDb. I'm testing application compatibility on WINE versions back to 0.9.9. I've written Winebot especially to make the testing easier. I often install and uninstall Windows programs from WINE bottles, I'm used to bottles (WINEPREFIX) system, too. Having the installation of programs (and their dependencies) scripted is the first step for making automated testing. 2., 3., 4. All Winebot packages should install only minimum neccessary dependencies and their install scripts should be ideally only using normal application Windows installer. Any hacks above will be reported (in case they weren't reported already) to WINE bugzilla. 5. That's a relict from winetools project. 'bottle initialization' will be removed soon as unnecessary. Working package dependencies allow to reconstruct every step of setup and every 'hack' in used packages. 6. Yes, I'm planning to set up a regression tests repository for WINE (and for Winebot too). As Winebot is using AutoHotKey system for installer automation, it can also run programs, check window properties and contents, click on specified button or areas, etc. For more information, see http://www.autohotkey.com 7. Actually I consider my Winebot work is a work for WINE project and WINE users. If I find some error in WINE, I report. Same when I need new functionality. If I'm capable, I'm trying to discuss, implement and send a patch for WINE. Actually Winebot could help more WINE developers with testing, with testing environment setup and with duplicating bug cases, IMHO. 8. User simply wants his application to work. Package maintainer, who prepares the package, should interface with WINE developers whenever he spots a glitch. Package maintainer goes with new WINE versions and prepares a package for each WINE
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
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: Ok... Someone tell me WTF is going on here.
The Sims 2 Seems to do make every single call Wine has trouble with in starting up... Good luck. On 3/19/07, Stefan Dösinger [EMAIL PROTECTED] wrote: Am Samstag 17 März 2007 20:29 schrieb Giles Cameron: Ok. I have been tring to track down what appears to be a bug in wine while trying to get The Sims 2 (Seasons) to work. And so I have been tring to add to the debug a bunch of useless bunk. and I am getting VERY strange results, attached are the cdrom.c file I edited in dlls/ntdll/ and the output. Did I manage to break the wine debugger? or uncover the monster of all bugs? I am sitting here wondering WTF right now You may see the copy protection doing its dirty work. WTF is sometimes the right word for describing what that does. Instead of using winedbg you may consider gdb. Run gdb wine, then do a start foo.exe -- Cheers, Bryan
Re: WineCfg and DirectX options
Completely seconded, some nice UI love is the only thing we have under Transgaming right now, really. But a native Exec. UI is a python buggy UI. On 3/17/07, Michael Lothian [EMAIL PROTECTED] wrote: Hi Has anyone thought about adding the directx options to the Graphics tab in WineCfg Just now I've been testing all the work been done on the graphics layer on different games so I've been switching on and off GLSL and changing backbuffer to fbo etc using regedit Would it not be better to change these things easily instead to allow for wider testing. PS With GLSL and FBO Tomb Raider Legent Opening Level Sequence the cliffs are black With all other options the watter effect is applied the the whole screen when any water is in the screen at all. Has anyone else noticed this. Also none of the menu writing shows up in FarCry but the game works a treat I'm now just waiting for mmstream to be implemented to I can see my video's on X3 Keep up all the good work your beating Transgaming hands down Mike PS the above reports were testing with 0.9.31, 0.9.32 and the latest git -- Cheers, Bryan
Re: Another GSoC idea
A DX app packed nicely with winlib would be wonderful. It realistically isn't an enormous hurdle but the 'look what I did!' factor would be amazing. Now if only you could convince Blizzard for WoW =D On 3/15/07, Remco [EMAIL PROTECTED] wrote: I was thinking of a combined project between Ogre (graphics engine) and Wine. Ogre works on Windows and Linux. It has an OpenGL and DirectX backend. Maybe a student could try to get the DirectX-backend working in Linux with Wine. This would result in a lot of patches for Wine, and the first native Linux DirectX app of this size that I know of. Wouldn't that be cool? Remco Need Mail bonding? Go to the Yahoo! Mail QA for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=listsid=396546091 -- Cheers, Bryan
Re: Submitting winetricks to winehq tree?
It looks a lot like a command-line version of what wine-doors aims to be, right? Only the installing software aspect, and not the dynamic aspect of repositories and such. On 3/14/07, Stefan Dösinger [EMAIL PROTECTED] wrote: Am Mittwoch 14 März 2007 20:01 schrieb Dan Kegel: I haven't been villified yet, so let me try harder. Should winetricks be committed to the winehq tree? It would be handy for people triaging Wine bugs to see if e.g. native dcom, odbc, or corefonts hide a bug. I haven't deeply looked at it yet(only the application list), but I am not sure what the answer is. For one part it is dangerous that people start using it to install native dcom and ignoring dcom bugs. Though considering the complexity of dcom, I don't think that anyone who does not know why he/she should not use native dcom would suddenly start fixing builtin dcom bugs. But it would reduce the number of regression testers and regression reporters because it would be much easier to switch to native dcom than to bisect and report a dcom regression. I think the other things like the vbo runtime, odbc drivers, ..., are out of scope for wine anyway, so no danger in that. Appart of dcom I'd say yes. With dcom I can't really answer this :-/ -- Cheers, Bryan
Re: DirectX 10 start as a SoC project?
Read the other thread for way more information. You would do best to follow that model instead of thinking large scale lump all that you can of 10 in, they're thinking more framework. On 3/12/07, Kovács András [EMAIL PROTECTED] wrote: Hi, I think, that start working on Dx10 is a great opportunity to learn about wined3d, and Microsoft's new platform. I would like to apply, because i want to contribute to open source projects, and i'm really interested in wine, especially in wined3d. I have some patches in the tree, and I really would like to work on together. Best Regards, Andras kovacs -- -- andras NetClub Lamarr csevego.net [EMAIL PROTECTED] -- -- Cheers, Bryan
Re: My plans for SOC
Frankly if you could get ALSA working perfectly, and DSOUND to do what it's supposed to without underruns (As in WoW, with default settings) You would make my life a lot easier. I answer so many questions about sound it's not even funny. Out of the box Just working sound would be pretty great. OSS is *alright* and all but it doesn't work so well with software mixing, ALSA however is easy to set up. On 3/13/07, Maarten Lankhorst [EMAIL PROTECTED] wrote: For the summer of code I'm planning to improve the dsound code and alsa code, to make alsa finally better then OSS, in a way that has a will get accepted into the wine tree, for that I'm thinking of improving on the following fronts: Winealsa: - Add mixer device and aux controls - Implement dsound capture - Seperate the initialisation of the directsound code from the waveout code, to allow creation of multiple dmix devices. - Try to configure alsa to allow arbitrarily big buffers, working around the alsa problem that only up to a certain amount can be allocated for buffers, certain programs (for example winamp) may require more. - Remove the queuing thread and use Lock() and Unlock() instead. - Make it run so well, people wouldn't want to use OSS any more. Both dsound/winealsa: - Allow proper usage of Lock() and Unlock() for sound drivers, it's not used properly or even tested in current dsound code. - Rework some of the dsound code, to allow mixing to be done in winealsa, and fix possible errors that can be caused by it. - Improve the dsound software mixer code to allow mixing and (if possible) be less prone to buffer underruns. The challenge is to get this working right, without too much of an impact hit. I also will have to work around alsa limitations: I cannot make buffers arbitrarily big, while in windows they can be. It seems no 2 programs use dsound in the same way, so I will have to test with various different programs to get everything working. I'll try to get in contact with alsa-devel first, if there is a way to change buffer size to something arbitrary, it is worth it in the long run to use that method. A manual fix seems to be close everything using alsa, then echo 256 /proc/asound/card0/pcm0p/sub0/prealloc, but I am hoping there is an easier way to fix it, in either case I am afraid I will have to put some memory buffer code in winealsa as fallback. If there's still some time left, I'll also try to get some 3d sound code in, using some openal code, the license seems to be lgpl compatible, or I will try to get support for multiple (4, 5.1 ?) speakers working, it depends a little on how fast I can get this to work in a nice shape. Looking for feedback. Cheers, Maarten -- Cheers, Bryan
Re: Add Xcursor support
not seeing a patch attached... and what exactly does it do? On 3/9/07, Adam Petaccia [EMAIL PROTECTED] wrote: This patch makes the Guild Wars show up in all its glory. -- Cheers, Bryan
Re: DirectX 10 start as a SoC project?
I'm no actual dev here by any means, but I think anything more than setting up the extreme basics would take away from the work done on 8, and 9. As not much uses 10 yet it would be a bit premature to do a ton of work on it. Porting the current code if only to the point of 10 working as well as 9 or 8 without the fancy new calls would suffice for now, and yes, I also think we should have a Vista version if only for the sake of consistency, it wouldn't really be any different than XP for us at the core just throwing the tag up there. I say focus SoC on 8 and 9, imagine having a more complete 8 and 9 then 10 would be cake, as I understand it all it does it add new calls right? And possibly dig up the theming zombie, so we might have that finally lol. On 3/10/07, Stefan Dösinger [EMAIL PROTECTED] wrote: Hi, Thinking about SoC I though that starting a DirectX 10 implementation may be a good summer of code project. I do not mean implementing the full d3d10 lib, that would be way to much, more starting the infrastructure. Henri disagreed with the idea, so I thought I'll write a mail for public discussion :-) . Looking at the timeline for SoC I hope it isn't too late. My idea is to start a d3d10 implementation up to the following point: - Add a winver Windows Vista to make version checkers happy :-) - Create the d3d10 lib and start the .idl file for header generation - Write stubs for the functions to allow the app to create all the interfaces - Write test cases for reference counting. ddraw and d3d9 show that Microsoft does not stick to its own COM rules - Make methods that have already 1:1 equivalents in wined3d call wined3d. Add other methods as required to wined3d. - Implement them as far as you feel like :-) I think the good thing about this is that there are is not much knowledge about wined3d and d3d10 necessary at the start. The one who works on it can learn the d3d10 interface while writing the stubs and learn about wined3d when starting to call it. Opinions? Suggestions? Cheers, Stefan -- Cheers, Bryan
Re: DirectX 10 start as a SoC project?
Ack I also meant to mention that yes, if we do this, we would be a little ahead of the game when DX10 apps really start rolling out, but if we do, we might also have some DX 8 and 9 people stray to 10... just a worry. I'm sure it will work out. Everything will be done eventually! Thankfully SoC really gives people a push, eh? On 3/10/07, Bryan Haskins [EMAIL PROTECTED] wrote: I'm no actual dev here by any means, but I think anything more than setting up the extreme basics would take away from the work done on 8, and 9. As not much uses 10 yet it would be a bit premature to do a ton of work on it. Porting the current code if only to the point of 10 working as well as 9 or 8 without the fancy new calls would suffice for now, and yes, I also think we should have a Vista version if only for the sake of consistency, it wouldn't really be any different than XP for us at the core just throwing the tag up there. I say focus SoC on 8 and 9, imagine having a more complete 8 and 9 then 10 would be cake, as I understand it all it does it add new calls right? And possibly dig up the theming zombie, so we might have that finally lol. On 3/10/07, Stefan Dösinger [EMAIL PROTECTED] wrote: Hi, Thinking about SoC I though that starting a DirectX 10 implementation may be a good summer of code project. I do not mean implementing the full d3d10 lib, that would be way to much, more starting the infrastructure. Henri disagreed with the idea, so I thought I'll write a mail for public discussion :-) . Looking at the timeline for SoC I hope it isn't too late. My idea is to start a d3d10 implementation up to the following point: - Add a winver Windows Vista to make version checkers happy :-) - Create the d3d10 lib and start the .idl file for header generation - Write stubs for the functions to allow the app to create all the interfaces - Write test cases for reference counting. ddraw and d3d9 show that Microsoft does not stick to its own COM rules - Make methods that have already 1:1 equivalents in wined3d call wined3d. Add other methods as required to wined3d. - Implement them as far as you feel like :-) I think the good thing about this is that there are is not much knowledge about wined3d and d3d10 necessary at the start. The one who works on it can learn the d3d10 interface while writing the stubs and learn about wined3d when starting to call it. Opinions? Suggestions? Cheers, Stefan -- Cheers, Bryan -- Cheers, Bryan
Re: DirectX 10 start as a SoC project?
That pretty much what I meant, you just explained it in a clearer way... I only had a minute or so to type it in heh. The irony here is I was writing it while playing WoW via wine through opengl... The factor of irony is overwhelming =P. I basically agree. I figured (without actually looking at it) that d3d was a shared code-base of some kind with the individual dx dlls basically pointing here and there for the nuggety center. Now just throwing up a (pretty much) mock up of d3d10 or dx10 in general would be great, it would atleats give a little structure, and as you said ease the code to a new structure if need be. On 3/10/07, Stefan Dösinger [EMAIL PROTECTED] wrote: Am Sonntag 11 März 2007 00:06 schrieb Bryan Haskins: I'm no actual dev here by any means, but I think anything more than setting up the extreme basics would take away from the work done on 8, and 9. As not much uses 10 yet it would be a bit premature to do a ton of work on it. Porting the current code if only to the point of 10 working as well as 9 or 8 without the fancy new calls would suffice for now, and yes, I also think we should have a Vista version if only for the sake of consistency, it wouldn't really be any different than XP for us at the core just throwing the tag up there. The idea is that our main Direct3D engine, wined3d, is shared between all Direct3D versions, from Direct3D 1 to Direct3D10. Admitadely, the core functionality that is equal between d3d1 and d3d10 is comparably small, and the part that exists should work pretty well by now. But work on d3d10 games can definitly fix bugs in d3d9 apps accidentally, in the same way the d3d7 merge fixed bugs in wined3d that affected d3d9 apps. Also consider that d3d10 may need some architectural changes to wined3d. I think it is better to make them now and when further optimizing it have things in the d3d10 style than to drive everything to d3d9 and see in a year that we have to turn a few core parts upside down. Of course having one SoC project on d3d10 does not exclude someone else who wants to do something do a SoC project on d3d9 :-) . Ideas would be Overlay support for movie players or the d3dx9_xy helper DLLs(Although those are maybe out of scope for wine). Or even a completely different area of DirectX. DirectSound, DirectPlay, ... I say focus SoC on 8 and 9, imagine having a more complete 8 and 9 then 10 would be cake, as I understand it all it does it add new calls right? And possibly dig up the theming zombie, so we might have that finally lol. One problem is nowadays that wined3d is pretty advanced already, and the learning curve is rather hard already. D3D10 is in my eyes an oportunity of an exciting project which allows a new developer to grow into wined3d. I personally won't start hacking on d3d10 immediately, I'll continue to work on d3d9 and below apps. The state of d3d9 does not justify that yet. And I think that *Direct3D* isn't in a bad shape nowadays. We recently had a nice success when that new Command and Conquer game came out, and ran on the day it hit the shelves. Wine is getting the public opinion that it does better on games than Cedega. What we should not shout our loudly is the shape of other DirectX stuff. DirectSound is an issue, although I must say that Maarten Lankhorst is doing nice work on winealsa :-) -- Cheers, Bryan
Re: Is there someone working on dxdiag?
have you tried plopping in a native dxdiag app. to see if it does enough for the application to think the environment is alright? It would be pretty cool to have a native Wine dxdiag though... Having a standardized set of tests would be very helpful, not to mention for the log output function, would simplify a lot of things for when d3d is good enough for the mainstream. On 3/9/07, Mirek [EMAIL PROTECTED] wrote: Hi, I would like to start some applications like Carmageddon TDR 2000 in HW mode, Neverwinter Nights 2 or just GetGPUAndSystemInfo.exe from Nvidia SDK demos and maybe 3DMark with HW info, but there are problems with detecting video card, I assume the main problem is in dxdiag library. So I would like to ask if there is someone working on this library, or if was there some code which was not accepted in wine tree to fix that? I am trying to hack this library, but with only small success. Mirek Slugen -- Cheers, Bryan
Re: Question about OpenGL/D3D
Ah so that was the infamous problem with things like the WC3 Map editor, and such? Thinking about that not it makes sense. On 3/9/07, Stefan Dösinger [EMAIL PROTECTED] wrote: Am Freitag 09 März 2007 19:47 schrieb Mike Schaadt: Has anyone tested using standard window objects in a window that also had an opengl/d3d context? This is known not to work. It was a regression due to the window management rewrite. The problem is that since the window management rewrite all window elements except the main window are not X11 windows. So the clipping done by X11 on opengl contexts does not work for subwindows in wine. The current plan for fixing this is, I believe, to create an overlay window which is used for opengl drawing. The other idea was to set up the opengl scissor test, but that turned out not to work correctly, and we need a seperate window for antialiasing support too. -- Cheers, Bryan
Re: Work legalities
Why would there be a problem? Unless you work for microsoft or something, how could there be an issue with that? On 3/7/07, Nathan Williams [EMAIL PROTECTED] wrote: Hey everyone, I have been planning to do some work on wine for a while now, but after I started working I got myself a new programming job. I'm worried about the copyright of any external work I do, so I need a little advice. What do I need from my employer to clear me to work on wine? Is something verbal ok, or should I get it in writing? -- Nathan -- Cheers, Bryan
Re: AppDB performance issue
I'm actually noticing it a little now... about a minute hang sometimes then poof it's up. So it's not a crawl... just a hang. It's weird really. Feels like too many people trying to connect for the server to handle so it throws them to the queue, or similar. On 2/20/07, Nick Law [EMAIL PROTECTED] wrote: I still find appdb really slow 60 seconds to view some pages, post on the forums etc It's driving me nuts to the point I've gone back to real life for a while as it's less frustrating. BTW this problems exists on systems separated by over 100 miles (but same login account) so it not hardware at my end. I'll check back now and again to see if it's fixed. Apart from that, keep up the good work devs, wine's functionality is improving all the time but appdb needs fixing. Cheers Nick John Smith wrote: Humm very strange it works well for me, I just tested it myself, seems reasonably fast in firefox 2.0.0.1 http://2.0.0.1 on windows 2000, on gentoo x86 with firefox 2.0.0.1 http://2.0.0.1 , and on gentoo amd64 firefox 2.0.0.1 http://2.0.0.1. I added, then removed, then edited a test result. Speed seemed normal. Hope this helps the investigation. Regards, John Klehm On 2/14/07, *Louis Lenders* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Bryan Haskins kingofallhearts999 at gmail.com http://gmail.com writes: I was just replying, and reading now, no slow down at all. It loads a little slow running through all that text, but no where near the minutes everyone says it takes them, even on dialup. For your info, Appdb, is complete unusable for me ... Loading a page, or adding a test result to an application takes several minutes. Please fix, as this is really annoying :( -- Cheers, Bryan
Re: We need a new version numbering scheme
90 percent of statistics don't contain a 0 either! Whoops... Jokes aside, I was answering some wine related question on Ubuntuforums.org and came across this, many light users tend to do it. I even thought of it that way when I first learned about the common linux versioning system. I don't think there is anything we can do about it but educate users. And correct them when they do this, maybe on the main download info page for repos and such say outright it's important. Thinks like that. Maybe on some kind of getting support page or the future wine help talk about how it's important. even after 1.0 we'll be hitting this again too unless you do major revisions and reworking it will always be 1.XX.XX so... they need to get with it somehow. Just a users POV. On 2/16/07, Scott Ritchie [EMAIL PROTECTED] wrote: On Fri, 2007-02-16 at 20:13 +0100, Marcus Meissner wrote: On Fri, Feb 16, 2007 at 10:53:51AM -0800, Scott Ritchie wrote: On Fri, 2007-02-16 at 09:40 -0600, John Smith wrote: Maybe this would be unworkable in git or whatnot but perhaps always making the minor version field double digit would do the trick? How about we make the next version Wine 0.9.99.01? Or how about we make the next version 1.0 ;) I think 0.9.31 will have removed this confusion again. Ciao, Marcus Except maybe that 0.9.4 might be thought of as higher than 0.9.31 Thanks, Scott Ritchie -- Cheers, Bryan
Re: Wine and menu integration
It does work in Ubuntu fine, which should conversely mean it works with any other gnome menu standard desktop. *should should should*. And in Feisty when you say always open this type of program (exe in this case) to use wine, it sticks and now I can just double-click and I'm in. Any Distro using the latest dev release of Gnome should be able to do this (don't know about pre this.) On 2/15/07, Scott Ritchie [EMAIL PROTECTED] wrote: On 2/15/07, David Saez Padros [EMAIL PROTECTED] wrote: I also have what should be add to installation so .exe files are executed with wine when double-clicked (tested in ubuntu) When did this break? I thought this worked in Ubuntu just fine. Thanks, Scott Ritchie -- Cheers, Bryan
Re: opengl
Well you don't have Direct rendering... if you dont have support from the ATI OSS drivers ( if you use ATi) then you should download the ATI or nvidia proprietary drivers. Should be in your Distros Repos, or you can set them up yourself from their sties. On 2/13/07, gaosheng [EMAIL PROTECTED] wrote: Hi: I want to use opengl with wine. //Here is my glxinfo. server glx vendor string:SGI server glx version string:1.2 client glx vendor string:SGI client glx version string:1.2 OpengGL vendor string:Mesa project:www.mesa3d.org OpengGL renderer string:Mesa GLX Indirect OpengGL version string:1.3 Mesa 4.0.4 //-- I can't init opengl. when ChoosePixel(), it failed. Can you tell me the reason. Best regards gao sheng -- Cheers, Bryan
Re: AppDB performance issue
I was just replying, and reading now, no slow down at all. It loads a little slow running through all that text, but no where near the minutes everyone says it takes them, even on dialup. On 2/13/07, Nick Law [EMAIL PROTECTED] wrote: Bryan Haskins wrote: Weird I'm on dial-up even and goto the same pages, and all around the wine sites, all the time, and they load surprisingly fast. On 2/12/07, *Nick Law* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Nick Law wrote: Tony Lambregts wrote: Chris Morgan wrote: On 2/11/07, Tony Lambregts [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Nick Law wrote: Hi Tony, Just lately, I've noticed that AppDB seems to be very slow, i.eit can take15 seconds or more for a page to come up or simply to login. Is there a bandwidth problem or is the server getting overwhelmed or is it a problem at my end (UK). 30 seconds later it's back to being very responsive as if the server was a bit overloaded for 30 seconds or so. Other websites I try at the time work fine including winehq. Is winehq on a different server ? I have noticed this too and it is very annoying. Yes www.winehq.org http://www.winehq.org qpdb.winehq.or and bugs.winehq.org http://bugs.winehq.org are all on the same server. Winehq and bugzilla are quite snappy but the AppDB is a pig now. I have know idea what is wrong -- Tony Lambregst Are particular pages slow? I'm not seeing slow page loads to the main page or to an application version page from here, a few seconds for each. Chris I see it when doing administration ie accepting or rejectiong applications and versions (maybe its the way we send emails). -- Tony Lambregts . Yes, ditto. Logging in to do admin tasks, but not only that, if I click on the link in an email from somebody that has posted to the WoW 2.0.x page it will take 30 seconds for the page to appear. I just posted some replies to the wow page and then clicked on the link in the email and it took 84 seconds for the page to appear. It find it seems to be more frequent now, maybe every other page or 1 in three pages are very slow. Nick Correction it seems to be bad at the moment, the last 4 pages are slow, 60-90 secs before they display, and now it's back to 2seconds to display a page again, it's like some process on the server hogs the CPU for 60 secs intermittently. Nick -- Cheers, Bryan Do you click on the links in the emails received from [EMAIL PROTECTED] to take you to the posts on the WoW AppDB page ? That's where I often see the problem. For instance this is a link to your recent post http://appdb.winehq.org/appview.php?iVersionId=6482mode=nested#Comment-18117 which takes over a minute to load, then 5 minutes later I try again and it loads in 2secs. Nick -- Cheers, Bryan
Re: AppDB performance issue
Weird I'm on dial-up even and goto the same pages, and all around the wine sites, all the time, and they load surprisingly fast. On 2/12/07, Nick Law [EMAIL PROTECTED] wrote: Nick Law wrote: Tony Lambregts wrote: Chris Morgan wrote: On 2/11/07, Tony Lambregts [EMAIL PROTECTED] wrote: Nick Law wrote: Hi Tony, Just lately, I've noticed that AppDB seems to be very slow, i.e it can take15 seconds or more for a page to come up or simply to login. Is there a bandwidth problem or is the server getting overwhelmed or is it a problem at my end (UK). 30 seconds later it's back to being very responsive as if the server was a bit overloaded for 30 seconds or so. Other websites I try at the time work fine including winehq. Is winehq on a different server ? I have noticed this too and it is very annoying. Yes www.winehq.org qpdb.winehq.or and bugs.winehq.org are all on the same server. Winehq and bugzilla are quite snappy but the AppDB is a pig now. I have know idea what is wrong -- Tony Lambregst Are particular pages slow? I'm not seeing slow page loads to the main page or to an application version page from here, a few seconds for each. Chris I see it when doing administration ie accepting or rejectiong applications and versions (maybe its the way we send emails). -- Tony Lambregts . Yes, ditto. Logging in to do admin tasks, but not only that, if I click on the link in an email from somebody that has posted to the WoW 2.0.x page it will take 30 seconds for the page to appear. I just posted some replies to the wow page and then clicked on the link in the email and it took 84 seconds for the page to appear. It find it seems to be more frequent now, maybe every other page or 1 in three pages are very slow. Nick Correction it seems to be bad at the moment, the last 4 pages are slow, 60-90 secs before they display, and now it's back to 2seconds to display a page again, it's like some process on the server hogs the CPU for 60 secs intermittently. Nick -- Cheers, Bryan
Re: wineboot: Start items in StartUp folder on boot, includes security measures.
If you've read the recent mailing list posts dating up to a few weeks back I think, there have been some cases. But like everyone said, the fact the malware would even run in itself is almost bittersweet. It is bug-for-bug though so you can't just do that. Possibly an 'msconfig' like thing would be more realistic you know where you control (in a poor poor pooor way,) what runs at startup. yo ucould even go as far as to show the programs in the gnome-sessions program or the kde equivilent, thought that would be a pain (though cool.) On 2/12/07, John Smith [EMAIL PROTECTED] wrote: Part of my confusion what usage pattern is contracting malware on wine in the first place On 2/12/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On 2/12/07, James Hawkins [EMAIL PROTECTED] wrote: On 2/11/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On 2/11/07, Misha Koshelev [EMAIL PROTECTED] wrote: Hi everybody, Thanks for your suggestions. I just posted a new patch on wine-patches where I tried to incorporate these and now it does the following (in addition to my previous patch which just started items in the StartUp folder): - When wineboot finds a file that it wants to start in the StartUp folder, it asks the user whether he wants to run the program. His options are: Always, Yes, No (default), and Never. - If he selects Yes the program is run, if he select No it is not. - If he selects Always or Never, I create a registry key in: HKEY_CURRENT_USER\Software\Wine\StartupItems with the full pathname of the program and the value always or never. When wineboot sees this program in the StartUp folder it checks this key, and if it is set it performs the appropriate action. What do you guys think? If you like the system, it would be pretty easy to incorporate this into the run key running as well (which are currently just run without any user confirmation)? This sounds almost perfect. I think the counterpoint raised by James Hawkins would be adequately addressed by adding a winecfg option as follows: Startup items behavior: (*) Silently allow -- This is bug-for-bug compatibility ( ) Ask-- Most computer-savvy folks would want this ( ) Silently block ( ) Block and notify me This is unnecessarily complicated, and i really doubt anything like this would ever make it into the Wine tree. Perhaps this should be independently set for each kind of startup item (startmenu\programs\startup, registry run key, profile settings, etc), but I think that's not really necessary. Also, I would suggest that the list of approved start items be stored outside of winespace, so that malware can't bypass the protection by setting the key. Of course, really nasty stuff could still call into Linux, but that would require some hybrid system that was aware of the ELF dynamic loader in order to not fall afoul of address space randomization. Ultimately I think wine is about more than just running Windows-compatible programs without the Microsoft tax. It's about running those programs without ceding control of your computer to an untrustworthy party. We don't want the limitations that Windows imposes... true bug-for-bug compatibility would mean only being able to access files on a FAT or NTFS partition, but I don't hear anyone advocating for that kind of crippling behavior. What? Wine has nothing to do with which file system your files reside on. You advocated that wine aim for working exactly like Windows, no less and no more, rather than deviating in user-configurable ways to enhance the user's control over his own system. Maybe while we're at it, wine should have the bug which allows certain software to prevent screen grabs. No, I think defeating DRM to enable fair use is perfectly reasonable, and there are some bugs which should be fixed. Should wine try to patch remote exploits at the exact same rate as windowsupdate.com? That would be also be required for true bug-for-bug compatibility. After all, someone properly authorized might be using that backdoor to reboot their webfarm remotely -- not! There are things that are wrong in a theoretical sense (i.e. the Pentium floating-point bug), or misclassification of Unicode characters, which some programs might reasonably depend on. And then there are things that are wrong from a practical engineering perspective, like software taking away the user's choice to not run it, which the mere fact that a program depends on it makes it malware. Asking if you want to run every file set for startup in wineboot every single time is crippling behavior, not to mention annoying. UAC anyone? If you're so worried about this malware, create a reduced privileges account just for Wine. That's the point of a remember my choice or
