December 2008 - Wine-Devel - list.winehq.org

Re: server: implement move/rename change notifications and support for multiple change notification in one reply

by Dan Kegel

On Tue, Dec 16, 2008 at 5:40 PM, Michael Pujos <pujos.michael(a)laposte.net> wrote: > The protocol is slightly changed between read_changes_apc() in ntdll and the > server > to support return of multiple FILE_NOTIFY_INFORMATION structs at a time. > This is transparent to win32 programs (is that what you are calling client ? > 'm still a bit new to wine terminology :) Yes, any wine app is a client of the wineserver. > using this API (ReadDirectoryChangeW) and I took great care to have all the > tests pass. Oh, I guess you're right... I keep forgetting that the software on both ends will get updated at the same time. This is discussed in http://bugs.winehq.org/show_bug.cgi?id=124 - Dan

Dec. 17, 2008

Re: server: implement move/rename change notifications and support for multiple change notification in one reply

by Michael Pujos

Dan Kegel wrote: > On Tue, Dec 16, 2008 at 5:21 PM, Michael Pujos > <pujos.michael(a)laposte.net> wrote: > >>> I don't see an attachment to >>> http://www.winehq.org/pipermail/wine-patches/2008-December/066224.html >>> or rather, there's only a zero-length one. >>> >> I just attached (In thunderbird) the file outputted by "git format-patch >> --keep-subject origin" >> Curiously the link above point to a zero length file but I received it >> correctly in my e-mail client from the mailing-list... >> > > That archive is a bit finicky. > I see the attachment in another archive: > http://marc.info/?l=wine-patches&m=122947592925831&w=2 > Suggestion: next time use a shorter filename, maybe that's > what screwed up the archive. > Ah ok, I've noticed it also happens with other patches posted > It looks like you're changing the protocol. Will old clients be able to > connect successfully? It looks like they won't. you need to support > old clients. We're not allowed to break compatibility now that we've > released wine-1.0. > - Dan > The protocol is slightly changed between read_changes_apc() in ntdll and the server to support return of multiple FILE_NOTIFY_INFORMATION structs at a time. This is transparent to win32 programs (is that what you are calling client ? 'm still a bit new to wine terminology :). using this API (ReadDirectoryChangeW) and I took great care to have all the tests pass.

Dec. 17, 2008

Re: server: implement move/rename change notifications and support for multiple change notification in one reply

by Dan Kegel

On Tue, Dec 16, 2008 at 5:21 PM, Michael Pujos <pujos.michael(a)laposte.net> wrote: >> I don't see an attachment to >> http://www.winehq.org/pipermail/wine-patches/2008-December/066224.html >> or rather, there's only a zero-length one. > > I just attached (In thunderbird) the file outputted by "git format-patch > --keep-subject origin" > Curiously the link above point to a zero length file but I received it > correctly in my e-mail client from the mailing-list... That archive is a bit finicky. I see the attachment in another archive: http://marc.info/?l=wine-patches&m=122947592925831&w=2 Suggestion: next time use a shorter filename, maybe that's what screwed up the archive. It looks like you're changing the protocol. Will old clients be able to connect successfully? It looks like they won't. you need to support old clients. We're not allowed to break compatibility now that we've released wine-1.0. - Dan

Dec. 17, 2008

Re: Wine t-shirts?

by Ismael Barros²

On Wed, Dec 17, 2008 at 12:58 AM, Andrew Fenn <andrewfenn(a)gmail.com> wrote: > Shouldn't you take off the "hq" part of the name? Indeed, I forgot to tell the arts team that. > I don't know how exactly you could do what I am about to suggest, but > is there a way to make the graphics tell a little more as to what wine > is? It's just that I can picture myself walking down the street in > this and everyone thinking I'm some kind of alcoholic. Well, what do you expect from a program called wine? :P All the wine logos I know are wine-related. Maybe we can use them but with some kind of C source code background, but even then most people would think you are some kind of alcoholic geek. > Also I think the web address should be on there somewhere. Maybe in the back, but I think that would make the T-shirt more expensive. I'll ask. On Wed, Dec 17, 2008 at 1:01 AM, Jeff Zaroyko <jeffzaroyko(a)gmail.com> wrote: > If the hq is taken off the name, shouldn't it then be Wine rather than WINE? Why? It's mostly written in Wine form, but it's also an acronym, so the way that looks better on the T-shirt should work fine.

Dec. 17, 2008

Re: Wine t-shirts?

by Jeff Zaroyko

On Wed, Dec 17, 2008 at 10:58 AM, Andrew Fenn <andrewfenn(a)gmail.com> wrote: > On Tue, Dec 16, 2008 at 11:25 PM, Ismael Barros² <razielmine(a)gmail.com> wrote: >> Which model and T-shirt do you like better? Any suggestion to improve >> them? Maybe in a future we can sell more than one Wine design, but >> right now we'd rather offer only one, to avoid logistic problems. > > Shouldn't you take off the "hq" part of the name? > > I don't know how exactly you could do what I am about to suggest, but > is there a way to make the graphics tell a little more as to what wine > is? It's just that I can picture myself walking down the street in > this and everyone thinking I'm some kind of alcoholic. > > Also I think the web address should be on there somewhere. > > It's looking great, can't wait to see the real things. > > Regards, > Andrew > > If the hq is taken off the name, shouldn't it then be Wine rather than WINE? -Jeff

Dec. 17, 2008

Re: Wine t-shirts?

by Andrew Fenn

On Tue, Dec 16, 2008 at 11:25 PM, Ismael Barros² <razielmine(a)gmail.com> wrote: > Which model and T-shirt do you like better? Any suggestion to improve > them? Maybe in a future we can sell more than one Wine design, but > right now we'd rather offer only one, to avoid logistic problems. Shouldn't you take off the "hq" part of the name? I don't know how exactly you could do what I am about to suggest, but is there a way to make the graphics tell a little more as to what wine is? It's just that I can picture myself walking down the street in this and everyone thinking I'm some kind of alcoholic. Also I think the web address should be on there somewhere. It's looking great, can't wait to see the real things. Regards, Andrew

Dec. 16, 2008

Re: Wine t-shirts?

by Ismael Barros²

On Thu, Dec 4, 2008 at 5:47 AM, Steven Edwards <winehacker(a)gmail.com> wrote: > Heh sorry for all the spam, it would help if I used gmail for > everything, in the original thread Jer already gave blanket permission > for Wine to that logo: > > from Jeremy White <jwhite(a)winehq.org> > to Dan Kegel <dank(a)kegel.com> > cc Wine Developers List <wine-devel(a)winehq.org> > date Wed, Apr 23, 2008 at 7:40 AM > subject Re: Wine t-shirts? > mailing list wine-devel.winehq.org Filter messages from this mailing list > >> http://kegel.com/wine/wine-penguin-corkscrew.png > > Jon Parshall is proud of his ability to draw those penguins, > and we'd gladly send that artwork to anyone that wanted to make a T-shirt. > > Note, though, that we felt we had to (very sadly) drop the penguin; it doesn't > really work for Mac users. > > > Again sorry for the spam, I will stop with it now. > -- > Steven Edwards > > "There is one thing stronger than all the armies in the world, and > that is an idea whose time has come." - Victor Hugo > Hi there, some preliminar desings, with two T-shirt models to choose from: http://www.freewear.org/images/release_candidates/propuesta_Wine.png http://www.freewear.org/images/release_candidates/Wine_baseball.png Which model and T-shirt do you like better? Any suggestion to improve them? Maybe in a future we can sell more than one Wine design, but right now we'd rather offer only one, to avoid logistic problems. I've created this to make voting easier: http://spreadsheets.google.com/viewform?key=pFqhThgtfGxo3OxU8pe8ZDg Cheers Ismael Barros

Dec. 16, 2008

Better user feedback and better user experience (idea)

by Sander Devrieze

Hi, One of the reasons why Linux distributions do not want to include Wine by default is because compatibility issues may result a bad impression of the quality of the OS. Users think Linux sucks because their Windows application does not run (as good) under Wine as it does under Windows. Problem: Windows applications ran by Wine do not always run without issues and the user does not know why. Hence, (s)he will think this is because Linux is less stable than Windows. What do Wine coders think about solving the issue by adding a user feedback interface to Wine? It may for instance work like this: * By default open a user feedback dialog after the application is closed (or crashes). In this dialog, the user will be explained why this dialog is shown, and why he might have experienced bugs or crashes in the Windows application. The user also can provide text feedback and other types of feedback (e.g. a checkbox saying "The application crashed"). * The user has the option to send this information to the Wine project by hitting a button. Gathered information will be integrated in the Wine application database and can be helpful for Wine coders and users. Advantages: * Users will better understand why their application did not run as well on Linux as on Windows. * Wine will become more interesting to be actively supported by Linux distributors. * Users will feel they easily can contribute to the Wine project. * The Wine project will receive more feedback. Other subidea: Create a database with hashes of .exe files. Wine can consult this database *before* it executes a Windows binary and provide the user with feedback like this: "Remark that 60% of users were not satisfied when running this application in this Wine version. Do you want to proceed?" Or like this: "This application has these issues: ... Do you want to proceed?" -- Kind Regards, Sander Devrieze.

Dec. 16, 2008

Re: Another machine passing tests

by Alasdair Sinclair

Austin English wrote: > On Mon, Dec 15, 2008 at 6:38 PM, Alasdair Sinclair > <alasdairs(a)dsl.pipex.com> wrote: > >> Austin English wrote: >> >>> On Mon, Dec 15, 2008 at 2:04 PM, Zachary Goldberg <zgold(a)bluesata.com> >>> wrote: >>> >>> >>>> All, >>>> >>>> It seems we have another machine which passes all tests on Wine >>>> >>>> http://test.winehq.org/data/bd25af9dba280e3d80f3080140f2f5ab2cd0dfb3/ >>>> >>>> Huzzah! >>>> >>>> --Zach >>>> >>>> >>>> >>>> >>>> >>> Who's machine is that, Aric's? >>> >>> >>> >> Hi >> >> Thats my machine. It seems to fluctuate between one and two errors, I guess >> this time I got lucky this time. >> >> Alasdair >> >> > > Would you mind sharing what hardware that's on? You're using Fedora 10, right? > > Sure, Its a Dell XPS1530 laptop (core 2 duo T8100), 4GB Ram, GeForce 8600M GT. Running fedora 10 x86-64 (recently upgraded from 9) all latest patches applied, desktop is Gnome. It's also running the proprietary Nvidia drivers packaged by rpmfusion. Alasdair

Dec. 16, 2008

Re: Unused vtables and debug channels

by Andrew Talbot

Christian Costa wrote: > Hi Andrew, > > BTW, if the vtable are removed, there may be some unused functions. Will > they be removed as well ? > > Bye, > Christian Hi Christian, Because I was mindful not to remove such things lightly, that is why I sought feedback from the community, and I shall respect the views expressed by some, therefore, to leave the vtables alone. However, I do agree with Henri's view that it is the keeping of pieces of code needs to be justified, and so am inclined to remove any genuinely unused Wine debug channels, since they are comparatively simple items and very easy to resurrect if eventually required. Thanks to everyone, -- Andy.

Dec. 16, 2008

Re: MSI: fix some NULL checking in MSI_RecordGetStringA

by James Hawkins

On Tue, Dec 16, 2008 at 11:59 AM, Aric Stewart <aric(a)codeweavers.com> wrote: > Ok, Though it mirrors what is happening over in MSI_RecordGetStringW so i > assumed it was just a few check that had been accidentally forgotten. > Yea, I'm sure it's right, but it's nice to verify those changes with tests and to keep it from regressing. -- James Hawkins

Dec. 16, 2008

Re: MSI: fix some NULL checking in MSI_RecordGetStringA

by Aric Stewart

Ok, Though it mirrors what is happening over in MSI_RecordGetStringW so i assumed it was just a few check that had been accidentally forgotten. -aric James Hawkins wrote: > On Tue, Dec 16, 2008 at 9:11 AM, Aric Stewart <aric(a)codeweavers.com> wrote: >> --- >> dlls/msi/record.c | 7 ++++--- >> 1 files changed, 4 insertions(+), 3 deletions(-) >> > > Can you add tests for this please? > > Thanks, > James Hawkins >

Dec. 16, 2008

Re: MSI: fix some NULL checking in MSI_RecordGetStringA

by James Hawkins

On Tue, Dec 16, 2008 at 9:11 AM, Aric Stewart <aric(a)codeweavers.com> wrote: > --- > dlls/msi/record.c | 7 ++++--- > 1 files changed, 4 insertions(+), 3 deletions(-) > Can you add tests for this please? Thanks, James Hawkins

Dec. 16, 2008

fixing all the not-properly-displaying characters that have suddenly appeared in the appdb

by Rosanne DiMesio

Since the change to the new design, AppDB entries have been displaying either a ? (Firefox, Konqueror, Opera) or a blank rectangle (IE in Windows) in place of a variety of special characters, including anything with an umlaut (bug 16514). I've played around with it a bit, and the entries can be fixed by manually editing them, but before I undertake the task, I figured I'd better ask if this is something that could be fixed more easily (e.g., changing a setting on the server). -- Rosanne DiMesio <dimesio(a)earthlink.net>

Dec. 16, 2008

Re: Another machine passing tests

by Austin English

On Mon, Dec 15, 2008 at 6:38 PM, Alasdair Sinclair <alasdairs(a)dsl.pipex.com> wrote: > Austin English wrote: >> >> On Mon, Dec 15, 2008 at 2:04 PM, Zachary Goldberg <zgold(a)bluesata.com> >> wrote: >> >>> >>> All, >>> >>> It seems we have another machine which passes all tests on Wine >>> >>> http://test.winehq.org/data/bd25af9dba280e3d80f3080140f2f5ab2cd0dfb3/ >>> >>> Huzzah! >>> >>> --Zach >>> >>> >>> >>> >> >> Who's machine is that, Aric's? >> >> > > Hi > > Thats my machine. It seems to fluctuate between one and two errors, I guess > this time I got lucky this time. > > Alasdair > Would you mind sharing what hardware that's on? You're using Fedora 10, right? -- -Austin

Dec. 16, 2008

Re: jscript: api.js, added test routines for Math functions

by Jacek Caban

Hi Patrick, First of all, tests must pass on Wine and Windows. Your test won't pass on any of them! When you have a test that passes on Windows, please send one function implementation and tests in one patch. Patrick Rudolph wrote: > From c43e52c3446fb846a760002f0222f697075fad1b Mon Sep 17 00:00:00 2001 > From: Patrick Rudolph <patrick1804(a)web.de> > Date: Thu, 11 Dec 2008 17:48:38 +0100 > Subject: jscript: api.js added test routines for Math functions > > modified: dlls/jscript/tests/api.js > added tests for : > Math.PI > Math.E > Math.SQRT2 > Math.SQRT1_2 > Math.sin > Math.cos > Math.random > Math.tan > Math.atan > Math.asin > Math.acos > Math.log > math.atan2 > > --- > dlls/jscript/tests/api.js | 38 +++++++++++++++----------------------- > 1 files changed, 42 insertions(+), 0 deletions(-) > > diff --git a/dlls/jscript/tests/api.js b/dlls/jscript/tests/api.js > index 6430397..50a28d5 100644 > --- a/dlls/jscript/tests/api.js > +++ b/dlls/jscript/tests/api.js > > +i = (Math.PI()).toString(); > Math.PI is constant, not function so you can't call it. You'd know that if you'd verified that the test passes on Windows. > +ok(i === "3.14159265358979","Math.PI() = " + i); > It's bad idea to compare double values in tests, and comparing strings is strange here. Math.PI already has a test, look there how it's done there. > + > +i = (Math.E()).toString(); > +ok(i === "2.71828182845905","Math.E() = " + i); > Same here. > + > +i = (Math.SQRT2()).toString(); > +ok(i === "1.4142135623731","Math.SQRT2() = " + i); > And here. > +i = (Math.SQRT1_2()).toString(); > +ok(i === "0.707106781186547","Math.SQRT1_2() = " + i); > And here. > +i = Math.sin(0); > +ok(i === 0, "Math.sin(0) = " + i); > + > +i = Math.cos(0); > +ok(i === 1, "Math.cos(0) = " + i); > + > +i = Math.tan(0); > +ok(i === 0, "Math.tan(0) = " + i); > + > +i = Math.log(1); > +ok(i === 0 , "Math.log() = " + i); > + > +i = Math.random(); > +ok(i !== 0 , "Math.random() = " + i); > + > +i = Math.random(); > +ok(i !== 1 , "Math.random() = " + i); > + > +i = Math.atan2(0,1); > +ok(i === 0 , "Math.atan2(0,1) = " + i); > + > +i = Math.atan(0); > +ok(i === 0 , "Math.atan(0) = " + i); > + > +i = (Math.asin(1)).toString(); > +ok(i === "1.5707963267949" , "Math.asin(1) = " + i); > + > +i = (Math.acos(-1)).toString(); > +ok(i === "3.14159265358979" , "Math.acos(-1) = " + i); > There functions should have more tests like passing no argument, testing invalid asin/acos arguments, passing too much arguments (and should be sent in one patch, together with implementation). Also, in other patches, please add comments pointing to specifications of these function when you implement them. It would be good idea to get one patch accepted before resending the whole series. Jacek

Dec. 16, 2008

Re: [1/5] jscript: Implement the String.anchor() method (resend).

by Jacek Caban

Hi Andrew, Andrew Nguyen wrote: > This revision incorporates Jacek Caban's suggestions. > --- > dlls/jscript/string.c | 55 +++++++++++++++++++++++++++++++++++++++++++- > dlls/jscript/tests/api.js | 17 ++++++++++++++ > 2 files changed, 70 insertions(+), 2 deletions(-) > + if(ret) { + sprintfW(ret, attrtagfmtW, tagname, attrname, (attrval ? attrval : undefinedW), string->str, tagname); + + V_VT(retv) = VT_BSTR; + V_BSTR(retv) = ret; + + SysFreeString(attrval); It looks for me much better now, but you leak attrval if retv is NULL or SysAllocStringLen fails. SysFreeString call should be moved just before the last return. Jacek

Dec. 16, 2008

winecfg volume serial number

by Hoehle, Joerg-Cyril

Hi, I just sent a bug-fix to wine-patches to prevent a crash in winecfg when editing the volume serial number input field, together with some unrelated thoughts about winecfg and the device/volume serial number handling. Then I realized that wine-patches is not a good place for discussion. So here are the ideas about winecfg's GUI: - Maybe the serial input field should be initialized with %08X instead of %X to hint at the format? E.g. input of serial numbers like "1122-dacf" as printed by DIR produce 00001122 in winecfg, due to strtoul(). - Possibly the input size should be restricted to 8 characters in the GUI? - Maybe winecfg should echo the hex number it read into the input field, no later than "apply" time? Currently one needs to select another drive, then come back to see what it got. Note that winecmd's DIR prints the number in lower case, while MS-w2k DOS window's DIR prints upper case. BTW, winecfg does not seem to be able to set .windows-label anymore: trace:winecfg:apply_drive_changes warn:winecfg:set_drive_label unable to set volume label for devicename of L"E:\\", label of L"xyz" trace:winecfg:PRINTERROR error: 'Access denied' Looks like http://bugs.winehq.org/show_bug.cgi?id=13273 Regards, Jörg Höhle

Dec. 16, 2008

Re: Unused vtables and debug channels

by Christian Costa

Hi Andrew, BTW, if the vtable are removed, there may be some unused functions. Will they be removed as well ? Bye, Christian > Message du 16/12/08 11:11 > De : "Maarten Lankhorst" > A : "Andrew Talbot" > Copie à : wine-devel(a)winehq.org > Objet : Re: Unused vtables and debug channels > > > Hi Andrew, > > Andrew Talbot schreef: > > It appears that the following vtables and Wine debug channels are not being used, so I am considering removing them. Please let me know, therefore, if you have plans for any of them and want them kept. > > > > > > Vtables: > > .... > > MemInputPin_Vtbl quartz/nullrenderer.c > > OutputPin_Vtbl* quartz/pin.c > > InputPin_Vtbl* quartz/pin.c > > PullPin_Vtbl* quartz/pin.c > > MemInputPin_Vtbl quartz/transform.c > > MemInputPin_Vtbl quartz/videorenderer.c > > > Feel free to remove the quartz ones, it should be harmless. > > Cheers, > Maarten. > > > >

Dec. 16, 2008

Use show instead of glyphshow: gylphshow very slow on kyocera

by Wolfgang Walter

Hello, wineps.drv uses the postscript operator glyphshow to print glyphs. This operator is very slow on all Kyocera postscript printers. To get an idea: its generally only 1/6 to 1/10 of the performance compared to the same document printed with the windows xp postscript driver (which does not use glyphsow). I wrote an email hier where I proposed a patch. This patch changes wineps.drv such that it uses the show operator for downloaded fonts (type1 and type42). This change is not trivial as the show operator (and its relatives xshow, yshow, xyshow) operates on character codes and not on glyhpnames. So wineps.drv must generate postscript code define an appropriate encoding. As a font may only have up to 256 characters encoded and as it is not allowed to modify the encoding once defined the font must be cloned if more then 256 characters are used. This is inexpensive, though, as actually all resources but the encoding array are shared. See the patch my earlier mail for a more detailed explanation. This modification brings the performance of the postscript code generated by wine up to windows' postscript driver (if no clipping region is defined - another problem). I tested it on a wide range of kyocera printer models and two hp models. Of course I tested it with ghostscript. I would appreciate any comments and ideas. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts Leiter EDV Leopoldstraße 15 80802 München

Dec. 16, 2008

Re: wineps: clipping bug; clipping performance

by Wolfgang Walter

Am Dienstag, 16. Dezember 2008 11:51 schrieb Kai Blin: > On Tuesday 16 December 2008 11:42:55 Wolfgang Walter wrote: > > I have not received any comment yet. > > That's probably because not too many people know much about this. Detlef > Riekenberg is probably the person who should comment on this, I've CCed > him. > > Cheers, > Kai Thanks. Then I'll send him my patch concerning the use of glyphshow, too :-). Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts Leiter EDV Leopoldstraße 15 80802 München

Dec. 16, 2008

Re: wineps: clipping bug; clipping performance

by Kai Blin

On Tuesday 16 December 2008 11:42:55 Wolfgang Walter wrote: > I have not received any comment yet. That's probably because not too many people know much about this. Detlef Riekenberg is probably the person who should comment on this, I've CCed him. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

Dec. 16, 2008

wineps: clipping bug; clipping performance

by Wolfgang Walter

Hello, as I wrote clipping in wineps.drv has a bug. Wine does only consider the clipping region and not the meta region. It should combine them. This is a bug which hurts us with a real windows application. I sent a patch which which corrects this. My patch also addressed a general performance problem with all postscript printers from Kyocera concerning non trivial clipping regions. Even if you use ghostscripts pxlmono/pxlcolor driver the generated PCL XL code may lead to errors on our Kyocera and HP printers because the clipping path gets to expensive. I have not received any comment yet. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts Leiter EDV Leopoldstraße 15 80802 München

Dec. 16, 2008

Re: AppDB rating definitions, was: Re: Canonical and wine

by M.Kiesel

On Mon, 15 Dec 2008, Austin English wrote: >> What about clarifying the wording on >> http://appdb.winehq.org/help/?sTopic=maintainer_ratings >> ? >> My suggestion for "Platinum": >> "Application installs and runs flawlessly completely/at highest settings >> 'out of the box'. No changes required in winecfg." >> (add "completely/at highest settings") > I think it's fine as is. Some games won't run at highest settings on > Windows, due to crappy video card, etc. Good point. I was thinking about games that run fine in Windows at highest settings but do not in Wine (on the same machine). What about "Application installs and runs just as it does in Windows, without <b>any</b> custom Wine tweaks or settings."? There's still a 'loophole' with for example hardware that works fine in Windows but doesn't in *nix (ATI graphics cards...) but probably it's no good to add tons of fine print to that definition. >> For "Gold": >> "Application works completely/at highest settings flawlessly in the latest >> Wine development release (no patches needed), possibly with DLL overrides, >> other settings, or third party software." >> (add same as above; add "latest Wine development release"; remove "*some* >> DLL overrides) > The ratings are done on a per version basis, so no need to stipulate > the latest release. The patches and DLL comments I agree with. "Application works just as it does in Windows with unpatched Wine, possibly with DLL overrides, other settings, or third party software."? [Patched Wine versions and Gold rating] > I see it quite a bit when approving programs in the AppDB (though I'm > not the one usually doing it, I only go through the queue when I'm on > the AppDB for other reasons). The main problem is when it get a > _platinum_ rating. I agree. Still, I feel that Gold should mean "an average user should be able to get the game running completely", and while with winetricks etc. adding DLL overrides is no problem, patching/building Wine probably IS. Also this might be an incentive to get patches into Wine proper instead of leaving hacks in AppDB/Bugzilla ("Well, the game is gold now, no need to fix things further"). Not sure whether I'm realistic here though ;-). >> I also suggest to hyperlink every mention of "Rating" in the browser with >> that page. Otherwise it isn't completely clear (without searching) what the >> individual ratings mean really. [...] >> Who has the rights to change AppDB on that level? > I'll send a patch tomorrow. If you don't see a change within a few > days, remind me. Cool, thanks a lot! Regards

Dec. 16, 2008

Re: Unused vtables and debug channels

by Maarten Lankhorst

Hi Andrew, Andrew Talbot schreef: > It appears that the following vtables and Wine debug channels are not being used, so I am considering removing them. Please let me know, therefore, if you have plans for any of them and want them kept. > > > Vtables: > .... > MemInputPin_Vtbl quartz/nullrenderer.c > OutputPin_Vtbl* quartz/pin.c > InputPin_Vtbl* quartz/pin.c > PullPin_Vtbl* quartz/pin.c > MemInputPin_Vtbl quartz/transform.c > MemInputPin_Vtbl quartz/videorenderer.c > Feel free to remove the quartz ones, it should be harmless. Cheers, Maarten.

Dec. 16, 2008

Re: [resend5] gdi32/tests: Add a test fot GdiGetCodePage().

by Paul Vriens

ByeongSik Jeon wrote: > --- > dlls/gdi32/tests/Makefile.in | 2 +- > dlls/gdi32/tests/font.c | 156 ++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 157 insertions(+), 1 deletions(-) > > > ------------------------------------------------------------------------ > > Hi, I applied these tests to my local box (no other patches) and the test fails for me. Or to but it more correct some (all?) of the todo_wine's succeeded. I then removed the todo_wine's from your tests and I don't have failures anymore. The fact that the tests fails for me (and probably for others as well) could mean the patch won't be committed (unless it succeeds on AJ's machine of course). -- Cheers, Paul.

Dec. 16, 2008

Re: oleaut32/tests: add tests for OleLoadPictureFile(Ex) and OleLoadPicurePath (resend) [3/3]

by Paul Vriens

Jeremy Drake wrote: > This integrates the scenarios that I wasn't testing from Nikolay Sivov's > patch to the tests of 12/7. Also works around some issues I was running > into trying to write wide strings as L"foo". > > --- > dlls/oleaut32/tests/olepicture.c | 311 ++++++++++++++++++++++++++++++++++++++ > 1 files changed, 311 insertions(+), 0 deletions(-) > > diff --git a/dlls/oleaut32/tests/olepicture.c b/dlls/oleaut32/tests/olepicture.c > index 2b5b8bb..2929bd7 100644 > --- a/dlls/oleaut32/tests/olepicture.c > +++ b/dlls/oleaut32/tests/olepicture.c > @@ -489,6 +489,315 @@ static void test_OleCreatePictureIndirect(void) > IPicture_Release(pict); > } > > +static void test_VerifyPictureType(IDispatch *pdisp, short expectedtype, int caller_line) > +{ > + IPicture *pict; > + HRESULT hr; > + short type; > + pict = (void*)0xdeadbeef; > + hr = IDispatch_QueryInterface(pdisp, &IID_IPicture, (LPVOID*)&pict); > + ok(hr == S_OK, "hr %08x\n", hr); > + ok(pict != (void*)0xdeadbeef && pict != NULL, "pict ptr, caller line %d\n", caller_line); > + > + if (SUCCEEDED(hr)) > + { > + type = 0xdead; > + hr = IPicture_get_Type(pict, &type); > + ok(hr == S_OK, "hr %08x, caller line %d\n", hr, caller_line); > + ok(type == expectedtype, "type %hd, expected %hd, caller line %d\n", type, expectedtype, caller_line); > + > + IPicture_Release(pict); > + } > +} > + > +static const WCHAR nopath[] = { '\\', 'n', 'o', 'p', 'a', 't', 'h', 0 }; > +static void test_OleLoadPictureFile(void) > +{ > + IDispatch *disp; > + HRESULT hr; > + char filename[MAX_PATH]; > + VARIANT varFilename; > + HANDLE file; > + DWORD written; > + DWORD widestringlen; > + BSTR tmp = NULL, tmp2 = NULL; > + > + GetTempFileNameA(".", "gif", 0, filename); > + file = CreateFileA(filename, GENERIC_READ|GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, 0); > + ok(file != INVALID_HANDLE_VALUE, "file creation error %u\n", GetLastError()); > + if (file == INVALID_HANDLE_VALUE) return; > + WriteFile(file, gif4pixel, sizeof(gif4pixel), &written, NULL); > + ok(written == sizeof(gif4pixel), "write\n"); > + > + VariantInit(&varFilename); > + V_VT(&varFilename) = VT_ERROR; > + V_ERROR(&varFilename) = DISP_E_PARAMNOTFOUND; > + > + todo_wine > + { > + disp = (void*)0xdeadbeef; > + hr = OleLoadPictureFileEx(varFilename, 2, 2, LP_DEFAULT, &disp); > + ok(hr == S_OK, "hr %08x\n", hr); > + ok(disp != (void*)0xdeadbeef, "dispatch ptr\n"); > + > + if (disp != (void*)0xdeadbeef) > + { > + test_VerifyPictureType(disp, PICTYPE_NONE, __LINE__); > + IDispatch_Release(disp); > + } > + } > + > + > + widestringlen = MultiByteToWideChar(CP_ACP, 0, filename, -1, NULL, 0); > + ok(widestringlen != 0, "determining wide string length error %u\n", GetLastError()); > + if (widestringlen == 0) return; > + V_VT(&varFilename) = VT_BSTR; > + V_BSTR(&varFilename) = SysAllocStringLen(NULL, widestringlen - 1); > + ok(MultiByteToWideChar(CP_ACP, 0, filename, -1, V_BSTR(&varFilename), widestringlen), > + "filename to wide string conversion error %u\n", GetLastError()); > + > + disp = (void*)0xdeadbeef; > + todo_wine > + { > + hr = OleLoadPictureFile(varFilename, &disp); > + ok(hr == CTL_E_PERMISSIONDENIED, "hr %08x\n", hr); > + } > + ok(disp == (void*)0xdeadbeef, "dispatch ptr\n"); > + > + CloseHandle(file); > + > + disp = (void*)0xdeadbeef; > + todo_wine > + { > + hr = OleLoadPictureFileEx(varFilename, 2, 2, LP_DEFAULT, &disp); > + ok(hr == S_OK, "hr %08x\n", hr); > + ok(disp != (void*)0xdeadbeef && disp != NULL, "dispatch ptr\n"); > + > + if (SUCCEEDED(hr)) > + { > + test_VerifyPictureType(disp, PICTYPE_BITMAP, __LINE__); > + IDispatch_Release(disp); > + } > + } > + > + todo_wine > + { > + disp = (void*)0xdeadbeef; > + hr = OleLoadPictureFile(varFilename, &disp); > + ok(hr == S_OK, "hr %08x\n", hr); > + ok(disp != (void*)0xdeadbeef && disp != NULL, "dispatch ptr\n"); > + > + if (SUCCEEDED(hr)) > + { > + test_VerifyPictureType(disp, PICTYPE_BITMAP, __LINE__); > + IDispatch_Release(disp); > + } > + } > + > + ok(MoveFileA(filename, "33"), "move file\n"); > + > + file = CreateFileA(filename, GENERIC_READ|GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, 0); > + ok(file != INVALID_HANDLE_VALUE, "file creation error %u\n", GetLastError()); > + if (file != INVALID_HANDLE_VALUE) > + { > + WriteFile(file, "this is not a valid picture", 28, &written, NULL); > + ok(written == 28, "write\n"); > + CloseHandle(file); > + > + disp = (void*)0xdeadbeef; > + todo_wine > + { > + hr = OleLoadPictureFile(varFilename, &disp); > + ok(hr == CTL_E_INVALIDPICTURE, "hr %08x\n", hr); > + ok(disp == NULL, "dispatch ptr\n"); /* XXX this one is not unmodified!! */ > + } > + DeleteFileA(filename); > + } > + > + tmp = SysAllocString(nopath); > + ok(tmp != NULL, "SysAllocString\n"); > + if (tmp != NULL) > + { > + hr = VarBstrCat(V_BSTR(&varFilename), tmp, &tmp2); > + if (SUCCEEDED(hr)) > + { > + SysFreeString(V_BSTR(&varFilename)); > + V_BSTR(&varFilename) = tmp2; > + > + disp = (void*)0xdeadbeef; > + todo_wine > + { > + hr = OleLoadPictureFile(varFilename, &disp); > + ok(hr == CTL_E_PATHNOTFOUND, "hr %08x\n", hr); > + } > + ok(disp == (void*)0xdeadbeef, "dispatch ptr\n"); > + } > + > + SysFreeString(tmp); > + } > + > + VariantClear(&varFilename); > + VariantInit(&varFilename); > + V_VT(&varFilename) = VT_I4; > + V_I4(&varFilename) = 33; > + > + todo_wine > + { > + disp = (void*)0xdeadbeef; > + hr = OleLoadPictureFile(varFilename, &disp); > + ok(hr == S_OK, "hr %08x\n", hr); > + ok(disp != (void*)0xdeadbeef && disp != NULL, "dispatch ptr\n"); > + > + if (SUCCEEDED(hr)) > + { > + test_VerifyPictureType(disp, PICTYPE_BITMAP, __LINE__); > + IDispatch_Release(disp); > + } > + } > + ok(V_VT(&varFilename) == VT_I4 && V_I4(&varFilename) == 33, "variant unmodified\n"); > + > + DeleteFileA("33"); > + > + VariantClear(&varFilename); > +} > + > +static void test_OleLoadPicturePath(void) > +{ > + static const WCHAR fileproto[] = { 'f','i','l','e',':','/','/',0 }; > + IDispatch *disp; > + HRESULT hr; > + char filename[MAX_PATH]; > + char absfile[MAX_PATH]; > + HANDLE file; > + DWORD written; > + DWORD widestringlen; > + BSTR bstrname = NULL; > + BSTR tmp = NULL, tmp2 = NULL; > + > + GetTempFileNameA(".", "gif", 0, filename); > + GetFullPathNameA(filename, MAX_PATH, absfile, NULL); > + file = CreateFileA(filename, GENERIC_READ|GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, 0); > + ok(file != INVALID_HANDLE_VALUE, "file creation error %u\n", GetLastError()); > + if (file == INVALID_HANDLE_VALUE) return; > + WriteFile(file, gif4pixel, sizeof(gif4pixel), &written, NULL); > + ok(written == sizeof(gif4pixel), "write\n"); > + > + widestringlen = MultiByteToWideChar(CP_ACP, 0, absfile, -1, NULL, 0); > + ok(widestringlen != 0, "determining wide string length error %u\n", GetLastError()); > + if (widestringlen == 0) return; > + bstrname = SysAllocStringLen(NULL, widestringlen - 1); > + ok(MultiByteToWideChar(CP_ACP, 0, absfile, -1, bstrname, widestringlen), > + "filename to wide string conversion error %u\n", GetLastError()); > + > + disp = (void*)0xdeadbeef; > + hr = OleLoadPicturePath(bstrname, NULL, 0, 0, &IID_IDispatch, (LPVOID*)&disp); > + if (hr == E_UNEXPECTED) > + { > + /* E_UNEXPECTED is returned from OleLoadPicturePath on win95 without IE installed */ > + win_skip("OleLoadPicturePath seems to not work on this platform. No IE?\n"); > + CloseHandle(file); > + DeleteFileA(filename); > + return; > + } > + ok(hr == INET_E_DATA_NOT_AVAILABLE /*>=XP*/ || > + hr == E_FAIL /*<=2k*/, "hr %08x\n", hr); > + todo_wine ok(disp == NULL, "dispatch ptr\n"); > + > + CloseHandle(file); > + > + disp = (void*)0xdeadbeef; > + todo_wine > + { > + hr = OleLoadPicturePath(bstrname, NULL, 0, 0, &IID_IDispatch, (LPVOID*)&disp); > + ok(hr == S_OK, "hr %08x\n", hr); > + ok(disp != NULL && disp != (void*)0xdeadbeef, "dispatch ptr\n"); > + > + if (SUCCEEDED(hr)) > + { > + test_VerifyPictureType(disp, PICTYPE_BITMAP, __LINE__); > + IDispatch_Release(disp); > + } > + } > + > + disp = (void*)0xdeadbeef; > + todo_wine > + { > + tmp = SysAllocString(fileproto); > + hr = VarBstrCat(tmp, bstrname, &tmp2); > + SysFreeString(tmp); > + tmp = NULL; > + > + > + hr = OleLoadPicturePath(tmp2, NULL, 0, 0, &IID_IDispatch, (LPVOID*)&disp); > + ok(hr == S_OK, "hr %08x\n", hr); > + ok(disp != NULL && disp != (void*)0xdeadbeef, "dispatch ptr\n"); > + > + if (SUCCEEDED(hr)) > + { > + test_VerifyPictureType(disp, PICTYPE_BITMAP, __LINE__); > + IDispatch_Release(disp); > + } > + SysFreeString(tmp2); > + tmp2 = NULL; > + } > + > + > + widestringlen = MultiByteToWideChar(CP_ACP, 0, filename, -1, NULL, 0); > + ok(widestringlen != 0, "determining wide string length error %u\n", GetLastError()); > + if (widestringlen == 0) return; > + tmp = SysAllocStringLen(NULL, widestringlen - 1); > + ok(MultiByteToWideChar(CP_ACP, 0, filename, -1, tmp, widestringlen), > + "filename to wide string conversion error %u\n", GetLastError()); > + > + disp = (void*)0xdeadbeef; > + > + todo_wine > + { > + hr = OleLoadPicturePath(tmp, NULL, 0, 0, &IID_IDispatch, (LPVOID*)&disp); > + ok(hr == INET_E_UNKNOWN_PROTOCOL /*>= XP*/ || > + hr == E_FAIL /*<= 2k*/, "hr %08x\n", hr); > + ok(disp == NULL, "dispatch ptr\n"); > + SysFreeString(tmp); > + tmp = NULL; > + } > + > + file = CreateFileA(filename, GENERIC_READ|GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, 0); > + ok(file != INVALID_HANDLE_VALUE, "file creation error %u\n", GetLastError()); > + if (file != INVALID_HANDLE_VALUE) > + { > + WriteFile(file, "this is not a valid picture", 28, &written, NULL); > + ok(written == 28, "write\n"); > + CloseHandle(file); > + > + disp = (void*)0xdeadbeef; > + todo_wine > + { > + hr = OleLoadPicturePath(bstrname, NULL, 0, 0, &IID_IDispatch, (LPVOID*)&disp); > + ok(hr == E_FAIL, "hr %08x\n", hr); > + ok(disp == NULL, "dispatch ptr\n"); > + } > + } > + > + DeleteFileA(filename); > + > + tmp = SysAllocString(nopath); > + hr = VarBstrCat(bstrname, tmp, &tmp2); > + SysFreeString(bstrname); > + bstrname = tmp2; > + > + disp = (void*)0xdeadbeef; > + todo_wine > + { > + hr = OleLoadPicturePath(bstrname, NULL, 0, 0, &IID_IDispatch, (LPVOID*)&disp); > + ok(hr == INET_E_RESOURCE_NOT_FOUND /*>=XP*/ || > + hr == E_FAIL /*<=2k*/, "hr %08x\n", hr); > + ok(disp == NULL, "dispatch ptr\n"); > + } > + > + SysFreeString(tmp); > + SysFreeString(bstrname); > +} > + > static void test_apm() > { > OLE_HANDLE handle; > @@ -671,6 +980,8 @@ START_TEST(olepicture) > > test_Invoke(); > test_OleCreatePictureIndirect(); > + test_OleLoadPictureFile(); > + test_OleLoadPicturePath(); > test_Render(); > } > Hi Jeremy, Could you please use spaces instead of tabs. I know that this file already has some tabs but please don't add more. -- Cheers, Paul.

Dec. 16, 2008

Re: AppDB rating definitions, was: Re: Canonical and wine

by Austin English

On Mon, Dec 15, 2008 at 10:56 PM, Ben Klein <shacklein(a)gmail.com> wrote: > Mentioning bug severity levels in appdb submission rules is asking for > trouble. Most appdb users don't use bugzilla at all. Agreed. Please bottom post on Wine mailing lists. > 2008/12/16 Rosanne DiMesio <dimesio(a)earthlink.net>: >> On Mon, 15 Dec 2008 19:28:18 -0600 >> "Austin English" <austinenglish(a)gmail.com> wrote: >> >>> 2008/12/15 M.Kiesel <wine-devel(a)continuity.cjb.net>: >>> > On Fri, 12 Dec 2008, Austin English wrote: >>> > >>> >> If I had a nickel for every times I've seen platinum and gold ratings for >>> >> apps that had dozens of native dlls or complicated scripts to work around >>> >> wine bugs, I'd be a much richer man. >>> > >>> > What about clarifying the wording on >>> > http://appdb.winehq.org/help/?sTopic=maintainer_ratings >>> > ? >>> > >> >> I've been thinking about this myself. >> >> My suggestion for "Platinum": >> >> Application runs as well as on Windows "out of the box" (no changes required in winecfg) and has no open, confirmed bugs with a severity higher than enhancement. >> >> My suggestion for "Gold": >> >> Application runs as well as on Windows with some tweaks. Any open, confirmed bugs with a severity higher than "trivial" can be worked around with dll overrides, other settings, or third party software. >> >> My rationale: >> >> 1. If an app doesn't run flawlessly on Windows (and how many do?), we shouldn't expect it to run flawlessly in Wine. >> 2. With complex apps like Word or Photoshop, testers often test only the basic functions, and give a gold or platinum rating based solely on that. Word 2003 currently has 19 bugs linked to it, of which 11 are confirmed, but someone who tested only basic word processing functions could legitimately give it a platinum rating under the current guidelines. We can't force people to test everything, but we can at least limit the top ratings based on known bugs. I like the 'runs as well as on Windows' bit... Much better metric, and accounts for hardware differences, etc. -- -Austin

Dec. 16, 2008

Re: AppDB rating definitions, was: Re: Canonical and wine

by Ben Klein

Mentioning bug severity levels in appdb submission rules is asking for trouble. Most appdb users don't use bugzilla at all. 2008/12/16 Rosanne DiMesio <dimesio(a)earthlink.net>: > On Mon, 15 Dec 2008 19:28:18 -0600 > "Austin English" <austinenglish(a)gmail.com> wrote: > >> 2008/12/15 M.Kiesel <wine-devel(a)continuity.cjb.net>: >> > On Fri, 12 Dec 2008, Austin English wrote: >> > >> >> If I had a nickel for every times I've seen platinum and gold ratings for >> >> apps that had dozens of native dlls or complicated scripts to work around >> >> wine bugs, I'd be a much richer man. >> > >> > What about clarifying the wording on >> > http://appdb.winehq.org/help/?sTopic=maintainer_ratings >> > ? >> > > > I've been thinking about this myself. > > My suggestion for "Platinum": > > Application runs as well as on Windows "out of the box" (no changes required in winecfg) and has no open, confirmed bugs with a severity higher than enhancement. > > My suggestion for "Gold": > > Application runs as well as on Windows with some tweaks. Any open, confirmed bugs with a severity higher than "trivial" can be worked around with dll overrides, other settings, or third party software. > > My rationale: > > 1. If an app doesn't run flawlessly on Windows (and how many do?), we shouldn't expect it to run flawlessly in Wine. > 2. With complex apps like Word or Photoshop, testers often test only the basic functions, and give a gold or platinum rating based solely on that. Word 2003 currently has 19 bugs linked to it, of which 11 are confirmed, but someone who tested only basic word processing functions could legitimately give it a platinum rating under the current guidelines. We can't force people to test everything, but we can at least limit the top ratings based on known bugs. > > Rosanne DiMesio <dimesio(a)earthlink.net> > > >

Dec. 16, 2008

Re: AppDB rating definitions, was: Re: Canonical and wine

by Rosanne DiMesio

On Mon, 15 Dec 2008 19:28:18 -0600 "Austin English" <austinenglish(a)gmail.com> wrote: > 2008/12/15 M.Kiesel <wine-devel(a)continuity.cjb.net>: > > On Fri, 12 Dec 2008, Austin English wrote: > > > >> If I had a nickel for every times I've seen platinum and gold ratings for > >> apps that had dozens of native dlls or complicated scripts to work around > >> wine bugs, I'd be a much richer man. > > > > What about clarifying the wording on > > http://appdb.winehq.org/help/?sTopic=maintainer_ratings > > ? > > I've been thinking about this myself. My suggestion for "Platinum": Application runs as well as on Windows "out of the box" (no changes required in winecfg) and has no open, confirmed bugs with a severity higher than enhancement. My suggestion for "Gold": Application runs as well as on Windows with some tweaks. Any open, confirmed bugs with a severity higher than "trivial" can be worked around with dll overrides, other settings, or third party software. My rationale: 1. If an app doesn't run flawlessly on Windows (and how many do?), we shouldn't expect it to run flawlessly in Wine. 2. With complex apps like Word or Photoshop, testers often test only the basic functions, and give a gold or platinum rating based solely on that. Word 2003 currently has 19 bugs linked to it, of which 11 are confirmed, but someone who tested only basic word processing functions could legitimately give it a platinum rating under the current guidelines. We can't force people to test everything, but we can at least limit the top ratings based on known bugs. Rosanne DiMesio <dimesio(a)earthlink.net>

Dec. 16, 2008

Re: AppDB rating definitions, was: Re: Canonical and wine

by Austin English

2008/12/15 M.Kiesel <wine-devel(a)continuity.cjb.net>: > On Fri, 12 Dec 2008, Austin English wrote: > >> If I had a nickel for every times I've seen platinum and gold ratings for >> apps that had dozens of native dlls or complicated scripts to work around >> wine bugs, I'd be a much richer man. > > What about clarifying the wording on > http://appdb.winehq.org/help/?sTopic=maintainer_ratings > ? > > My suggestion for "Platinum": > "Application installs and runs flawlessly completely/at highest settings > 'out of the box'. No changes required in winecfg." > (add "completely/at highest settings") I think it's fine as is. Some games won't run at highest settings on Windows, due to crappy video card, etc. > For "Gold": > "Application works completely/at highest settings flawlessly in the latest > Wine development release (no patches needed), possibly with DLL overrides, > other settings, or third party software." > (add same as above; add "latest Wine development release"; remove "*some* > DLL overrides) The ratings are done on a per version basis, so no need to stipulate the latest release. The patches and DLL comments I agree with. > I feel that games that are playable only at low settings shouldn't get Gold > or Platinum ratings at all. Other opinions? Depends on how they run in Windows on the same hardware ;-). > Austin: I think for apps that run completely with tweaks a Gold rating is > okay regardless of the number of tweaks involved; for the user it doesn't > matter really whether one or ten DLLs have to be overridden. I wouldn't go > as far as allowing patched Wine versions though. I don't disagree with that, though I see it quite a bit when approving programs in the AppDB (though I'm not the one usually doing it, I only go through the queue when I'm on the AppDB for other reasons). The main problem is when it get a _platinum_ rating. > I also suggest to hyperlink every mention of "Rating" in the browser with > that page. Otherwise it isn't completely clear (without searching) what the > individual ratings mean really. Agreed. > Who has the rights to change AppDB on that level? I'll send a patch tomorrow. If you don't see a change within a few days, remind me. -- -Austin

Dec. 16, 2008

patch to fix bug 8072, but need some help with tests

by ricardo filipe

hi guys! after many days tinkering on this i managed to make the notification work! (pump fist) now media player classic correctly displays the files when browsing on "Open File" with no native libraries :) i would like some feedback on the patch though because there is some "repeated" code and there is a LPITEMIDLIST cast that i've tried to take out using pointers, but i didn't manage to since the variable is a constant... but you guys might know some other way to not use the cast, no? also i would like some help doing tests for this because i'm sure AJ won't accept this without tests. thanks :) _________________________________________________________________ Receba GRÁTIS as mensagens do Messenger no seu celular quando você estiver offline. Conheça o MSN Mobile! http://mobile.live.com/signup/signup2.aspx?lc=pt-br

Dec. 16, 2008

Re: Another machine passing tests

by Alasdair Sinclair

Austin English wrote: > On Mon, Dec 15, 2008 at 2:04 PM, Zachary Goldberg <zgold(a)bluesata.com> wrote: > >> All, >> >> It seems we have another machine which passes all tests on Wine >> >> http://test.winehq.org/data/bd25af9dba280e3d80f3080140f2f5ab2cd0dfb3/ >> >> Huzzah! >> >> --Zach >> >> >> >> > > Who's machine is that, Aric's? > > Hi Thats my machine. It seems to fluctuate between one and two errors, I guess this time I got lucky this time. Alasdair

Dec. 16, 2008

Re: AppDB rating definitions, was: Re: Canonical and wine

by Sparr

I think that Highest Settings is unfair, there are issues with many games in Windows with settings maxed (Check Oblivion forums, every problem we have in wine is also had by people in native windows). Default settings is a far more appropriate measuring stick. I also think there needs to be a reviewer meta-review system, similar to slashdot's karma system. There are a few reviewers consistently rating 1 or 2 steps above what they should. "Rating: Gold. What doesn't work: Sound. What wasn't tested: Multiplayer." WTF? 2008/12/15 M.Kiesel <wine-devel(a)continuity.cjb.net>: > My suggestion for "Platinum": > "Application installs and runs flawlessly completely/at highest settings > 'out of the box'. No changes required in winecfg." > (add "completely/at highest settings") > > For "Gold": > "Application works completely/at highest settings flawlessly in the latest > Wine development release (no patches needed), possibly with DLL overrides, > other settings, or third party software." > (add same as above; add "latest Wine development release"; remove "*some* > DLL overrides) > > I feel that games that are playable only at low settings shouldn't get Gold > or Platinum ratings at all. Other opinions? > > Austin: I think for apps that run completely with tweaks a Gold rating is > okay regardless of the number of tweaks involved; for the user it doesn't > matter really whether one or ten DLLs have to be overridden. I wouldn't go > as far as allowing patched Wine versions though. > > I also suggest to hyperlink every mention of "Rating" in the browser with > that page. Otherwise it isn't completely clear (without searching) what the > individual ratings mean really. > Who has the rights to change AppDB on that level? > > Regards

Dec. 16, 2008

Re: Unused vtables and debug channels

by Andrew Talbot

Ken Thomases wrote: > On Dec 15, 2008, at 3:41 PM, Andrew Talbot wrote: > >> It appears that the following vtables and Wine debug channels are >> not being used, so I am considering removing them. Please let me >> know, therefore, if you have plans for any of them and want them kept. >> >> >> Wine debug channels in: >> >> [...] >> winecoreaudio.drv/audiounit.c > > What debug channel is unused in this file? > > -Ken Hi Ken, I used the word "appears" above because this list was suggested by static analysis. Of course, I would examine each file before actually editing it. I think this one was flagged because the debug channel is declared before the bulk of the file is conditionally #ifdef'd in: WINE_DEFAULT_DEBUG_CHANNEL(wave); #ifdef HAVE_AUDIOUNIT_AUDIOUNIT_H ... -- Andy.

Dec. 16, 2008

AppDB rating definitions, was: Re: Canonical and wine

by M.Kiesel

On Fri, 12 Dec 2008, Austin English wrote: > If I had a nickel for every times I've seen platinum and gold ratings > for apps that had dozens of native dlls or complicated scripts to work > around wine bugs, I'd be a much richer man. What about clarifying the wording on http://appdb.winehq.org/help/?sTopic=maintainer_ratings ? My suggestion for "Platinum": "Application installs and runs flawlessly completely/at highest settings ‘out of the box‘. No changes required in winecfg." (add "completely/at highest settings") For "Gold": "Application works completely/at highest settings flawlessly in the latest Wine development release (no patches needed), possibly with DLL overrides, other settings, or third party software." (add same as above; add "latest Wine development release"; remove "*some* DLL overrides) I feel that games that are playable only at low settings shouldn't get Gold or Platinum ratings at all. Other opinions? Austin: I think for apps that run completely with tweaks a Gold rating is okay regardless of the number of tweaks involved; for the user it doesn't matter really whether one or ten DLLs have to be overridden. I wouldn't go as far as allowing patched Wine versions though. I also suggest to hyperlink every mention of "Rating" in the browser with that page. Otherwise it isn't completely clear (without searching) what the individual ratings mean really. Who has the rights to change AppDB on that level? Regards

Dec. 16, 2008

Re: Unused vtables and debug channels

by Ken Thomases

On Dec 15, 2008, at 3:41 PM, Andrew Talbot wrote: > It appears that the following vtables and Wine debug channels are > not being used, so I am considering removing them. Please let me > know, therefore, if you have plans for any of them and want them kept. > > > Wine debug channels in: > > [...] > winecoreaudio.drv/audiounit.c What debug channel is unused in this file? -Ken

Dec. 15, 2008

Re: Unused vtables and debug channels

by James Hawkins

On Mon, Dec 15, 2008 at 3:36 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > 2008/12/15 James Hawkins <truiken(a)gmail.com>: >> Why would you remove any of them? That's like removing stub functions >> because we don't know if they're ever called. >> > Although it probably doesn't make sense to remove these if people have > plans for them, I do think that in general you shouldn't add code > until it's actually needed. > In general sure, but this is an open source project where time commitments are rarely guaranteed. For most of the listed cases, I'm sure the plan was to implement them more fully as soon as possible. My point is that code cleanup is good, but not to this extent. Removing dead code is a worthy goal, but I can't imagine a case where a stubbed interface implementation is dead code. -- James Hawkins

Dec. 15, 2008

Re: Unused vtables and debug channels

by Henri Verbeet

2008/12/15 Austin English <austinenglish(a)gmail.com>: > The same argument would apply to the debug channels. They don't hurt > anything, and when needed, are easier to use if already in place. > > What do you gain by removing them? > It doesn't work that way. The question should be if you can justify keeping a piece of code.

Dec. 15, 2008

Re: Unused vtables and debug channels

by Henri Verbeet

2008/12/15 James Hawkins <truiken(a)gmail.com>: > Why would you remove any of them? That's like removing stub functions > because we don't know if they're ever called. > Although it probably doesn't make sense to remove these if people have plans for them, I do think that in general you shouldn't add code until it's actually needed.

Dec. 15, 2008

Re: Unused vtables and debug channels

by Austin English

On Mon, Dec 15, 2008 at 4:52 PM, Andrew Talbot <Andrew.Talbot(a)talbotville.com> wrote: > James Hawkins wrote: > >> >> Why would you remove any of them? That's like removing stub functions >> because we don't know if they're ever called. >> > > OK. I get the message; I shall leave the vtables alone. May I take out the > unused debug channels, though? I presume they can easily be re-introduced > where required. > > -- > Andy. > > > > > The same argument would apply to the debug channels. They don't hurt anything, and when needed, are easier to use if already in place. What do you gain by removing them? -- -Austin

Dec. 15, 2008

Re: Unused vtables and debug channels

by Andrew Talbot

James Hawkins wrote: > > Why would you remove any of them? That's like removing stub functions > because we don't know if they're ever called. > OK. I get the message; I shall leave the vtables alone. May I take out the unused debug channels, though? I presume they can easily be re-introduced where required. -- Andy.

Dec. 15, 2008

Re: Unused vtables and debug channels

by Christian Costa

I Agree. There was also this can of cleanup in d3dxof and direct music dlls whereas there are not complete. Some code are put in place as placeholder for future developments in one hand and there is some clean-up to remove them in the other. I don't see the point. Christian James Hawkins a écrit : > On Mon, Dec 15, 2008 at 1:41 PM, Andrew Talbot > <andrew.talbot(a)talbotville.com> wrote: > >> It appears that the following vtables and Wine debug channels are not being used, so I am considering removing them. Please let me know, therefore, if you have plans for any of them and want them kept. >> >> >> > > Why would you remove any of them? That's like removing stub functions > because we don't know if they're ever called. > > > Yes to keeping the following two, and I'm pretty sure you're going to > get the same response for the entire list. They're stubbed out > because they need to be implemented. The APIs that provide access to > the objects are stubs as well, which is why you're saying they're not > being used. > > >> AssemblyCacheItemVtbl fusion/asmcache.c >> AssemblyEnumVtbl fusion/asmcache.c >> > > >

Dec. 15, 2008

Re: amstream: Some fixes

by Christian Costa

Alexandre Julliard a écrit : > Christian Costa <titan.costa(a)wanadoo.fr> writes: > > >> commit bb5a3b161d69bb2dc0e5be8cbbc5268dbc7d513f >> Author: Christian Costa <titan.costa(a)wanadoo.fr> >> Date: Sun Dec 14 00:46:24 2008 +0100 >> >> Some fixes. >> > > Please avoid white space changes, and provide a proper log message, > "some fixes" doesn't say anything about the change. > > I did it a little too fast, sorry. Will be more careful next time. :-) Christian

Dec. 15, 2008

Re: d3dxof: Add a test to dump an X object data (enabled when objects.txt and templates.txt are present) (try 2)

by Christian Costa

Hi Stefan, Damned. You discovered all my secret activities. ;-) More seriously, thanks for noticing that. :-) There is some memory leakage issues remaining which cause some apps to run out of memory. This is due to the lack of ref count handling between objects. Bug 16293 deals with that. http://bugs.winehq.org/show_bug.cgi?id=16293 That should be fixed soon. Now I would like to thank you with all d3d guys for the work you've done so far. This is a big piece of work. Even if I cannot enjoy all advanced shaders stuff with my poor G-Force 2 that replaced my dead R300, I find a lot of improvement in that area. Currently I'm very surprised how gaming has improved since 2 or 3 years. Almost all games I'm playing currently install fine and run flawlessly apart from few small graphics glitches. I thank all wine developers for making it possible. That said I'm still waiting for playing Myst under Wine. ;-) Keep up the good work ! :-) Cheers, Christian Stefan Dösinger a écrit : > Hi all, > I just wanted to take the opportunity to draw some attention to Christian's > great work on these higher-level DirectX libraries. I didn't really notice > it until I accidentally ran some dx8 sdk samples with the builtin d3dxof and > it just worked instead of complaining about lots of stubs. > > His whole work has been pretty silent, but I think Christian deserves lots > of credits here. Good work! > > > >> -----Original Message----- >> From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- >> bounces(a)winehq.org] On Behalf Of Christian Costa >> Sent: Sunday, December 14, 2008 6:53 PM >> To: wine-patches(a)winehq.org >> Subject: d3dxof: Add a test to dump an X object data (enabled when >> objects.txt and templates.txt are present) (try 2) >> >> Fixed stdio include that broke make dep. >> > > > > > > >

Dec. 15, 2008

Re: Unused vtables and debug channels

by Henri Verbeet

2008/12/15 Andrew Talbot <andrew.talbot(a)talbotville.com>: > secur32/schannel.c This one isn't unused, but all its uses are inside an #ifdef.

Dec. 15, 2008

Re: Unused vtables and debug channels

by James Hawkins

On Mon, Dec 15, 2008 at 1:41 PM, Andrew Talbot <andrew.talbot(a)talbotville.com> wrote: > It appears that the following vtables and Wine debug channels are not being used, so I am considering removing them. Please let me know, therefore, if you have plans for any of them and want them kept. > > Why would you remove any of them? That's like removing stub functions because we don't know if they're ever called. Yes to keeping the following two, and I'm pretty sure you're going to get the same response for the entire list. They're stubbed out because they need to be implemented. The APIs that provide access to the objects are stubs as well, which is why you're saying they're not being used. > AssemblyCacheItemVtbl fusion/asmcache.c > AssemblyEnumVtbl fusion/asmcache.c -- James Hawkins

Dec. 15, 2008

Unused vtables and debug channels

by Andrew Talbot

It appears that the following vtables and Wine debug channels are not being used, so I am considering removing them. Please let me know, therefore, if you have plans for any of them and want them kept. Vtables: IDirectXFileBinary_Vtbl d3dxof/d3dxof.c IDirectXFileObject_Vtbl d3dxof/d3dxof.c IDirectXFileSaveObject_Vtbl d3dxof/d3dxof.c DirectMusicPortDownload_Vtbl dmusic/portdownload.c DirectMusicThru_Vtbl dmusic/thru.c DirectMusicSegment8_Segment_Vtbl dswave/dswave.c AssemblyCacheItemVtbl fusion/asmcache.c AssemblyEnumVtbl fusion/asmcache.c InkCollectorVtbl inkobj/inkcollector.c HTMLInputTextElementVtbl mshtml/htmlinput.c MemInputPin_Vtbl quartz/nullrenderer.c OutputPin_Vtbl* quartz/pin.c InputPin_Vtbl* quartz/pin.c PullPin_Vtbl* quartz/pin.c MemInputPin_Vtbl quartz/transform.c MemInputPin_Vtbl quartz/videorenderer.c *Shadow variable(s) present. Wine debug channels in: comctl32/theme_button.c d3drm/math.c d3dx8/mesh.c d3dx9_24/d3dx9_24_main.c d3dx9_25/d3dx9_25_main.c d3dx9_26/d3dx9_26_main.c d3dx9_27/d3dx9_27_main.c d3dx9_28/d3dx9_28_main.c d3dx9_30/d3dx9_30_main.c d3dx9_31/d3dx9_31_main.c d3dx9_32/d3dx9_32_main.c d3dx9_33/d3dx9_33_main.c d3dx9_34/d3dx9_34_main.c d3dx9_35/d3dx9_35_main.c d3dx9_36/d3dx9_36_main.c d3dx9_37/d3dx9_37_main.c dmime/dmutils.c dmstyle/dmutils.c jscript/parser.tab.c kernel32/fiber.c kernel32/relay16.c msvcr71/msvcr71.c msvcrt40/msvcrt40.c ole32/oleproxy.c riched20/table.c secur32/schannel.c sxs/sxs.c winealsa.drv/waveinit.c winecoreaudio.drv/audiounit.c winecoreaudio.drv/coremidi.c Thanks, -- Andy.

Dec. 15, 2008

Re: msi: improve a debugging message

by James Hawkins

On Mon, Dec 15, 2008 at 1:15 PM, Austin English <austinenglish(a)gmail.com> wrote: > -- > -Austin > Are you adding this because you've been debugging the msi db code? Knowing the row number that we failed to insert is not helpful. In most cases, this message is harmless and should be a warn or removed completely as this is hit if the row already exists in the db (common). Please don't send in a patch for that change, as I'm waiting till I write an exhaustive set of tests for transforms before removing the message. -- James Hawkins

Dec. 15, 2008

Re: Another machine passing tests

by Paul Vriens

Zachary Goldberg wrote: > All, > > It seems we have another machine which passes all tests on Wine > > http://test.winehq.org/data/bd25af9dba280e3d80f3080140f2f5ab2cd0dfb3/ > > Huzzah! > > --Zach > > And unfortunately it has one error in the last run. Getting consistent test results will be a major task in itself I guess. -- Cheers, Paul.

Dec. 15, 2008