Re: Starter projects for new Wine contributors?
On 1/9/06, Al Tobey <[EMAIL PROTECTED]> wrote: > On 1/9/06, Dan Kegel <[EMAIL PROTECTED]> wrote: > > Hi all! > > I'm looking for suggestions for starter projects for > > new contributors that would take something like a week to do, > > and wouldn't require much knowledge of Wine ahead of time. > > Tests! > I agree completely. Testing the API is especially relevant for win32 developers, because they're coding an API they're familiar with. Even if a new developer has little programming experience, win32 or otherwise, tests are a great place to start. It helps the new developers by familiarizing them with the particular API they are testing, and it sheds light for not only wine developer's, but anyone who references wine as a source of win32 API information. Tests verify our implementation of the API, and make sure no regressions sneak into the code. -- James Hawkins
Re: Invisible fonts - unimplemented SPI_GETFONTSMOOTHINGTYPE
On Mon, 9 Jan 2006, Ron Jensen wrote: Here you go: http://www.cendio.se/~peter/tmp/MFC_GDI_PLUS.exe. Indeed this is fixed in CVS HEAD if you set the windows version to win2k. I can see the text output on MFC_GDI_PLUS.exe I pulled a CVS update about 8 hours ago, I can not see the text output in the demo program. Thanks for confirming my result. I tried Debian myself yesterday, with the same result. Regards, -- Peter Åstrand ThinLinc Chief Developer Cendio www.cendio.se Teknikringen 3 583 30 LinköpingPhone: +46-13-21 46 00
Re: Please read: Wine(HQ) needs a reorganization (AppDB, Bugzilla, etc.)
On Tue, 2006-01-10 at 01:55 +1030, n0dalus wrote: > On 1/10/06, S. Schauenburg <[EMAIL PROTECTED]> wrote: > > 2. Create a Wine forum. This solves the problem of users asking the > > same questions over and over again. Here also the "comments" of the > > AppDB could be centralized (because most of them aren't really > > comments) > > > > 3. With a forum in place, the user-mailing list could be dropped and > > maybe also even the devel-mailing list. > > I think a forum is a good idea, but the lists are invaluable. Please > don't remove the lists. I think you'll find many developers prefer > mailing lists anyway, as they can use their own mail clients and > setups and have the posts delivered to them instead of having to go to > some forum. Forums are absolutely a good idea. I can't tell you how many Wine-related posts I find on places like the Ubuntu forums, Linux-gamers, and even Something Awful's Serious Hardware/Software Crap forum. The reason is the same reason I post to these forums - they're far more usable, well-sorted, and accessable than a mailing list. I brought this up about a year ago when I pointed out that the whole reason websites with forums such as Frankscorner had popped up was because we weren't supplying forums at winehq, but nothing ever happened because of it as we assumed that fixing the AppDB would take care of that problem. It hasn't - there's still a lot to say about Wine, and it ain't happening there. Thanks, Scott Ritchie Thanks, Scott Ritchie
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.)
S. Schauenburg wrote: On IRC we started a chat on #WineHQ and discussed how to improve Wine. There were comments made and I wanted to summarize them and ask for your opinion. My comments: * It would be nice to have a checkbox: [x] "installs and works with Wine and a fresh ~/.wine" This is the most valuable kind of application for regression testing, and the target Wine should aim for. Apps that require copying windows dlls into ~/.wine and tweaking the configuration are prone to breaking, and the breakage tells us little about Wine regressions, especially as it's not always recorded which set of native dlls/configuration the app worked with. Secondly encouraging users to use windows dlls reduces the chances that they will find and report bugs with the Wine dlls, or that they will figure out that their application works without those dlls. * Minor problems with the app screenshots The screenshots screen (eg. [1]) has too many boxes and requires too many clicks to see a screenshot. IMO, it would be a little cleaner to just show the first screenshot here, and have a [<>] link or quick index. Other than that, the App DB looks great, and it's great work :) Mike [1] http://appdb.winehq.org/screenshots.php?appId=1567&versionId=
Re: Starter projects for new Wine contributors?
On 1/9/06, Dan Kegel <[EMAIL PROTECTED]> wrote: > Hi all! > I'm looking for suggestions for starter projects for > new contributors that would take something like a week to do, > and wouldn't require much knowledge of Wine ahead of time. Tests! Pretty much any level of C programmer (even me!) could whip out a test for any Win32 API they care about and provide something useful within a few minutes to an hour. I'm still mostly lurking but I might have a few tests to post in the future. It's just the easiest thing to do to get developers to look at problems I'm running into but don't quite know how to fix.Once I make a test that a more seasoned wine developer can use to accelerate their work, it's more likely they'll fix it (and keep it that way). http://www.winehq.org/site/docs/winedev-guide/testing -Al Tobey > > http://wiki.winehq.org/TodoList is the place we've gathered > that stuff, but nothing there really grabs me. > I suppose the tasks > http://wiki.winehq.org/CrossCallsWtoA > http://wiki.winehq.org/ConstifyData > http://wiki.winehq.org/SpecDiscrepencies > might qualify. Do they still need doing? > > http://winehq.org/site/fun_projects has some cool stuff > on it, particularly the idea of using Mono's libgdiplus > to implement gdi+ in Wine. (That's probably more than > a week's worth of work, though.) > > http://wiki.winehq.org/SummerOfCode has very cool > stuff in it, but that's all about 100x times harder than what I'm looking for. > > And then there's riched20. It's missing quite a few > little features; see the 11 open bugs here: > http://bugs.winehq.org/buglist.cgi?product=Wine&component=wine-richedit&bug_status=UNCONFIRMED&bug_status=NEW > Might some of those be doable in a couple days? > - Dan > > -- > Wine for Windows ISVs: http://kegel.com/wine/isv > > >
Re: Starter projects for new Wine contributors?
On Mon, 2006-01-09 at 16:36 -0800, Dan Kegel wrote: > http://wiki.winehq.org/TodoList is the place we've gathered > that stuff, but nothing there really grabs me. > I suppose the tasks > http://wiki.winehq.org/CrossCallsWtoA > http://wiki.winehq.org/ConstifyData > http://wiki.winehq.org/SpecDiscrepencies > might qualify. Do they still need doing? Absolutely. It would be great if we can finally get them over with. Not so sure about ConstifyData, but there we either need to get rid of it if nothing is left to do, or provide a comprehensive list of what is to be done like we do in the other cases, so we have a better feel of the scope and magnitude of the task. > http://winehq.org/site/fun_projects has some cool stuff > on it, particularly the idea of using Mono's libgdiplus > to implement gdi+ in Wine. (That's probably more than > a week's worth of work, though.) This should really be moved to the Wiki :). > And then there's riched20. It's missing quite a few > little features; see the 11 open bugs here: > http://bugs.winehq.org/buglist.cgi?product=Wine&component=wine-richedit&bug_status=UNCONFIRMED&bug_status=NEW > Might some of those be doable in a couple days? Yes, I think so. From past experience, once you get past the first few days of understanding what is going on, you can fix/implement a lot of these little features. -- Dimi Paun <[EMAIL PROTECTED]> Lattica, Inc.
Re: Invisible fonts - unimplemented SPI_GETFONTSMOOTHINGTYPE
On Mon, 2006-01-09 at 10:36 +0100, Peter Åstrand wrote: > On Mon, 9 Jan 2006, Vik Kumar wrote: > > Here you go: http://www.cendio.se/~peter/tmp/MFC_GDI_PLUS.exe. > > > Indeed this is fixed in CVS HEAD if you set the windows version to > > win2k. I can see the text output on MFC_GDI_PLUS.exe I pulled a CVS update about 8 hours ago, I can not see the text output in the demo program. > Strange, I wonder what's different with my environment: > > * Which version of gdiplus.dll are you using? I'm using 5.1.3097.0. The one from dll-files, like Vik. 5.1.3102.1360 > * Which OS are you running? I've tested Wine on both Fedora Core 4 and > RedHat 9. Debian Etch > * Do you get this error message as well?: > > fixme:win:EnumDisplayDevicesW ((null),0,0x4075f65c,0x), stub! > fixme:dciman:DCICreatePrimary 0x320 0x418511fc With W2K the colored lines are drawn, no text: [EMAIL PROTECTED]:~$ wine MFC_GDI_PLUS.exe fixme:win:EnumDisplayDevicesW ((null),0,0x7fc4f65c,0x), stub! fixme:dciman:DCICreatePrimary 0x320 0x7e6211fc If I set to Windows98, there are no colored lines, either: [EMAIL PROTECTED]:~$ wine MFC_GDI_PLUS.exe err:dc:CreateDCW no device found for L".\\DISPLAY1" Ron Jensen
A modest proposal
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.
Starter projects for new Wine contributors?
Hi all! I'm looking for suggestions for starter projects for new contributors that would take something like a week to do, and wouldn't require much knowledge of Wine ahead of time. http://wiki.winehq.org/TodoList is the place we've gathered that stuff, but nothing there really grabs me. I suppose the tasks http://wiki.winehq.org/CrossCallsWtoA http://wiki.winehq.org/ConstifyData http://wiki.winehq.org/SpecDiscrepencies might qualify. Do they still need doing? http://winehq.org/site/fun_projects has some cool stuff on it, particularly the idea of using Mono's libgdiplus to implement gdi+ in Wine. (That's probably more than a week's worth of work, though.) http://wiki.winehq.org/SummerOfCode has very cool stuff in it, but that's all about 100x times harder than what I'm looking for. And then there's riched20. It's missing quite a few little features; see the 11 open bugs here: http://bugs.winehq.org/buglist.cgi?product=Wine&component=wine-richedit&bug_status=UNCONFIRMED&bug_status=NEW Might some of those be doable in a couple days? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: Please read: Wine(HQ) needs a reorganization (AppDB, Bugzilla, etc.)
n0dalus wrote: > Trac looks interesting, but the demo there seems a bit messy. The demo has write access for anonymous users, so yes. Look at the Trac project's own ticket system instead. Perhaps try one of these URLs. http://projects.edgewall.com/trac/report http://projects.edgewall.com/trac/search http://projects.edgewall.com/trac/browser/trunk http://projects.edgewall.com/trac/log/trunk Or a couple of the weirder ones: automatic timeline - http://projects.edgewall.com/trac/timeline?daysback=14&milestone=on&ticket=on&changeset=on automatic changelog generation - http://projects.edgewall.com/trac/log/trunk?format=changelog I'll agree any day that Trac has less features than Bugzilla. I just think that extending Trac with any features needed is a lot easier than making Bugzilla remotely usable :-). > Unfortunately it uses SQLite, which may not be able to effectively > handle the huge needs of wine's bug tracking. It says they will try > implement support for other sql servers in later versions, but > currently it doesn't. Bull... There are commercial products out there that handle millions of records of data per hour running on SQLite. I can't quite imagine what you're afraid of.
RE: daily winetest generation
Paul Millar wrote: > The problem above (at the beginning of this year) was with a > missing GUID in the compiler, which is now fixed. Could you tell me what GUID it was. I'm currently in the process of trying to get compilation of DLLs working again with MSVC and the winapi tools and noticed a specific issue with GUIDs. Maybe I can learn a bit here. For instance the GUIDs IID_IAVIStreaming and CLSID_AVIFile used in avifil32.dll are put by wine in the uuid.lib/dll file but the two MS SDKs I tried do not seem to provide these exports in either uuid.lib nor vfw32.lib(avifil32.dll). Rolf Kalbermatter
Re: Regression in Icewind Dale II
On 1/9/06, Mike McCormack <[EMAIL PROTECTED]> wrote: James Trotter wrote:> I just got the latest cvs and compiled it. The game fails with the> output as in the first mail I sent.Please try a regression analysis, as described by: http://winehq.org/docs/en/winedev-guide.html#AEN1344Mike Alright, I've found the offending patch: http://www.winehq.org/pipermail/wine-cvs/2005-July/016971.html After this patch is applied Icewind Dale II crashes and produces the debug output as in the first mail in this thread. That output doesn't appear to be particularly useful. Is there any other output that might be helpful? Thanks, James
Re: Please read: Wine(HQ) needs a reorganization (AppDB, Bugzilla, etc.)
On 1/9/06, S. Schauenburg <[EMAIL PROTECTED]> wrote: > By the way, I hate the AppDB comments/summarize where people put a > error log or something into the comment and/or the summary (under what > doesn't work) This clearly states that people aren't using > bugzilla. So if we (Wine) would be a bit more user-friendly I guess it > would get the ball rolling. Yes, this is why I have stated in the very beginning of the War3 howto to report problems to bugzilla. All the logs were filling up the comments block making very long, and I'd say that none of them have ever been seriously looked at. With the test results section, they are starting to put it there now and only the appdb maintainers see anyways. If people filed reports in bugzilla, more people would see it, and we can actually interact with the user easier.
Re: Please read: Wine(HQ) needs a reorganization (AppDB, Bugzilla, etc.)
On Mon, Jan 09, 2006 at 06:48:26PM +0100, 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. You are not a user of bugzilla, at least for WINE. The number of new bugs is definitely not an issue, we get more than enough good bugreports. Ciao, Marcus
Re: shlwapi: Finnish translation (resent)
"Ge van Geldorp" <[EMAIL PROTECTED]> writes: > Previously sent > http://www.winehq.org/pipermail/wine-patches/2005-December/023112.html > > (shlwapi_Fi.rc sent as attachment instead of inline in the hope it won't get > mangled then) Could you please send it as a proper patch? It makes things a lot easier for me (you can still send the whole patch as an attachment if you think it will get mangled). -- Alexandre Julliard [EMAIL PROTECTED]
Re: cabinet: Implement Extract on top of FDI
James Hawkins <[EMAIL PROTECTED]> writes: > @@ -30,6 +30,7 @@ > #define NO_SHLWAPI_REG > #include "shlwapi.h" > #undef NO_SHLWAPI_REG > +#include "msvcrt/fcntl.h" You shouldn't use msvcrt headers if you are not importing msvcrt, this will cause trouble. Simply copy the definitions you need, like we already do for S_IREAD/IWRITE. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Please read: Wine(HQ) needs a reorganization (AppDB, Bugzilla, etc.)
On 1/9/06, Jonathan Ernst <[EMAIL PROTECTED]> wrote: > > I don't know why you are thinking maintainers should be developers only. > Maintainers are quite active on the AppDB. And new features (like send > test result) are making the job of the maintainers even more easy. > I have doubts about the user submitted test results. I think its discouraging proper bug reporting. Like the current test on the diablo 2 node: http://appdb.winehq.org/appview.php?versionId=49 I really think there's something wrong with his wine setup. What's worse is there is no way to find who sent it. It would be better for people to submit their test problems to bugzilla, and have the bug links added to the db entry. (PS, I must have been removed as maintainer in the db by mistake, because it doesn't show any maintained under my account anymore)
Re: Please read: Wine(HQ) needs a reorganization (AppDB, Bugzilla, etc.)
We use trac where I work and users that would normally be unable to use bugzilla appear to have success with the simpler interface of trac. Chris > > > >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. > >
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.)
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: Invisible fonts - unimplemented SPI_GETFONTSMOOTHINGTYPE
On Tue, 10 Jan 2006, Vik Kumar wrote: * Which version of gdiplus.dll are you using? I'm using 5.1.3097.0. *Mine's apparently 5.1.3102.1360* I've tried this version as well now, no difference. fixme:win:EnumDisplayDevicesW ((null),0,0x4075f65c,0x), stub! fixme:dciman:DCICreatePrimary 0x320 0x418511fc I do. And I also get the same errors as yours when I use win98. I guess it's the gdiplus version I got mine off of dll-files. Apparently not. Perhaps it depends on which fonts you have available. -- Peter \xC5strandThinLinc Chief Developer Cendio www.cendio.se Teknikringen 3 583 30 Link\xF6pingPhone: +46-13-21 46 00
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: Invisible fonts - unimplemented SPI_GETFONTSMOOTHINGTYPE
Hi, > * Which version of gdiplus.dll are you using? I'm using 5.1.3097.0. *Mine's apparently 5.1.3102.1360* > * Which OS are you running? I've tested Wine on both Fedora Core 4 and > RedHat 9. Gentoo > * Do you get this error message as well?: > > fixme:win:EnumDisplayDevicesW ((null),0,0x4075f65c,0x), stub! > fixme:dciman:DCICreatePrimary 0x320 0x418511fc I do. And I also get the same errors as yours when I use win98. I guess it's the gdiplus version I got mine off of dll-files. Cheers Vik
Re: winecfg: Problems with audio configuration
On Mon, 2006-01-02 at 19:23 -0700, Vitaliy Margolen wrote: > Monday, January 2, 2006, 6:18:11 PM, Jesse Allen wrote: > > On 1/2/06, Jesse Allen <[EMAIL PROTECTED]> wrote: > >> I'm the one having complete lockups with wineoss.drv. I also have the > >> nforce2 sound chip (snd_intel8x0), but I use it as a secondary device. > >> I actually use cmi 8738 (snd_cmipci) for most everything. I will > >> disable snd_intel8x0 and switch back to wineoss.drv to see what > >> happens. > > > The problem is with snd_cmipci. Furthermore I get a gpf when > > rmmoding. So I have something else to go by now without resorting to > Yeah that's fun I've seen something like that crashing kernel 8-[ ] > > > the winecfg hard lockup. This is probably a kernel regression so I > > will track it down. You can ask the others having a lockup with the > > winecfg what sound drivers are loaded into the kernel too. > Yeah we should at least print to the console and flush buffers before > opening next driver. This will give as at least some info if we get hard > lockup. > > > snd_intel8x0 seems fine, so actually, you are ok too then. > Oh good > > Vitaliy Externally to Wine I came across a similar "page fault" issue... that turned out to be an alsa versioning issue by appearance using Kernel 2.6.15rc7 with "alsa-driver" package for SourceMage (source build from alsa-driver-1.0.10.tar.bz2 archive) I kept getting a repetitive "free_hot_cold_page()" call message in the kernel messages queue I simply removed the alsa-driver package and updated my kernel build with a clean build enabling intel8x0+intel8x0m drivers from the kernel instead... maybe some alsa internal changes are being reflected to outside the kernel, Im not totally sure if this is relevant Hopefully there is something there and not just some random bug Send instant messages to your online friends http://au.messenger.yahoo.com
Re: Please read: Wine(HQ) needs a reorganization (AppDB, Bugzilla, etc.)
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 example) keyword and wine version. With the bug submission page I wouldn't know what to fill in at "Component" and "Priority". And there's no real place to 'attach' a error report/log to (for example a +seh debug channel) By the way, I hate the AppDB comments/summarize where people put a error log or something into the comment and/or the summary (under what doesn't work) This clearly states that people aren't using bugzilla. So if we (Wine) would be a bit more user-friendly I guess it would get the ball rolling. Offtopic: I myself would volunteer to be a moderator on the forum. On 1/9/06, James Hawkins <[EMAIL PROTECTED]> wrote: > On 1/9/06, S. Schauenburg <[EMAIL PROTECTED]> wrote: > > > > Back onto the main topic. Remarks made: > > 1. AppDB needs a revamp. Maybe drop the maintainers (those things just > > need to be set by developers only). Just have a look at the activity > > of all the maintainers in the last year. **Read on for suggestions to > > drop the AppDB. > > > > What is the point of dropping maintainers? Activity is always > appreciated, but for most apps it doesn't take much. It either works > out of the box, or the status doesn't really change much over the > releases. Simply putting up a HOWTO is the most some maintainers need > to do for an app. The maintainer doesn't need to report back to the > appdb every release to say no regressions have occurred. > > > 2. Create a Wine forum. This solves the problem of users asking the > > same questions over and over again. Here also the "comments" of the > > AppDB could be centralized (because most of them aren't really > > comments) > > > > The AppDB comments need to stay where they are. Each comment is > specific to a particular app and only shows up on that app's page. We > already have wine-users, bugzilla, and the appdb for users to > communicate about wine. Adding a forum would spread ourselves too > thin. > > > 3. With a forum in place, the user-mailing list could be dropped and > > maybe also even the devel-mailing list. > > > > hehe that'll never happen. > > > 4. Create a Wine Wiki, instead of the AppDB. Only certain developers > > (or maybe users) can set/edit certain pages. Then also howto's could > > be inserted here. > > > > wiki.winehq.org > > > 5. It's too difficult for users to add a bugreport. Either create a > > small program/app which does it for the user (like "Submit this > > bugreport" *click*) and you're done. The other option is to create a > > simplified method for searching and inserting a bug report, because > > from a users view, there are too many options. (and probably the user > > wouldn't even know what to click on. Don't forget to give the users > > the option to 'add' a file with certain 'debug channels' (which ones? > > only +seh?) > > > > I don't see how a program would make submitting bugs easier. I'm > guessing you're thinking about a crash reporter, which would report a > bug with the crash info/backtrace etc, but that would just flood the > bugzilla with duplicate crash-only bugs. I'm curious as to what > user's find hard about submitting bug reports. If you know, please > post the issues here. > > > 6. Users need to know that if they submit a bug report (when it's > > simplified) that it actually HELPS you, the developers. So it's "Help > > us, help you". > > > > I agree. > > -- > James Hawkins >
Re: Please read: Wine(HQ) needs a reorganization (AppDB, Bugzilla, etc.)
On 1/9/06, S. Schauenburg <[EMAIL PROTECTED]> wrote: > On IRC we started a chat on #WineHQ and discussed how to improve Wine. > There were comments made and I wanted to summarize them and ask for > your opinion. > By the way: Who is in charge of WineHQ, AppDB etc.? A list of people > who are responsible for that would be nice (it could be I've missed > that one though). > > Back onto the main topic. Remarks made: > 1. AppDB needs a revamp. Maybe drop the maintainers (those things just > need to be set by developers only). Just have a look at the activity > of all the maintainers in the last year. **Read on for suggestions to > drop the AppDB. I have mail from the many thousands of changes to the appdb that have occurred in the last few months, I even deleted some 10k+ of them just a few weeks ago. Its more active now than it has ever been :-) Chris
Re: Please read: Wine(HQ) needs a reorganization (AppDB, Bugzilla, etc.)
On 1/10/06, S. Schauenburg <[EMAIL PROTECTED]> wrote: > On IRC we started a chat on #WineHQ and discussed how to improve Wine. > There were comments made and I wanted to summarize them and ask for > your opinion. > By the way: Who is in charge of WineHQ, AppDB etc.? A list of people > who are responsible for that would be nice (it could be I've missed > that one though). > > Back onto the main topic. Remarks made: > 1. AppDB needs a revamp. Maybe drop the maintainers (those things just > need to be set by developers only). Just have a look at the activity > of all the maintainers in the last year. **Read on for suggestions to > drop the AppDB. > > 2. Create a Wine forum. This solves the problem of users asking the > same questions over and over again. Here also the "comments" of the > AppDB could be centralized (because most of them aren't really > comments) > > 3. With a forum in place, the user-mailing list could be dropped and > maybe also even the devel-mailing list. I think a forum is a good idea, but the lists are invaluable. Please don't remove the lists. I think you'll find many developers prefer mailing lists anyway, as they can use their own mail clients and setups and have the posts delivered to them instead of having to go to some forum. > > 4. Create a Wine Wiki, instead of the AppDB. Only certain developers > (or maybe users) can set/edit certain pages. Then also howto's could > be inserted here. > > 5. It's too difficult for users to add a bugreport. Either create a > small program/app which does it for the user (like "Submit this > bugreport" *click*) and you're done. The other option is to create a > simplified method for searching and inserting a bug report, because > from a users view, there are too many options. (and probably the user > wouldn't even know what to click on. Don't forget to give the users > the option to 'add' a file with certain 'debug channels' (which ones? > only +seh?) Bugzilla is not hard to use as it is, maybe we just need to have more tutorials and info, and a link to it when an app crashes. > > 6. Users need to know that if they submit a bug report (when it's > simplified) that it actually HELPS you, the developers. So it's "Help > us, help you". > > What's your opinion about this? In my eyes, it would greatly improve > the user input/feedback and would even make Wine more popular. > Other than those things, most of the ideas here I agree with to some extent. Just my $0.015, n0dalus.
Re: Implementing SYS-files for Wine
--- "Anton Litvinov (wine_user)" <[EMAIL PROTECTED]>
wrote:
> I want to run a proprietary program which does the
> following things:
>
> ...
> fh =
>
CreateFileA("C:\WINDOWS\system32\DRIVERS\BIOSMAP.SYS",
> ...);
> ...
> dh = CreateFileA("\\.\BIOSMAP", ...);
> ...
> r = DeviceIoControl(dh, 0x1000, ...);
> ...
>
>
> On recieving 0x1000 code BIOSMAP maps BIOS
> content
> (brand, creation date, etc) to some area and returns
> address of one null-terminated string from it to
> main program.
>
> Is there a way to re-implement a SYS-file (so that
> main program
> would run w/o any change) like it's done with some
> VXD's in Wine-tree?
I wish :~(.
> Can I get some examples?
You cannot use a VxD since they don't get considered
for ioctl codes above 0x.
I made an example that uses a Linux kernel module that
does the equivalent of USBSCAN.SYS. Basically you hack
away at CreateFile() in KERNEL32.DLL to get it to
open() /dev/... (a device node hooked up to the kernel
module) and then use wine_server_register_fd() (or
something like that) to register the file descriptor.
Then you need to change NtDeviceIoControl() in
NTDLL.DLL so that it actually does an ioctl() call to
the kernel module. You'll have to use
wine_server_handle_to_fd() to get the file descriptor
for the first parameter of the ioctl(), and then
wine_server_release_handle() after, and you'll have to
make a custom struct that gets passed around as the
third parameter in the ioctl(). Of course, the hardest
part is writing the kernel module...
I'll probably put up my example on the net in a week
or so.
There is also some people working on a user-space
device-driver system for wine (an out-of-process
server emulating NTOSKRNL.EXE), they've gotten some
results, but they've been quite mysterious and silent
about it...
>
> Hope to get your answer,
> Anton Litvinov
>
>
>
__
Yahoo! DSL Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com
Re: Please read: Wine(HQ) needs a reorganization (AppDB, Bugzilla, etc.)
On 1/9/06, S. Schauenburg <[EMAIL PROTECTED]> wrote: > > Back onto the main topic. Remarks made: > 1. AppDB needs a revamp. Maybe drop the maintainers (those things just > need to be set by developers only). Just have a look at the activity > of all the maintainers in the last year. **Read on for suggestions to > drop the AppDB. > What is the point of dropping maintainers? Activity is always appreciated, but for most apps it doesn't take much. It either works out of the box, or the status doesn't really change much over the releases. Simply putting up a HOWTO is the most some maintainers need to do for an app. The maintainer doesn't need to report back to the appdb every release to say no regressions have occurred. > 2. Create a Wine forum. This solves the problem of users asking the > same questions over and over again. Here also the "comments" of the > AppDB could be centralized (because most of them aren't really > comments) > The AppDB comments need to stay where they are. Each comment is specific to a particular app and only shows up on that app's page. We already have wine-users, bugzilla, and the appdb for users to communicate about wine. Adding a forum would spread ourselves too thin. > 3. With a forum in place, the user-mailing list could be dropped and > maybe also even the devel-mailing list. > hehe that'll never happen. > 4. Create a Wine Wiki, instead of the AppDB. Only certain developers > (or maybe users) can set/edit certain pages. Then also howto's could > be inserted here. > wiki.winehq.org > 5. It's too difficult for users to add a bugreport. Either create a > small program/app which does it for the user (like "Submit this > bugreport" *click*) and you're done. The other option is to create a > simplified method for searching and inserting a bug report, because > from a users view, there are too many options. (and probably the user > wouldn't even know what to click on. Don't forget to give the users > the option to 'add' a file with certain 'debug channels' (which ones? > only +seh?) > I don't see how a program would make submitting bugs easier. I'm guessing you're thinking about a crash reporter, which would report a bug with the crash info/backtrace etc, but that would just flood the bugzilla with duplicate crash-only bugs. I'm curious as to what user's find hard about submitting bug reports. If you know, please post the issues here. > 6. Users need to know that if they submit a bug report (when it's > simplified) that it actually HELPS you, the developers. So it's "Help > us, help you". > I agree. -- James Hawkins
Re: Please read: Wine(HQ) needs a reorganization (AppDB, Bugzilla, etc.)
Le lundi 09 janvier 2006 à 15:47 +0100, S. Schauenburg a écrit : > On IRC we started a chat on #WineHQ and discussed how to improve Wine. > There were comments made and I wanted to summarize them and ask for > your opinion. > By the way: Who is in charge of WineHQ, AppDB etc.? A list of people > who are responsible for that would be nice (it could be I've missed > that one though). > > Back onto the main topic. Remarks made: > 1. AppDB needs a revamp. Maybe drop the maintainers (those things just > need to be set by developers only). Just have a look at the activity > of all the maintainers in the last year. **Read on for suggestions to > drop the AppDB. I don't know why you are thinking maintainers should be developers only. Maintainers are quite active on the AppDB. And new features (like send test result) are making the job of the maintainers even more easy. > > 2. Create a Wine forum. This solves the problem of users asking the > same questions over and over again. Here also the "comments" of the > AppDB could be centralized (because most of them aren't really > comments) > 3. With a forum in place, the user-mailing list could be dropped and > maybe also even the devel-mailing list. A mailing list has many advantages over a forum (readable from any nntp client, etc.). > > 4. Create a Wine Wiki, instead of the AppDB. Only certain developers > (or maybe users) can set/edit certain pages. Then also howto's could > be inserted here. There are already two Wine Wiki: http://wiki.winehq.org (official, developper centric) http://wine-wiki.org/ (more user oriented) As of dropping the AppDB, I don't see the point ? The AppDB might be improved but it's a lot more efficient than a simple wiki to track applications. You can track the bugs linked to a particular application, get an e-mail each time someone adds something to an application of interest, ... > > 5. It's too difficult for users to add a bugreport. Either create a > small program/app which does it for the user (like "Submit this > bugreport" *click*) and you're done. The other option is to create a > simplified method for searching and inserting a bug report, because > from a users view, there are too many options. (and probably the user > wouldn't even know what to click on. Don't forget to give the users > the option to 'add' a file with certain 'debug channels' (which ones? > only +seh?) The bug reporting tool used by Wine is the same used by most Opensource projects (bugzilla). I don't think this tool is too much complicated but if it is, it must be fixed upstream. Dan Kegel has a nice page on how to do QA for Wine though: http://www.kegel.com/wine/qa/ The integration of this page in WineHQ or in the Wiki has been discussed on this mailing list. Jonathan signature.asc Description: Ceci est une partie de message numériquement signée
Please read: Wine(HQ) needs a reorganization (AppDB, Bugzilla, etc.)
On IRC we started a chat on #WineHQ and discussed how to improve Wine. There were comments made and I wanted to summarize them and ask for your opinion. By the way: Who is in charge of WineHQ, AppDB etc.? A list of people who are responsible for that would be nice (it could be I've missed that one though). Back onto the main topic. Remarks made: 1. AppDB needs a revamp. Maybe drop the maintainers (those things just need to be set by developers only). Just have a look at the activity of all the maintainers in the last year. **Read on for suggestions to drop the AppDB. 2. Create a Wine forum. This solves the problem of users asking the same questions over and over again. Here also the "comments" of the AppDB could be centralized (because most of them aren't really comments) 3. With a forum in place, the user-mailing list could be dropped and maybe also even the devel-mailing list. 4. Create a Wine Wiki, instead of the AppDB. Only certain developers (or maybe users) can set/edit certain pages. Then also howto's could be inserted here. 5. It's too difficult for users to add a bugreport. Either create a small program/app which does it for the user (like "Submit this bugreport" *click*) and you're done. The other option is to create a simplified method for searching and inserting a bug report, because from a users view, there are too many options. (and probably the user wouldn't even know what to click on. Don't forget to give the users the option to 'add' a file with certain 'debug channels' (which ones? only +seh?) 6. Users need to know that if they submit a bug report (when it's simplified) that it actually HELPS you, the developers. So it's "Help us, help you". What's your opinion about this? In my eyes, it would greatly improve the user input/feedback and would even make Wine more popular. Regards, SWAT
Re: user: Fix dropdown combo creation when there is no space for an edit control
Hi, Sorry, I meant: ChangeLog: Fixed dropdown combo creation when there is NO space for an edit control. -- Ph.
Implementing SYS-files for Wine
I want to run a proprietary program which does the following things:
...
fh = CreateFileA("C:\WINDOWS\system32\DRIVERS\BIOSMAP.SYS", ...);
...
dh = CreateFileA("\\.\BIOSMAP", ...);
...
r = DeviceIoControl(dh, 0x1000, ...);
...
On recieving 0x1000 code BIOSMAP maps BIOS content
(brand, creation date, etc) to some area and returns
address of one null-terminated string from it to main program.
Is there a way to re-implement a SYS-file (so that main program
would run w/o any change) like it's done with some VXD's in Wine-tree?
Can I get some examples?
Hope to get your answer,
Anton Litvinov
Re: Invisible fonts - unimplemented SPI_GETFONTSMOOTHINGTYPE
On Mon, 9 Jan 2006, Vik Kumar wrote: Here you go: http://www.cendio.se/~peter/tmp/MFC_GDI_PLUS.exe. Indeed this is fixed in CVS HEAD if you set the windows version to win2k. I can see the text output on MFC_GDI_PLUS.exe Strange, I wonder what's different with my environment: * Which version of gdiplus.dll are you using? I'm using 5.1.3097.0. * Which OS are you running? I've tested Wine on both Fedora Core 4 and RedHat 9. * Do you get this error message as well?: fixme:win:EnumDisplayDevicesW ((null),0,0x4075f65c,0x), stub! fixme:dciman:DCICreatePrimary 0x320 0x418511fc Regards, -- Peter Åstrand ThinLinc Chief Developer Cendio www.cendio.se Teknikringen 3 583 30 LinköpingPhone: +46-13-21 46 00
Re: shell32: fix folder icon index when read from registry
"Martin Fuchs" <[EMAIL PROTECTED]> wrote: Any reason you using int* instead of LPINT? What's better when using LPINT? This are all internal functions and not exported from shell32.dll. 'INT' has the same size on all platforms and with all compilers in both win32 and win64, while 'int' is platform/compiler dependent and is 32-bit or 64-bit entity depending on the platform. -- Dmitry.
