Re: A modest proposal
the wine included in fc4 is customized by redhat.. there are no new features in it afaik. Tom gslink wrote: I noticed that for FC4 Red Hat is providing a copy of Wine in extras. This is something that THEY are producing and it is in a different form from the one put out by Wine HQ. It appears to me that there is no reason for Wine HQ to duplicate their effort and suggest some sort of collaboration. The version posted by RH seems to be later than what is posted by Wine HQ. I think this should be investigated.
Re: Please read: Wine(HQ) needs a reorganization (AppDB, Bugzilla, etc.)
Perhaps we should check this out? Anyone? Tom Molle Bestefich wrote: Tom Spear (aka Dustin Navea) wrote: ANYWAYS this email has gotten longer than I planned, and my hands are starting to hurt, so please, comments or suggestions, send em my way. Maybe the reason that your mail is so long is that it's an impossible feat to save that zilla. Let's pronounce that monstrosity from the past dead and start using a better product. Switch to Trac, for example. It will import your Bugzilla bugs in a snap and you're ready to go. User friendly and much simpler and much more consistent than Bugzilla. http://projects.edgewall.com/trac/ The administrator can define custom reports, they're available under < View Tickets >. Click this and see. Instead of the custom script you talk of, now choose < Custom Query , add a "reporter" filter and set it to yourself. Can also be used in URL fashion like this: http://projects.edgewall.com/trac/query?reporter=jonas Lots of other niceties too. There's an integrated Wiki where you make inline references to the ticket system. Or inline references to the source code, which is also conveniently browsable in Trac. You can search across tickets, source code commits and the wiki with a simple google-like search box. You can even keep your product manual in the wiki like the Trac project does (see http://projects.edgewall.com/trac/wiki/TracGuide). There's even a plugin for making the wiki DOCBOOK compatible somewhere. Possibilities seems endless.
Re: Please read: Wine(HQ) needs a reorganization (AppDB, Bugzilla, etc.)
I disagree with both sides of the forum issue.. I think that depending on how it is implemented, it could go either way.. There are forum software's out there that will send you a mail (including what was said) whenever a section is replied to.. Which means you just subscribe to the wine-devel section for example and any new threads will be emailed to you, as well as replies to the ones already posted.. And I'm sure someone here could write something so that you could reply to the email and have a script send whatever you wrote to the forum for you. Of course at the same time, you have to worry about forum db crashes (i know we have all heard of that happening from time to time).. Bug searching is harder than it needs to be. I personally have made a custom search to find bugs that i have reported, and bugs that are assigned to me, just because the my bugs and bugs by me links dont find all of them.. Plus, when searching for an app-specific crash, searching thru just the summary doesn't always work, as user may post the err message on the console, so then you need to create a custom search thru the comments as well. And most users who are searching for a bug dont care what the status of the bug is, they want to search all bugs, in case it has a known workaround.. So here are my recommendations for bugzilla, obviously these would have to be implemented by mozilla, but we'll worry about that later. 1) Create a simplified mode and advanced mode, and if the user hasn't specified which mode they want, then default to simplified. Advanced mode would be the search as it is now, simplified mode would be the modifications below: 2) At the top of the page, change the word summary to "Search for:" and make the text field next to it search thru all comment and summary fields, and if possible, textonly attachments, and put a link to the advanced search. 3) Remove the following sections: component, status, resolution, severity, priority, hardware, os, email and numbering, and bug changes, as well as the advanced querying section. That way it is more google-ish, which is what users want.. For entering new bugs, the following changes should be implemented: 1) Remove component altogether, or make it a little more clear at least. If I am entering a bug for an app crash, and it doesnt use directx, for the most part i use wine-misc, which doesnt help anyone out. At the very least if it does stay in there, put an unknown component in the list so i can pick unknown and change it later, once the area in question is discovered. 2) Allow us to attach a file on the main bug entry page, so we can attach the trace and comment the trace at the same time, instead of having to file the report, and then go back to the bug to attach the log. 3) Change the default for platform to PC, the default for os to linux, and remove the windows entries from os. 4) Remove priority and severity. Anything that I have asked to be removed from the enter bug form should be left in the actual report, but should be allowed to be changed or set by regular users, only by developers, and people with the change flags set (bugzilla maintainers).. Thats all I can think of for the user-friendliness factor in those areas. I should add that the appdb is flooded with bug reports, which doesnt look good for wine. I say we reset the appdb comments to null, and pot a note at the top of every page in red letters that says "Problems using a particular app? Click here!" and make Click here! be a link to bugzilla's bug report page. That will reduce the number of bug reports in the comments. Then each app maintainer should put a note at the top of their app pages saying "If you have a problem using this app, please (do such and such)" where such and such is whatever the maintainer would prefer, either email them privately, or file a bug report, or write to wine-devel, or anything other than complain about it in that app's thread. That would make wine look a lot more user-friendly, as new users can see hey this app works, and there arent any issues with it, or they can see hey this app partially works, but any problems i have can be easily reported, and people aren't bashing wine about lack of support for that app. ANYWAYS this email has gotten longer than I planned, and my hands are starting to hurt, so please, comments or suggestions, send em my way. Tom S. Schauenburg wrote: OK, but I mean (don't hit me for this) take a look at Cedega. They have a forum and a wiki and have loads of user input. This generates (inter)activity of users and 'promotes' the application in a certain way, people like to tell other people something finally works :-) 5. First you need to search for a bug. A normal user wouldn't know what things to select and would need to 'guess' where to fill in the keywords etc. The search form looks threatening/scary, so it needs to be simplified into (for exa
Re: Licensing question
Dominic Wise wrote: On Wed, 2006-01-04 at 17:00 +0100, Andreas Mohr wrote: Hi, On Wed, Jan 04, 2006 at 03:29:22PM +, Dominic Wise wrote: I have a question regarding the use of portions of Wine in a commercial application. Sorry if this is not the right place to post but I am not sure who I can directly address this to. np (I don't think wine-users would be an appropriate place for such a specific question) The application my employer develops is a financial application designed to work on Win 2K and Win XP, but we have a need for a Win32 function that is only supported in XP (TzSpecificLocalTimeToSystemTime). We could write an implementation of this function ourselves for Win 2K but I have noticed that there is a full implementation in Wine. Are you sure this is the only Win32 API with this exact functionality? There might be a good reason why it's been introduced at such a late date as XP+ only... cd wine; find . -name "*.spec"|xargs grep -i time.*time Pretty sure it's the only one. Not sure why it was added later. Maybe there wasn't demand for it until XP came about. Is it permissible to use the source for this function in our application? If so, what provisions do we need to make with regard to recognition of Wine and supply of source code to our customers ? Err... no. (at least not directly) While Wine's license (LGPL) allows linking to Wine components, it still carries the same restrictions as the GPL license when it comes to directly integrating such code in closed-source programs. However I think(!) that it's legally valid to gather some "inspirations" from such code if absolutely needed and then write your own implementation of this function, much preferrably by first looking at the code and then, completely isolated, writing your own quite different code. (anybody please correct me NOW if this is fatally incorrect!) But I'm afraid the best way to avoid license violations is to code this function without looking at the (L)GPL'd implementation of this algorithm, if possible. Another way *might* be to ask the original author of this function (see CVS logs) whether he permits you to use his *original*, *unpatched* version of this function. BTW, if you absolutely want to directly use Wine-related code in a commercial (or, to be exact: proprietary) application, then may I direct you to http://de.wikipedia.org/wiki/ReWind ? This is a source tree mostly consisting of the old Wine codebase before the MIT -> LGPL license change. Problem is that rewind is too old to already contain an implementation of TzSpecificLocalTimeToSystemTime(). Hmmm... I thought from Dan Kegel's earlier response that it would be OK to put the function into a separate library (DLL) and release this library under a separate license to the rest of the application. It's a pity if this is not permissible. AFAIK, that is correct. You can license individual files within any application however you want, and as long as the DLL containing the aforementioned function is licensed under LGPL (which it would be, since the license would be inherited from wine), and you can release the entire source of that DLL, then I see no problem with it. SO.. the question is, will that DLL contain _only_ that function, or will it contain others that need to be linked to as well, and if the 2nd applies, can the rest of the functions within that DLL be open source, LGPL'ed? Tom
Re: Question regarding the Wine Vs WineLib performance
This may sound like a stupid thought, and may have already been discussed (I couldnt attend wineconf), but doesnt g++ compile everything with -Ox upon request, so it is size-optimized (read: Compressed), and don't most people use that same flag on most compilations? It seems to me that if the above 2 statements are correct, then the reason MSVC produces faster code than g++ is because MSVC doesnt compress it's output, you have to use something like upx to compress it, while keeping it executable, and then once that is done, the binary runs slower... Like I said, probably already discussed, and probably incorrect, but my 2c either way. Brian Vincent wrote: On 1/3/06, Ananth M <[EMAIL PROTECTED]> wrote: Then I converted the dll into .so and compiled and linked this .so with win32 program using WineLib and Wineg++ The timing that was taken to execute the function exported by the dll ( through .so ) is almost two times, compread with executing using wine. Does any one has any reference for further investigation on this problem or any information I'm not sure if this is the reason or not, but we discussed this a bit at WineConf last year. The concensus was that MSVC produces much faster code compared to GCC. Maybe try compiling with MinGW on Windows and see what happens with the DLL in Windows? -Brian
Re: winecfg: Problems with audio configuration
Vitaliy Margolen wrote: Monday, January 2, 2006, 2:55:38 PM, Robert Reif wrote: Vitaliy Margolen wrote: I have noticed significant increase in crashes and lockups in winecfg's audio page. Could we do something about that before the next release? I agree with you but can you be more specific? I'm afraid I can't. It all works here. But all the reports I get from people on #winehq don't have that much details. I had one person who had winecfg crash each time he went to audio tab. Installing arts & esd didn't help - same result. It was a pre-compiled binaries. Vitaliy, in the circumstance of pre-compiled binaries I know, at least for me, that the last time I tried using them, they didnt work.. This was back in 2002, and I was using Mandrake at the time, using their precompiled binaries that came with the latest release. It crashed running _anything_.. But once I removed that and got source, it worked fine.. So if a user is having a problem with precompiled binaries, check what distro it is the user is using, and if it is one that is known to add their own code to their binaries (like Mandrake), ask them to se fi the same happens from source. Now I know we already did that, and I just stated the obvious, but I just think I should make it known that several distro's add code to wine that cause it to not work on some of their users' machines.. The above is why I personally unless, I am forced to do otherwise, always download and compile from source, well that and the fact that I now use Slackware.. lol Tom
Re: wine's setupapi.dll / newdev.dll ?
Marcus Meissner wrote: What does STI provide? Access to digital cameras and scanners? IIRC, STI.dll is the API for scanners, and STI_CI is the API for digital cameras.. (STI being STill Image, and STI_CI being STill Image Capture Instrument or something close to that)..
