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

Re: Another machine passing tests

by Austin English

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? -- -Austin

Dec. 15, 2008

Re: [4/10] WineD3D: Some GL_EXT_fog_coord prototype fixes

by Henri Verbeet

2008/12/15 Stefan Dösinger <stefan(a)codeweavers.com>: > -typedef void (WINE_GLAPI * PGLFNGLFOGCOORDFVEXTPROC) (GLfloat intesity); > -typedef void (WINE_GLAPI * PGLFNGLFOGCOORDDEXTPROC) (GLfloat intesity); > -typedef void (WINE_GLAPI * PGLFNGLFOGCOORDDVEXTPROC) (GLfloat intesity); > +typedef void (WINE_GLAPI * PGLFNGLFOGCOORDFVEXTPROC) (const GLfloat *intesity); > +typedef void (WINE_GLAPI * PGLFNGLFOGCOORDDEXTPROC) (GLdouble intesity); > +typedef void (WINE_GLAPI * PGLFNGLFOGCOORDDVEXTPROC) (const GLdouble *intesity); > You might as well fix the parameter names while you're at it :-)

Dec. 15, 2008

Another machine passing tests

by Zachary Goldberg

All, It seems we have another machine which passes all tests on Wine http://test.winehq.org/data/bd25af9dba280e3d80f3080140f2f5ab2cd0dfb3/ Huzzah! --Zach

Dec. 15, 2008

Re: wine-1.2 release criteria?

by Massimo Del Fedele

Reece Dunn ha scritto: > 2008/12/15 Dan Kegel <dank(a)kegel.com>: > >> - DIB Engine >> As mentioned in >> http://www.winehq.org/wwn/354#Another%20shot%20at%20a%20DIB%20Engine >> Massimo picked up Jesse's DIB engine code and has been trying to >> use it with Autocad. He says he's starting to get fonts working. >> (It's surprising that he chose Jesse's 2007 implementation >> rather than Huw's 2008 implementation, but he said Jesse's >> seemed more usable at the moment, even though Huw's >> looked better in some ways). > > What is the status of these? As far as I can tell, there are a few > changes that could be merged into wine proper, without pulling in the > respective DIB engines: > > Huw -- gdi32: The dib colour table should always have 1 << bpp entries > (for bpp <= 8). > http://repo.or.cz/w/wine/dibeng-hd.git?a=commitdiff;h=4c9188ee5e8c56aa0fb57… > > Huw -- gdi32: Don't use biSizeImage for a BI_BITFIELDS dib. > http://repo.or.cz/w/wine/dibeng-hd.git?a=commitdiff;h=892bd17b188f8afa23030… > > Jesse -- gdi32: Keep physDevs consistent to driver in Blt calls > http://repo.or.cz/w/wine/dibdrv.git?a=commitdiff;h=754f91a30771a76e4704397f… > > Jesse -- gdi32: Pass color table to drivers with SelectBitmap > http://repo.or.cz/w/wine/dibdrv.git?a=commitdiff;h=9b60e63fd31877c7350c757b… > > From there, it depends on whether Huw's approach, Jesse's approach or > some other approach is the way to go. It would be useful to try and > get the 'core' DIB engine architecture in first, so that any necessary > changes to the architecture can be made before too much time/effort is > spent on this. > > The core should have an option to turn on the DIB engine routing, so > that it can live in the main tree without breaking existing > applications. Once the core architecture is in place, it will then be > a matter of filling in the blanks. > > From there, the selection logic (which should be fairly small -- a > registry key check, like the Direct3D fbo setting?) can be removed. > > Or am I missing something? > > - Reece > > > No, you aren't missing much :-) I'm (slowly) going on with dib engine, I choose at first Jesse's one as starting point because it had a source file structure I liked more. Now I'm merging Huw's one, it has ROP support, pen and brushes.... Stuffs are going on. I paused the font code for a while, it's very basic by now but I wanted to see "something" in order to test the speed difference in autocad.... which is awesome. The engine still have some bugs that cause it crashing sometimes... I'm investigating about it before going on. When I'll get something stable I'll post the code somewhere. About disabling/enabling the engine, there are 4 choices : 1-by registry 2-by environment variable 3-by ./configure 4-simply removing winedib.dll.so; driver goes thru x11 if it doesn't exist. Ciao Max

Dec. 15, 2008

Re: wine-1.2 release criteria?

by Pavel Troller

> > * USB Support (iPod, etc.) > No motion here, I think. > I see a big potential here. What makes me crazy, is to beg my colleagues running windoze to - flash my Nokia phone with a new firmware - Program an EPROM in a progammer - Use an SDR (Software Defined Radio) - a box with just a radio hardware without any classic controls, controlled entirely from a PC - etc. etc... All these things have a common denominator: proprietary USB drivers. It's fine that wine can use USB scanners/cameras/printers etc, which can be interfaced though native Linux drivers/libraries, but these are almost always usable directly from Linux, while those proprietary devices aren't. Is there any chance that wine will progress in this area ? I'm ready to supply a bounty for a volunteer making some progress here. With regards, Pavel Troller

Dec. 15, 2008

Re: wine-1.2 release criteria?

by Reece Dunn

2008/12/15 Dan Kegel <dank(a)kegel.com>: > - DIB Engine > As mentioned in > http://www.winehq.org/wwn/354#Another%20shot%20at%20a%20DIB%20Engine > Massimo picked up Jesse's DIB engine code and has been trying to > use it with Autocad. He says he's starting to get fonts working. > (It's surprising that he chose Jesse's 2007 implementation > rather than Huw's 2008 implementation, but he said Jesse's > seemed more usable at the moment, even though Huw's > looked better in some ways). What is the status of these? As far as I can tell, there are a few changes that could be merged into wine proper, without pulling in the respective DIB engines: Huw -- gdi32: The dib colour table should always have 1 << bpp entries (for bpp <= 8). http://repo.or.cz/w/wine/dibeng-hd.git?a=commitdiff;h=4c9188ee5e8c56aa0fb57… Huw -- gdi32: Don't use biSizeImage for a BI_BITFIELDS dib. http://repo.or.cz/w/wine/dibeng-hd.git?a=commitdiff;h=892bd17b188f8afa23030… Jesse -- gdi32: Keep physDevs consistent to driver in Blt calls http://repo.or.cz/w/wine/dibdrv.git?a=commitdiff;h=754f91a30771a76e4704397f… Jesse -- gdi32: Pass color table to drivers with SelectBitmap http://repo.or.cz/w/wine/dibdrv.git?a=commitdiff;h=9b60e63fd31877c7350c757b… >From there, it depends on whether Huw's approach, Jesse's approach or some other approach is the way to go. It would be useful to try and get the 'core' DIB engine architecture in first, so that any necessary changes to the architecture can be made before too much time/effort is spent on this. The core should have an option to turn on the DIB engine routing, so that it can live in the main tree without breaking existing applications. Once the core architecture is in place, it will then be a matter of filling in the blanks. >From there, the selection logic (which should be fairly small -- a registry key check, like the Direct3D fbo setting?) can be removed. Or am I missing something? - Reece

Dec. 15, 2008

Re: wine-1.2 release criteria?

by Paul Vriens

Dan Kegel wrote: > - Tests that pass > We're making progress here, but it's hard to quantify. > http://test.winehq.org shows some runs still failing > 20% of the tests, and others failing 0.3%, because > we don't have a consistent set of machines running the > tests. I would love to see that site add a feature showing > the failure history for particular machines. > I am doing this locally with my (6) testboxes. This way it's very easy to spot differences or even flaky and inconsitent test results (see attached screenshot). This is nice for me as I only have 1 box per OS. Not sure how this will work out on test.winehq.org. And I'm not even talking about the extra amount of diskspace we need for this. -- Cheers, Paul.

Dec. 15, 2008

wine-1.2 release criteria?

by Dan Kegel

It's been six months since the release of 1.0, maybe now is a good time to review the 1.2 release criteria listed in http://www.winehq.org/wwn/353#WineConf%202008%20Keynote One big item that wasn't listed is "make asian users happy". I think we're starting to see some motion on that, cf. http://bugs.winehq.org/show_bug.cgi?id=16325 This is exciting... getting this fixed might bring in a lot of asian developers / testers / users. I'm nominating this one for 1.2. The criteria listed by Alexandre were: * Fix the remnant bugs from 1.0 (the new 1.2 bug milestone) * Better desktop integration with respect to transparency and desktop mode * Tests that pass Plus some 'nice to have' items. Would like at least one for 1.2: * DIB Engine * Quartz Driver * Direct3D 10 * USB Support (iPod, etc.) * 64-bit support Taking the one by one: - There are 83 open bugs nominated for 1.2: http://bugs.winehq.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bu… We'll probably end up deferring a lot of these, and adding a few more. (If you think a bug not on this list needs adding to the list, add a comment to the bug saying "Nominating for 1.2.") - Better desktop integration with respect to transparency and desktop mode I don't know about this one, can somebody report on the status? - Tests that pass We're making progress here, but it's hard to quantify. http://test.winehq.org shows some runs still failing 20% of the tests, and others failing 0.3%, because we don't have a consistent set of machines running the tests. I would love to see that site add a feature showing the failure history for particular machines. Nice-to-have items: the last status update on these two months ago is at http://www.winehq.org/wwn/353#Updates%20on%20The%20Big%20Tickets:%20Quartz,… Here's what I know has changed since then: - DIB Engine As mentioned in http://www.winehq.org/wwn/354#Another%20shot%20at%20a%20DIB%20Engine Massimo picked up Jesse's DIB engine code and has been trying to use it with Autocad. He says he's starting to get fonts working. (It's surprising that he chose Jesse's 2007 implementation rather than Huw's 2008 implementation, but he said Jesse's seemed more usable at the moment, even though Huw's looked better in some ways). * Quartz Driver Any update? * Direct3D 10 Any update? And does anybody care? * USB Support (iPod, etc.) No motion here, I think. * 64-bit support Thanks to the gcc guy, Maarten, and Alexandre, "hello world" is working. Maarten is working on relay support now. These are exicting times for Wine... it doesn't feel like it's quite time to start a 1.2 release countdown, but maybe in a couple months.

Dec. 15, 2008

Re: user32: Sign-compare warnings fix (Try 2)

by James Mckenzie

-----Original Message----- >From: Alexandre Julliard <julliard(a)winehq.org> >Sent: Dec 15, 2008 5:25 AM >To: Andrew Talbot <andrew.talbot(a)talbotville.com> >Cc: wine-devel(a)winehq.org >Subject: Re: user32: Sign-compare warnings fix (Try 2) > >Andrew Talbot <andrew.talbot(a)talbotville.com> writes: > >> diff --git a/dlls/user32/dialog.c b/dlls/user32/dialog.c >> index 9dd9083..4ea1959 100644 >> --- a/dlls/user32/dialog.c >> +++ b/dlls/user32/dialog.c >> @@ -84,9 +84,9 @@ typedef struct >> /* Radio button group */ >> typedef struct >> { >> - UINT firstID; >> - UINT lastID; >> - UINT checkID; >> + INT firstID; >> + INT lastID; >> + INT checkID; >> } RADIOGROUP; > >This change would need a test case. > Alexandre/Andrew: I don't think this change is necessary, unless there is checking against a -1 somewhere in the code. Also, I would like to see an array of 32K or so radio buttons somewhere in Windows code. James McKenzie

Dec. 15, 2008

Re: user32: Sign-compare warnings fix (Try 2)

by Alexandre Julliard

Andrew Talbot <andrew.talbot(a)talbotville.com> writes: > diff --git a/dlls/user32/dialog.c b/dlls/user32/dialog.c > index 9dd9083..4ea1959 100644 > --- a/dlls/user32/dialog.c > +++ b/dlls/user32/dialog.c > @@ -84,9 +84,9 @@ typedef struct > /* Radio button group */ > typedef struct > { > - UINT firstID; > - UINT lastID; > - UINT checkID; > + INT firstID; > + INT lastID; > + INT checkID; > } RADIOGROUP; This change would need a test case. -- Alexandre Julliard julliard(a)winehq.org

Dec. 15, 2008

Re: amstream: Some fixes

by Alexandre Julliard

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. -- Alexandre Julliard julliard(a)winehq.org

Dec. 15, 2008

Re: richedit: OpenClipboard doesn't need to be given a window handle.

by Alexandre Julliard

"Dylan Smith" <dylan.ah.smith(a)gmail.com> writes: > I have been looking to reduce the number of places where window handles > are used, so I did a relay trace to see if native richedit controls gave > a non-null handle when calling OpenClipboard. The relay trace showed > that NULL was being used, even for normal windowed richedit controls. Please don't do that. The calls that native makes are part of the internal workings that you are not supposed to peek into. You should treat native as a black box and only replicate behavior that can be observed through test cases. -- Alexandre Julliard julliard(a)winehq.org

Dec. 15, 2008

Re: Wine64 hello world app runs!

by Maarten Lankhorst

Hi Zach, Zachary Goldberg schreef: > 2008/12/5 Maarten Lankhorst <m.b.lankhorst(a)gmail.com>: > >> ... > > So 9 days, a WWN article, and a Slashdot article this story's gotten a > lot of press. I know we've talked a bit offline Maarten about this > but would you perhaps have any other updates for readers at large? I > know you've been mentioning a bit about getting +relay to work and > messing with some intricacies in the AMD64 instructions. > Kai Tietz and I have been working on squashing all gcc related bugs. Now that they are gone I'm moving on to other stuff. Right now I want to have +relay working so that debugging will be a bit easier to do. If this works then I will need to work on exception handling and moving menus to wineserver. I will also need to talk with AJ some more about what he exactly wants from wineserver for 64-bits compatibility. There's enough to do without even worrying about the WoW64 stuff, so more help is of course welcome. :) Cheers, Maarten.

Dec. 15, 2008

Regression - Photoshop CS3 tryout won't install anymore?

by Dan Kegel

Bleah: http://bugs.winehq.org/show_bug.cgi?id=15590 Golly. After all the work we put into getting Photoshop running, I hope we don't regress...

Dec. 14, 2008

Re: Wine64 hello world app runs!

by Zachary Goldberg

2008/12/5 Maarten Lankhorst <m.b.lankhorst(a)gmail.com>: > Hi guys, > > I can finally report success on the first ever win64 program running on > wine. The program was a textbook classic, but to make it work gcc had to > be changed a lot. This was done by Kai Tietz, who has put a lot of > effort in the task of making gcc accept the calling convention. > > There are still a lot of things which should be done before this will be > able to get into mainline though. > > My repository is at http://repo.or.cz/w/wine/wine64.git , but in order > to actually get it working you need gcc checked out from subversion with > some experimental patches. They are expected to get merged soon, so > until then it is not recommended to even try. :) > > There are a bunch of things in my tree which are not merged with > mainline. A few of them are hacks (disabling SEGV handling for example). > > There are also some changes which should be accepted, but still need > some work. For example wineserver, AJ wants something with regards to fd > handling, but I didn't find him clear on what exactly. va_list also is > incompatible, and should be replaced with ms_va_list where appropiate. > > Once again, thanks to Kai Tietz for making this possible. > > Cheers, > Maarten. > > > So 9 days, a WWN article, and a Slashdot article this story's gotten a lot of press. I know we've talked a bit offline Maarten about this but would you perhaps have any other updates for readers at large? I know you've been mentioning a bit about getting +relay to work and messing with some intricacies in the AMD64 instructions.

Dec. 14, 2008

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

by Stefan Dösinger

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. 14, 2008

IE, mshtml.dll, oledb32.dll and vulnerability in XML parsing / data binding

by Saulius Krasuckas

Hello, I noticed article about some IE issue: [1] And couldn't stop smiling at the amount and spectre of the workarounds needed to prevent attacks ;) And maybe Jacek (or some other mshtml guy) could test Wine's html engine against the external test case [2] to see whether we are better at handling [3] such XMLs. [1] http://www.pcmag.com/article2/0,2817,2336831,00.asp [2] http://www.milw0rm.com/exploits/7410 [3] http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4844

Dec. 14, 2008

Re: amstream: Some fixes

by Vincent Povirk

Please send a separate patch for each group of related changes, per http://winehq.org/sending_patches Vincent Povirk On Sun, Dec 14, 2008 at 12:07 PM, Christian Costa <titan.costa(a)wanadoo.fr> wrote: > > > > >

Dec. 14, 2008

Re: [resend2] gdi32/tests: Add a test for GdiGetCodePage().

by Peter Oberndorfer

On Sonntag 14 Dezember 2008, ByeongSik Jeon wrote: > http://bugs.winehq.org/show_bug.cgi?id=16325 > > 2008-12-14 (Sun), 13:34 +0100, Paul Vriens wrote: > > Could you turn the skip in this piece of code: > > > > + if (!pGdiGetCodePage) > > + { > > + skip("GdiGetCodePage not available on this platform\n"); > > + return; > > + } > > > > into a win_skip? That way we fail if the function is not available in Wine. > > > I changed it to the trace(). > > Another thing I'm not sure about though is that in the for() loop you > > don't do a DeleteObject( hfont ). Is that only needed at the end? > > Thanks. > > --- > dlls/gdi32/tests/Makefile.in | 2 +- > dlls/gdi32/tests/font.c | 153 ++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 154 insertions(+), 1 deletions(-) > Hi, some small style notes. > + CHARSETINFO csi; > + > + if ( ( ansi_assoc == -1 || oem_assoc == -1 ) && > + RegOpenKeyA ( HKEY_LOCAL_MACHINE, associated_charset, &hkey) == ERROR_SUCCESS ) > + { > + RegQueryInfoKeyA ( hkey, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, &max_data_len, NULL, NULL ); > + data = HeapAlloc ( GetProcessHeap(), 0, max_data_len ); > + please try to use similar spacing like other parts of the file no space before and after '(' when calling a function. > + case MAC_CHARSET: > + acp = GetACP(); > + cp = ( acp == 932 || acp == 936 || acp == 949 || acp == 950 )? 1252 : CP_ACP; > + break; Please try to avoid trailing whitespace > + JOHAB_CHARSET, > + VISCII_CHARSET, > + TCVN_CHARSET, > + KOI8_CHARSET, > + ISO3_CHARSET, > + ISO4_CHARSET, > + ISO10_CHARSET, > + CELTIC_CHARSET, also some trailing whitespace here. Thanks for you patch. Greetings Peter

Dec. 14, 2008

Re: [resend2] gdi32/tests: Add a test for GdiGetCodePage().

by Paul Vriens

ByeongSik Jeon wrote: > http://bugs.winehq.org/show_bug.cgi?id=16325 > > 2008-12-14 (Sun), 13:34 +0100, Paul Vriens wrote: >> Could you turn the skip in this piece of code: >> >> + if (!pGdiGetCodePage) >> + { >> + skip("GdiGetCodePage not available on this platform\n"); >> + return; >> + } >> >> into a win_skip? That way we fail if the function is not available in Wine. >> > I changed it to the trace(). >> Another thing I'm not sure about though is that in the for() loop you >> don't do a DeleteObject( hfont ). Is that only needed at the end? > > Thanks. > > --- > dlls/gdi32/tests/Makefile.in | 2 +- > dlls/gdi32/tests/font.c | 153 ++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 154 insertions(+), 1 deletions(-) > > > ------------------------------------------------------------------------ > > Hi, The trace() is worse. The first one should be a win_skip() the second one a skip(), so: if (!pGdiGetCodePage) { win_skip("GdiGetCodePage not available on this platform\n"); return; } if (!is_font_installed( "Arial" ) ) { skip("Arial is not installed\n"); return; } The win_skip() means we skip the test on Windows if this function is not present but it will fail on Wine if this function is not there(exported). This will make sure that nobody messes up this function . The skip() will make sure we skip the tests on all platforms if Arial is not available. For that second item. Isn't it enough to put the GetDC() before the for-loop and the ReleaseDC after the for-loop? -- Cheers, Paul.

Dec. 14, 2008

Re: [resend] gdi32/tests: Add a test for GdiGetCodePage().

by Paul Vriens

ByeongSik Jeon wrote: > http://bugs.winehq.org/show_bug.cgi?id=16325 > --- > dlls/gdi32/tests/Makefile.in | 2 +- > dlls/gdi32/tests/font.c | 152 ++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 153 insertions(+), 1 deletions(-) > > > ------------------------------------------------------------------------ > > Hi, Could you turn the skip in this piece of code: + if (!pGdiGetCodePage) + { + skip("GdiGetCodePage not available on this platform\n"); + return; + } into a win_skip? That way we fail if the function is not available in Wine. Another thing I'm not sure about though is that in the for() loop you don't do a DeleteObject( hfont ). Is that only needed at the end? -- Cheers, Paul.

Dec. 14, 2008

implicit declaration of function '_mkdir'

by Gerald Pfeifer

I am mostly offline (2s ping times) for another two weeks, but noticed the following starting a couple of days ago on my nightly FreeBSD 6.4 tester: server.c:755: warning: implicit declaration of function '_mkdir' shellpath.c:2163: warning: implicit declaration of function '_mkdir' shfldr_unixfs.c:1745: warning: implicit declaration of function '_mkdir' xdg.c:253: warning: implicit declaration of function '_mkdir' theme.c:966: warning: implicit declaration of function '_mkdir' winemenubuilder.c:707: warning: implicit declaration of function '_mkdir' fd.c:1562: warning: implicit declaration of function '_mkdir' request.c:530: warning: implicit declaration of function '_mkdir' Perhaps one of you has an idea where this might come from and how to avoid it? Gerald

Dec. 14, 2008

Re: No response to updated patch for gdi32/StretchDIBits

by Mathias Kosch

Hello Сергей! > Hi, Mathias. I'm working on DIB Engine for Wine. Some of DIB functions was > developed separatly inthe DIB Driver, but it's necessary to develop DIB > Engine functions inside GDI 32. What DIB function tests are you working on? > Is it only "StretchDIBBits" or something else? I'm developing some DIB tests > now and want to avoid any collisions with other developers in this bug. Sorry, I didn't notice your answer until now. I'm only working on a patch for "StretchDIBBits". -- Mathias Kosch <info(a)mkosch.de> | http://www.mkosch.de/ RSA Public Key: http://www.mkosch.de/pubkey Deutsch-Englisches Wörterbuch: http://dict.leo.org/

Dec. 13, 2008

Re: Bugfix-patches for dlls/comdlg32/filedlg.c

by Paul Vriens

Elias wrote: > - Fix for bugzilla bug 16332 > crash in file dialog if the previous selected folder is deleted > > No checking was done on the selected initial directory for the > open-file dialog, which resulted in a stack overflow if the directory > was not present. > > - Prevent free on NULL values > A typo made the CommDlg32 leak memory and potenially free NULL values. > Checks added/changed in two places. > > > > ------------------------------------------------------------------------ > > Hi, Apart from the remark that Austin made about the 'only one patch per e-mail" I think the part about the 'free on NULL values' can be improved. MemFree is a wrapper around HeapFree and there is no need to check for NULL when calling HeapFree. So it's better to get rid of the whole if() altogether (and correctly indent the MemFree of course). -- Cheers, Paul.

Dec. 13, 2008

Re: RFC: Wine Icons

by Roderick Colenbrander

> > Joel Holdsworth <joel(a)airwebreathe.org.uk> writes: > > > > > Yes I agree it would be good for the icons to get some improvement. > Some > > > of the ones there currently are pretty poor. We really need to try and > > > get as much consistency as we can. I really would encourage you to go > > > for tango if you can. It's served ReactOS well. It might even be > > > possible for me to help with making custom Tango icons. > > > > Last I checked the Tango icons are under a Creative Commons license that > > is not compatible with the LGPL, so I'm afraid it's not an option. > > > > -- > > Alexandre Julliard > > julliard(a)winehq.org > > > > At this point Tango is Creative Commons but according to a post on their > mailing list they are planning to move to public domain. > (http://lists.freedesktop.org/archives/tango-artists/2008-September/001890.h…) Further there > are some more licensing discussions. I doubt their intension is to not > allow open source projects not to use their icons. We could ask them to > relicense them. > > Roderick > -- > Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: > http://www.gmx.net/de/go/multimessenger > I talked to the tango guys on irc (#tango on freenode) and they are willing to relicense fonts if we know which ones we want. We need to email the tango list for that. At some point in the future a lot of tango fonts will become public domain and another part (the gnome theme set) will be licensed under the LGPL. So with a small amount of effort we should be able to use tango in Wine :) Roderick -- Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a

Dec. 13, 2008

Re: RFC: Wine Icons

by Roderick Colenbrander

> > Joel Holdsworth <joel(a)airwebreathe.org.uk> writes: > > > > > Yes I agree it would be good for the icons to get some improvement. > Some > > > of the ones there currently are pretty poor. We really need to try and > > > get as much consistency as we can. I really would encourage you to go > > > for tango if you can. It's served ReactOS well. It might even be > > > possible for me to help with making custom Tango icons. > > > > Last I checked the Tango icons are under a Creative Commons license that > > is not compatible with the LGPL, so I'm afraid it's not an option. > > > > -- > > Alexandre Julliard > > julliard(a)winehq.org > > > > At this point Tango is Creative Commons but according to a post on their > mailing list they are planning to move to public domain. > (http://lists.freedesktop.org/archives/tango-artists/2008-September/001890.h…) Further there > are some more licensing discussions. I doubt their intension is to not > allow open source projects not to use their icons. We could ask them to > relicense them. > > Roderick After thinking a bit more about it I think we can use the Tango icons in their current form. To me it sounds like the main issue is that we need to merge the icons into our own dlls. Windows XP style themes allow you to replace icons. If we would improve our theming code, so that we can use icons from theme files then we would be able to use the tango icons. Roderick -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

Dec. 13, 2008

Re: RFC: Wine Icons

by Roderick Colenbrander

> Joel Holdsworth <joel(a)airwebreathe.org.uk> writes: > > > Yes I agree it would be good for the icons to get some improvement. Some > > of the ones there currently are pretty poor. We really need to try and > > get as much consistency as we can. I really would encourage you to go > > for tango if you can. It's served ReactOS well. It might even be > > possible for me to help with making custom Tango icons. > > Last I checked the Tango icons are under a Creative Commons license that > is not compatible with the LGPL, so I'm afraid it's not an option. > > -- > Alexandre Julliard > julliard(a)winehq.org > At this point Tango is Creative Commons but according to a post on their mailing list they are planning to move to public domain. (http://lists.freedesktop.org/archives/tango-artists/2008-September/001890.h…) Further there are some more licensing discussions. I doubt their intension is to not allow open source projects not to use their icons. We could ask them to relicense them. Roderick -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

Dec. 13, 2008

Re: Bugfix-patches for dlls/comdlg32/filedlg.c

by Austin English

On Sat, Dec 13, 2008 at 10:35 AM, Austin English <austinenglish(a)gmail.com> wrote: > On Fri, Dec 12, 2008 at 12:42 PM, Elias <elno0959(a)student.su.se> wrote: >> >> - Fix for bugzilla bug 16332 >> crash in file dialog if the previous selected folder is deleted >> >> No checking was done on the selected initial directory for the >> open-file dialog, which resulted in a stack overflow if the directory >> was not present. >> >> - Prevent free on NULL values >> A typo made the CommDlg32 leak memory and potenially free NULL values. >> Checks added/changed in two places. >> >> -- >> Fortune-of-the-Mail: >> Lady, lady, should you meet >> One whose ways are all discreet, >> One who murmurs that his wife >> Is the lodestar of his life, >> One who keeps assuring you >> That he never was untrue, >> Never loved another one... >> Lady, lady, better run! >> -- Dorothy Parker, "Social Note" >> >> >> >> > > Please only patch per e-mail. > > -- > -Austin > /s/patch/one patch -- -Austin

Dec. 13, 2008

Re: Bugfix-patches for dlls/comdlg32/filedlg.c

by Austin English

On Fri, Dec 12, 2008 at 12:42 PM, Elias <elno0959(a)student.su.se> wrote: > > - Fix for bugzilla bug 16332 > crash in file dialog if the previous selected folder is deleted > > No checking was done on the selected initial directory for the > open-file dialog, which resulted in a stack overflow if the directory > was not present. > > - Prevent free on NULL values > A typo made the CommDlg32 leak memory and potenially free NULL values. > Checks added/changed in two places. > > -- > Fortune-of-the-Mail: > Lady, lady, should you meet > One whose ways are all discreet, > One who murmurs that his wife > Is the lodestar of his life, > One who keeps assuring you > That he never was untrue, > Never loved another one... > Lady, lady, better run! > -- Dorothy Parker, "Social Note" > > > > Please only patch per e-mail. -- -Austin

Dec. 13, 2008

Re: Add DIB Test for Polyline

by Austin English

2008/12/12 Sergey Novosyolov <chi(a)etersoft.ru>: > > > > > You need to add this file to the list of tests in dlls/gdi32/tests/Makefile.in. -- -Austin

Dec. 13, 2008

Re: Where to put new (vfw32) compatibility tests that wine fails?

by Michael Karcher

Am Freitag, den 12.12.2008, 17:10 +0100 schrieb Hoehle, Joerg-Cyril: > I have attached to http://bugs.winehq.org/show_bug.cgi?id=15915#c3 > ("Cinepak reportedly not installed") the skeleton of a test that wine > fails but win2k passes. Nice work, thank you. Tests like this do help Wine development. > o Is it "right" to add compatibility tests that wine is known to fail > now (people are already complaining that a wine build does not pass > all tests), or are the tests considered more like regression aids and > should be added only when they succeed for the first time? It is definitely right to add such a test. But you have to mark it todo_wine. In that case, "make test" will expect that the test fails and complain if it does *not* fail. > o What directory to add this test specific to vfw32 (or rather iccvid) ? > winmm seems to test sound only, although in principle, it could be there as well. I would put it into msvfw32/tests. You would have to create it. > o Which files to change (beside Makefile.in and testlist.c) so that > the patch builds and becomes fully integrated into the wine source > tree if it were located in a new file, instead of e.g. being added to > tests/mmio.c? Just change Makefile.in, testlist.c is automatically generated. If you add a new tests dir, you need to run tools/make_makefiles in the top level directory of your wine sourcecode. If your wine sourcecode is a git repository, make_makefiles only considers Makefile.in files already added to the git index, so call git-add before make_makefiles. If you don't use git, make_makefiles scans all directories for Makefile.in to find about buildable directories. > Thank you, > Jörg Höhle You're welcome, Michael Karcher

Dec. 13, 2008

Re: RFC: Wine Icons

by Alexandre Julliard

Joel Holdsworth <joel(a)airwebreathe.org.uk> writes: > Yes I agree it would be good for the icons to get some improvement. Some > of the ones there currently are pretty poor. We really need to try and > get as much consistency as we can. I really would encourage you to go > for tango if you can. It's served ReactOS well. It might even be > possible for me to help with making custom Tango icons. Last I checked the Tango icons are under a Creative Commons license that is not compatible with the LGPL, so I'm afraid it's not an option. -- Alexandre Julliard julliard(a)winehq.org

Dec. 13, 2008

Re: RFC: Wine Icons

by Joel Holdsworth

On Wed, 2008-12-10 at 20:43 +0000, Hervÿffffe9 Chanal wrote: > > On Friday 14 November 2008 19:13:32 Juan Lang wrote: > > > > > > I find that a bit alarming. I'm sure he's working very hard, and doing > > > > good stuff, but I don't think Wine should be redrawing anything. Not > > > > when we have Tango around - it's designed to try create some consistency > > > > through standardisation. IMO standards are really good! - we use them if > > > > we possibly can. > > > > > > The trouble is that the Tango icon set doesn't cover all the icons > > > Wine needs. There's no Tango icon for regedit, for instance. > > > > IIRC there's Tango icon sets for specific applications. If we're doing our own > > icons anyway, we could try to keep them coherent with the rest of the Tango > > look and get the icons upstream to Tango. > > > > This seems like the most reasonable approach. Of course the only things I > > usually paint are walls so I'd have no idea how easy it is to match the Tango > > specs when designing icons. > > > > Cheers, > > Kai > > First of all, sorry to not have answered before and for my poor English, but I was quite busy > these past months and I didn't see all these messages since today. I realize that the two patch I > sent an hour ago are not the best answer to all these issues (I think these two newer icons > look nicer in the open dialog boxes anyway) and that all theses points have to be discussed. > > When remaking icons, I tried to add a bit of consistency while improving a bit the icons. > Obviously, I missed something. Reading all theses remarks, I agree that a better way to handle > these icons are to use the Tango ones when they are available. As it was stated, including them > is not straightforward and I haven't the skill to work on including these libraries into the wine > tree. I hope somebody will work on these issues. In the meanwhile, maybe I'll try to improve the > others shell32 icons as the bin or the computer which I found awful in this size but I don't know > if it's a good idea. > > Cheers, > Hervé Hi Herve, Yes I agree it would be good for the icons to get some improvement. Some of the ones there currently are pretty poor. We really need to try and get as much consistency as we can. I really would encourage you to go for tango if you can. It's served ReactOS well. It might even be possible for me to help with making custom Tango icons. Here on the Lumiera project we've adopted a method for making icons called the one canvas work flow, which was inspired by these videos: http://blip.tv/file/1075329 and http://blip.tv/file/1077148 This allows you to use a single SVG canvas with icon drawings specialised for different sizes. A script is then executed as part of the build process to render the individual sizes into their appropriate PNGs. The Tango library is large, so there are many icons available already. You might find this helpful in seeing what's already there: http://people.freedesktop.org/~jimmac/icons/#tit Let me know if I can help at all. God bless Joel

Dec. 13, 2008

Re: Compiling dbghelp with MinGW

by Eric Pouech

Francois Gouget a écrit : > When I compile Wine with MinGW, the first error I get is in > dlls/dbghelp/source.c. Yet it seems to me that there is no fundamental > reason that would prevent dbghelp from working on Windows (i.e. it's not > in the 'ntdll' category). > > So the error is that although MinGW does not have regex.h and > HAVE_REGEX_H is not set, we still use regex_t in many places and call > the corresponding functions: regcomp(), regexec() and regfree(). > > So how should we handle this? > > 1) #ifdef-out regexp support if regex.h is missing? Maybe with > an autoconf check for regcomp()? > 2) Add some reg*() stubs that do nothing if regex.h & co are missing? > 3) Use some Windows API that provides regular expression support? Is > there one? Is it implemented already? > 4) Reimplement regular expression support straight in dbghelp? Maybe by > importing some c files from another project with a compatible > license? > > 1,2) most of the dbghelp code will be of no use if no regex support is present 3) doesn't exist to my knowledge 4) I don't see a reason to clutter wine's code with that *** new option *** 5) use a regex lib for mingw... that work(ed) just fine http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=73286… we could be a bit more verbose in mingw configuration for this case A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

Dec. 13, 2008

Compiling dbghelp with MinGW

by Francois Gouget

When I compile Wine with MinGW, the first error I get is in dlls/dbghelp/source.c. Yet it seems to me that there is no fundamental reason that would prevent dbghelp from working on Windows (i.e. it's not in the 'ntdll' category). So the error is that although MinGW does not have regex.h and HAVE_REGEX_H is not set, we still use regex_t in many places and call the corresponding functions: regcomp(), regexec() and regfree(). So how should we handle this? 1) #ifdef-out regexp support if regex.h is missing? Maybe with an autoconf check for regcomp()? 2) Add some reg*() stubs that do nothing if regex.h & co are missing? 3) Use some Windows API that provides regular expression support? Is there one? Is it implemented already? 4) Reimplement regular expression support straight in dbghelp? Maybe by importing some c files from another project with a compatible license? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The last time religion ruled, it was called the dark ages.

Dec. 13, 2008

Re: Canonical and wine

by Markus Hitter

Am 13.12.2008 um 01:12 schrieb Ben Klein: > But I have to ask, what exactly is this system going to > replace? > > Current equivalent method is: > 1) Try your app with Wine > 2) If it doesn't work, check appdb for Wine version compatibility > 3) Follow any instructions on the appdb page, such as reg > settings/hacks, DLL overrides, specific Wine versions > 4) If it works, yay for you > > This proposal of packages for proprietary Windows software follows > these steps, then adds a step 5) Create a package based on what you've > found that automates step 3. I argue that a more correct way to deal > with this is education of newbies. As far as I followed the discussion, you'd replace 1) to 3). The one simple rule you'd have to teach people is "Before installing Windows software, install the appropriate compatibility package". Alternatively, if you want to have something like a default Wine package, teach them: "If your app doesn't work, look for a compatibility package". IMHO, the former is the better, because it's more consistent. You could name the packages like "Wine for Adobe applications" to avoid thousands of new packages. Also, "doesn't work" is a weak description, as non-working features might not be noticed by the user immediately. Third, it's likely tricky to replace Wine with a different version of Wine with the app already installed along other apps on a drive_c. BTW, how would you interact between different Windows apps running on different versions of Wine? MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/

Dec. 12, 2008

Re: Canonical and wine

by Ben Klein

2008/12/13 Steven Edwards <winehacker(a)gmail.com>: > On Thu, Dec 11, 2008 at 6:22 PM, Ben Klein <shacklein(a)gmail.com> wrote: > Yes the wrapper script is implied by the deb package/template. I think > each application > package should have a hard dep on a given Wine version and the > launcher script should > reflect that. Then it would be up to the package maintainer to update > his package for newer > versions of Wine. If you did it right you could make it compatible > across multiple Wine versions > and just use the deb/rpm database to check to make sure version > numbers are high enough > and or blacklist known bad ones. If you did it wrong, you could end up with one copy of Wine per application, and have overlap in application support (e.g. foo works in 1.0.1 and 1.1.10, but has a hard dep on 1.0.1, bar has hard dep on 1.1.10). > Its not that hard to keep seperate versions of Wine isolated. > You could have something like > > /usr/local/lib/wine-1.0.1 > /usr/local/lib/wine-1.2.0 > etc > > And use the variables Wine already supports to point to different Wine > binaries and Wineserver versions. > CodeWeavers already does this to allow CrossOver and Wine to co-exist > on the same system. I did this sort of thing myself with a wrapper script I called vineyard. I never made a big deal of it because: 1) Putting multiple versions of wine in /usr/local/wine* or /usr/wine* is ugly 2) Ideally, we don't need to have multiple concurrent Wine versions, and if I found out what apps I used to run using vineyard, I'd likely find that I only need 1.1.10 to run them all now (I know for a fact that one of them works reasonably well now) > As far as the database resources, that information is already there in > appdb. It's already been said before, but appdb can be hideously inaccurate. > Its just a matter of getting it in the right framework to be automagically > packaged. Lets say an application is known as > gold or whatever in appdb. Assuming a known good version of Wine is > listed and the proper dependances > are met, it should be possible to automate generation of the packages. I would object to any system like what is being proposed here that doesn't have a full version compatibility database attached and some algorithm to calculate the minimum set required for your applications. Perhaps automagic appdb info would be a good start, but have the system prefer certified data by trusted testers. The biggest problem with maintaining a compatibility database is the manpower and resources required. Every time a new version of the application comes out, full range of Wine version testing would be required for a quality database. Even the idea of certifying specific appdb entries will take a lot of resources and manpower. > I think the first step is to take what we've already got with IE6 in > Winetricks. Find a stable version of Wine > it works well with and attempt to make a package for it based upon all > of the ideas already covered here. I just thought - it's not just a problem of maintaining concurrent Wines on end-user systems, it's also a problem of maintaining concurrent Wine versions in the central repositories. You wouldn't be able to use the current Wine packages because they install in /usr/, not in /usr/wine-version. And unless you do something like directly accessing older archives and manually installing (so that it's outside high-level package management), each version of Wine in the repository would need its own package *name*! This all sounds like a lot of work to me, but if people are willing to put in the time and effort to do it *properly*, it does have its merits. But I have to ask, what exactly is this system going to replace? Current equivalent method is: 1) Try your app with Wine 2) If it doesn't work, check appdb for Wine version compatibility 3) Follow any instructions on the appdb page, such as reg settings/hacks, DLL overrides, specific Wine versions 4) If it works, yay for you This proposal of packages for proprietary Windows software follows these steps, then adds a step 5) Create a package based on what you've found that automates step 3. I argue that a more correct way to deal with this is education of newbies.

Dec. 12, 2008

Re: Canonical and wine

by Austin English

On Fri, Dec 12, 2008 at 12:59 PM, Steven Edwards <winehacker(a)gmail.com> wrote: > On Fri, Dec 12, 2008 at 1:34 PM, Austin English <austinenglish(a)gmail.com> wrote: >> I think you have a bit too much faith in the AppDB. 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. >> >> I know that this wouldn't be used for a lot of apps, just really >> popular ones that (assumedly) at least a few developers have >> used/verified, but worth pointing out nonetheless. > > It might be possible to have some sort of certification system setup > whereby the maintainer of the appdb entry signs off on the information > being correct. I could see a fit for some sort of tool being developed > to automate this whole process for apps that are certified but this is > thinking too far ahead. When I get some time I'll see if I can put > together a proof of concept IE deb package. Many times the maintainers are the ones giving those falsely inflated ratings. I could see this being useful for really popular apps, and in a small enough number to where a developer or AppDB admin could sign off on it. -- -Austin

Dec. 12, 2008

Re: Canonical and wine

by Steven Edwards

On Fri, Dec 12, 2008 at 1:34 PM, Austin English <austinenglish(a)gmail.com> wrote: > I think you have a bit too much faith in the AppDB. 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. > > I know that this wouldn't be used for a lot of apps, just really > popular ones that (assumedly) at least a few developers have > used/verified, but worth pointing out nonetheless. It might be possible to have some sort of certification system setup whereby the maintainer of the appdb entry signs off on the information being correct. I could see a fit for some sort of tool being developed to automate this whole process for apps that are certified but this is thinking too far ahead. When I get some time I'll see if I can put together a proof of concept IE deb package. Thanks -- 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

Dec. 12, 2008

Re: Canonical and wine

by Austin English

On Fri, Dec 12, 2008 at 11:52 AM, Steven Edwards <winehacker(a)gmail.com> wrote: > Lets say an application is known as gold or whatever in appdb. > Assuming a known good version of Wine is listed and the proper dependances > are met, it should be possible to automate generation of the packages. I think you have a bit too much faith in the AppDB. 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. I know that this wouldn't be used for a lot of apps, just really popular ones that (assumedly) at least a few developers have used/verified, but worth pointing out nonetheless. -- -Austin

Dec. 12, 2008

Serial Fixes

by Uwe Bonnes

Hello Wolfgang, nice findings and fixes around the serial driver! What application do you test against? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Dec. 12, 2008

Re: Canonical and wine

by Steven Edwards

On Thu, Dec 11, 2008 at 6:22 PM, Ben Klein <shacklein(a)gmail.com> wrote: > One problem you missed is a sensible way to keep multiple versions of > Wine on the system as needed. This could get extremely messy; the best > solution would be to keep a database of all known-working Wine > versions for all supported applications, and install only the minimum > set required to get those applications that you install working. With > each new version of Wine and application, the set will likely change, > and you'd need some wrapper script in order to know which installed > version of Wine to run for a particular application. Not to mention > the additional manpower required to maintain the database, and any > additional things required (like winetricks stuff that's required for > some versions of wine but not others). Yes the wrapper script is implied by the deb package/template. I think each application package should have a hard dep on a given Wine version and the launcher script should reflect that. Then it would be up to the package maintainer to update his package for newer versions of Wine. If you did it right you could make it compatible across multiple Wine versions and just use the deb/rpm database to check to make sure version numbers are high enough and or blacklist known bad ones. Its not that hard to keep seperate versions of Wine isolated. You could have something like /usr/local/lib/wine-1.0.1 /usr/local/lib/wine-1.2.0 etc And use the variables Wine already supports to point to different Wine binaries and Wineserver versions. CodeWeavers already does this to allow CrossOver and Wine to co-exist on the same system. As far as the database resources, that information is already there in appdb. Its just a matter of getting it in the right framework to be automagically packaged. Lets say an application is known as gold or whatever in appdb. Assuming a known good version of Wine is listed and the proper dependances are met, it should be possible to automate generation of the packages. Maybe we are talking about some sort of xml importing data exchange tool to generate the deb specs and the Wine templates. I am not sure, I've not really thought the automation part through enough. That can really come later once some proof of concept debs/rpms are built for IE and Photoshop. I think the first step is to take what we've already got with IE6 in Winetricks. Find a stable version of Wine it works well with and attempt to make a package for it based upon all of the ideas already covered here. -- 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

Dec. 12, 2008

RE: winmm: Sign-compare warning fix (Resend)

by James Mckenzie

Michael Karcher <wine(a)mkarcher.dialup.fu-berlin.de> at: Dec 12, 2008 9:23 AM (MST) wrote about: RE: winmm: Sign-compare warning fix (Resend) > >Am Freitag, den 12.12.2008, 09:07 -0700 schrieb James Mckenzie: >> > unsigned int i; >> > >> > ... >> > >> > for (i = sizeof(foo) / sizeof(foo[0]) - 1; ~i; --i) >> > >> >Tested? No. >> >Readable? Don't ask me... :-) >> I understood it, but is not the goal to avoid the use of C++ constructs in WINE code? >There is no C++ construct in that code. Still i-- would do the same and >is more idiomatic C. > >> The real question is why convert a for loop to a while loop? >After the last iteration, the --i (or i--) overflows. In a for loop, the >step statement (the third statement in the loop head) is always executed >before the test (the second statement in the loop head), so there is no >way to prevent the overflow. While this is not a problem per se, as >overflow of unsigned variables is well-defined, testing for "overflow >just happended" tends to be more confusing to the readers than testing >for "is at the end". > >If you use a while loop instead, you can arrange the test to be executed >*before* the step is performed, so you have to abort on "i == 0 just >finished" insted of "i == ~0U is next", the former being easier to >understand. > This is a definite improvement. Glad you caught it and thank you for the lesson in the use of structures vice arrays. I'll take a close look at the code and your change this weekend. I was caught by the use of sizeof(array[0]) vice sizeof(struct[0]), which do yeild different results. James McKenzie

Dec. 12, 2008

RE: winmm: Sign-compare warning fix (Resend)

by Michael Karcher

Am Freitag, den 12.12.2008, 09:07 -0700 schrieb James Mckenzie: > > unsigned int i; > > > > ... > > > > for (i = sizeof(foo) / sizeof(foo[0]) - 1; ~i; --i) > > > >Tested? No. > >Readable? Don't ask me... :-) > I understood it, but is not the goal to avoid the use of C++ constructs in WINE code? There is no C++ construct in that code. Still i-- would do the same and is more idiomatic C. > The real question is why convert a for loop to a while loop? After the last iteration, the --i (or i--) overflows. In a for loop, the step statement (the third statement in the loop head) is always executed before the test (the second statement in the loop head), so there is no way to prevent the overflow. While this is not a problem per se, as overflow of unsigned variables is well-defined, testing for "overflow just happended" tends to be more confusing to the readers than testing for "is at the end". If you use a while loop instead, you can arrange the test to be executed *before* the step is performed, so you have to abort on "i == 0 just finished" insted of "i == ~0U is next", the former being easier to understand. > My guess is to avoid a possible empty or zero length foo. Even in for loops, the tests is executed before the first iteration, so it would work in the for loop as well. > Of course, there should be a check before this for an empty or misformed > foo[0] avoiding a divide by zero error. Sorry for the strong language: Either you need to take a second look at the code we talk about or a second look at an medium-level C textbook. sizeof is a built-in operator that returns the amount of memory storage the object foo[0] directly occupies. If foo[0] is a pointer, it is the size of a pointer, not the size of the allocated memory foo[0] might point to. As there are no objects of size zero in C or C++, sizeof(foo[0]) can *never* be zero. The idiom used here "sizeof(foo) / sizeof(foo[0])" yields the size of an array "foo". It breaks *horribly*[1] if foo is not an array, but a pointer. If foo denotes an array, sizeof foo returns the size of the whole array, which is the size per element multiplied by the number of elements. The size of a single element is calculated by sizeof(foo[anything]), anything being zero by convention. Regards, Michael Karcher 1: breaks horribly means in that case: Returns nonsense (if foo[0] is a structure, usually zero), no compile-time error, no obvious error in that line (one needs the context to find it, and most people just assume foo to be an array reading that line).

Dec. 12, 2008

Where to put new (vfw32) compatibility tests that wine fails?

by Hoehle, Joerg-Cyril

Hi, I have attached to http://bugs.winehq.org/show_bug.cgi?id=15915#c3 ("Cinepak reportedly not installed") the skeleton of a test that wine fails but win2k passes. I could turn this into a format that git and wine-patches understands, if I knew the answer to these questions: o Is it "right" to add compatibility tests that wine is known to fail now (people are already complaining that a wine build does not pass all tests), or are the tests considered more like regression aids and should be added only when they succeed for the first time? o What directory to add this test specific to vfw32 (or rather iccvid) ? winmm seems to test sound only, although in principle, it could be there as well. o Which files to change (beside Makefile.in and testlist.c) so that the patch builds and becomes fully integrated into the wine source tree if it were located in a new file, instead of e.g. being added to tests/mmio.c? Thank you, Jörg Höhle

Dec. 12, 2008

RE: winmm: Sign-compare warning fix (Resend)

by James Mckenzie

Peter Rosin <peda(a)axentia.se> at: Dec 12, 2008 4:27 AM wrote about: RE: winmm: Sign-compare warning fix (Resend) > >> But how would you then fix the sign-compare violation, or >> would you just let this one go? > >If you want it to be more compact: > > unsigned int i; > > ... > > for (i = sizeof(foo) / sizeof(foo[0]) - 1; ~i; --i) > >Tested? No. >Readable? Don't ask me... :-) I understood it, but is not the goal to avoid the use of C++ constructs in WINE code? The real question is why convert a for loop to a while loop? My guess is to avoid a possible empty or zero length foo. Of course, there should be a check before this for an empty or misformed foo[0] avoiding a divide by zero error. James McKenzie

Dec. 12, 2008

RE: [1\3] setupapi: add CM_Locate_DevNodeA\W stubs

by ricardo filipe

thanks, i thought i had corrected the patches before sending... seems not... i'll resend. > From: Stefan.Leichter(a)camline.com > To: wine-devel(a)winehq.org; ricardo_barbano(a)hotmail.com > Subject: Re: [1\3] setupapi: add CM_Locate_DevNodeA\W stubs > Date: Fri, 12 Dec 2008 16:04:36 +0100 > > Am Friday 12 December 2008 01:42 schrieb ricardo filipe: > > >--- a/dlls/setupapi/setupapi.spec > >+++ b/dlls/setupapi/setupapi.spec > >@@ -53,7 +53,7 @@ > > @ stub CM_Free_Res_Des > > @ stub CM_Free_Res_Des_Ex > > @ stub CM_Free_Res_Des_Handle > >-@ stub CM_Get_Child > >+@ stdcall CM_Get_Child(ptr long long) > > @ stub CM_Get_Child_Ex > > @ stub CM_Get_Class_Key_NameA > > @ stub CM_Get_Class_Key_NameW > > this part is wrong here as it is in the second patch too .. > > Stefan _________________________________________________________________ Instale a Barra de Ferramentas com Desktop Search e ganhe EMOTICONS para o Messenger! É GRÁTIS! http://www.msn.com.br/emoticonpack

Dec. 12, 2008

Re: [1\3] setupapi: add CM_Locate_DevNodeA\W stubs

by Stefan Leichter

Am Friday 12 December 2008 01:42 schrieb ricardo filipe: >--- a/dlls/setupapi/setupapi.spec >+++ b/dlls/setupapi/setupapi.spec >@@ -53,7 +53,7 @@ > @ stub CM_Free_Res_Des > @ stub CM_Free_Res_Des_Ex > @ stub CM_Free_Res_Des_Handle >-@ stub CM_Get_Child >+@ stdcall CM_Get_Child(ptr long long) > @ stub CM_Get_Child_Ex > @ stub CM_Get_Class_Key_NameA > @ stub CM_Get_Class_Key_NameW this part is wrong here as it is in the second patch too .. Stefan

Dec. 12, 2008

Re: mshtml: Add some interfaces in mshtml.idl (try 2) (resend)

by Konstantin Kondratyuk

On Thursday 11 December 2008 17:28:03 Konstantin Kondratyuk wrote: > Add: > ILineInfo > IDisplayPointer > IDisplayPointer > IHTMLComputedStyle > IDisplayServices > IMarkupServices This patch is wrong. Please, ignore it. -- Best regards, Konstantin Kondratyuk.

Dec. 12, 2008

Re: winmm: Sign-compare warning fix (Resend)

by Andrew Talbot

On Fri Dec 12 10:29 , Michael Stefaniuc <mstefani(a)redhat.com> sent: >Andrew Talbot wrote: >> But how would you then fix the sign-compare violation, or would you just let this >> one go? >I had to look twice as the initial warning was in a for loop above: >Either leave it as is for now as the warning is bogus or at least add >the decrement directly to the while like this: > i = sizeof(MMDrvs) / sizeof(MMDrvs[0]); > while (i-- > 0) > { > MMDRV_ExitPerType(&MMDrvs[i], MMDRV_AUX); > >Though the later would still have to pass Alexandre's review. > >bye > michael Come to think of it, I believe Alexandre did improve one of my earlier efforts in this latter way, so I might retry with the slimmer while loop you suggest. Thanks, Michael (and Chris and Peter)! -- Andy.

Dec. 12, 2008