May 2006 - Wine-Devel - list.winehq.org

Re: wineconsole: Store the font as a DWORD_PTR.

by Detlef Riekenberg

Am Mittwoch, den 31.05.2006, 16:28 +0900 schrieb Mike McCormack: > index 169f4e1..73a0987 100644 > --- a/programs/wineconsole/dialog.c > +++ b/programs/wineconsole/dialog.c > + return GetWindowLongPtr(hWnd, 0); > + HFONT hFont = (HFONT)GetWindowLongPtr(hWnd, 0L); Are 0 and 0L always the same ? (32bit and 64bit) -- By By ... ... Detlef

May 31, 2006

Re: crypt32: implement CryptBinaryToStringA and CryptStringToBinaryA

by Detlef Riekenberg

Hi Juan Lang. > ChangeLog: implement CryptBinaryToStringA and CryptStringToBinaryA based > on Kai Blin's base64 encoder/decoder The Functions are not Present in every crypt_32.dll. The test will crash on win9x. (The Results from GetProcAddress are not tested) -- By By ... ... Detlef

May 31, 2006

Re: How are we doing?

by Detlef Riekenberg

Am Dienstag, den 30.05.2006, 00:17 +0100 schrieb Mike Hearn: Thanks a lot for starting this. As I'm connected with wine about a Year now, I give my comments / feeling here. (It's large, but i'm unable to Split ...) > Questions to consider: > > * Is Wine improving or is the regression rate matching the improvement > rate? Depends on the Area, and how the Wine improvements are validated by regression Tests. We have hundreds of Tests failing on various Windows Systems, and this is really bad. Many reasons for the regression rate is the fact, that we have no regression tests at all for many Functions. > * Are we producing a quality product, from the perspective of > non-technical end users? (I appreciate this isn't a goal for everyone) It seems, that we produce a quality product, when an a widely used, previously untested Application works 'out of the box', but IMHO, we fail, because we have lot's of bugs (and regressions: missing tests) that stay unfixed for a long time. Can we get an overview with "new bugs" / "still existing bugs" / "closed bugs" per month from bugzilla (without duplicates)? > * Are we turning away potential developers for any reason? Could we do > more to attract new hackers? I was starting with wine, because i want to get my Lexmark X5130 working on Linux and my Idea was: Use the Windows-Driver with wine. When I started development with winspool, we had only 2 regression-tests. It was very hard to get the first Patch accepted: I needed to learn, how windows works in this area, how CVS works and what was expected from a fine Patch. I read a lot of Documentation (wine-dev-guide, wine-wiki.org, winehq.org, MSDN and the Wine-source), got a lot of hints on wine-devel and finally my first Patch was accepted. (Great to be a Member of such a large Project.) During the Time, things changed and I get confused more and more times about "special Developers" and "other Developers", as well as "special Patches" and "other Patches". (It's also Possible, that i did not see the big differences before). I aware of the fact, that some Developer earn there Money when working on Wine, working on a special project with a Company behind them (wine on macos / Codeweavers as example) or others stay already a long time with Wine and all of the resulting special Patches are handled a bit different. Some Examples from my point of View: EnumMonitors (Test + Implementation) needed a long Time: - I created, tested and send a Patch - No commit, and no comments for my Patch for almost two weeks - I ask for comments and got one Hint from one Person. - Updating, testing and resending the Patch - next week waiting again without a reaction. - Asking for comments: One Hint from a different Person - loop again > 5 times I was frustrated that it need so many loops from the first Patch for the tests upto the commit of the last Patch for the Implementation due to the fact, that I got only one Hint after every Update. One Hint was changing NO_ERROR to ERROR_SUCCESS. Another Example was to split the ANSI-Implementation and the UNICODE-Implementation (together ~11kb)in two Patches. Here a Code-Review that I did: 1: http://www.winehq.org/pipermail/wine-devel/2006-February/045163.html 2: http://www.winehq.org/pipermail/wine-devel/2006-March/045278.html A Test from Stefan Dösinger: http://www.winehq.org/pipermail/wine-cvs/2006-April/022105.html I have no Idea about d3d, but the test-style is very Strange. Various tests in this Style (I created the Line-Wrap) : + /* Check the results */ + if( !comparefloat(out[0].x, 128.0 ) || + !comparefloat(out[0].y, 128.0 ) || + !comparefloat(out[0].z, 0.0 ) || + !comparefloat(out[0].rhw, 1.0 )) + { + todo_wine ok(FALSE, "Output 0 vertex is (%f , %f , %f , %f)\n", out[0].x, out[0].y, out[0].z, out[0].rhw); + } + else + { + todo_wine ok(TRUE, "Output 0 vertex is (%f , %f , %f , %f)\n", out[0].x, out[0].y, out[0].z, out[0].rhw); + } + I wanted to comment the patch, but it was already in the Tree. My only Idea is: "special Patch": @codeweavers.com Big Patches went into the tree: Juan Lang: crypt32: Implement CryptBinaryToStringA and CryptStringToBinaryA. When I saw the big Patch, i wanted to ask to split this in seperate Patches: 1x Header-Changes 2x Testcase (2 tested Functions -> 2 Patches) 2x Implementation ( 2 Functions) However, the Big patch was already in the Tree: http://www.winehq.org/pipermail/wine-cvs/2006-May/023291.html My only Idea is: "special Patch": SoC Problem with this Patch: Functions not Present every crypt32.dll Emmanuel Maillard: winecoreaudio: Initial Audio Driver for Mac OS X I saw the Patch and asked about the Project: Merge all sound-driver to "dlls/wineaudio.drv" Reaction: Resend a Day later after a comment from Alexandre and in the Tree the next commit-day: http://www.winehq.org/pipermail/wine-cvs/2006-May/023277.html This Patch needed a bunch of fixes, done by Alexandre another day later: http://www.winehq.org/pipermail/wine-cvs/2006-May/023295.html IMHO, every other Patch with a bunch of warnings will never pass. My Idea for this "special Patch" (wine-macos) Is the Project for a single "wineaudio.drv" dead? > * Are the projects fundamental processes serving us well? > * Any other thoughts for improvement? > In case it's not clear, I'm talking about the project as a community > adventure here rather than technical aspects of the codebase. - A Mentor for a new wine - developer, that tries to Guide the "new blood" a bit. (Vitaliy Margolen did a lot for me by commenting my Patches, when I started dev. for wine. Many Thanks!) - Merge the Coding Hints from wine-wiki.org, wiki.wine.org and wine-dev-guide - Wine Roadmap: Update the ToDo-List for 1.0 and Create a ToDo-List for post-1.0 - "Contributing to Wine" is really large and complex. I would suggest a small Welcome-Page that has: - Importand Headlines from the actual Page, - an invitation to join wine-devel and say Hello, I'm new on wine, - Link: "More Details for Developer" - Link: "More Details on Documentation and Localization" - Link: "More Details on Translations" - Link: "More Details on Application testing" - Link: "More Details on Artwork" - The Wine Party Found. The Links go to something that we have now in "Contributing to Wine" It's IMHO important, that the user does not need to scroll the Welcome-Page With the Welcome-Page and a Mentor, we should get more developer to wine. The other Side is the limited Bandwidth of Alexandre. For the Direct3D - Group, it's great, that they manage to test the Patches even if they sometimes fail (the double code-move) We need more Groups like this. The Group from Dan Kegel, wo worked on richedit, was great. It might help, that we state in the Patch, on which machines / OS the Patch was tested and which other Persons tested the Patch also. > * No clear roadmap to 1.0 - for 0.9 we had Dimis TODO list and it was > quite satisfying to see them go green as tasks were completed. I guess > we have a 1.0 TODO list too but I never see any updates to it :( Yep. > * A few random things I already got into arguments about (forums, libwine > api etc) :) - The number failures on Windows for our regression Tests must go down fast - We need more Regression tests - Maybe use parts of the SoC - Money, that Google give to the Project as Bounty for special Bugs (2398 OpenGL in a window or DSOUND-Buffer underrun as examples) or start a small "Wine Winter-of-Code" -- By By ... ... Detlef

May 31, 2006

Re: file timestamps in a git tree

by Michael Stefaniuc

Saulius Krasuckas wrote: > * On Wed, 31 May 2006, Marcus Meissner wrote: > >>* On Wed, May 31, 2006 at 12:55:02PM +0300, Saulius Krasuckas wrote: >> >>>$ git rebase master ugly_hack > > ... > >>>$ git checkout master >>>$ make >>>Makefile is older than Makefile.in configure, please rerun ./configure >>>make: *** [Makefile] Error 1 > > ... > >>>I thought git would reset all the file timestamps once I switch to >>>another (master) branch... Am I wrong? >> >>"Makefile" is not in git, so you need to run ./configure anyway? > > > Well, yes, but what is changed in the tree after I checkout master branch > back? If nothing changes, why make is complaining? Does configure change between your two branches? That would explain it. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

May 31, 2006

Quartz driver

by Emmanuel Maillard

Hi all, Quartz driver is up to date on Darwine CVS. Winemine is playable on both PPC and x86 but it look fine only on PPC, x86 driver suffer strange rendering bugs. See wiki for building the driver : http://wiki.opendarwin.org/ index.php/Darwine:quartzdrv I will update wiki soon with issues and todo for Quartz driver. Cheers Emmanuel

May 31, 2006

Re: How are we doing?

by Tony Lambregts

Mike Hearn wrote: > As the Summer Of Code begins and new blood joins us all at once, > I thought it'd be a good time to open a discussion on how we are doing as > a project. > > Questions to consider: > > * Is Wine improving or is the regression rate matching the improvement > rate? Since I have Administrated both the AppDB and Bugzilla for quite a while I would say that this is about even with regressions keeping pace with improvements. What seems to be improving is the rate at which the regressions are caught and fixed. Catching regressions early is critical to fixing them and the faster release cycle helps but only if the user upgrades in a timely fashion. Some programs have been Rock Solid for years (eg: SimCity 3000) while others are are not. Myst worked for years and then fell victim the Windows Management rewrite and I have just recently been able to run it again but it is still very unstable. Over All I am seeing a lot more activity in bugzilla [1] since we went to 0.9.0 as I am sure most of you are aware. Some may call it a flood but over all I think this has been a good thing. The real downside to this is that it takes a lot more of my time to go through each email and see if I can assist and that the proper bug links are in place. [1] 501 in Apr 2005 1492 in Apr 2006 610 in May 2005 1174 in May 2006 > > * Are we producing a quality product, from the perspective of > non-technical end users? (I appreciate this isn't a goal for everyone) > Going to winecfg has made the product more user friendly but we are still seem to be a long way away from "It Just Works" in a lot of cases. In the interm I believe the AppDB has helped a lot. I think that the work that we have put into it has paid off fairly well to a point. So far we have added: - Applications Maintantainers that can modify application entries on an App by App basis. - Notification emails so that people (Administrators, Maintainers and Monitors) kept up to date on changes to applications. - Bug links to track bugs affecting an application. - Test results to track how well an application runs on a Wine version. and help spot regressions - Lots of small improvements. Lots of thanks to Chris Morgan and Johnathan Ernst and everyone else that submited patches to get it to its current state. However there are a number of things that are needed still. - We need a general search page. - It would be nice to have the ability for people to have classes of rights so that they can add/change/delete certain fields IE: "Application Description" without having to become a maintainer or administrator. There is a todo list here as well. http://wiki.winehq.org/AppdbInfo If anyone has experience with PHP or wants to gain some, there is a real need for your help. - A newsgroup set up that works the same as bugs so that anyone can see the notifications generated by the AppDB. I asked Jeremy Newman for this before but I don't think that I explained the need for it very well. (trying again) - More Maintainers If you have an app that you run on a regular basis please consider becomeing a maintainer for that app. - More Administrators The Application Queue is not being processed in a timely fashion. For myself I am busy with my day job, working on upgrading bugzilla, and burnt out/frustrated trying to keep up with Application submitions (I am too soft hearted to reject some submittions that probably should be rejected). Keeping up with the Application Queue is a tough job (for me at least, at this time) and at this point just reviewing some of the submittions makes my head hurt. Alexander Nicolaysen Sørnes and KillerTux have picked up some of the slack but I think we could use some more help. This job is time consuming, tedious, thankless and does not come with a paycheck. It requires attention to detail and is a position of trust and responsability. On the plus side it does NOT require any programming skills. So... if this sounds like something you would like to do please send an email to appdb(a)winehq.org explaining why you you think you would be a good AppDB Administrator. (The guys in the white coats will be around ASAP) Thanks -- Tony Lambregts.

May 31, 2006

Re: Wine 1.0 Tasks

by Olaf Leidinger

> ... "make Windows developers take Wine seriously." What about "make offices take Wine seriously."? Okay... former versions of MS Office work very well, but many offices, e.g. at universities, also depend on Acrobat Standard for doing everyday-stuff. The latest Acrobat which works (more or less - seems to have a printing problems) out of the box is v. 5, although you can get Acrobat Reader 7 working using Microsoft's IE. Ciao, Olaf

May 31, 2006

Re: How are we doing?

by Mike Hearn

On Wed, 31 May 2006 14:57:06 +0200, Hans Leidekker wrote: > At the same time we should think of exciting new possibilities that an open > source implementation of the Windows API brings to the table. At past WineConfs the possibility of reaching out to Windows developers was raised, by making it easier for Windows guys to use our code. For instance if they have built their app on an API but need a bugfix or feature Wine is the obvious candidate but right now we make it hard for them to do that. We're very Linux/UNIX centric (eg build system ...) thanks

May 31, 2006

Re: Wine 1.0 Tasks

by Robert Shearman

Alex Villacís Lasso wrote: > In addition, if anyone tries to use DBGRID32.OCX, they will surely hit > this bug: > > Bug 3846 - Wine can't run Roderick Colenbrander's DBGRID32.OCX VB test > apps yet > http://bugs.winehq.org/show_bug.cgi?id=3846 This should be fixed as of today. -- Rob Shearman

May 31, 2006

Re: svrapi: add stub implementation

by Robert Shearman

Vitaly Lipatov wrote: >svrapi.dll is exist on Win9X OS and used in some programs. > > What programs? Is it still used even with the winver set to win2k? -- Rob Shearman

May 31, 2006