August 2010 - Wine-Devel - list.winehq.org

Wine Gecko 1.1.0 RC1

by Luca Bennati

Applied the patch to master, recompiled ok. I put the rc1 cab in /usr/share/wine/gecko/, as always. In the creation of a new prefix, it gave me an err which wasn't there before: err:mshtml:init_xpcom AutoRegister(NULL) failed: 80070057 but 'wine iexplore' works better than before (sites that crashed wine before don't crash it anymore). I investigated it a bit recreating a new prefix with 'WINEDEBUG=+mshtml winecfg' and here's the log: wine: created the configuration directory '/home/luca/.wine' trace:mshtml:register_server (1) trace:mshtml:load_gecko () trace:mshtml:install_cab (L"Z:\\usr\\bin\\..\\share\\wine\\gecko\\wine_gecko-1.1.0-rc1-x86.cab") trace:mshtml:check_version "Wine Gecko 1.1.0-rc1" trace:mshtml:load_xpcom (L"C:\\windows\\system32\\gecko\\1.1.0-rc1\\wine_gecko") fixme:system:SetProcessDPIAware stub! trace:mshtml:nsDirectoryServiceProvider_QueryInterface (IID_nsISupports 0x33d374) trace:mshtml:nsDirectoryServiceProvider_QueryInterface (IID_nsIDirectoryServiceProvider 0x33d214) trace:mshtml:nsDirectoryServiceProvider_GetFile ("GreD" 0x33d2ec 0x33d2e8) trace:mshtml:nsDirectoryServiceProvider_QueryInterface (IID_nsIDirectoryServiceProvider 0x33d214) trace:mshtml:nsDirectoryServiceProvider_GetFile ("XCurProcD" 0x33d2ec 0x33d2e8) trace:mshtml:nsDirectoryServiceProvider_QueryInterface (IID_nsIDirectoryServiceProvider 0x33bfc4) trace:mshtml:nsDirectoryServiceProvider_GetFile ("PrfDef" 0x33c09c 0x33c098) warn:mshtml:nsDirectoryServiceProvider_QueryInterface ({2f977d4b-5485-11d4-87e2-0010a4e75ef2} 0x33bff4) warn:mshtml:nsDirectoryServiceProvider_QueryInterface ({2f977d4b-5485-11d4-87e2-0010a4e75ef2} 0x33bff4) fixme:iphlpapi:NotifyAddrChange (Handle 0xf5e914, overlapped 0xf5e918): stub trace:mshtml:nsDirectoryServiceProvider_QueryInterface (IID_nsIDirectoryServiceProvider 0x33bc64) trace:mshtml:nsDirectoryServiceProvider_GetFile ("AChrom" 0x33bd3c 0x33bd38) err:mshtml:init_xpcom AutoRegister(NULL) failed: 80070057 trace:mshtml:nsIOService_GetProtocolHandler ("file" 0x33cff8) trace:mshtml:nsIOService_NewURI ("file:///C:/windows/system32/gecko/1.1.0-rc1/wine_gecko/components/nsTryToClose.js" (null) (nil) 0x33d15c) trace:mshtml:nsDirectoryServiceProvider_QueryInterface (IID_nsIDirectoryServiceProvider 0x33ccb4) trace:mshtml:nsDirectoryServiceProvider_GetFile ("ProfDS" 0x33cd8c 0x33cd88) trace:mshtml:nsDirectoryServiceProvider_QueryInterface (IID_nsIDirectoryServiceProvider 0x33ccb4) trace:mshtml:nsDirectoryServiceProvider_GetFile ("ProfD" 0x33cd8c 0x33cd88) trace:mshtml:nsDirectoryServiceProvider_QueryInterface (IID_nsIDirectoryServiceProvider 0x33ccb4) trace:mshtml:nsDirectoryServiceProvider_GetFile ("ProfLDS" 0x33cd8c 0x33cd88) trace:mshtml:nsDirectoryServiceProvider_QueryInterface (IID_nsIDirectoryServiceProvider 0x33ccb4) trace:mshtml:nsDirectoryServiceProvider_GetFile ("ProfLD" 0x33cd8c 0x33cd88) trace:mshtml:nsIOService_NewURI ("resource://gre/modules/XPCOMUtils.jsm" (null) (nil) 0x33acb8) trace:mshtml:nsDirectoryServiceProvider_QueryInterface (IID_nsIDirectoryServiceProvider 0x33851c) trace:mshtml:nsDirectoryServiceProvider_GetFile ("CurProcD" 0x3385f4 0x3385f0) trace:mshtml:nsIOService_NewFileURI (0x7613b8 0x338674) trace:mshtml:nsIOService_NewFileURI (0x7613b8 0x338674) trace:mshtml:nsIOService_NewURI ("jar:chrome/toolkit.jar!/res/" (null) 0x75f6c8 0x3386e4) trace:mshtml:nsIOService_ExtractScheme ("jar:chrome/toolkit.jar!/res/" 0x3363d0) trace:mshtml:nsIOService_NewURI ("chrome/toolkit.jar!/res/" "" 0x75f6c8 0x7613cc) trace:mshtml:nsIOService_NewURI not wraping trace:mshtml:nsIOService_NewChannelFromURI (0x75fa90 0x33acb4) trace:mshtml:nsIOService_NewChannelFromURI Could not get nsWineURI: 80004002 trace:mshtml:nsIOService_NewChannel ("file:///C:/windows/system32/gecko/1.1.0-rc1/wine_gecko/modules/XPCOMUtils.jsm" (null) (nil) 0x33acb4) trace:mshtml:close_gecko () wine: configuration in '/home/luca/.wine' has been updated. Hope it helps :)

Aug. 24, 2010

Re: ddraw [try 2]: SetCooperativeLevel with Full screen + exclusive + normal is authorized

by Henri Verbeet

This looks suspicious to me, you have to assume the code wasn't just added for the hell of it, even though with ddraw you're never quite sure. Do other ddraw versions behave the same? Please don't add trailing spaces, neither in the code nor in TRACEs.

Aug. 24, 2010

Re: d3dx9: Implement D3DXDeclaratorFromFVF. (try 2)

by Henri Verbeet

On 24 August 2010 05:05, Misha Koshelev <misha680(a)gmail.com> wrote: > + elements[idx].Stream = 0xFF; > + elements[idx].Offset = D3DXGetDeclVertexSize(elements, 0); > + elements[idx].Stream = 0; That's ugly. > + memcpy(Declaration, elements, size * sizeof(D3DVERTEXELEMENT9)); That's unnecessary.

Aug. 24, 2010

Re: ddraw [try 2]: SetCooperativeLevel with Full screen + exclusive + normal is authorized

by Stefan Dösinger

Hi, Can you add a test that tests in which mode ddraw is after such a call? Specfically, try to create a double buffered primary surface. If this succeeds, ddraw is in fullscreen mode. If ddraw is in normal mode you'll get DDERR_NOEXCLUSIVEMODE (or similar) back. Am 24.08.2010 um 10:00 schrieb David Adam: > Fixed a typo > > A+ > > David > <0001-SetCooperativeLevel-with-Full-screen-exclusive-norma.patch>

Aug. 24, 2010

Re: Use SUBLANG_NEUTRAL for the Gaelic resources?

by Huw Davies

On Tue, Aug 24, 2010 at 09:59:51AM +0200, Francois Gouget wrote: > > Are SUBLANG_GAELIC, SUBLANG_GAELIC_SCOTTISH and SUBLANG_GAELIC_MANX very > different languages? > > If not it would be better to use SUBLANG_NEUTRAL instead of > SUBLANG_GAELIC. For instance: I think they're different enough to warrant falling back to English rather than Irish (which is essentially what you're asking). See: http://en.wikipedia.org/wiki/Manx_language#Background Huw.

Aug. 24, 2010

Re: explorerframe/tests: Add a trailing '\n' to an ok() call.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4711 Your paranoid android. === W2K8SE (32 bit nstc) === nstc.c:1889: Test failed: Got event 7, count 0 nstc.c:1891: Test failed: Got event 4, count 0 nstc.c:1898: Test failed: Got event 6, count 1 nstc.c:1904: Test failed: Got event 4, count 0 nstc.c:1956: Test failed: Got event 7, count 0 nstc.c:1965: Test failed: Item not expanded. nstc.c:1968: Test failed: itemstate is 0x00000000 nstc.c:1985: Test failed: itemstate is 0x00000000 nstc.c:2111: Test failed: Got event 7, count 0 nstc.c:2118: Test failed: itemstate is 0x00000000 nstc.c:2142: Test failed: itemstate is 0x0000000c nstc.c:2157: Test failed: itemstate is 0x0000000c nstc.c:2171: Test failed: itemstate is 0x00000004 nstc.c:2183: Test failed: itemstate is 0x00000004 nstc.c:2240: Test failed: Got event 7, count 0 nstc.c:2245: Test failed: Got (0x80004005) nstc.c:2246: Test failed: psi is 00000000

Aug. 24, 2010

Re: ddraw [try 2]: SetCooperativeLevel with Full screen + exclusive + normal is authorized

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4710 Your paranoid android. === W98SE (32 bit ddrawmodes) === No test summary line found === W7PROX64 (64 bit ddrawmodes) === Timeout

Aug. 24, 2010

Re: [PATCH 1/5] server: move is_removeable to fd_ops

by Alexandre Julliard

Mike Kaplinskiy <mike.kaplinskiy(a)gmail.com> writes: > On Wed, Aug 4, 2010 at 1:29 AM, Mike Kaplinskiy > <mike.kaplinskiy(a)gmail.com> wrote: >> --- >> server/change.c | 2 ++ >> server/device.c | 1 + >> server/fd.c | 18 ++++++++++++------ >> server/file.c | 1 + >> server/file.h | 3 +++ >> server/mailslot.c | 3 +++ >> server/mapping.c | 1 + >> server/named_pipe.c | 3 +++ >> server/process.c | 1 + >> server/protocol.def | 2 +- >> server/queue.c | 1 + >> server/request.c | 1 + >> server/serial.c | 1 + >> server/signal.c | 1 + >> server/sock.c | 1 + >> server/thread.c | 1 + >> 16 files changed, 34 insertions(+), 7 deletions(-) >> > > Could I have some feedback on this? I haven't had the time to go on > IRC at work and US Eastern is not a widely used timezone around here > :-\. I've been working on a better way to achieve this, it should be committed shortly. -- Alexandre Julliard julliard(a)winehq.org

Aug. 24, 2010

Re: How managing crashing tests ?

by GOUJON Alexandre

On 08/23/2010 11:47 PM, Andrew Eikum wrote: > Just don't execute the code on that platforms that don't support it. > How to check if the platform supports that codepath can be tricky, and > there are a lot of ways to do it. Some examples are to use > GetProcAddress; use a different function (if it's not the one being > tested, obviously); or call the function in a certain way that can tip > you off to platform differences. > > If you have a specific problem in mind, people on the list might be > able to help. I read again the test file and in my case, there are some broken() /* NT4 */ so I'll declare a BOOL isNT4 and add a win_skip when appropriate. Many thanks !

Aug. 24, 2010

Use SUBLANG_NEUTRAL for the Gaelic resources?

by Francois Gouget

Are SUBLANG_GAELIC, SUBLANG_GAELIC_SCOTTISH and SUBLANG_GAELIC_MANX very different languages? If not it would be better to use SUBLANG_NEUTRAL instead of SUBLANG_GAELIC. For instance: dlls/mapi32/Ga.rc | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/dlls/mapi32/Ga.rc b/dlls/mapi32/Ga.rc index e8aa3c0..104a658 100644 --- a/dlls/mapi32/Ga.rc +++ b/dlls/mapi32/Ga.rc @@ -22,7 +22,7 @@ #include "res.h" -LANGUAGE LANG_GAELIC, SUBLANG_GAELIC +LANGUAGE LANG_GAELIC, SUBLANG_NEUTRAL STRINGTABLE { -- 1.7.1

Aug. 24, 2010

Re: ddraw/tests: New visual back buffer flipping tests. (resend)

by GOUJON Alexandre

On 08/23/2010 11:28 PM, Oldřich Jedlička wrote: > My mistake, I've mixed up the C and C++ comments. I thought // is the C style > (for a while). I will send the fixed patch In fact, // is not C++ only : it has been added in the C99 revision. But for compatibility, we don't accept C99. Have a look at http://wiki.winehq.org/SubmittingPatches, there are some interesting infos there.

Aug. 24, 2010

Re: Wine Gecko 1.1.0 RC1

by Paul "TBBle" Hampson

On 24 August 2010 05:00, Jacek Caban <jacek(a)codeweavers.com> wrote: > The attached patch contains remaining bits. Haven't tested it, but I was having a flick through, and noticed that the second hunk for dlls/mshtml/nsembed.c has: ERR("Could not get nsIDontent interface: %08x\n", nsres); instead of ERR("Could not get nsIContent interface: %08x\n", nsres); -- Paul "TBBle" Hampson, Paul.Hampson(a)Pobox.com

Aug. 24, 2010

Re: user32: Optimize the storage of default values

by Dmitry Timoshkov

André Hentschel <nerv(a)dawncrow.de> wrote: > -static const char * const DefSysColors[] = > +static struct { > + const char *name; > + const COLORREF rgb; > +} DefSysColors[] = It should be 'static const struct {'. -- Dmitry.

Aug. 24, 2010

Re: RFC: test of 16 bit wine (DOS)

by Dmitry Timoshkov

Morten Rønne <morten.roenne(a)tdcadsl.dk> wrote: > 16 bit programs require a compiler that is able to create the old style > address method in order to be able to test those parts of wine. I have > been told by Dmitry Timoshkov that I should use OpenWatcom for that. So > that is what I have done. I didn't tell you that. I told you that you don't need any compiler at all for the tests to be integrated into the Wine make system. Obviously you need the compiler (or rather assembler) when you create the test, but then you just convert it into a binary blob which you copy into %TEMP% and run from there. -- Dmitry.

Aug. 24, 2010

Re: ddraw/tests: New visual back buffer flipping tests. (try 2)

by Oldřich Jedlička

On Tuesday 24 August 2010 00:14:31 Octavian Voicu wrote: > 2010/8/24 Oldřich Jedlička <oldium.pro(a)seznam.cz>: > > + ok((GetRValue(color) == 0xFF && GetGValue(color) == 0xFF && > > GetBValue(color) == 0xFF) || + broken(GetRValue(color) == 0xFF > > && GetGValue(color) == 0 && GetBValue(color) == 0), // broken driver + > > "got R %02X G %02X B %02X, expected R FF G FF B FF\n", + > > GetRValue(color), GetGValue(color), GetBValue(color)); > > I hate to be the bearer of bad news, but you missed one :) Fixed in "try 3" :-) Oldřich.

Aug. 24, 2010

Re: [PATCH 1/5] server: move is_removeable to fd_ops

by Mike Kaplinskiy

Aug. 24, 2010

Re: [PATCH 1/2] quartz/tests: move shareable code to a separate file

by James McKenzie

Anton Khirnov wrote: > On Sat, Aug 21, 2010 at 07:50:50PM -0700, James McKenzie wrote: > >> Looks like you did not test the build before running it against the >> testbot (I've been guilty of this as well.) >> >> > actually i did test it and it worked for some reason, must be magic :) > in any case, after rebasing it doesn't -- and the reason seems to be > that the build system assumes that each .c file under tests/ actually > contains a test. is there a way around that (besides the > obvious-but-ugly empty test in the common file)? > > One hint is if you are introducing a new function that exists in MSDN, look for an existing test case. If there is none, one will be required before Wine implementation code will be accepted. If the test exists in a file, then the implementing code should go in the corresponding .c file in the base dll directory from what I've read here over the years. If you are introducing a new function class, then it may be best to put the tests and code into new files. Empty test case files are frowned upon unless there really is no way to successfully test what you are trying to implement, but that is extremely rare. It is best to ask in the Wine Development list as to the most appropriate manner of implementation. The folks in the list are much more knowledgeable about this, I'm just giving suggestions. James McKenzie

Aug. 24, 2010

re: RFC: test of 16 bit wine (DOS)

by Dan Kegel

Morten Rønne wrote: > I have been working on creating tests for the 16 bit implementation of wine Great! Have you seen http://code.google.com/p/win16test/ ? That's for Win16 binaries, not DOS, but it might have some similarities. For instance, it also uses openwatcom. I had trouble back then getting the Linux version of openwatcom to produce win16 binaries, so I used 'winetricks openwatcom' to install the windows version. - Dan

Aug. 23, 2010

Re: ddraw: SetCooperativeLevel with Full screen + exclusive + normal is authorized

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4696 Your paranoid android. === W98SE (32 bit ddrawmodes) === No test summary line found === W7PROX64 (64 bit ddrawmodes) === Timeout

Aug. 23, 2010

Re: ddraw/tests: New visual back buffer flipping tests. (try 2)

by Octavian Voicu

2010/8/24 Oldřich Jedlička <oldium.pro(a)seznam.cz>: > + ok((GetRValue(color) == 0xFF && GetGValue(color) == 0xFF && GetBValue(color) == 0xFF) || > + broken(GetRValue(color) == 0xFF && GetGValue(color) == 0 && GetBValue(color) == 0), // broken driver > + "got R %02X G %02X B %02X, expected R FF G FF B FF\n", > + GetRValue(color), GetGValue(color), GetBValue(color)); I hate to be the bearer of bad news, but you missed one :)

Aug. 23, 2010

Re: gdiplus: add a stub for GdipWindingModeOutline

by Austin English

On Mon, Aug 23, 2010 at 4:47 PM, Vincent Povirk <madewokherd(a)gmail.com> wrote: > You need to add it to the .spec file too. Thanks. Bad cut and paste... -- -Austin

Aug. 23, 2010

Re: gdiplus: add a stub for GdipWindingModeOutline

by Vincent Povirk

You need to add it to the .spec file too. On Mon, Aug 23, 2010 at 4:45 PM, Austin English <austinenglish(a)gmail.com> wrote: > -- > -Austin > > > >

Aug. 23, 2010

Re: How managing crashing tests ?

by Andrew Eikum

On 08/23/2010 12:59 PM, GOUJON Alexandre wrote: > Anyway, I've seen mainly two approaches > - if(0) > - /* comment > the crashing ok() > */ > > What's the difference ? And why not #if 0 ? Using if(0) means the code in the body of the if-statement still has to compile. This can check against errors while modifying headers, help protect against misplaced braces in some cases, etc. Commenting the code out loses that verification, to no advantage. Really, it doesn't matter much. > I maybe lack some basic C knowledges but I think that /**/ and #if 0 are > not added to the executable (from preprocessing stage). > If it's right, it means we can then 'enable' these blocks maybe with > (gdb) edit something Likely not, since the optimizer probably just removes the body of the if-statement entirely. > And what about a test crashing on a specific Windows ? Just don't execute the code on that platforms that don't support it. How to check if the platform supports that codepath can be tricky, and there are a lot of ways to do it. Some examples are to use GetProcAddress; use a different function (if it's not the one being tested, obviously); or call the function in a certain way that can tip you off to platform differences. If you have a specific problem in mind, people on the list might be able to help. Andrew

Aug. 23, 2010

Re: ddraw/tests: New visual back buffer flipping tests. (resend)

by Oldřich Jedlička

On Monday 23 August 2010 23:00:24 Octavian Voicu wrote: > 2010/8/23 Oldřich Jedlička <oldium.pro(a)seznam.cz>: > > + // Check it out > > You have a C++ style comment in this patch and I don't think it's allowed. My mistake, I've mixed up the C and C++ comments. I thought // is the C style (for a while). I will send the fixed patch. Oldřich. > > Octavian

Aug. 23, 2010

Re: ddraw/tests: New visual back buffer flipping tests. (resend)

by Octavian Voicu

2010/8/23 Oldřich Jedlička <oldium.pro(a)seznam.cz>: > + // Check it out You have a C++ style comment in this patch and I don't think it's allowed. Octavian

Aug. 23, 2010

RFC: test of 16 bit wine (DOS)

by Morten Rønne

Hi I have been working on creating tests for the 16 bit implementation of wine, and now I have come so far that I would like some comments on the way I have chosen to do it. 16 bit programs require a compiler that is able to create the old style address method in order to be able to test those parts of wine. I have been told by Dmitry Timoshkov that I should use OpenWatcom for that. So that is what I have done. OpenWatcom also supports building DOS32 (using a number of extenders) and WIN 3.x programs. Since the DOS program can't run in the current test enviroment, because that is new style 32 bit address method, I am using a wrapper program which start the old style program from the 32 bit environment. The wrapper also makes it possible to do a skip message in case the needed DOS program is missing (due to no OpenWatcom compiler). In order to be able to create a stand-alone DOS program I have modified the wine/test.h file so that certain parts got omitted, while others were added. This means that writing a DOS test will be the same as writing normal 32 bit tests, except that you include a different test include file. The current version uses the define __WINE_WINE_DOS16_TEST_H from the include file that defines the DOS environment, since I haven't been able to find a better name. Suggestions for a better name are most welcome. The DOS test it self, is only a very simple one because I consider this more a proof of concept than a full test. Also a full test will require a number of changes in the current 16 bit tree to move a number of definitions from .c files to .h files so the test can reference them. Once this have been commited work can start towards making more complete test of the 16 bit environment. I hope that the naming will make Wine Testbot able to detect changes to the test suite. As can be seen above the OpenWatcom compiler is needed to build the DOS 16 bit programs. Currently only Linux 32 bit platform is supported. The compiler can't be built on 64 bit yet, this includes Mac. The easiest way to install the compiler is to download the binary installer from: http://www.openwatcom.org/index.php/Download Select one of the mirrors and download the file: open-watcom-c-linux-1.9 Ignore the fact that the main download page points to other places to get the linux version. This is a binary program that you have to run. It will ask you were to install OpenWatcom and all files will be installed under that tree. After that you must add a definition of WATCOM to your shell profile, pointing it to the directory you selected. After that change PATH to search in $WATCOM/binl as the LAST thing. Watcom includes programs that are called the same as some wine programs (wrc for one), so be sure you don't find these by searching OpenWatcom last. As a note I can tell that Debian have rejected the Sybase license (under which OpenWatcom is released) as not being free, and therefore there will be no official debian packages of OpenWatcom. Best Regards Morten Rønne

Aug. 23, 2010

Wine Gecko 1.1.0 RC1

by Jacek Caban

HI all, (If you're not interested in details, please read the last paragraph). It's been over year since the last Gecko update. A lot has happen since then. I've been planning to update our build a bit later, with Firefox 4 codebase, but plans have changed. We had some serious problems with previous build (like bug 22157 and bug 24059, both should be fixed in the new build). Also there is *a lot* happening in Mozilla world. With upcoming Firefox 4, the backward compatibility is no longer supported and the code is changing with an impressive speed. I try to follow these changes, but I need a good solid base so that I can take care of our needs in Mozilla. This build is based on Firefox 4 beta 4 (that is expected to be released this week). It goes with massive improvements, but it's less interesting here. We finally have sane building procedure. Thanks to mingw-w64 project, we no longer have to maintain our own fixes to headers and libraries. Also I've fixed a bug so that moztools is no longer needed for crosscompiling. It means that we no longer need any binary files, which should make open source fanatics (in a good sense) happy. Well... almost. We still need to create .cab file, which I do via Filzip on Windows. That's something we can work around. We use .cab files, because that's the only archive format that Wine can deal with. We can teach Wine to use other formats, which would finally make it possible for Wine packagers to do their own builds, if they like. The new Gecko is also the first to support Win64. Not all tests pass yet, but failing ones are due to missing DispCallFunc implementation for Win64, so it's not a Gecko problem. It's not yet fully tested and I need help with this. I'd appreciate any help with testing. Almost all changes required by the new Gecko were possible to be committed to current Wine. The attached patch contains remaining bits. All you need to test it is current Wine Git (must be today's or later), the attached patch and a new Gecko build. You can find new builds [1] and win64 build [2]. Put .cab files according to generic instructions [3] (obviously with different file names due to different Gecko versions). Please let me know of any regressions. Thanks, Jacek [1] http://gerwazy.lo3.wroc.pl/~jcaban/wine_gecko-1.1.0-rc1-x86.cab [2] http://gerwazy.lo3.wroc.pl/~jcaban/wine_gecko-1.1.0-rc1-x86_64.cab [3] http://wiki.winehq.org/Gecko

Aug. 23, 2010

Re: Ongoing Debian package maintenance.

by Lei Zhang

On Fri, Aug 20, 2010 at 4:00 PM, Ben Klein <shacklein(a)gmail.com> wrote: > Hello everyone, > > My health has not improved at all since my last call for help with the > Debian package management. I really need someone to take over from me, or at > least some help to devise a new set of (semi-)automated build scripts. Any > volunteers? Hi Ben, Does the task basically involve building new .deb packages for every release? I can probably take over this if nobody else volunteered. Get better! - Lei

Aug. 23, 2010

How managing crashing tests ?

by GOUJON Alexandre

Hi guys, A patch has been committed today saying "Make .. crashing like it does on native". I know we have to follow (genuine) Windows behavior but I'm wondering how to handle these cases. For instance, how to add a test crashing on every Windows ? Is it useful ? I mean, none program can rely on it .. since it crashes. Anyway, I've seen mainly two approaches - if(0) - /* comment the crashing ok() */ What's the difference ? And why not #if 0 ? I maybe lack some basic C knowledges but I think that /**/ and #if 0 are not added to the executable (from preprocessing stage). If it's right, it means we can then 'enable' these blocks maybe with (gdb) edit something And what about a test crashing on a specific Windows ? I guess #ifdef CRASHES_ON_NT40 is not an elegant way (even if it's currently used). Commenting such tests prevent us to check wine behavior on 'working' Windows. I attempted to use __TRY ... __EXCEPT_PAGE_FAULT in a test but it got rejected. Any advice ? Thanks

Aug. 23, 2010

Re: Re : Re : d3dx9: Implement D3DXDeclaratorFromFVF.

by Henri Verbeet

On 23 August 2010 19:02, paulo lesgaz <jeremielapuree(a)yahoo.fr> wrote: > Both patches work very well (they passed the todo_wine tests) > But, I think that the second one does not answer to Julliard 's complain > about tons of if...then I'm not sure I remember reading that specific comment. I know there was one about the unnecessary BOOLs though.

Aug. 23, 2010

Re : Re : d3dx9: Implement D3DXDeclaratorFromFVF.

by paulo lesgaz

Both patches work very well (they passed the todo_wine tests) But, I think that the second one does not answer to Julliard 's complain about tons of if...then Or maybe there is no way to simplify the patch David ________________________________ De : Henri Verbeet <hverbeet(a)gmail.com> À : paulo lesgaz <jeremielapuree(a)yahoo.fr> Cc : wine-devel(a)winehq.org Envoyé le : Lun 23 août 2010, 14h 01min 01s Objet : Re: Re : d3dx9: Implement D3DXDeclaratorFromFVF. On 23 August 2010 13:49, paulo lesgaz <jeremielapuree(a)yahoo.fr> wrote: > I already sent such a patch. Julliard did not like the gazillions of > conditions if.... then. > I never found a way to avoid them. > The offset can be computed thanks to the function D3DXGetDeclVertexSize > You know, just give the attached patches a try. Untested, of course.

Aug. 23, 2010

Re: New winetricks 20100822: new verb lucida

by Jacek Caban

On 8/23/10 6:26 PM, Dan Kegel wrote: > Jacek wrote: >> I still hope that gecko will be removed from winetricks at some point. >> It clearly doesn't belong to winetricks. > That would be nice. Does every distro install wine-gecko yet? I don't know, but I think we may assume that yes. Otherwise distros would leave users with an ugly dialog box on every wineprefix creation. There was a plan to make a list on http://wiki.winehq.org/Gecko, but it doesn't seem to be updated. Jacek

Aug. 23, 2010

re: New winetricks 20100822: new verb lucida

by Dan Kegel

Jacek wrote: > I still hope that gecko will be removed from winetricks at some point. > It clearly doesn't belong to winetricks. That would be nice. Does every distro install wine-gecko yet? > Also fakeie6 doesn't make sense anymore. We set these registries > by default for over 2.5 years now. OK, deleted. - Dan

Aug. 23, 2010

Re: configure: Enable prelink on x86_64

by Stefan Dösinger

Am Montag 23 August 2010, 16:03:51 schrieb Alexandre Julliard: > Stefan Dösinger <stefan(a)codeweavers.com> writes: > > From 98e8cc5d0b5b2d397c1d904d2537c326ed36d43c Mon Sep 17 00:00:00 2001 > > From: =?UTF-8?q?Stefan=20D=C3=B6singer?= <stefan(a)codeweavers.com> > > Date: Sun, 22 Aug 2010 19:49:58 +0200 > > Subject: [PATCH 4/4] Enable prelink on x86_64 > > Which app needs this? Steam in a wow64 build.

Aug. 23, 2010

Re: avifil32: Removed sign comparison warning (sizeof expresions)

by Michael Stefaniuc

Marko Nikolic wrote: > Andrey Turkin wrote: > >> On Monday 23 August 2010 13:16:07 Michael Stefaniuc wrote: >>> IMHO gcc is *wrong* in emitting a warning there. sizeof(PCMWAVEFORMAT) >>> is a compile time constant and gcc can see that sizeof(PCMWAVEFORMAT) >>> falls well inside the number range expressible by a LONG. Logically >>> there is no difference between >>> formatsize <= sizeof(PCMWAVEFORMAT) >>> and >>> formatsize <= 16 >>> One gives a bogus warning and the other doesn't. >> C99 std (para 6.5.3.4.4) states following about sizeof operator: >> "...its type (an unsigned integer type) is size_t, deﬁned in <stddef.h> >> (and other headers)." >> >> sizeof result is a compile-time constant but, unlike numeric constants, >> its type must always be size_t so gcc does the correct thing here. > > The same is with C89, paragraph 3.3.3.4 from standard: > > The value of the result is implementation-defined, and its type (an > unsigned integral type) is size_t defined in the <stddef.h> header. > > So, the gcc is correct. In the example above, correct would be > > formatsize <= 16U > > which gives a warning, as expected. Yeah, sorry about that. I ASSumed the C spec would preserve the value and as sizeof(PCMWAVEFORMAT) is a constant expression it would be promoted to a LONG as that would preserve the values of both sides. gcc has no choice in this case then to follow the C standard. So I've read up on it and now I blame the C standard; especially after reading the "Coding guidelines" on page 7 of http://c0x.coding-guidelines.com/6.5.3.4.pdf aka the commentary to the changes proposed to sizeof() in the next C standard iteration. So much for the "principle of the least surprise" ... > What remains is how to correctly remove warning. In this case (and there are > many similar in the code), signed function parameter is comparing with > values that are natively unsigned. Changing type of the parameter is not > possible, the same if with sizeof operator. One possiblity is to add some > temporary variable, but in my opinioin it will just unncesary bloat the code > and is worse than casting return value of sizeof. > > Maybe better solution is to make signed_sizeof macro, which will always > return signed values and use it instead of sizeof; I will check if there is > possiblity for that. bye michael

Aug. 23, 2010

Re: avifil32: Removed sign comparison warning (sizeof expresions)

by Michael Stefaniuc

Alexandre Julliard wrote: > Marko Nikolic <grkoma(a)gmail.com> writes: > >> What remains is how to correctly remove warning. In this case (and there are >> many similar in the code), signed function parameter is comparing with >> values that are natively unsigned. Changing type of the parameter is not >> possible, the same if with sizeof operator. One possiblity is to add some >> temporary variable, but in my opinioin it will just unncesary bloat the code >> and is worse than casting return value of sizeof. > > In general a negative size would be an error too, so casting the sizeof > wouldn't do the right thing. Hmm ... gcc would still issue the warning even if we know that formatsize cannot be negative aka formatsize >= 0 && formatsize <= sizeof(PCMWAVEFORMAT) would still produce a warning. bye michael

Aug. 23, 2010

Re: avifil32: Removed sign comparison warning (sizeof expresions)

by Alexandre Julliard

Marko Nikolic <grkoma(a)gmail.com> writes: > What remains is how to correctly remove warning. In this case (and there are > many similar in the code), signed function parameter is comparing with > values that are natively unsigned. Changing type of the parameter is not > possible, the same if with sizeof operator. One possiblity is to add some > temporary variable, but in my opinioin it will just unncesary bloat the code > and is worse than casting return value of sizeof. In general a negative size would be an error too, so casting the sizeof wouldn't do the right thing. -- Alexandre Julliard julliard(a)winehq.org

Aug. 23, 2010

Re: [PATCH 1/3] msvcp90/tests: Added basic_string<char> tests (try2)

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4681 Your paranoid android. === WINEBUILD (build) === Make failed

Aug. 23, 2010

Re: New winetricks 20100822: new verb lucida

by James Mckenzie

Scott Ritchie <scott(a)open-vote.org> wrote: >Sent: Aug 23, 2010 6:37 AM >To: Wine Devel <wine-devel(a)winehq.org> >Subject: Re: New winetricks 20100822: new verb lucida > >On 08/23/2010 05:01 AM, Jacek Caban wrote: >> Hi Dan, >> >> On 8/22/10 8:57 PM, Dan Kegel wrote: >>> Dan Kegel: >>> gecko: make it work even if WINE isn't set. (How did this get >>> through?) >> >> I still hope that gecko will be removed from winetricks at some point. >> It clearly doesn't belong to winetricks. >> >> Also fakeie6 doesn't make sense anymore. We set these registries by >> default for over 2.5 years now. >> > >Well on Ubuntu at least installing the Wine package will pull in the >wine-gecko package and all will be well in the world. This is the >ultimate path forward, I think. > Any word from the RedHat/CentOS/Fedora crowd? I have to fix the video on my laptop (it's just messed up) and then I can check if this happens on CentOS 5.5 as well. James McKenzie

Aug. 23, 2010

Re: [PATCH] ntdll: set correct protection flags on sections in builtin DLLs

by Alexandre Julliard

Marcus Meissner <marcus(a)jet.franken.de> writes: > So a call to change the protection without calling mprotect() in the end? > like VIRTUAL_SetProtData() or something? Something like that yes (and please do it all in virtual.c, that's not the sort of function you want to make global). -- Alexandre Julliard julliard(a)winehq.org

Aug. 23, 2010

Re: New winetricks 20100822: new verb lucida

by Marcus Meissner

On Mon, Aug 23, 2010 at 06:37:44AM -0700, Scott Ritchie wrote: > On 08/23/2010 05:01 AM, Jacek Caban wrote: > > Hi Dan, > > > > On 8/22/10 8:57 PM, Dan Kegel wrote: > >> Dan Kegel: > >> gecko: make it work even if WINE isn't set. (How did this get > >> through?) > > > > I still hope that gecko will be removed from winetricks at some point. > > It clearly doesn't belong to winetricks. > > > > Also fakeie6 doesn't make sense anymore. We set these registries by > > default for over 2.5 years now. > > > > Well on Ubuntu at least installing the Wine package will pull in the > wine-gecko package and all will be well in the world. This is the > ultimate path forward, I think. Same for openSUSE. Ciao, Marcus

Aug. 23, 2010

Re: [PATCH] ntdll: set correct protection flags on sections in builtin DLLs

by Marcus Meissner

On Mon, Aug 23, 2010 at 03:43:35PM +0200, Alexandre Julliard wrote: > Marcus Meissner <marcus(a)jet.franken.de> writes: > > > @@ -1406,7 +1409,18 @@ static void load_builtin_callback( void *module, const char *filename ) > > } > > virtual_create_system_view( module, nt->OptionalHeader.SizeOfImage, > > VPROT_SYSTEM | VPROT_IMAGE | VPROT_COMMITTED | > > - VPROT_READ | VPROT_WRITECOPY | VPROT_EXEC ); > > + VPROT_READ | VPROT_WRITECOPY | VPROT_EXEC, &view ); > > + > > + sec = (IMAGE_SECTION_HEADER*)((char*)&nt->OptionalHeader+nt->FileHeader.SizeOfOptionalHeader); > > + for (i=0;i<nt->FileHeader.NumberOfSections;i++) { > > + DWORD flags = VPROT_SYSTEM | VPROT_IMAGE | VPROT_COMMITTED; > > + > > + if (sec[i].Characteristics & IMAGE_SCN_MEM_EXECUTE) flags |= VPROT_EXEC; > > + if (sec[i].Characteristics & IMAGE_SCN_MEM_READ) flags |= VPROT_READ; > > + if (sec[i].Characteristics & IMAGE_SCN_MEM_WRITE) flags |= VPROT_WRITE; > > + if (sec[i].Characteristics & IMAGE_SCN_MEM_SHARED) flags |= VPROT_WRITECOPY; > > + VIRTUAL_SetProt( view, (char*)module + sec[i].VirtualAddress, sec[i].Misc.VirtualSize, flags ); > > I don't think you want to actually change the permissions, our headers > don't necessarily match the real ELF sections. So a call to change the protection without calling mprotect() in the end? like VIRTUAL_SetProtData() or something? > (BTW, could you please convince your mailer to set a valid Message-Id?) I am bouncing them from the "git format-patch origin" created files currently. Ciao, Macus

Aug. 23, 2010

Re: configure: Enable prelink on x86_64

by Alexandre Julliard

Stefan Dösinger <stefan(a)codeweavers.com> writes: > From 98e8cc5d0b5b2d397c1d904d2537c326ed36d43c Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Stefan=20D=C3=B6singer?= <stefan(a)codeweavers.com> > Date: Sun, 22 Aug 2010 19:49:58 +0200 > Subject: [PATCH 4/4] Enable prelink on x86_64 Which app needs this? -- Alexandre Julliard julliard(a)winehq.org

Aug. 23, 2010

Re: [PATCH] ntdll: set correct protection flags on sections in builtin DLLs

by Alexandre Julliard

Marcus Meissner <marcus(a)jet.franken.de> writes: > @@ -1406,7 +1409,18 @@ static void load_builtin_callback( void *module, const char *filename ) > } > virtual_create_system_view( module, nt->OptionalHeader.SizeOfImage, > VPROT_SYSTEM | VPROT_IMAGE | VPROT_COMMITTED | > - VPROT_READ | VPROT_WRITECOPY | VPROT_EXEC ); > + VPROT_READ | VPROT_WRITECOPY | VPROT_EXEC, &view ); > + > + sec = (IMAGE_SECTION_HEADER*)((char*)&nt->OptionalHeader+nt->FileHeader.SizeOfOptionalHeader); > + for (i=0;i<nt->FileHeader.NumberOfSections;i++) { > + DWORD flags = VPROT_SYSTEM | VPROT_IMAGE | VPROT_COMMITTED; > + > + if (sec[i].Characteristics & IMAGE_SCN_MEM_EXECUTE) flags |= VPROT_EXEC; > + if (sec[i].Characteristics & IMAGE_SCN_MEM_READ) flags |= VPROT_READ; > + if (sec[i].Characteristics & IMAGE_SCN_MEM_WRITE) flags |= VPROT_WRITE; > + if (sec[i].Characteristics & IMAGE_SCN_MEM_SHARED) flags |= VPROT_WRITECOPY; > + VIRTUAL_SetProt( view, (char*)module + sec[i].VirtualAddress, sec[i].Misc.VirtualSize, flags ); I don't think you want to actually change the permissions, our headers don't necessarily match the real ELF sections. (BTW, could you please convince your mailer to set a valid Message-Id?) -- Alexandre Julliard julliard(a)winehq.org

Aug. 23, 2010

Re: New winetricks 20100822: new verb lucida

by Scott Ritchie

On 08/23/2010 05:01 AM, Jacek Caban wrote: > Hi Dan, > > On 8/22/10 8:57 PM, Dan Kegel wrote: >> Dan Kegel: >> gecko: make it work even if WINE isn't set. (How did this get >> through?) > > I still hope that gecko will be removed from winetricks at some point. > It clearly doesn't belong to winetricks. > > Also fakeie6 doesn't make sense anymore. We set these registries by > default for over 2.5 years now. > Well on Ubuntu at least installing the Wine package will pull in the wine-gecko package and all will be well in the world. This is the ultimate path forward, I think. Thanks, Scott Ritchie

Aug. 23, 2010

Re: [PATCH 4/6] shell32: Implement IExplorerBrowser::Advise and IExplorerBrowser::Unadvise.

by Alexandre Julliard

David Hedberg <david.hedberg(a)gmail.com> writes: > +#define EBE_IMPL(iface) \ > + ((IExplorerBrowserEventsImpl*)iface) > [...] > +static ULONG WINAPI IExplorerBrowserEvents_fnAddRef(IExplorerBrowserEvents *iface) > +{ > + return InterlockedIncrement(&(EBE_IMPL(iface)->ref)); That's ugly, declare a proper This pointer instead. -- Alexandre Julliard julliard(a)winehq.org

Aug. 23, 2010

Re: avifil32: Removed sign comparison warning (sizeof expresions)

by Michael Stefaniuc

Andrey Turkin wrote: > On Monday 23 August 2010 13:16:07 Michael Stefaniuc wrote: >> IMHO gcc is *wrong* in emitting a warning there. sizeof(PCMWAVEFORMAT) >> is a compile time constant and gcc can see that sizeof(PCMWAVEFORMAT) >> falls well inside the number range expressible by a LONG. Logically >> there is no difference between >> formatsize <= sizeof(PCMWAVEFORMAT) >> and >> formatsize <= 16 >> One gives a bogus warning and the other doesn't. > > C99 std (para 6.5.3.4.4) states following about sizeof operator: > "...its type (an unsigned integer type) is size_t, deﬁned in <stddef.h> (and > other headers)." > > sizeof result is a compile-time constant but, unlike numeric constants, its > type must always be size_t so gcc does the correct thing here. That's actually not the problem but the "value preservation rule" especially the "unsigned preservation rule". As sizeof(LONG) <= sizeof(size_t) the formatsize will be promoted to an unsigned. Iff formatsize is negative it will produce a big unsigned integer. So I'll retract my critique of gcc (in this case as the compiler cannot know what values formatsize will hold) and blame the C standard instead. bye michael

Aug. 23, 2010

Re: New winetricks 20100822: new verb lucida

by Jacek Caban

Hi Dan, On 8/22/10 8:57 PM, Dan Kegel wrote: > Dan Kegel: > gecko: make it work even if WINE isn't set. (How did this get through?) I still hope that gecko will be removed from winetricks at some point. It clearly doesn't belong to winetricks. Also fakeie6 doesn't make sense anymore. We set these registries by default for over 2.5 years now. Jacek

Aug. 23, 2010

Re: Re : d3dx9: Implement D3DXDeclaratorFromFVF.

by Henri Verbeet

On 23 August 2010 13:49, paulo lesgaz <jeremielapuree(a)yahoo.fr> wrote: > I already sent such a patch. Julliard did not like the gazillions of > conditions if.... then. > I never found a way to avoid them. > The offset can be computed thanks to the function D3DXGetDeclVertexSize > You know, just give the attached patches a try. Untested, of course.

Aug. 23, 2010

Re : d3dx9: Implement D3DXDeclaratorFromFVF.

by paulo lesgaz

I already sent such a patch. Julliard did not like the gazillions of conditions if.... then. I never found a way to avoid them. The offset can be computed thanks to the function D3DXGetDeclVertexSize A+ David ________________________________ De : Henri Verbeet <hverbeet(a)gmail.com> À : wine-devel(a)winehq.org Envoyé le : Lun 23 août 2010, 12h 03min 16s Objet : Re: d3dx9: Implement D3DXDeclaratorFromFVF. On 20 August 2010 21:16, Misha Koshelev <misha680(a)gmail.com> wrote: > Thank you for your helpful feedback on my tests. > > This is based mostly on dlls/d3d9/vertexdeclaration.c with some > changes specific to D3DXDeclaratorFromFVF. > > Again, if there are any suggested changes please let me know. > As you already mentioned, this is pretty much another copy/paste implementation, including e.g. the useless macros and typedef.

Aug. 23, 2010

Re: [5/5] libport: Add msvc isnan and isinf implementations

by Alexandre Julliard

Stefan Dösinger <stefan(a)codeweavers.com> writes: > @@ -31,6 +31,14 @@ int isinf(double x) > return (!(finite(x) || isnand(x))); > } > > +#elif defined(HAVE_FLOAT_H) && defined(_MSC_VER) > +#include <float.h> You should use proper configure checks instead of _MSC_VER, like we do for other similar cases. -- Alexandre Julliard julliard(a)winehq.org

Aug. 23, 2010

Re: avifil32: Removed sign comparison warning (sizeof expresions)

by Marko Nikolic

Andrey Turkin wrote: > On Monday 23 August 2010 13:16:07 Michael Stefaniuc wrote: >> IMHO gcc is *wrong* in emitting a warning there. sizeof(PCMWAVEFORMAT) >> is a compile time constant and gcc can see that sizeof(PCMWAVEFORMAT) >> falls well inside the number range expressible by a LONG. Logically >> there is no difference between >> formatsize <= sizeof(PCMWAVEFORMAT) >> and >> formatsize <= 16 >> One gives a bogus warning and the other doesn't. > > C99 std (para 6.5.3.4.4) states following about sizeof operator: > "...its type (an unsigned integer type) is size_t, deﬁned in <stddef.h> > (and other headers)." > > sizeof result is a compile-time constant but, unlike numeric constants, > its type must always be size_t so gcc does the correct thing here. The same is with C89, paragraph 3.3.3.4 from standard: The value of the result is implementation-defined, and its type (an unsigned integral type) is size_t defined in the <stddef.h> header. So, the gcc is correct. In the example above, correct would be formatsize <= 16U which gives a warning, as expected. What remains is how to correctly remove warning. In this case (and there are many similar in the code), signed function parameter is comparing with values that are natively unsigned. Changing type of the parameter is not possible, the same if with sizeof operator. One possiblity is to add some temporary variable, but in my opinioin it will just unncesary bloat the code and is worse than casting return value of sizeof. Maybe better solution is to make signed_sizeof macro, which will always return signed values and use it instead of sizeof; I will check if there is possiblity for that.

Aug. 23, 2010

Re: [PATCH 3/3] gameux/tests: verifying registry values created by GameExplorer

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4676 Your paranoid android. === WVISTAADM (32 bit gameexplorer) === gameexplorer.c:450: Test failed: cannot find expected registry value gameexplorer.c:468: Test failed: cannot find expected registry value

Aug. 23, 2010

Re: [2/6] wincodec.idl: invent an ICNS encoder CLSID

by Alexandre Julliard

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > Changelog: > * wincodec.idl: invent an ICNS encoder CLSID If it's invented it shouldn't be in a public header. -- Alexandre Julliard julliard(a)winehq.org

Aug. 23, 2010

Re: comctl32: Remove unused last parameter from TOOLTIPS_EnumToolsT.

by Nikolay Sivov

On 8/23/2010 00:51, Gerald Pfeifer wrote: > --- > dlls/comctl32/tooltips.c | 6 ++---- > 1 files changed, 2 insertions(+), 4 deletions(-) > > diff --git a/dlls/comctl32/tooltips.c b/dlls/comctl32/tooltips.c > index 688d3b5..d17f067 100644 > --- a/dlls/comctl32/tooltips.c > +++ b/dlls/comctl32/tooltips.c > @@ -1177,8 +1177,7 @@ TOOLTIPS_DelToolT (TOOLTIPS_INFO *infoPtr, const TTTOOLINFOW *ti, BOOL isW) > } > > static LRESULT > -TOOLTIPS_EnumToolsT (const TOOLTIPS_INFO *infoPtr, UINT uIndex, TTTOOLINFOW *ti, > - BOOL isW) > +TOOLTIPS_EnumToolsT (const TOOLTIPS_INFO *infoPtr, UINT uIndex, TTTOOLINFOW *ti) > { > TTTOOL_INFO *toolPtr; > > @@ -2176,8 +2175,7 @@ TOOLTIPS_WindowProc (HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam) > uMsg == TTM_DELTOOLW); > case TTM_ENUMTOOLSA: > case TTM_ENUMTOOLSW: > - return TOOLTIPS_EnumToolsT (infoPtr, (UINT)wParam, (LPTTTOOLINFOW)lParam, > - uMsg == TTM_ENUMTOOLSW); > + return TOOLTIPS_EnumToolsT (infoPtr, (UINT)wParam, (LPTTTOOLINFOW)lParam); > case TTM_GETBUBBLESIZE: > return TOOLTIPS_GetBubbleSize (infoPtr, (LPTTTOOLINFOW)lParam); > This needs to be implemented properly instead of being removed. Significant part is here: --- /* ti->lpszText = toolPtr->lpszText; */ ti->lpszText = NULL; /* FIXME */ --- which needs some tests. It's really doubtful that text is not returned when A/W messages exist.

Aug. 23, 2010

Re: d3dx9: Implement D3DXDeclaratorFromFVF.

by Henri Verbeet

On 20 August 2010 21:16, Misha Koshelev <misha680(a)gmail.com> wrote: > Thank you for your helpful feedback on my tests. > > This is based mostly on dlls/d3d9/vertexdeclaration.c with some > changes specific to D3DXDeclaratorFromFVF. > > Again, if there are any suggested changes please let me know. > As you already mentioned, this is pretty much another copy/paste implementation, including e.g. the useless macros and typedef.

Aug. 23, 2010

Re: avifil32: Removed sign comparison warning (sizeof expresions)

by Andrey Turkin

On Monday 23 August 2010 13:16:07 Michael Stefaniuc wrote: > IMHO gcc is *wrong* in emitting a warning there. sizeof(PCMWAVEFORMAT) > is a compile time constant and gcc can see that sizeof(PCMWAVEFORMAT) > falls well inside the number range expressible by a LONG. Logically > there is no difference between > formatsize <= sizeof(PCMWAVEFORMAT) > and > formatsize <= 16 > One gives a bogus warning and the other doesn't. C99 std (para 6.5.3.4.4) states following about sizeof operator: "...its type (an unsigned integer type) is size_t, deﬁned in <stddef.h> (and other headers)." sizeof result is a compile-time constant but, unlike numeric constants, its type must always be size_t so gcc does the correct thing here.

Aug. 23, 2010

Re: avifil32: Removed sign comparison warning (sizeof expresions)

by Michael Stefaniuc

Marko Nikolic wrote: > sizeof expresion always return unsigned type, so it is casted > when comparing with signed values. This is ugly. > --- > dlls/avifil32/wavfile.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/avifil32/wavfile.c b/dlls/avifil32/wavfile.c > index fd6d9ec..3fc934c 100644 > --- a/dlls/avifil32/wavfile.c > +++ b/dlls/avifil32/wavfile.c > @@ -803,7 +803,7 @@ static HRESULT WINAPI IAVIStream_fnSetFormat(IAVIStream *iface, LONG pos, > TRACE("(%p,%d,%p,%d)\n", iface, pos, format, formatsize); > > /* check parameters */ > - if (format == NULL || formatsize <= sizeof(PCMWAVEFORMAT)) > + if (format == NULL || formatsize <= (LONG)sizeof(PCMWAVEFORMAT)) IMHO gcc is *wrong* in emitting a warning there. sizeof(PCMWAVEFORMAT) is a compile time constant and gcc can see that sizeof(PCMWAVEFORMAT) falls well inside the number range expressible by a LONG. Logically there is no difference between formatsize <= sizeof(PCMWAVEFORMAT) and formatsize <= 16 One gives a bogus warning and the other doesn't. bye michael

Aug. 23, 2010

Re: [5/5] gdiplus: Test flags of loaded images.

by Vincent Povirk

Yep, this patch should not be committed. So the flags for a loaded image on Windows 7 are always 13010. So while earlier versions of gdiplus could determine whether the DPI was set in an image header, win7's gdiplus cannot, and always claims that it is. I remember reading that gdiplus on win7 uses WIC for its image loading/saving, and I know that WIC cannot get this information. So it makes sense. It's also very convenient for me. On Sun, Aug 22, 2010 at 1:42 PM, Marvin <testbot(a)testbot.winehq.org> wrote: > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > http://testbot.winehq.org/JobDetails.pl?Key=4650 > > Your paranoid android. > > > === WVISTAADM (32 bit image) === > No test summary line found > > === W7PRO (32 bit image) === > image.c:103: Test failed: Expected 00012010, got 00013010 > image.c:103: Test failed: Expected 00013088, got 00013010 > > === W7PROX64 (32 bit image) === > image.c:103: Test failed: Expected 00012010, got 00013010 > image.c:103: Test failed: Expected 00013088, got 00013010 > > === W7PROX64 (64 bit image) === > image.c:103: Test failed: Expected 00012010, got 00013010 > image.c:103: Test failed: Expected 00013088, got 00013010 > > >

Aug. 22, 2010

Re: msvideo: Forward MCIWndCreate16 to MCIWndCreateA (2nd)

by Alexandre Julliard

Stefan Leichter <Stefan.Leichter(a)camline.com> writes: > This was just a try to fix bug 23866. > > call 32 bit function from 16 bit and back is still some "black magic" for me. > Therefore i searched the wine sources for a similar case. Most/all places to > convert HINSTANCE16 to HINSTANCE i found are dlls/user.exe16/window.c . Looks > like i picked a "wrong" code fragment from there. > > Should i send a new patch only using HINSTANCE_32(GetExePtr( hinst16 )) ? No, that's wrong too. If the 16-bit code really needs a valid instance you have to pass it unmodified, otherwise you may just as well pass 0. -- Alexandre Julliard julliard(a)winehq.org

Aug. 22, 2010

New winetricks 20100822: new verb lucida

by Dan Kegel

Another fortnight, another Winetricks. Online as always at http://kegel.com/wine/winetricks or http://winezeug.googlecode.com (Bug reports to the issue tracker at the above URL, please.) Changes: Austin English mdac26: can't download anymore, so make it a synonym for mdac27 firefox: fix install. (filenames can have spaces. Patch by depesz. Issue 153.) lucida: add new font verb lucida mingw: fix PATH Andrew Nguyen wsh57: Fix the wsh57 dependency check and remove calls to load_wsh56 helper. Dan Kegel: gecko: make it work even if WINE isn't set. (How did this get through?)

Aug. 22, 2010

Re: appwiz.cpl: Removed sign comparison warning

by Marko Nikolic

Nikolay Sivov wrote: > On 8/21/2010 12:18, Marko Nikolic wrote: >> Nikolay Sivov wrote: >> >>> On 8/20/2010 20:04, Marko Nikolic wrote: >>>> Changed variable type to match function return type. >>>> --- >>>> dlls/appwiz.cpl/appwiz.c | 2 +- >>>> 1 files changed, 1 insertions(+), 1 deletions(-) >>>> >>>> diff --git a/dlls/appwiz.cpl/appwiz.c b/dlls/appwiz.cpl/appwiz.c >>>> index ffd2b24..1b3370b 100644 >>>> --- a/dlls/appwiz.cpl/appwiz.c >>>> +++ b/dlls/appwiz.cpl/appwiz.c >>>> @@ -406,7 +406,7 @@ static void UpdateButtons(HWND hWnd) >>>> { >>>> APPINFO *iter; >>>> LVITEMW lvItem; >>>> - DWORD selitem = SendDlgItemMessageW(hWnd, IDL_PROGRAMS, >>>> LVM_GETNEXTITEM, -1, >>>> + LRESULT selitem = SendDlgItemMessageW(hWnd, IDL_PROGRAMS, >>>> LVM_GETNEXTITEM, -1, >>>> LVNI_FOCUSED | LVNI_SELECTED); >>>> BOOL enable_modify = FALSE; >>>> >>> There's no need for that, return value means integer item index. What >>> are you fixing with that? >> Hi Nikolay, >> >> The above change suppresses sign comparison warning in the line >> >> if (selitem != -1) ... >> >> and two more places below. selitem is declared as unsigned (DWORD), so >> comparing with -1 produces warning. Since SendDlgItemMessageW anyway >> return LRESULT which is signed integer, patch changes the variable type >> to match function result and removes sign warnings. > LRESULT is something that supposed to work anyway as I understand it, > for this case I think it's > better to cast function return value to INT and use INT as a local type. Hi Nikolay, I don't think that casting is a good practice, it could just hide warnings instead of fixing them (ok, sometimes is necesary). However, in this case LRESULT (Long result) is anyway an int, 32 or 64 bit, depending on the platform. As I can see it, using LRESULT or INT is the same. Or maybe I am missing something else... Marko

Aug. 22, 2010

Re: [5/5] gdiplus: Test flags of loaded images.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4650 Your paranoid android. === WVISTAADM (32 bit image) === No test summary line found === W7PRO (32 bit image) === image.c:103: Test failed: Expected 00012010, got 00013010 image.c:103: Test failed: Expected 00013088, got 00013010 === W7PROX64 (32 bit image) === image.c:103: Test failed: Expected 00012010, got 00013010 image.c:103: Test failed: Expected 00013088, got 00013010 === W7PROX64 (64 bit image) === image.c:103: Test failed: Expected 00012010, got 00013010 image.c:103: Test failed: Expected 00013088, got 00013010

Aug. 22, 2010

Re: [4/5] gdiplus: Set bitmap has alpha flag based on format.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4649 Your paranoid android. === WVISTAADM (32 bit image) === No test summary line found

Aug. 22, 2010

Re: wineboot: More architectures and vendorIDs in create_hardware_registry_keys

by André Hentschel

Am 22.08.2010 12:48, schrieb Konrad Wartke: > Am 22.08.2010, 13:36 Uhr, schrieb André Hentschel <nerv(a)dawncrow.de>: > >>> +#ifdef __i386__ >>> + /* get VendorID from CPUID, eax = 0 */ >>> + unsigned int regs[3]; >> >> >> Hello Konrad, >> you are generating declerations after some code here. > > fixed and resend > > +#else > + static const WCHAR VenidIntelW[] = {'G','e','n','u','i','n','e','I','n','t','e','l',0}; Be more carefull, you still do it here. -- Best Regards, André Hentschel

Aug. 22, 2010

Re: problem with ./configure & libGLU vs. libice-dev

by wylda＠volny.cz

> > configure: libGLU development files not found, > > GLU won't be supported. GOUJON Alexandre: > It clearly appears that libGLU.so was present > during the "ok" configure > execution and not for the other. No, that's not true, because "ls -alF /usr/lib/libGLU*" showed that all files and even checksum are correct (before installation of libice and after installation of libice) Andrew Nguyen: > /usr/bin/ld: cannot find -lSM > Presumably libsm is unavailable, which causes the configure check > to fail. That's it :-D Installing libsm-dev solved the libGLU issue. Many thanks! Interesting, that ./configure does not say a word about missing libsm, like a "checking for -lSM... not found". So if another not related to wine installs libice-dev, then i can't play games under wine ;) Anyway why configure complains about mpg123 or libGLU like: configure: libGLU development files not found, GLU won't be supported. but does not complain at all about: libasound2-dev, libice-dev, libsm-dev?

Aug. 22, 2010

Re: wineboot: More architectures and vendorIDs in create_hardware_registry_keys

by André Hentschel

> +#ifdef __i386__ > + /* get VendorID from CPUID, eax = 0 */ > + unsigned int regs[3]; Hello Konrad, you are generating declerations after some code here. -- Best Regards, André Hentschel

Aug. 22, 2010

Re: problem with ./configure & libGLU vs. libice-dev

by GOUJON Alexandre

On 08/22/2010 10:09 AM, wylda(a)volny.cz wrote: >>> So why configure says me "-lGLU... not found" >>> when file "/usr/lib/libGLU.so.1" is present alex(a)Evan:~/Desktop$ diff configure_output_ok_libice_dev_missing.txt configure_output_bad_libice_dev_present.txt 506c506 < checking for IceConnectionNumber in -lICE... no --- > checking for IceConnectionNumber in -lICE... yes 539c539 < checking for -lGLU... libGLU.so.1 --- > checking for -lGLU... not found 802a803 > configure: libGLU development files not found, GLU won't be supported. It clearly appears that libGLU.so was present during the "ok" configure execution and not for the other.

Aug. 22, 2010

Re: problem with ./configure & libGLU vs. libice-dev

by Andrew Nguyen

On Sun, Aug 22, 2010 at 3:09 AM, <wylda(a)volny.cz> wrote: > Thanks for hints, Austin. Unfortunately looking at it and comparing > GOOD vs BAD log did not move me any further. So if anyone would see > there a bug, please let me know. Logs attached. > > W. > >From the bad configure log: configure:8817: checking for -lGLU configure:8842: gcc -o conftest -g -O2 conftest.c -lGLU -lGL -lSM -lICE -lXext -lX11 -lm >&5 /usr/bin/ld: cannot find -lSM Presumably libsm is unavailable, which causes the configure check to fail.

Aug. 22, 2010

Re: wineboot: More architectures and vendorIDs in create_hardware_registry_keys

by Konrad Wartke

Am 22.08.2010, 13:36 Uhr, schrieb André Hentschel <nerv(a)dawncrow.de>: >> +#ifdef __i386__ >> + /* get VendorID from CPUID, eax = 0 */ >> + unsigned int regs[3]; > > > Hello Konrad, > you are generating declerations after some code here. fixed and resend

Aug. 22, 2010

Re: msvideo: Forward MCIWndCreate16 to MCIWndCreateA (2nd)

by Stefan Leichter

Am Thursday 19 August 2010 11:58:23 schrieb Alexandre Julliard: > Stefan Leichter <Stefan.Leichter(a)camline.com> writes: > > + HINSTANCE hinst32; > > + if (hinst16 == GetModuleHandle16("msvideo.dll")) > > + hinst32 = GetModuleHandleA("msvfw32.dll"); > > + else > > + hinst32 = HINSTANCE_32(GetExePtr( hinst16 )); > > This doesn't seem right. Why do you need this? This was just a try to fix bug 23866. call 32 bit function from 16 bit and back is still some "black magic" for me. Therefore i searched the wine sources for a similar case. Most/all places to convert HINSTANCE16 to HINSTANCE i found are dlls/user.exe16/window.c . Looks like i picked a "wrong" code fragment from there. Should i send a new patch only using HINSTANCE_32(GetExePtr( hinst16 )) ? -- Stefan Leichter

Aug. 22, 2010

Re: problem with ./configure & libGLU vs. libice-dev

by wylda＠volny.cz

> > > > So why configure says me "-lGLU... not found" > > when file "/usr/lib/libGLU.so.1" is present? > > You'll want to check config.log for a more verbose > error. > > -- > -Austin Thanks for hints, Austin. Unfortunately looking at it and comparing GOOD vs BAD log did not move me any further. So if anyone would see there a bug, please let me know. Logs attached. W.

Aug. 22, 2010

Re: [PATCH 1/2] quartz/tests: move shareable code to a separate file

by Anton Khirnov

On Sat, Aug 21, 2010 at 07:50:50PM -0700, James McKenzie wrote: > Looks like you did not test the build before running it against the > testbot (I've been guilty of this as well.) > actually i did test it and it worked for some reason, must be magic :) in any case, after rebasing it doesn't -- and the reason seems to be that the build system assumes that each .c file under tests/ actually contains a test. is there a way around that (besides the obvious-but-ugly empty test in the common file)? Anton Khirnov

Aug. 22, 2010

Re: [PATCH 1/2] quartz/tests: move shareable code to a separate file

by James McKenzie

(Marvin) wrote: > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > http://testbot.winehq.org/JobDetails.pl?Key=4626 > > Your paranoid android. > > > === WINEBUILD (build) === > Make failed > > Looks like you did not test the build before running it against the testbot (I've been guilty of this as well.) Rebase your code against the most current git and then resubmit. James McKenzie

Aug. 22, 2010

Re: [PATCH 2/5] ddraw/tests: New visual back buffer flipping tests. (try 5, resend)

by Oldřich Jedlička

Hi Stefan, On Thursday 19 August 2010 15:40:53 Stefan Dösinger wrote: > This test contains a C++ comment, please remove it. Otherwise it looks ok, > as does patch 1 I will start sending patches one-by-one and wait until it is applied - as you recommended. It will not contain the [PATCH x/y] prefix, so don't be confused :-) I will also remove the "try 5" and start from the beginning. I will start with this patch, description is unmodified, but the C++ comment is converted to C comment. Oldřich. > > Am 18.08.2010 um 22:01 schrieb Oldřich Jedlička: > > --- > > dlls/ddraw/tests/visual.c | 123 > > +++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 123 > > insertions(+), 0 deletions(-) > > > > diff --git a/dlls/ddraw/tests/visual.c b/dlls/ddraw/tests/visual.c > > index 290cb76..aecc2ab 100644 > > --- a/dlls/ddraw/tests/visual.c > > +++ b/dlls/ddraw/tests/visual.c > > @@ -2920,6 +2920,128 @@ static void depth_clamp_test(IDirect3DDevice7 > > *device) > > > > ok(SUCCEEDED(hr), "SetViewport failed, hr %#x.\n", hr); > > > > } > > > > +static void DX1_BackBufferFlipTest(void) > > +{ > > + HRESULT hr; > > + int ret; > > + IDirectDraw *DirectDraw1 = NULL; > > + IDirectDrawSurface *Primary = NULL; > > + IDirectDrawSurface *Backbuffer = NULL; > > + WNDCLASS wc = {0}; > > + DDSURFACEDESC ddsd; > > + DDBLTFX ddbltfx; > > + COLORREF color; > > + const DWORD white = 0xffffff; > > + const DWORD red = 0xff0000; > > + BOOL attached = FALSE; > > + > > + wc.lpfnWndProc = DefWindowProc; > > + wc.lpszClassName = "DX1_BackBufferFlipTest_wc"; > > + RegisterClass(&wc); > > + window = CreateWindow("DX1_BackBufferFlipTest_wc", > > "DX1_BackBufferFlipTest", + WS_MAXIMIZE | > > WS_VISIBLE | WS_CAPTION , 0, 0, 640, 480, 0, 0, 0, 0); + > > + hr = DirectDrawCreate( NULL, &DirectDraw1, NULL ); > > + ok(hr==DD_OK || hr==DDERR_NODIRECTDRAWSUPPORT, "DirectDrawCreate > > returned: %x\n", hr); + if(FAILED(hr)) goto out; > > + > > + hr = IDirectDraw_SetCooperativeLevel(DirectDraw1, window, > > DDSCL_EXCLUSIVE | DDSCL_FULLSCREEN); + ok(hr==DD_OK, > > "SetCooperativeLevel returned: %x\n", hr); > > + if(FAILED(hr)) goto out; > > + > > + hr = IDirectDraw_SetDisplayMode(DirectDraw1, 640, 480, 32); > > + if(FAILED(hr)) { > > + /* 24 bit is fine too */ > > + hr = IDirectDraw_SetDisplayMode(DirectDraw1, 640, 480, 24); > > + } > > + ok(hr==DD_OK || hr == DDERR_UNSUPPORTED, "SetDisplayMode returned: > > %x\n", hr); + if (FAILED(hr)) { > > + goto out; > > + } > > + > > + memset(&ddsd, 0, sizeof(DDSURFACEDESC)); > > + ddsd.dwSize = sizeof(DDSURFACEDESC); > > + ddsd.dwFlags = DDSD_CAPS; > > + ddsd.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE; > > + > > + hr = IDirectDraw_CreateSurface(DirectDraw1, &ddsd, &Primary, NULL); > > + ok(hr==DD_OK, "IDirectDraw_CreateSurface returned: %08x\n", hr); > > + > > + memset(&ddsd, 0, sizeof(DDSURFACEDESC)); > > + ddsd.dwSize = sizeof(DDSURFACEDESC); > > + ddsd.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT | > > DDSD_PIXELFORMAT; + ddsd.ddsCaps.dwCaps = DDSCAPS_BACKBUFFER; > > + ddsd.dwWidth = 640; > > + ddsd.dwHeight = 480; > > + ddsd.ddpfPixelFormat.dwSize = sizeof(ddsd.ddpfPixelFormat); > > + ddsd.ddpfPixelFormat.dwFlags = DDPF_RGB; > > + U1(ddsd.ddpfPixelFormat).dwRGBBitCount = 32; > > + U2(ddsd.ddpfPixelFormat).dwRBitMask = 0x00ff0000; > > + U3(ddsd.ddpfPixelFormat).dwGBitMask = 0x0000ff00; > > + U4(ddsd.ddpfPixelFormat).dwBBitMask = 0x000000ff; > > + > > + hr = IDirectDraw_CreateSurface(DirectDraw1, &ddsd, &Backbuffer, > > NULL); + todo_wine ok(hr==DD_OK, "IDirectDraw_CreateSurface returned: > > %08x\n", hr); + if(FAILED(hr)) goto out; > > + > > + hr = IDirectDrawSurface_AddAttachedSurface(Primary, Backbuffer); > > + todo_wine ok(hr == DD_OK || broken(hr == DDERR_CANNOTATTACHSURFACE), > > + "Attaching a back buffer to a front buffer returned %08x\n", hr); > > + if (FAILED(hr)) goto out; > > + > > + attached = TRUE; > > + > > + memset(&ddbltfx, 0, sizeof(ddbltfx)); > > + ddbltfx.dwSize = sizeof(ddbltfx); > > + U5(ddbltfx).dwFillColor = red; > > + hr = IDirectDrawSurface_Blt(Backbuffer, NULL, NULL, NULL, > > DDBLT_COLORFILL | DDBLT_WAIT, &ddbltfx); + ok(hr == DD_OK, > > "IDirectDrawSurface_Blt returned: %x\n", hr); + > > + U5(ddbltfx).dwFillColor = white; > > + hr = IDirectDrawSurface_Blt(Primary, NULL, NULL, NULL, > > DDBLT_COLORFILL | DDBLT_WAIT, &ddbltfx); + ok(hr == DD_OK, > > "IDirectDrawSurface_Blt returned: %x\n", hr); + > > + // Check it out > > + color = getPixelColor_GDI(Primary, 5, 5); > > + ok(GetRValue(color) == 0xFF && GetGValue(color) == 0xFF && > > GetBValue(color) == 0xFF, + "got R %02X G %02X B %02X, > > expected R FF G FF B FF\n", + GetRValue(color), > > GetGValue(color), GetBValue(color)); + > > + color = getPixelColor_GDI(Backbuffer, 5, 5); > > + ok(GetRValue(color) == 0xFF && GetGValue(color) == 0 && > > GetBValue(color) == 0, + "got R %02X G %02X B %02X, expected > > R FF G 00 B 00\n", + GetRValue(color), GetGValue(color), > > GetBValue(color)); + > > + hr = IDirectDrawSurface_Flip(Primary, NULL, DDFLIP_WAIT); > > + todo_wine ok(hr == DD_OK, "IDirectDrawSurface_Flip returned > > 0x%08x\n", hr); + > > + if (hr == DD_OK) > > + { > > + color = getPixelColor_GDI(Primary, 5, 5); > > + ok(GetRValue(color) == 0xFF && GetGValue(color) == 0 && > > GetBValue(color) == 0, + "got R %02X G %02X B %02X, > > expected R FF G 00 B 00\n", + GetRValue(color), > > GetGValue(color), GetBValue(color)); + > > + color = getPixelColor_GDI(Backbuffer, 5, 5); > > + ok((GetRValue(color) == 0xFF && GetGValue(color) == 0xFF && > > GetBValue(color) == 0xFF) || + broken(GetRValue(color) == 0xFF > > && GetGValue(color) == 0 && GetBValue(color) == 0), // broken driver + > > "got R %02X G %02X B %02X, expected R FF G FF B FF\n", + > > GetRValue(color), GetGValue(color), GetBValue(color)); + > > } > > + > > + out: > > + > > + if (Backbuffer) > > + { > > + if (attached) > > + IDirectDrawSurface_DeleteAttachedSurface(Primary, 0, > > Backbuffer); + IDirectDrawSurface_Release(Backbuffer); > > + } > > + if (Primary) IDirectDrawSurface_Release(Primary); > > + if (DirectDraw1) IDirectDraw_Release(DirectDraw1); > > + if (window) DestroyWindow(window); > > +} > > + > > START_TEST(visual) > > { > > > > HRESULT hr; > > > > @@ -2983,6 +3105,7 @@ START_TEST(visual) > > > > D3D3_ViewportClearTest(); > > p8_primary_test(); > > > > + DX1_BackBufferFlipTest(); > > > > return ;

Aug. 21, 2010

Re: Specifying Reply-To header in patches email using git-send-email?

by Frédéric Delanoy

2010/8/21 Octavian Voicu <octavian.voicu(a)gmail.com>: > 2010/8/21 GOUJON Alexandre <ale.goujon(a)gmail.com>: >> [format] >> headers = "To: wine-patches <wine-patches(a)winehq.org>\nReply-To: >> wine-devel <wine-devel(a)winehq.org>\n" > > As the name of the section suggests, this adds header lines to files > generated with `git format-patch'. If you then send those files with > `git send-email', it should work. If you `git send-email' files > generated before configuring that, then it wouldn't have any effect. > > Initially I thought the mailing list software was configured to add > the Reply-To header automagically, guess I was wrong. > > Octavian OK. By using [format] headers = "Reply-To: wine-devel <wine-devel(a)winehq.org>\n" [sendemail] to = wine-patches <wine-patches(a)winehq.org> I manage to get fully automated sending (yeah!). OTOH, using headers = "wine-patches <wine-patches(a)winehq.org>\nReply-To: wine-devel <wine-devel(a)winehq.org>\n" doesn't work since you're asked to provide the "To:" and you end up with two different "To" headers. I'll update the wiki. Thanks guys for your help. Frédéric

Aug. 21, 2010

Re: [PATCH 2/2] quartz: implement IBaseFilter_FindPin

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4627 Your paranoid android. === WINEBUILD (build) === Make failed

Aug. 21, 2010

Re: [PATCH 1/2] quartz/tests: move shareable code to a separate file

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4626 Your paranoid android. === WINEBUILD (build) === Make failed

Aug. 21, 2010

Re: problem with ./configure & libGLU vs. libice-dev

by Austin English

On Fri, Aug 20, 2010 at 4:26 PM, <wylda(a)volny.cz> wrote: > > Hi, > > isn't there a problem with wine's configure script? I'm running on > new Debian Squezee and noticed (luckily), that when libice-dev is > installed, than ./configure can't find "-lGLU". > > But libice-dev doesn't have any influence on file "libGLU.so.1". > > So why configure says me "-lGLU... not found" when file > "/usr/lib/libGLU.so.1" is present? You'll want to check config.log for a more verbose error. -- -Austin

Aug. 21, 2010

Re: Specifying Reply-To header in patches email using git-send-email?

by GOUJON Alexandre

On 08/21/2010 03:35 PM, Frédéric Delanoy wrote: > This is used for git imap-send, and does not work for git-send-email > (I checked). > Following the relevant git send-email section > (http://wiki.winehq.org/GitWine#head-f09f3498e5910648468960a60ecf0f51b0fd4815 > - Sending the patches using smtp), I set "thread" to true, but this > doesn't change anything/has nothing to do with the "Reply-To" header, > rather the "In-Reply-To" header. > > I'm using git 1.7.2.1 > I attached the script I use to send patches to wine + my .git/config file The only drawback is that the "wine-patches <>" is added twice. But it works for me.

Aug. 21, 2010

Re: Specifying Reply-To header in patches email using git-send-email?

by Octavian Voicu

2010/8/21 GOUJON Alexandre <ale.goujon(a)gmail.com>: > [format] > headers = "To: wine-patches <wine-patches(a)winehq.org>\nReply-To: > wine-devel <wine-devel(a)winehq.org>\n" As the name of the section suggests, this adds header lines to files generated with `git format-patch'. If you then send those files with `git send-email', it should work. If you `git send-email' files generated before configuring that, then it wouldn't have any effect. Initially I thought the mailing list software was configured to add the Reply-To header automagically, guess I was wrong. Octavian

Aug. 21, 2010

Re: Specifying Reply-To header in patches email using git-send-email?

by Frédéric Delanoy

2010/8/21 GOUJON Alexandre <ale.goujon(a)gmail.com>: > On 08/21/2010 09:34 AM, Frédéric Delanoy wrote: >> >> Here's how my git config looks like: >> [sendemail] >> <smtp server config> >> from = user<email> >> to = wine-patches<wine-patches(a)winehq.org> >> assume8bitEncoding = UTF-8 >> >> suppresscc = self >> chainreplyto = false >> thread = false >> suppressfrom = true >> > > From > http://wiki.winehq.org/GitWine#head-4051a521ff163340844bba9c78036cd8c594a980 > and according to my .git/config, I think you're missing > > [format] > headers = "To: wine-patches <wine-patches(a)winehq.org>\nReply-To: > wine-devel <wine-devel(a)winehq.org>\n" > This is used for git imap-send, and does not work for git-send-email (I checked). Following the relevant git send-email section (http://wiki.winehq.org/GitWine#head-f09f3498e5910648468960a60ecf0f51b0fd4815 - Sending the patches using smtp), I set "thread" to true, but this doesn't change anything/has nothing to do with the "Reply-To" header, rather the "In-Reply-To" header. I'm using git 1.7.2.1 Frédéric

Aug. 21, 2010

Re: appwiz.cpl: Removed sign comparison warning

by Nikolay Sivov

On 8/21/2010 12:18, Marko Nikolic wrote: > Nikolay Sivov wrote: > >> On 8/20/2010 20:04, Marko Nikolic wrote: >>> Changed variable type to match function return type. >>> --- >>> dlls/appwiz.cpl/appwiz.c | 2 +- >>> 1 files changed, 1 insertions(+), 1 deletions(-) >>> >>> diff --git a/dlls/appwiz.cpl/appwiz.c b/dlls/appwiz.cpl/appwiz.c >>> index ffd2b24..1b3370b 100644 >>> --- a/dlls/appwiz.cpl/appwiz.c >>> +++ b/dlls/appwiz.cpl/appwiz.c >>> @@ -406,7 +406,7 @@ static void UpdateButtons(HWND hWnd) >>> { >>> APPINFO *iter; >>> LVITEMW lvItem; >>> - DWORD selitem = SendDlgItemMessageW(hWnd, IDL_PROGRAMS, >>> LVM_GETNEXTITEM, -1, >>> + LRESULT selitem = SendDlgItemMessageW(hWnd, IDL_PROGRAMS, >>> LVM_GETNEXTITEM, -1, >>> LVNI_FOCUSED | LVNI_SELECTED); >>> BOOL enable_modify = FALSE; >>> >> There's no need for that, return value means integer item index. What >> are you fixing with that? > Hi Nikolay, > > The above change suppresses sign comparison warning in the line > > if (selitem != -1) ... > > and two more places below. selitem is declared as unsigned (DWORD), so > comparing with -1 produces warning. Since SendDlgItemMessageW anyway return > LRESULT which is signed integer, patch changes the variable type to match > function result and removes sign warnings. LRESULT is something that supposed to work anyway as I understand it, for this case I think it's better to cast function return value to INT and use INT as a local type. > BR, > > Marko > >

Aug. 21, 2010

Re: dlls/d3dx9_36/bytecodewriter.c oddity

by Gerald Pfeifer

On Thu, 19 Aug 2010, Matteo Bruni wrote: > Hmm, so srcidx is unused. Yes, that piece of code is useless now, it's > a remnant of an older version of that function where the source > register was handled by some ad-hoc code, which I since then replaced > with a call to the generic This->funcs->srcreg(). The function is > correct otherwise, there are some tests to confirm that. > In my opinion you can send the patch as is. Alternatively you can > replace that piece of code with just a check for instr->src[0].regnum > != T[0123]_REG, to keep the WARN, but it's not worth the effort > probably. Thanks a lot Matteo for your guidance! Based on this, I'll formally submit this to wine-patches. Gerald

Aug. 21, 2010

Re: crypt32: Correct CryptVerifyMessageSignature's use of pcbDecoded

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4624 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: appwiz.cpl: Removed sign comparison warning

by Marko Nikolic

Nikolay Sivov wrote: > On 8/20/2010 20:04, Marko Nikolic wrote: >> Changed variable type to match function return type. >> --- >> dlls/appwiz.cpl/appwiz.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/dlls/appwiz.cpl/appwiz.c b/dlls/appwiz.cpl/appwiz.c >> index ffd2b24..1b3370b 100644 >> --- a/dlls/appwiz.cpl/appwiz.c >> +++ b/dlls/appwiz.cpl/appwiz.c >> @@ -406,7 +406,7 @@ static void UpdateButtons(HWND hWnd) >> { >> APPINFO *iter; >> LVITEMW lvItem; >> - DWORD selitem = SendDlgItemMessageW(hWnd, IDL_PROGRAMS, >> LVM_GETNEXTITEM, -1, >> + LRESULT selitem = SendDlgItemMessageW(hWnd, IDL_PROGRAMS, >> LVM_GETNEXTITEM, -1, >> LVNI_FOCUSED | LVNI_SELECTED); >> BOOL enable_modify = FALSE; >> > There's no need for that, return value means integer item index. What > are you fixing with that? Hi Nikolay, The above change suppresses sign comparison warning in the line if (selitem != -1) ... and two more places below. selitem is declared as unsigned (DWORD), so comparing with -1 produces warning. Since SendDlgItemMessageW anyway return LRESULT which is signed integer, patch changes the variable type to match function result and removes sign warnings. BR, Marko

Aug. 21, 2010

Re: Specifying Reply-To header in patches email using git-send-email?

by GOUJON Alexandre

On 08/21/2010 09:34 AM, Frédéric Delanoy wrote: > Here's how my git config looks like: > [sendemail] > <smtp server config> > from = user<email> > to = wine-patches<wine-patches(a)winehq.org> > assume8bitEncoding = UTF-8 > > suppresscc = self > chainreplyto = false > thread = false > suppressfrom = true > >From http://wiki.winehq.org/GitWine#head-4051a521ff163340844bba9c78036cd8c594a980 and according to my .git/config, I think you're missing [format] headers = "To: wine-patches <wine-patches(a)winehq.org>\nReply-To: wine-devel <wine-devel(a)winehq.org>\n"

Aug. 21, 2010

Specifying Reply-To header in patches email using git-send-email?

by Frédéric Delanoy

I've tried for some time to specify the wine-devel Reply-To using git-send-email, with little success so far Any idea how this might be done? Here's how my git config looks like: [sendemail] <smtp server config> from = user <email> to = wine-patches <wine-patches(a)winehq.org> assume8bitEncoding = UTF-8 suppresscc = self chainreplyto = false thread = false suppressfrom = true Frédéric

Aug. 21, 2010

Re: [PATCH 5/5] shell32: Implement IExplorerBrowser::SetRect.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4604 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: [PATCH 4/5] shell32: Implement IExplorerBrowser::Initialize.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4603 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: [PATCH 3/5] shell32: Add IShellBrowser stub.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4602 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: [PATCH 2/5] shell32/tests: Add initial tests for the IExplorerBrowser control.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4601 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: [PATCH] ntdll/tests: Add tests for RtlIpv4AddressToString / RtlIpv4AddressToStringEx [try 5]

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4600 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: advpakc/tests: Removed sign comparison warning in advpack tests

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4599 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: [PATCH 7/8] msvcp90/tests: Added basic_string<char> tests

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4597 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: [PATCH 2/2] d3dcompiler: Add D3DCreateBlob() test.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4596 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: [PATCH try 2] ntdll: IMAGE_REL_BASED_HIGH, IMAGE_REL_BASED_LOW and IMAGE_REL_BASED_HIGHLOW should be supported on win64.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4595 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: [7/7] comctl32/imagelist: Fail to create imagelist with zero or negative image dimensions

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4594 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: [6/7] comctl32/imagelist: Fail in ImageList_GetIconSize on null parameters

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4593 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: [5/7] comctl32/tests: More imagelist tests to show broken parameter validation

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4592 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: [4/7] comctl32/imagelist: Fix failure code for IImageList_Remove()

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4591 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: [3/7] comctl32/imagelist: Fix failure code for IImageList_Draw()

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4590 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: [2/7] comctl32/tests: Use reduced IMAGELISTDRAWPARAMS structure size for tests

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4589 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: [1/7] comctl32/tests: Use better names for test functions, discover some new test failures

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4588 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: oleau32: Try both SYS_WIN64 and SYS_WIN32 syskind in QueryPathOfRegTypeLib on win64.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4582 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: gdi32: Properly set ERROR_NOACCESS when GetObject receives invalid arguments

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4581 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: [PATCH 4/4] explorerframe: Some additional basic tests.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4578 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: [PATCH 3/4] explorerframe: Implement EnsureItemVisible.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4577 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: [PATCH 2/4] explorerframe: Implement HitTest

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4576 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: [PATCH] comctl32/tests: DateTimePicker and MonthCalendar controls only support Gregorian calendar.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4574 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Re: [5/5] urlmon/tests: Added tests for IUriBuilder_GetFragment

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4571 Your paranoid android. === WINEBUILD (build) === Patch failed

Aug. 21, 2010

Ongoing Debian package maintenance.

by Ben Klein

Hello everyone, My health has not improved at all since my last call for help with the Debian package management. I really need someone to take over from me, or at least some help to devise a new set of (semi-)automated build scripts. Any volunteers? Kind regards, Ben

Aug. 20, 2010

problem with ./configure & libGLU vs. libice-dev

by wylda＠volny.cz

Hi, isn't there a problem with wine's configure script? I'm running on new Debian Squezee and noticed (luckily), that when libice-dev is installed, than ./configure can't find "-lGLU". But libice-dev doesn't have any influence on file "libGLU.so.1". So why configure says me "-lGLU... not found" when file "/usr/lib/libGLU.so.1" is present? Desperate W.

Aug. 20, 2010

Re: [website]Japanese Translation for "About Wine" page

by Jeremy Newman

I'll accept this patch when we also have a JA translation of the Front landing page. No point having other pages translated without at least that. -Newman On 08/17/2010 11:00 PM, kikuchy.h(a)gmail.com wrote: > From: Hiroshi Kikuchi<kikuchy.h(a)gmail.com> > > I want to join wine project. Nice to meet you. > Hiroshi Kikuchi > --- > templates/ja/about.template | 27 +++++++++++++++++++++++++++ > 1 files changed, 27 insertions(+), 0 deletions(-) > create mode 100644 templates/ja/about.template > > diff --git a/templates/ja/about.template b/templates/ja/about.template > new file mode 100644 > index 0000000..b83fad7 > --- /dev/null > +++ b/templates/ja/about.template > @@ -0,0 +1,27 @@ > + > + > + > +<h1 class="title">Wine について</h1> > + > +<p>Wine は、 Windows のソフトウェアを Windows 以外のOSで動作させるものです。Wine を使えば、Windows でするように Windows アプリケーションのインストールと実行が出来るようになります。</p> > + > +<p>Wine は現在活発に開発されています。まだ全てのプログラムが動作する訳ではありませんが、すでに<a href="http://wiki.winehq.org/UsageStatistics" title="Wine Usage Statistics">何人もの人たちが</a> Wine を使ってソフトウェアを動かしています。</p> > + > +<h3>オープンソース、そしてユーザーによる支援</h3> > + > +<p>Wine は未来永劫<a href="http://wiki.winehq.org/Licensing" title="Wine licensing">フリーソフト</a>です。Wine のソースコードのおよそ半分がボランティアによって書かれています。残り半分は商業的利潤のため、特にサポートがあるバージョンの Wine を発売している<a href="http://www.codeweavers.com/products/" title="Codeweavers Crossover Office">Codeweavers</a>によって支えられています。</p> > + > +<p>Wine はユーザーコミュニティに大きく頼っています。ユーザーのテストが私たちの、プログラムの動作状況を記録した<a href="http://appdb.winehq.org/" title="Wine Application Database">アプリケーションデータベース</a>を埋めてくれていますし、<a href="http://forums.winehq.org/" title="WineHQ Forums">フォーラム</a>の質問に対する答えも全てボランティアによるものです。</p> > + > +<h3>こちらもご覧ください:</h3> > +<ul> > +<li><a href="http://wiki.winehq.org/ImportanceOfWine">Wine が重要な理由</a></li> > +<li><a href="http://wiki.winehq.org/Debunking_Wine_Myths">Wine にまつわるウソ・ホント</a></li> > +<li><a href="http://wiki.winehq.org/WineHistory">Wine プロジェクトの歴史</a></li> > +<li><a href="http://wiki.winehq.org/ProjectOrganization">Organization and Leadership</a></li> > +</ul> > + > +<hr> > +<div class="link-container"> > +<p class="right-link">Wine の歴史:<a href="{$root}/history">次へ</a></p> > +</div> > > > >

Aug. 20, 2010

Re: appwiz.cpl: Removed sign comparison warning

by Nikolay Sivov

On 8/20/2010 20:04, Marko Nikolic wrote: > Changed variable type to match function return type. > --- > dlls/appwiz.cpl/appwiz.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/appwiz.cpl/appwiz.c b/dlls/appwiz.cpl/appwiz.c > index ffd2b24..1b3370b 100644 > --- a/dlls/appwiz.cpl/appwiz.c > +++ b/dlls/appwiz.cpl/appwiz.c > @@ -406,7 +406,7 @@ static void UpdateButtons(HWND hWnd) > { > APPINFO *iter; > LVITEMW lvItem; > - DWORD selitem = SendDlgItemMessageW(hWnd, IDL_PROGRAMS, LVM_GETNEXTITEM, -1, > + LRESULT selitem = SendDlgItemMessageW(hWnd, IDL_PROGRAMS, LVM_GETNEXTITEM, -1, > LVNI_FOCUSED | LVNI_SELECTED); > BOOL enable_modify = FALSE; > There's no need for that, return value means integer item index. What are you fixing with that?

Aug. 20, 2010

Re: The Test Bot seems to be having issues

by André Hentschel

Am 20.08.2010 17:15, schrieb Greg Geldorp: > Hi Thomas, > >> From: Thomas Mallaly >> >> First off, I'm not sure who should be contacted about this, but, it > appears >> that the test bot has got itself stuck while trying to run tests on a > patch >> submitted last night. > > Sorry, hadn't noticed it got stuck. Usually it doesn't need much > baby-sitting, > so I don't keep a close look on it. > You can always use the "Feedback" link on the TestBot home page. > >> The job in question is here [1], it's been over 12 >> hours since any progress has been made on it and no other submissions have >> run since then. Also, the Windows 98SE has been "reverting" this whole > time, >> so I'm not sure if this is the culprit or not. >> >> I also hate to admit that the job in question is from one of my patches I >> sent in last night (although I'm pretty sure it doesn't have anything to > do >> with the quality of the code in the patch ;-) ). > > The Win9x VMs are on a different (physical) machine, it appears there was a > network problem between the Test Bot host and the machine hosting the Win9x > VMs. The Win98SE VM getting stuck in the "reverting" state is the cause of > the problems, nothing to do with your patch. > >> Anyways, I'm hoping that somebody in charge of the test bot might be able > to >> fix the traffic jam it's causing. > > It's back up and running again, trying to catch up. > > Ge. > > > > Thx, will be a hard weekend for testbot, as today there should be two commits :) -- Best Regards, André Hentschel

Aug. 20, 2010

RE: The Test Bot seems to be having issues

by Greg Geldorp

Hi Thomas, > From: Thomas Mallaly > > First off, I'm not sure who should be contacted about this, but, it appears > that the test bot has got itself stuck while trying to run tests on a patch > submitted last night. Sorry, hadn't noticed it got stuck. Usually it doesn't need much baby-sitting, so I don't keep a close look on it. You can always use the "Feedback" link on the TestBot home page. > The job in question is here [1], it's been over 12 > hours since any progress has been made on it and no other submissions have > run since then. Also, the Windows 98SE has been "reverting" this whole time, > so I'm not sure if this is the culprit or not. > > I also hate to admit that the job in question is from one of my patches I > sent in last night (although I'm pretty sure it doesn't have anything to do > with the quality of the code in the patch ;-) ). The Win9x VMs are on a different (physical) machine, it appears there was a network problem between the Test Bot host and the machine hosting the Win9x VMs. The Win98SE VM getting stuck in the "reverting" state is the cause of the problems, nothing to do with your patch. > Anyways, I'm hoping that somebody in charge of the test bot might be able to > fix the traffic jam it's causing. It's back up and running again, trying to catch up. Ge.

Aug. 20, 2010

CVS gateway down for good

by Alexandre Julliard

Folks, The git->CVS gateway broke again, so I'm going to pull the plug on it. It doesn't make sense for me to spend more time fixing something that sees so little usage at this point. If you are still using CVS, you'll have to switch to git (or volunteer to host the gateway yourself...) Sorry about the inconvenience. -- Alexandre Julliard julliard(a)winehq.org

Aug. 20, 2010

Re: The Test Bot seems to be having issues

by Thomas Mullaly

On Fri, Aug 20, 2010 at 4:44 AM, GOUJON Alexandre <ale.goujon(a)gmail.com>wrote: > > It's Grep Geldorp but wine-devel is a good place too. > Thanks, hopefully he notices the thread. > There are some <div> and </div> in your patch. > Anyway, the bot applied your patch successfully and began to run some of > your tests. > Hmm... All my patches (coming through wine-patches) seem to end up with those <div> tags in them, but, they've never caused problems. > Now, the only thing to do is waiting... > At this point I would be surprised if the Test bot started randomly working without any assistance. The job has been in the "running" state for 24+ hours already, without any progress being made. -- Thomas Mullaly thomas.mullaly(a)gmail.com

Aug. 20, 2010

Re: user32/dialog.c: GetNextDlgTabItem returns hwndDlg if it does not contain controls. [try 2]

by Alexandre Julliard

"Mikhail Maroukhine" <mikolg(a)yandex.ru> writes: > GetNextDlgTabItem returns hwndDlg if it does not contain controls and > searching next item. > GetNextDlgTabItem returns the first child if next TABSTOP control not > found. > > And returns 0 in both cases if searching prev item It breaks the tests: ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so propsheet.c && touch propsheet.ok propsheet.c:312: Test failed: Focus should have been set to the Next button. Expected: 12324, Found: 65535 propsheet.c:363: Test failed: Focus should have been set to the Next button. Expected: 12324, Found: 65535 make[1]: *** [propsheet.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

Aug. 20, 2010

Re: [PATCH] gdi32/enhmfdrv: Do not leak a HDC

by Alexandre Julliard

Detlef Riekenberg <wine.dev(a)web.de> writes: > --- > dlls/gdi32/enhmfdrv/init.c | 14 ++++++++------ > 1 files changed, 8 insertions(+), 6 deletions(-) It would be cleaner to move the CreateDCW call where it's needed. -- Alexandre Julliard julliard(a)winehq.org

Aug. 20, 2010

Re: cmd: Improved a FIXME in WCMD_filesize64

by Alexandre Julliard

"Konrad Wartke" <kwartke(a)googlemail.com> writes: > cmd: Improved a FIXME in WCMD_filesize64 by using a better algorithm. It's not much better. Anyway, this should be done by using one of the existing formatting functions, maybe VarFormatNumber. -- Alexandre Julliard julliard(a)winehq.org

Aug. 20, 2010

Re: [PATCH 7/8] msvcp90/tests: Added basic_string<char> tests

by Alexandre Julliard

Piotr Caban <piotr(a)codeweavers.com> writes: > @@ -0,0 +1,30 @@ > +/* > + * Copyright 2010 Piotr Caban for CodeWeavers > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +/* basic_string<char, char_traits<char>, allocator<char>> */ > +#define BUF_SIZE_CHAR 16 > +typedef struct _basic_string_char > +{ > + void *allocator; > + union _data { > + char buf[BUF_SIZE_CHAR]; > + char *ptr; > + } data; > + size_t size; > + size_t res; > +} basic_string_char; Unless there's going to be a ton of definitions in there used by many different files, it's better to put that sort of thing directly in the C file to make it easier to build stand-alone. -- Alexandre Julliard julliard(a)winehq.org

Aug. 20, 2010

Re: The Test Bot seems to be having issues

by GOUJON Alexandre

On 08/19/2010 07:56 PM, Thomas Mullaly wrote: > First off, I'm not sure who should be contacted about this It's Grep Geldorp but wine-devel is a good place too. > , but, it appears that the test bot has got itself stuck while trying > to run tests on a patch submitted last night. The job in question is > here [1], it's been over 12 hours since any progress has been made on > it and no other submissions have run since then. Also, the Windows > 98SE has been "reverting" this whole time, so I'm not sure if this is > the culprit or not. There are some <div> and </div> in your patch. Anyway, the bot applied your patch successfully and began to run some of your tests. Now, the only thing to do is waiting...

Aug. 20, 2010

Re: gdi32: Properly set ERROR_NOACCESS when GetObject receives invalid arguments

by Jerome Leclanche

That's what I was going for originally, but AJ on IRC deemed it not necessary. J. Leclanche On Fri, Aug 20, 2010 at 12:27 AM, Octavian Voicu <octavian.voicu(a)gmail.com> wrote: > On Thu, Aug 19, 2010 at 4:56 PM, Jerome Leclanche <adys.wh(a)gmail.com> wrote: >> Broken programs will crash on wine if they, for example, pass >> arguments to GetObject in the wrong order. >> This fixes bug #18864. > >> + if (buffer && ((ULONG_PTR)buffer >> 16) == 0) > > Wouldn't a __TRY ... __EXCEPT_PAGE_FAULT be better / safer? > > Octavian > > >

Aug. 19, 2010

Re: gdi32: Properly set ERROR_NOACCESS when GetObject receives invalid arguments

by Octavian Voicu

On Thu, Aug 19, 2010 at 4:56 PM, Jerome Leclanche <adys.wh(a)gmail.com> wrote: > Broken programs will crash on wine if they, for example, pass > arguments to GetObject in the wrong order. > This fixes bug #18864. > + if (buffer && ((ULONG_PTR)buffer >> 16) == 0) Wouldn't a __TRY ... __EXCEPT_PAGE_FAULT be better / safer? Octavian

Aug. 19, 2010

Re: PDB files generated by Intel C++ Compiler

by Eric Pouech

Le 19/08/2010 19:36, Peter Urbanec a écrit : > > I have some x64 binaries and associated PDBs that have been generated > using Intel C++ Compiler 11.1. These PDBs cause issues such as this: > > 1 0x00000000781cc1ba in msvcr80 (+0x9c1b9) (0x00007ff047a4c840) > fixme:dbghelp_msc:codeview_fetch_type Cannot locate type 670 > err:dbghelp_msc:pe_load_debug_directory Got a page fault while loading > symbols > 2 0x000000006189a00d in lua5.1 (+0xa00c) (0x00007ff047a4c840) > > > Now, from a quick look at mscvpdb.h, it looks like these PDBs contain > datatypes with 64-bit near pointers, however wine does not seem to > understand this mode. How would one go about adding support for this > type of PDB? I actually don't have access to the Intel C++ Compiler to > do much testing. :-( > > > > > if the near 64bit pointer, is a 64bit pointer, that's trivial, just add the needed types to dlls/dbghelp/msc.c and include/dbghelp.h with things like: cv_basic_types[T_64PVOID] = cv_basic_types[T_PVOID]; .... if it's something else, then that's another issue... A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

Aug. 19, 2010

The Test Bot seems to be having issues

by Thomas Mullaly

Hi all, First off, I'm not sure who should be contacted about this, but, it appears that the test bot has got itself stuck while trying to run tests on a patch submitted last night. The job in question is here [1], it's been over 12 hours since any progress has been made on it and no other submissions have run since then. Also, the Windows 98SE has been "reverting" this whole time, so I'm not sure if this is the culprit or not. I also hate to admit that the job in question is from one of my patches I sent in last night (although I'm pretty sure it doesn't have anything to do with the quality of the code in the patch ;-) ). Anyways, I'm hoping that somebody in charge of the test bot might be able to fix the traffic jam it's causing. [1] https://testbot.winehq.org/JobDetails.pl?Key=4570 <https://testbot.winehq.org/JobDetails.pl?Key=4570> -- Thomas Mullaly thomas.mullaly(a)gmail.com

Aug. 19, 2010

PDB files generated by Intel C++ Compiler

by Peter Urbanec

I have some x64 binaries and associated PDBs that have been generated using Intel C++ Compiler 11.1. These PDBs cause issues such as this: 1 0x00000000781cc1ba in msvcr80 (+0x9c1b9) (0x00007ff047a4c840) fixme:dbghelp_msc:codeview_fetch_type Cannot locate type 670 err:dbghelp_msc:pe_load_debug_directory Got a page fault while loading symbols 2 0x000000006189a00d in lua5.1 (+0xa00c) (0x00007ff047a4c840) Now, from a quick look at mscvpdb.h, it looks like these PDBs contain datatypes with 64-bit near pointers, however wine does not seem to understand this mode. How would one go about adding support for this type of PDB? I actually don't have access to the Intel C++ Compiler to do much testing. :-(

Aug. 19, 2010

Re: winepath bug without arguments?

by Austin English

On Mon, Aug 9, 2010 at 5:41 AM, Paul Chitescu <paulc(a)voip.null.ro> wrote: > On Monday 09 August 2010 01:23:24 pm Jerome Leclanche wrote: >> Hi >> >> After fixing a bug in MPQEdit related to opening directories, I >> noticed winepath returns a different result with and without quotes: >> >> adys(a)azura:~/.wine/drive_c$ winepath -w >> adys(a)azura:~/.wine/drive_c$ winepath -w "" >> C:\ >> >> With quotes it returns the current directory. Is that intended? If not >> I'll open a bug... >> >> >> >> J. Leclanche > > Yes, it's intended. winepath converts zero or more arguments. An empty > argument means "start from current dir... and print!" > > [paulc(a)bussard drive_c]$ winepath -w "" users "Program Files" > C:\ > C:\users > C:\Program Files Then it seems there's still a bug: austin(a)midna:~$ winepath -w ; echo $? 0 either a path should be returned or a non-zero status... -- -Austin

Aug. 19, 2010

Re: [01/11] d3dx10: Add stub for d3dx10_43

by Owen Rudge

> At least with all d3dx10 DLLs released so far, D3D10_SDK_VERSION has not > changed. Obviously, if it does change in the future, we will need to > accommodate that in new DLLs. Although I suppose we could hard-code the SDK version into the DLLs now, rather than having to change it later, which I guess is what you were getting at, Henri. I'm not too convinced Microsoft is likely to change it during the D3D10 lifecycle, but I guess it doesn't hurt to be safe. Cheers, -- Owen Rudge http://www.owenrudge.net/

Aug. 19, 2010

Re: [01/11] d3dx10: Add stub for d3dx10_43

by Owen Rudge

> Is it really safe to assume D3D10_SDK_VERSION will always keep the > same value? (I know d3dx9 does it as well.) For d3d9 the SDK version > changed between d3d9b and d3d9c, for example. At least with all d3dx10 DLLs released so far, D3D10_SDK_VERSION has not changed. Obviously, if it does change in the future, we will need to accommodate that in new DLLs. -- Owen Rudge http://www.owenrudge.net/

Aug. 19, 2010

Re: [PATCH 3/5] ddraw/tests: New CreateSurface for 3D DDSCAPS_BACKBUFFER tests. (try 5, resend)

by Stefan Dösinger

Hi, Can you try to create a d3d device with this surface? In the first d3d version this works by querying the d3d device ID from the surface. Patch 4 looks OK. Thank you for your persistence with the patches by the way! Cheers, Stefan Am 18.08.2010 um 22:01 schrieb Oldřich Jedlička: > --- > dlls/ddraw/tests/d3d.c | 82 ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 82 insertions(+), 0 deletions(-) > > diff --git a/dlls/ddraw/tests/d3d.c b/dlls/ddraw/tests/d3d.c > index 53ef04b..a83b0d5 100644 > --- a/dlls/ddraw/tests/d3d.c > +++ b/dlls/ddraw/tests/d3d.c > @@ -3536,6 +3536,87 @@ static void FindDevice(void) > "Expected IDirect3D1::FindDevice to return D3D_OK, got 0x%08x\n", hr); > } > > +static void BackBuffer3DCreateSurfaceTest(void) > +{ > + DDSURFACEDESC ddsd; > + DDSURFACEDESC created_ddsd; > + DDSURFACEDESC2 ddsd2; > + IDirectDrawSurface *surf; > + IDirectDrawSurface4 *surf4; > + IDirectDrawSurface7 *surf7; > + HRESULT hr; > + IDirectDraw2 *dd2; > + IDirectDraw4 *dd4; > + IDirectDraw7 *dd7; > + DDCAPS ddcaps; > + > + const DWORD caps = DDSCAPS_BACKBUFFER | DDSCAPS_3DDEVICE; > + const DWORD expected_caps = DDSCAPS_BACKBUFFER | DDSCAPS_3DDEVICE | DDSCAPS_VIDEOMEMORY | DDSCAPS_LOCALVIDMEM; > + > + memset(&ddcaps, 0, sizeof(ddcaps)); > + ddcaps.dwSize = sizeof(DDCAPS); > + hr = IDirectDraw_GetCaps(DirectDraw1, &ddcaps, NULL); > + if (!(ddcaps.ddsCaps.dwCaps & DDSCAPS_VIDEOMEMORY)) > + { > + skip("DDraw reported no VIDEOMEMORY cap. Broken video driver? Skipping surface caps tests.\n"); > + return ; > + } > + > + memset(&ddsd, 0, sizeof(ddsd)); > + ddsd.dwSize = sizeof(ddsd); > + ddsd.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT; > + ddsd.dwWidth = 64; > + ddsd.dwHeight = 64; > + ddsd.ddsCaps.dwCaps = caps; > + memset(&ddsd2, 0, sizeof(ddsd2)); > + ddsd2.dwSize = sizeof(ddsd2); > + ddsd2.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT; > + ddsd2.dwWidth = 64; > + ddsd2.dwHeight = 64; > + ddsd2.ddsCaps.dwCaps = caps; > + memset(&created_ddsd, 0, sizeof(created_ddsd)); > + created_ddsd.dwSize = sizeof(DDSURFACEDESC); > + > + hr = IDirectDraw_CreateSurface(DirectDraw1, &ddsd, &surf, NULL); > + todo_wine ok(SUCCEEDED(hr), "IDirectDraw_CreateSurface failed: 0x%08x\n", hr); > + if (surf != NULL) > + { > + hr = IDirectDrawSurface_GetSurfaceDesc(surf, &created_ddsd); > + ok(SUCCEEDED(hr), "IDirectDraw_GetSurfaceDesc failed: 0x%08x\n", hr); > + todo_wine ok(created_ddsd.ddsCaps.dwCaps == expected_caps, > + "GetSurfaceDesc returned caps %x, expected %x\n", created_ddsd.ddsCaps.dwCaps, > + expected_caps); > + IDirectDrawSurface_Release(surf); > + } > + > + hr = IDirectDraw_QueryInterface(DirectDraw1, &IID_IDirectDraw2, (void **) &dd2); > + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: 0x%08x\n", hr); > + > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd, &surf, NULL); > + ok(hr == DDERR_INVALIDCAPS, "IDirectDraw2_CreateSurface didn't return %x08x, but %x08x\n", > + DDERR_INVALIDCAPS, hr); > + > + IDirectDraw2_Release(dd2); > + > + hr = IDirectDraw_QueryInterface(DirectDraw1, &IID_IDirectDraw4, (void **) &dd4); > + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: 0x%08x\n", hr); > + > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2, &surf4, NULL); > + ok(hr == DDERR_INVALIDCAPS, "IDirectDraw4_CreateSurface didn't return %x08x, but %x08x\n", > + DDERR_INVALIDCAPS, hr); > + > + IDirectDraw4_Release(dd4); > + > + hr = IDirectDraw_QueryInterface(DirectDraw1, &IID_IDirectDraw7, (void **) &dd7); > + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: 0x%08x\n", hr); > + > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2, &surf7, NULL); > + ok(hr == DDERR_INVALIDCAPS, "IDirectDraw7_CreateSurface didn't return %x08x, but %x08x\n", > + DDERR_INVALIDCAPS, hr); > + > + IDirectDraw7_Release(dd7); > +} > + > START_TEST(d3d) > { > init_function_pointers(); > @@ -3571,6 +3652,7 @@ START_TEST(d3d) > TextureLoadTest(); > ViewportTest(); > FindDevice(); > + BackBuffer3DCreateSurfaceTest(); > D3D1_releaseObjects(); > } > > -- > 1.7.2 > > >

Aug. 19, 2010

Re: user32/dialog.c: GetNextDlgTabItem returns hwndDlg if it does not contain controls.

by Alexandre Julliard

"Mikhail Maroukhine" <mikolg(a)yandex.ru> writes: > @@ -1695,7 +1696,19 @@ HWND WINAPI GetNextDlgTabItem( HWND hwndDlg, HWND hwndCtrl, > */ > if (!hwndCtrl && fPrevious) return 0; > > - return DIALOG_GetNextTabItem(hwndDlg,hwndDlg,hwndCtrl,fPrevious); > + nextItem = DIALOG_GetNextTabItem(hwndDlg,hwndDlg,hwndCtrl,fPrevious); > + > + /* if next tab item not found return the first child even if it does not have TABSTOP > + Checked on XP > + */ > + if (!nextItem && !fPrevious) nextItem = GetWindow(hwndDlg,GW_CHILD); > + > + /* if there is no controls on hwndDlg return hwndDlg > + Checked on XP > + */ > + if (!nextItem && !fPrevious) nextItem = hwndDlg; > + > + return nextItem; You should test the fPrevious case too, it's probably similar. -- Alexandre Julliard julliard(a)winehq.org

Aug. 19, 2010

Re: oleau32: Use correct sysking in QueryPathOfRegTypeLib.

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/oleaut32/typelib.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) It breaks the 64-bit tests: ../../../../wine/tools/runtest -q -P wine -M oleaut32.dll -T ../../.. -p oleaut32_test.exe.so ../../../../wine/dlls/oleaut32/tests/typelib.c && touch typelib.ok typelib.c:784: Test failed: QueryPathOfRegTypeLib(3.0) returned 8002801d typelib.c:784: Test failed: QueryPathOfRegTypeLib(3.1) returned 8002801d typelib.c:784: Test failed: QueryPathOfRegTypeLib(3.22) returned 8002801d typelib.c:784: Test failed: QueryPathOfRegTypeLib(3.37) returned 8002801d typelib.c:784: Test failed: QueryPathOfRegTypeLib(3.40) returned 8002801d typelib.c:784: Test failed: QueryPathOfRegTypeLib(65535.65535) returned 8002801d make: *** [typelib.ok] Error 6 -- Alexandre Julliard julliard(a)winehq.org

Aug. 19, 2010

Re: [PATCH 2/5] ddraw/tests: New visual back buffer flipping tests. (try 5, resend)

by Stefan Dösinger

This test contains a C++ comment, please remove it. Otherwise it looks ok, as does patch 1 Am 18.08.2010 um 22:01 schrieb Oldřich Jedlička: > --- > dlls/ddraw/tests/visual.c | 123 +++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 123 insertions(+), 0 deletions(-) > > diff --git a/dlls/ddraw/tests/visual.c b/dlls/ddraw/tests/visual.c > index 290cb76..aecc2ab 100644 > --- a/dlls/ddraw/tests/visual.c > +++ b/dlls/ddraw/tests/visual.c > @@ -2920,6 +2920,128 @@ static void depth_clamp_test(IDirect3DDevice7 *device) > ok(SUCCEEDED(hr), "SetViewport failed, hr %#x.\n", hr); > } > > +static void DX1_BackBufferFlipTest(void) > +{ > + HRESULT hr; > + int ret; > + IDirectDraw *DirectDraw1 = NULL; > + IDirectDrawSurface *Primary = NULL; > + IDirectDrawSurface *Backbuffer = NULL; > + WNDCLASS wc = {0}; > + DDSURFACEDESC ddsd; > + DDBLTFX ddbltfx; > + COLORREF color; > + const DWORD white = 0xffffff; > + const DWORD red = 0xff0000; > + BOOL attached = FALSE; > + > + wc.lpfnWndProc = DefWindowProc; > + wc.lpszClassName = "DX1_BackBufferFlipTest_wc"; > + RegisterClass(&wc); > + window = CreateWindow("DX1_BackBufferFlipTest_wc", "DX1_BackBufferFlipTest", > + WS_MAXIMIZE | WS_VISIBLE | WS_CAPTION , 0, 0, 640, 480, 0, 0, 0, 0); > + > + hr = DirectDrawCreate( NULL, &DirectDraw1, NULL ); > + ok(hr==DD_OK || hr==DDERR_NODIRECTDRAWSUPPORT, "DirectDrawCreate returned: %x\n", hr); > + if(FAILED(hr)) goto out; > + > + hr = IDirectDraw_SetCooperativeLevel(DirectDraw1, window, DDSCL_EXCLUSIVE | DDSCL_FULLSCREEN); > + ok(hr==DD_OK, "SetCooperativeLevel returned: %x\n", hr); > + if(FAILED(hr)) goto out; > + > + hr = IDirectDraw_SetDisplayMode(DirectDraw1, 640, 480, 32); > + if(FAILED(hr)) { > + /* 24 bit is fine too */ > + hr = IDirectDraw_SetDisplayMode(DirectDraw1, 640, 480, 24); > + } > + ok(hr==DD_OK || hr == DDERR_UNSUPPORTED, "SetDisplayMode returned: %x\n", hr); > + if (FAILED(hr)) { > + goto out; > + } > + > + memset(&ddsd, 0, sizeof(DDSURFACEDESC)); > + ddsd.dwSize = sizeof(DDSURFACEDESC); > + ddsd.dwFlags = DDSD_CAPS; > + ddsd.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE; > + > + hr = IDirectDraw_CreateSurface(DirectDraw1, &ddsd, &Primary, NULL); > + ok(hr==DD_OK, "IDirectDraw_CreateSurface returned: %08x\n", hr); > + > + memset(&ddsd, 0, sizeof(DDSURFACEDESC)); > + ddsd.dwSize = sizeof(DDSURFACEDESC); > + ddsd.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT | DDSD_PIXELFORMAT; > + ddsd.ddsCaps.dwCaps = DDSCAPS_BACKBUFFER; > + ddsd.dwWidth = 640; > + ddsd.dwHeight = 480; > + ddsd.ddpfPixelFormat.dwSize = sizeof(ddsd.ddpfPixelFormat); > + ddsd.ddpfPixelFormat.dwFlags = DDPF_RGB; > + U1(ddsd.ddpfPixelFormat).dwRGBBitCount = 32; > + U2(ddsd.ddpfPixelFormat).dwRBitMask = 0x00ff0000; > + U3(ddsd.ddpfPixelFormat).dwGBitMask = 0x0000ff00; > + U4(ddsd.ddpfPixelFormat).dwBBitMask = 0x000000ff; > + > + hr = IDirectDraw_CreateSurface(DirectDraw1, &ddsd, &Backbuffer, NULL); > + todo_wine ok(hr==DD_OK, "IDirectDraw_CreateSurface returned: %08x\n", hr); > + if(FAILED(hr)) goto out; > + > + hr = IDirectDrawSurface_AddAttachedSurface(Primary, Backbuffer); > + todo_wine ok(hr == DD_OK || broken(hr == DDERR_CANNOTATTACHSURFACE), > + "Attaching a back buffer to a front buffer returned %08x\n", hr); > + if (FAILED(hr)) goto out; > + > + attached = TRUE; > + > + memset(&ddbltfx, 0, sizeof(ddbltfx)); > + ddbltfx.dwSize = sizeof(ddbltfx); > + U5(ddbltfx).dwFillColor = red; > + hr = IDirectDrawSurface_Blt(Backbuffer, NULL, NULL, NULL, DDBLT_COLORFILL | DDBLT_WAIT, &ddbltfx); > + ok(hr == DD_OK, "IDirectDrawSurface_Blt returned: %x\n", hr); > + > + U5(ddbltfx).dwFillColor = white; > + hr = IDirectDrawSurface_Blt(Primary, NULL, NULL, NULL, DDBLT_COLORFILL | DDBLT_WAIT, &ddbltfx); > + ok(hr == DD_OK, "IDirectDrawSurface_Blt returned: %x\n", hr); > + > + // Check it out > + color = getPixelColor_GDI(Primary, 5, 5); > + ok(GetRValue(color) == 0xFF && GetGValue(color) == 0xFF && GetBValue(color) == 0xFF, > + "got R %02X G %02X B %02X, expected R FF G FF B FF\n", > + GetRValue(color), GetGValue(color), GetBValue(color)); > + > + color = getPixelColor_GDI(Backbuffer, 5, 5); > + ok(GetRValue(color) == 0xFF && GetGValue(color) == 0 && GetBValue(color) == 0, > + "got R %02X G %02X B %02X, expected R FF G 00 B 00\n", > + GetRValue(color), GetGValue(color), GetBValue(color)); > + > + hr = IDirectDrawSurface_Flip(Primary, NULL, DDFLIP_WAIT); > + todo_wine ok(hr == DD_OK, "IDirectDrawSurface_Flip returned 0x%08x\n", hr); > + > + if (hr == DD_OK) > + { > + color = getPixelColor_GDI(Primary, 5, 5); > + ok(GetRValue(color) == 0xFF && GetGValue(color) == 0 && GetBValue(color) == 0, > + "got R %02X G %02X B %02X, expected R FF G 00 B 00\n", > + GetRValue(color), GetGValue(color), GetBValue(color)); > + > + color = getPixelColor_GDI(Backbuffer, 5, 5); > + ok((GetRValue(color) == 0xFF && GetGValue(color) == 0xFF && GetBValue(color) == 0xFF) || > + broken(GetRValue(color) == 0xFF && GetGValue(color) == 0 && GetBValue(color) == 0), // broken driver > + "got R %02X G %02X B %02X, expected R FF G FF B FF\n", > + GetRValue(color), GetGValue(color), GetBValue(color)); > + } > + > + out: > + > + if (Backbuffer) > + { > + if (attached) > + IDirectDrawSurface_DeleteAttachedSurface(Primary, 0, Backbuffer); > + IDirectDrawSurface_Release(Backbuffer); > + } > + if (Primary) IDirectDrawSurface_Release(Primary); > + if (DirectDraw1) IDirectDraw_Release(DirectDraw1); > + if (window) DestroyWindow(window); > +} > + > START_TEST(visual) > { > HRESULT hr; > @@ -2983,6 +3105,7 @@ START_TEST(visual) > > D3D3_ViewportClearTest(); > p8_primary_test(); > + DX1_BackBufferFlipTest(); > > return ; > > -- > 1.7.2 > > >

Aug. 19, 2010

Re: [PATCH 5/5] ddraw: Allow creating back buffer for DirectX 1 interfaces. (try 5, resend)

by Stefan Dösinger

Am 18.08.2010 um 22:01 schrieb Oldřich Jedlička: > + if(DDSD->ddsCaps.dwCaps & DDSCAPS_FRONTBUFFER) { > + WARN("Application tried to create an explicit front buffer\n"); > LeaveCriticalSection(&ddraw_cs); > return DDERR_INVALIDCAPS; > } This test seems redundant now. The ddraw1 thunk removes the flag, and all other thunks check for the frontbuffer flag on their own.

Aug. 19, 2010

Re: [01/11] d3dx10: Add stub for d3dx10_43

by Henri Verbeet

On 18 August 2010 23:01, Owen Rudge <orudge(a)codeweavers.com> wrote: > +BOOL WINAPI D3DX10CheckVersion(UINT d3dsdkvers, UINT d3dxsdkvers) > +{ > + if ((d3dsdkvers == D3D10_SDK_VERSION) && (d3dxsdkvers == 43)) > + return TRUE; > + > + return FALSE; > +} Is it really safe to assume D3D10_SDK_VERSION will always keep the same value? (I know d3dx9 does it as well.) For d3d9 the SDK version changed between d3d9b and d3d9c, for example.

Aug. 19, 2010

Re: have all MCI tests in winmm/tests/ or distributed across mci*/tests/?

by Alexandre Julliard

<Joerg-Cyril.Hoehle(a)t-systems.com> writes: > although my patch creates mcicda/tests/ > I'd like to query whether it would make more > sense to have all mci tests grouped in winmm/tests/. That's probably better, yes. -- Alexandre Julliard julliard(a)winehq.org

Aug. 19, 2010

Re: [1/2] user32: add a way to poll for messages on extra handles

by Alexandre Julliard

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > diff --git a/dlls/user32/driver.c b/dlls/user32/driver.c > index f2f9892..05c83d4 100644 > --- a/dlls/user32/driver.c > +++ b/dlls/user32/driver.c > @@ -126,6 +126,7 @@ static const USER_DRIVER *load_driver(void) > GET_USER_FUNC(WindowMessage); > GET_USER_FUNC(WindowPosChanging); > GET_USER_FUNC(WindowPosChanged); > + GET_USER_FUNC(GetExtraMessageHandles); That's ugly, it doesn't correspond to anything in the Windows API. -- Alexandre Julliard julliard(a)winehq.org

Aug. 19, 2010

Re: [PATCH 2/2] ntdll/tests: Add tests for RtlIpv4AddressToString / RtlIpv4AddressToStringEx [try 4]

by Alexandre Julliard

Detlef Riekenberg <wine.dev(a)web.de> writes: > + ok( (res == (void *)~0) || > + broken(res == (NULL + len)), /* XP and w2003 */ You can't do that. -- Alexandre Julliard julliard(a)winehq.org

Aug. 19, 2010

Re: msvideo: Forward MCIWndCreate16 to MCIWndCreateA (2nd)

by Alexandre Julliard

Stefan Leichter <Stefan.Leichter(a)camline.com> writes: > + HINSTANCE hinst32; > + if (hinst16 == GetModuleHandle16("msvideo.dll")) > + hinst32 = GetModuleHandleA("msvfw32.dll"); > + else > + hinst32 = HINSTANCE_32(GetExePtr( hinst16 )); This doesn't seem right. Why do you need this? -- Alexandre Julliard julliard(a)winehq.org

Aug. 19, 2010

Re: [PATCH] comctl32/tests: DateTimePicker and MonthCalendar controls only support Gregorian calendar.

by Austin Lund

On 19 August 2010 16:34, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > On Thu, Aug 19, 2010 at 9:50 AM, Austin Lund <austin.lund(a)gmail.com> wrote: >> http://www.microsoft.com/middleeast/msdn/ArabicCalendar.aspx > > Hi, Austin. > > This information is outdated probably. There's a message to set a > calendar for MonthCal at least, see: > > http://msdn.microsoft.com/en-us/library/bb760995%28VS.85%29.aspx > > Not sure about DateTimePicker, it uses Monthcal internally so a > calendar could still be switched. > Anyway this won't work on pre-Vista and without a manifest for v6, but > you could enable tests using V6 loading > helpers that we have already and MCM_SETCALID message, so tests will > run on Arabic or some Asian boxes. > I don't understand what you are suggesting exactly. Is it that the CALID of the MonthCal be set to the locale CALID or to set it to the Gregorian CALID? Either way I don't see how it helps as the problem is with the control of functions like GetDateFormat to choose a CALID which matches the one which the controls falls back on when the locale has a non-Gregorian calendar (something I haven't figured out).

Aug. 19, 2010

Re: [PATCH] comctl32/tests: DateTimePicker and MonthCalendar controls only support Gregorian calendar.

by Nikolay Sivov

On Thu, Aug 19, 2010 at 9:50 AM, Austin Lund <austin.lund(a)gmail.com> wrote: > http://www.microsoft.com/middleeast/msdn/ArabicCalendar.aspx Hi, Austin. This information is outdated probably. There's a message to set a calendar for MonthCal at least, see: http://msdn.microsoft.com/en-us/library/bb760995%28VS.85%29.aspx Not sure about DateTimePicker, it uses Monthcal internally so a calendar could still be switched. Anyway this won't work on pre-Vista and without a manifest for v6, but you could enable tests using V6 loading helpers that we have already and MCM_SETCALID message, so tests will run on Arabic or some Asian boxes.

Aug. 19, 2010

Re: [PATCH 5/5] ddraw: Allow creating back buffer for DirectX 1 interfaces. (try 5, resend)

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4557 Your paranoid android. === W2KPROSP4 (32 bit visual) === visual.c:1619: Test failed: Got color 000a246a, expected 00ff0040 or near visual.c:1625: Test failed: Got color 006b8bbd, expected 00ff0080 or near === W98SE (32 bit dsurface) === No test summary line found

Aug. 19, 2010

Re: [PATCH 1/5] ddraw/tests: Add test for bad size of surface caps in CreateSurface. (try 5, resend)

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4553 Your paranoid android. === W98SE (32 bit dsurface) === No test summary line found

Aug. 19, 2010

Re: [PATCH 2/2] gameux/tests: verifying registry values created by GameExplorer (try 2)

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4552 Your paranoid android. === W98SE (32 bit gameexplorer) === Failure running script in VM: Exceeded timeout limit of 315 sec === W2KPROSP4 (32 bit gameexplorer) === Timeout === WXPPROSP3 (32 bit gameexplorer) === Timeout

Aug. 19, 2010

Re: ntdll: IMAGE_REL_BASED_HIGH, IMAGE_REL_BASED_HIGH and IMAGE_REL_BASED_HIGHLOW are supported on win64.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4548 Your paranoid android. === W98SE (32 bit rtl) === Failure running script in VM: Exceeded timeout limit of 315 sec

Aug. 19, 2010

Re: dlls/d3dx9_36/bytecodewriter.c oddity

by Matteo Bruni

2010/8/18 Gerald Pfeifer <gerald(a)pfeifer.com>: > Metteo et al, > > I noticed d3dx9_36/bytecodewriter.c can be simplified as follows, but > somewhat tells me this may rather point out a problem somewhere in that > code, so I am not sending this to wine-patches. > > (The only functional difference should be the missing WARN in some cases, > and I could restore that if desired, but...see above.) > > Thoughts? Guidance? > > Gerald > > > diff --git a/dlls/d3dx9_36/bytecodewriter.c > b/dlls/d3dx9_36/bytecodewriter.c > index 07f96e7..e7bd8a5 100644 > --- a/dlls/d3dx9_36/bytecodewriter.c > +++ b/dlls/d3dx9_36/bytecodewriter.c > @@ -1035,7 +1035,7 @@ static const struct bytecode_backend vs_1_x_backend = { > static void instr_ps_1_0123_texld(struct bc_writer *This, > const struct instruction *instr, > struct bytecode_buffer *buffer) { > - DWORD idx, srcidx; > + DWORD idx; > struct shader_reg reg; > DWORD swizzlemask; > > @@ -1074,17 +1074,6 @@ static void instr_ps_1_0123_texld(struct bc_writer *This, > /* map the temp dstreg to the ps_1_3 texture temporary register */ > This->funcs->dstreg(This, &instr->dst, buffer, instr->shift, instr->dstmod); > } else if(instr->src[0].type == BWRITERSPR_TEMP) { > - if(instr->src[0].regnum == T0_REG) { > - srcidx = 0; > - } else if(instr->src[0].regnum == T1_REG) { > - srcidx = 1; > - } else if(instr->src[0].regnum == T2_REG) { > - srcidx = 2; > - } else if(instr->src[0].regnum == T3_REG) { > - srcidx = 3; > - } else { > - WARN("Invalid address data source register r%u\n", instr->src[0].regnum); > - } > > swizzlemask = (3 << BWRITERVS_SWIZZLE_SHIFT) | > (3 << (BWRITERVS_SWIZZLE_SHIFT + 2)) | > Hmm, so srcidx is unused. Yes, that piece of code is useless now, it's a remnant of an older version of that function where the source register was handled by some ad-hoc code, which I since then replaced with a call to the generic This->funcs->srcreg(). The function is correct otherwise, there are some tests to confirm that. In my opinion you can send the patch as is. Alternatively you can replace that piece of code with just a check for instr->src[0].regnum != T[0123]_REG, to keep the WARN, but it's not worth the effort probably. Thanks!

Aug. 18, 2010

dlls/d3dx9_36/bytecodewriter.c oddity

by Gerald Pfeifer

Metteo et al, I noticed d3dx9_36/bytecodewriter.c can be simplified as follows, but somewhat tells me this may rather point out a problem somewhere in that code, so I am not sending this to wine-patches. (The only functional difference should be the missing WARN in some cases, and I could restore that if desired, but...see above.) Thoughts? Guidance? Gerald diff --git a/dlls/d3dx9_36/bytecodewriter.c b/dlls/d3dx9_36/bytecodewriter.c index 07f96e7..e7bd8a5 100644 --- a/dlls/d3dx9_36/bytecodewriter.c +++ b/dlls/d3dx9_36/bytecodewriter.c @@ -1035,7 +1035,7 @@ static const struct bytecode_backend vs_1_x_backend = { static void instr_ps_1_0123_texld(struct bc_writer *This, const struct instruction *instr, struct bytecode_buffer *buffer) { - DWORD idx, srcidx; + DWORD idx; struct shader_reg reg; DWORD swizzlemask; @@ -1074,17 +1074,6 @@ static void instr_ps_1_0123_texld(struct bc_writer *This, /* map the temp dstreg to the ps_1_3 texture temporary register */ This->funcs->dstreg(This, &instr->dst, buffer, instr->shift, instr->dstmod); } else if(instr->src[0].type == BWRITERSPR_TEMP) { - if(instr->src[0].regnum == T0_REG) { - srcidx = 0; - } else if(instr->src[0].regnum == T1_REG) { - srcidx = 1; - } else if(instr->src[0].regnum == T2_REG) { - srcidx = 2; - } else if(instr->src[0].regnum == T3_REG) { - srcidx = 3; - } else { - WARN("Invalid address data source register r%u\n", instr->src[0].regnum); - } swizzlemask = (3 << BWRITERVS_SWIZZLE_SHIFT) | (3 << (BWRITERVS_SWIZZLE_SHIFT + 2)) |

Aug. 18, 2010

Re: [PATCH 1/3] gameux: Add definitions of resource identifiers to header file

by Mariusz Pluciński

W dniu 18.08.2010 19:34, GOUJON Alexandre pisze: > On 08/18/2010 07:06 PM, Mariusz Pluciński wrote: >> Can I do it by passing __LINE__ macro as parameter to my _validate* >> functions? > > Some tests already use __LINE__ as a parameter. > See > http://source.winehq.org/git/wine.git/?a=blob;f=dlls/advapi32/tests/cred.c#… > > and > http://source.winehq.org/git/wine.git/?a=blob;f=dlls/advapi32/tests/cred.c#… > > for instance. > Thanks for these examples. I though about little different solution, but this looks really easier than my ideas.

Aug. 18, 2010

Re: [PATCH 1/3] gameux: Add definitions of resource identifiers to header file

by GOUJON Alexandre

On 08/18/2010 07:06 PM, Mariusz Pluciński wrote: > Can I do it by passing __LINE__ macro as parameter to my _validate* > functions? Some tests already use __LINE__ as a parameter. See http://source.winehq.org/git/wine.git/?a=blob;f=dlls/advapi32/tests/cred.c#… and http://source.winehq.org/git/wine.git/?a=blob;f=dlls/advapi32/tests/cred.c#… for instance.

Aug. 18, 2010

Re: [PATCH 1/3] gameux: Add definitions of resource identifiers to header file

by Mariusz Pluciński

W dniu 18.08.2010 18:09, Vincent Povirk pisze: > I think it would be helpful if you passed a string description to your > _validate functions so that in case of failure, you can tell where the > original call to _validateGameRegistryKey was, instead of just the > line containing the ok() call. Can I do it by passing __LINE__ macro as parameter to my _validate* functions?

Aug. 18, 2010

Re: [PATCH 3/3] gameux/tests: verifying registry values created by GameExplorer

by Mariusz Pluciński

W dniu 18.08.2010 18:28, Andrew Eikum pisze: >> This result is strange, cause routine modified by this patch (called >> test_add_remove_game ) is not even called on these operating systems - >> and test added by my previous patch demonstrates it (and it succeeded). >> Did I something wrong? I cannot imagine how it could fail when previous >> test was succeeded. > > You can see the error message dialog in the screenshots on the testbot > result webpage. In this case, you've got missing exports, > ConvertSidToSidStringW and RegGetValueW. Some solutions are to make > those into function pointers (and skip appropriately if they're > missing), use the A versions if they exist, or use a different function > that exists on more platforms. > > Andrew > I understand. Thank you very much for the explanation. I did not know, that new code can interfere in any way on systems where it is never called. W dniu 18.08.2010 18:33, Vincent Povirk pisze: > Oh. > > Personally, I would ignore failures on operating systems< Vista, > since gameux won't be present and the tests would not normally be run. > OK, I'll see if my patch is accepted despite of these results. If not, I'll modify it, to make it calling these routines through pointers.

Aug. 18, 2010

Re: [PATCH 3/3] gameux/tests: verifying registry values created by GameExplorer

by Vincent Povirk

> You can see the error message dialog in the screenshots on the testbot > result webpage. In this case, you've got missing exports, > ConvertSidToSidStringW and RegGetValueW. Some solutions are to make those > into function pointers (and skip appropriately if they're missing), use the > A versions if they exist, or use a different function that exists on more > platforms. Oh. Personally, I would ignore failures on operating systems < Vista, since gameux won't be present and the tests would not normally be run.

Aug. 18, 2010

Re: [PATCH 3/3] gameux/tests: verifying registry values created by GameExplorer

by Andrew Eikum

> This result is strange, cause routine modified by this patch (called > test_add_remove_game ) is not even called on these operating systems - > and test added by my previous patch demonstrates it (and it succeeded). > Did I something wrong? I cannot imagine how it could fail when previous > test was succeeded. You can see the error message dialog in the screenshots on the testbot result webpage. In this case, you've got missing exports, ConvertSidToSidStringW and RegGetValueW. Some solutions are to make those into function pointers (and skip appropriately if they're missing), use the A versions if they exist, or use a different function that exists on more platforms. Andrew

Aug. 18, 2010

Re: [PATCH 3/3] gameux/tests: verifying registry values created by GameExplorer

by Vincent Povirk

The testbot gives weird results at times. I wouldn't worry about it. 2010/8/18 Mariusz Pluciński <vshader(a)gmail.com>: > W dniu 18.08.2010 17:49, (Marvin) pisze: >> >> Hi, >> >> While running your changed tests on Windows, I think I found new failures. >> Being a bot and all I'm not very good at pattern recognition, so I might >> be >> wrong, but could you please double-check? >> Full results can be found at >> http://testbot.winehq.org/JobDetails.pl?Key=4540 >> >> Your paranoid android. >> >> >> === W98SE (32 bit gameexplorer) === >> Failure running script in VM: Exceeded timeout limit of 315 sec >> >> === W2KPROSP4 (32 bit gameexplorer) === >> Timeout >> >> === WXPPROSP3 (32 bit gameexplorer) === >> Timeout >> > > This result is strange, cause routine modified by this patch (called > test_add_remove_game ) is not even called on these operating systems - and > test added by my previous patch demonstrates it (and it succeeded). Did I > something wrong? I cannot imagine how it could fail when previous test was > succeeded. > > >

Aug. 18, 2010

Re: [PATCH 3/3] gameux/tests: verifying registry values created by GameExplorer

by Mariusz Pluciński

W dniu 18.08.2010 17:49, (Marvin) pisze: > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > http://testbot.winehq.org/JobDetails.pl?Key=4540 > > Your paranoid android. > > > === W98SE (32 bit gameexplorer) === > Failure running script in VM: Exceeded timeout limit of 315 sec > > === W2KPROSP4 (32 bit gameexplorer) === > Timeout > > === WXPPROSP3 (32 bit gameexplorer) === > Timeout > This result is strange, cause routine modified by this patch (called test_add_remove_game ) is not even called on these operating systems - and test added by my previous patch demonstrates it (and it succeeded). Did I something wrong? I cannot imagine how it could fail when previous test was succeeded.

Aug. 18, 2010

Re: [PATCH 1/3] gameux: Add definitions of resource identifiers to header file

by Vincent Povirk

> @@ -32,7 +33,6 @@ > > #include "wine/test.h" > > - > static void test_create(BOOL* gameExplorerAvailable, BOOL* gameExplorer2Available) > { > HRESULT hr; Don't put formatting changes in functional patches, please. I think it would be helpful if you passed a string description to your _validate functions so that in case of failure, you can tell where the original call to _validateGameRegistryKey was, instead of just the line containing the ok() call.

Aug. 18, 2010

Re: [PATCH 5/6] gameux: Add initial implementation of IGameExplorer2::CheckAccess method

by Mariusz Pluciński

Hello W dniu 16.08.2010 10:00, Mariusz Pluciński pisze: > --- > dlls/gameux/gameexplorer.c | 7 +++++-- > 1 files changed, 5 insertions(+), 2 deletions(-) > > This is patch I sent to wine-patches yesterday. It was marked as "Pending". I know that what I sent is not proper solution. But as I wrote in FIXME, it's in my opinion impossible to implement it properly, cause from what I know Wine does not support parental control. So, instead of doing real check, my function simply always grants access. My question is: what should I do with it? It cannot be left stub, as there's already bug caused by this (bug #23850). And probably every game which uses Game Explorer will behave that same. Should I write test case to demonstrate that native works that same in most cases?

Aug. 18, 2010

Re: [PATCH 1/1] d3dx9: Add tests for FVF <-> declaration conversion.

by Alexandre Julliard

Misha Koshelev <misha680(a)gmail.com> writes: > +#define VDECL_CHECK(fcall) \ > + if(fcall != S_OK) \ > + trace(" Test failed on line #%d\n", __LINE__); > + > +#define VDECL_CHECK_FAIL(fcall) \ > + if(fcall != E_FAIL) \ > + trace(" Test failed on line #%d\n", __LINE__); That's ugly. If the goal is to print the line number, you should pass it to the test function. -- Alexandre Julliard julliard(a)winehq.org

Aug. 18, 2010

Re: [PATCH 3/3] gameux/tests: verifying registry values created by GameExplorer

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4540 Your paranoid android. === W98SE (32 bit gameexplorer) === Failure running script in VM: Exceeded timeout limit of 315 sec === W2KPROSP4 (32 bit gameexplorer) === Timeout === WXPPROSP3 (32 bit gameexplorer) === Timeout

Aug. 18, 2010

Re: [PATCH 1/2] ntdll: Implement RtlIpv4AddressToString / RtlIpv4AddressToStringEx [try 3]

by Alexandre Julliard

Detlef Riekenberg <wine.dev(a)web.de> writes: > + in = *pin; What is this for? -- Alexandre Julliard julliard(a)winehq.org

Aug. 18, 2010

Re: Wine64 debugger

by Peter Urbanec

On 18/08/10 01:51, Marcus Meissner wrote: > On Wed, Aug 18, 2010 at 01:00:35AM +1000, Peter Urbanec wrote: >> I'm seeing crashes in FindNextFileW/FindNextFileA due to what >> looks like a 64 bit HANDLE value being truncated to 32 bits. > > Check if your code uses "int" in its FindNextFile or findfirst things. I had a good look at the wine source code as well as those parts of the application source code that I can get access to and it all looks good as far as correctly using HANDLE type to store HANDLE values. Unfortunately, the application in question also makes use of FLEXlm libraries from Macrovision and these binary blobs appear to be buggy. All the symptoms point to the FLEXlm code storing the 64-bit HANDLE value in a 32-bit int - this is evidenced by sign extension on some of the values. Of course, the initial cause and the issues with the debugger are essentially unrelated. I have sent some sample test binaries to Eric, to reproduce the debugger issue. The buggy Win64 application is another story. It looks like Win64 must most of the time return HANDLE values that fit within 31 bits, because from what I hear, Windows users go through thousands of invocations of this app without seeing any issues. I wonder if there is a way of making wine allocate the memory for the object pointed to by the HANDLE somewhere in the lower part of the address space. That ought to mitigate this particular application bug and bring the compatibility a little closer to what's observed under Win64.

Aug. 18, 2010

have all MCI tests in winmm/tests/ or distributed across mci*/tests/?

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, although my patch creates mcicda/tests/ I'd like to query whether it would make more sense to have all mci tests grouped in winmm/tests/. Pro: + Future fixes to winmm/mci.c would affect winmm/tests/*.c only. E.g. when I'll make "stop all" work I'd have to touch mcicda/tests/mcicda.c as well to eliminate the todo_wine there. Same when I'll patch mciparse to accept [TT:]MM:SS:FF format. + When Maarten will write mciqtz tests, perhaps resources could be reused to execute mciavi tests as well (the file creation code need not be duplicated). Similar tests could be written for: "open foo.avi" (mciavi) and "open foo.avi type mpegvideo" (mciqtz) or "open foo.wav" (micwave) and "open foo.wav type mpegvideo" although there's some difference in behaviour. + The functions test_notification could be in one file only, not repeated. I can rewrite my current mcicda/tests/mcicda.c patch to live in winmm/tests/. What do you think? Jörg Höhle

Aug. 18, 2010

Re: [PATCH] advapi32: Add magic codes to HCRYPTKEY and HCRYPTHASH.

by Austin Lund

On 18 August 2010 20:44, GOUJON Alexandre <ale.goujon(a)gmail.com> wrote: > On 08/18/2010 12:22 PM, Hans Leidekker wrote: >> >> They are often built from four character ascii strings to help find out >> where the structures come from. I don't know why this one was chosen >> but I guess you could use something like 0xA39E741E and 0xA39E741D. >> > > Yep, there are some magic values at http://en.wikipedia.org/wiki/Hexspeak > FYI, MAGIC_CRYPTPROV comes from the following commit > http://source.winehq.org/git/wine.git/?a=commitdiff;h=44cb0906da3dddbca1fe6… > None of that answers the "why" question except perhaps the part about unaligned pointer values which isn't really relevant for modern architectures. I'll wait for any further feedback, try something like above and resubmit tomorrow.

Aug. 18, 2010

Re: wldap32: Fix handling of zero timeout value in ldap_search_extW. (try 2)

by Hans Leidekker

On Wed, 2010-08-18 at 13:41 +0200, testbot(a)testbot.winehq.org wrote: > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > http://testbot.winehq.org/JobDetails.pl?Key=4530 > > Your paranoid android. > > > === W2KPROSP4 (32 bit parse) === > parse.c:101: Test failed: ldap_search_extW failed 0x00000034 > parse.c:105: Test failed: ldap_search_extW failed 0x00000051 0x34 == LDAP_UNAVAILABLE, likely caused by a network problem.

Aug. 18, 2010

Re: wldap32: Fix handling of zero timeout value in ldap_search_extW. (try 2)

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4530 Your paranoid android. === W2KPROSP4 (32 bit parse) === parse.c:101: Test failed: ldap_search_extW failed 0x00000034 parse.c:105: Test failed: ldap_search_extW failed 0x00000051

Aug. 18, 2010

Re: [4/5] msi: Handle signature filenames in short|long notation.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4528 Your paranoid android. === W7PROX64 (32 bit package) === package.c:8348: Test failed: Expected "C:\Program Files\VMware\VMware Tools\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\", got "C:\Program Files (x86)\VMware\VMware Tools\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\" === W7PROX64 (64 bit package) === package.c:8385: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8396: Test failed: Expected "C:\winetest\", got "" package.c:8407: Test failed: Expected "C:\winetest\", got "" package.c:8457: Test failed: Expected "C:\winetest\FileName3.dll", got "" package.c:8468: Test failed: Expected "C:\winetest\FileName5.dll", got "" package.c:8477: Test failed: Expected "C:\", got "" package.c:8483: Test failed: Expected "C:\winetest\", got "" package.c:8504: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8513: Test failed: Expected "C:\winetest\FileName1", got ""

Aug. 18, 2010

Re: [3/5] msi/tests: Skip SourceDir tests on win9x.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4527 Your paranoid android. === W2K3R2SESP2 (32 bit install) === Timeout

Aug. 18, 2010

Re: Wine64 debugger

by Eric Pouech

the assertion `addr->Mode == AddrModeFlat' failed is likely an address returned by dbghelp which is not properly initialized. Could you send me off line the .exe (and associated DLL if any) so that I can check it TIA 2010/8/17 Peter Urbanec <winehq.org(a)urbanec.net> > > Hi, > > I'm trying to get a fairly complex Win64 application to work with wine. I'm > seeing crashes in FindNextFileW/FindNextFileA due to what looks like a 64 > bit HANDLE value being truncated to 32 bits. I thought that I would employ > winedbg to help me, but I can't get very far. I don't have any luck with > winedbg even on a simple x64 Win32 app. > > For my simplified test, I used MSVC2005 to generate an x64 executable > created from the standard MSVC2005 template Win32 application. This is a > simple app that just creates an empty window. As simple as one could get for > a Win32 test and it executes correctly when run as "./wine Test1.exe". When > I try to execute this test app under winedbg, I get an assert failure: > > ./wine winedbg Test1.exe > WineDbg starting on pid 001a > ./programs/winedbg/memory.c:37: be_cpu_linearize: Assertion `addr->Mode == > AddrModeFlat' failed. > wine: Assertion failed at address 0x7fec2fa657c5 (thread 0009), starting > debugger... > Unhandled exception: assertion failed in 64-bit code (0x00007fec2fa657c5). > > Any ideas about why I can not use winedbg to run Win32 x64 code? > > Thanks, > > Peter Urbanec > > > > > > > -- -- Eric Pouech

Aug. 18, 2010

Re: [2/5] msi/tests: Use HKEY_CURRENT_USER instead of HKEY_LOCAL_MACHINE for registry tests.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4526 Your paranoid android. === W2K3R2SESP2 (32 bit install) === Timeout

Aug. 18, 2010

Re: [PATCH] advapi32: Add magic codes to HCRYPTKEY and HCRYPTHASH.

by GOUJON Alexandre

On 08/18/2010 12:22 PM, Hans Leidekker wrote: > They are often built from four character ascii strings to help find out > where the structures come from. I don't know why this one was chosen > but I guess you could use something like 0xA39E741E and 0xA39E741D. > Yep, there are some magic values at http://en.wikipedia.org/wiki/Hexspeak FYI, MAGIC_CRYPTPROV comes from the following commit http://source.winehq.org/git/wine.git/?a=commitdiff;h=44cb0906da3dddbca1fe6…

Aug. 18, 2010

Re: [1/5] msi/tests: Fix some WoW64 test failures.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4525 Your paranoid android. === W7PROX64 (32 bit package) === package.c:8329: Test failed: Expected "C:\Program Files\VMware\VMware Tools\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\", got "C:\Program Files (x86)\VMware\VMware Tools\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\" === W7PROX64 (64 bit package) === package.c:8366: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8377: Test failed: Expected "C:\winetest\", got "" package.c:8388: Test failed: Expected "C:\winetest\", got "" package.c:8438: Test failed: Expected "C:\winetest\FileName3.dll", got "" package.c:8449: Test failed: Expected "C:\winetest\FileName5.dll", got "" package.c:8458: Test failed: Expected "C:\", got "" package.c:8464: Test failed: Expected "C:\winetest\", got "" package.c:8485: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8494: Test failed: Expected "C:\winetest\FileName1", got ""

Aug. 18, 2010

Re: [PATCH] advapi32: Add magic codes to HCRYPTKEY and HCRYPTHASH.

by Hans Leidekker

On Wed, 2010-08-18 at 20:02 +1000, Austin Lund wrote: > On 18 August 2010 18:34, Hans Leidekker <hans(a)codeweavers.com> wrote: > > On Wed, 2010-08-18 at 10:14 +1000, Austin Lund wrote: > > > >> #define MAGIC_CRYPTPROV 0xA39E741F > >> +#define MAGIC_CRYPTKEY 0xA39E741F > >> +#define MAGIC_CRYPTHASH 0xA39E741F > > > > The app might pass a crypto handle of the wrong type, so it would be > > better to use different magic values. > > > > Are there any rules to these magic values? Why was 0xA39E741F chosen? They are often built from four character ascii strings to help find out where the structures come from. I don't know why this one was chosen but I guess you could use something like 0xA39E741E and 0xA39E741D.

Aug. 18, 2010

kernel32/tests: GetVolumeInformationA X: succeeds iff drive's default dir is root. (try 2)

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, please consider that patch, submitted on the 3rd of August, for inclusion. Tests pass on native w95,w98,w2k,xp,7. Greg Geldorp went into the extra effort to instrument the testbot machines (NT upto 7, not win9X) http://www.winehq.org/pipermail/wine-devel/2010-August/085919.html with a second drive to validate my new tests, avoiding the volume.c:345: Tests skipped: Please re-run from another device than C: of a normal testbot run, such that the GetVolumeInformation tests are not skipped when started from drive E: >In short: everything passes. Thank you, Jörg Höhle

Aug. 18, 2010

Re: [PATCH] advapi32: Add magic codes to HCRYPTKEY and HCRYPTHASH.

by Austin Lund

On 18 August 2010 18:34, Hans Leidekker <hans(a)codeweavers.com> wrote: > On Wed, 2010-08-18 at 10:14 +1000, Austin Lund wrote: > >> #define MAGIC_CRYPTPROV 0xA39E741F >> +#define MAGIC_CRYPTKEY 0xA39E741F >> +#define MAGIC_CRYPTHASH 0xA39E741F > > The app might pass a crypto handle of the wrong type, so it would be > better to use different magic values. > Are there any rules to these magic values? Why was 0xA39E741F chosen?

Aug. 18, 2010

Re: wldap32: Fix handling of zero timeout value in ldap_search_extW.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4524 Your paranoid android. === W98SE (32 bit parse) === parse.c:108: Test failed: ldap_search_extW failed 0x00000059 === WNT4WSSP6 (32 bit parse) === parse.c:108: Test failed: ldap_search_extW failed 0x00000059

Aug. 18, 2010

Re: [PATCH] advapi32: Add magic codes to HCRYPTKEY and HCRYPTHASH.

by Hans Leidekker

On Wed, 2010-08-18 at 10:14 +1000, Austin Lund wrote: > #define MAGIC_CRYPTPROV 0xA39E741F > +#define MAGIC_CRYPTKEY 0xA39E741F > +#define MAGIC_CRYPTHASH 0xA39E741F The app might pass a crypto handle of the wrong type, so it would be better to use different magic values.

Aug. 18, 2010

Re: [PATCH 2/3] winex11.drv: set global key state

by Vitaliy Margolen

On 08/16/2010 01:06 PM, Rafał Miłecki wrote: > It's prehistoric thread already, but issue still isn't solved. I > wanted to rework that old patch but I noticed set_key_state was > already changed and it doesn't change single key state, but instead > sets whole array at every call. > > This was I can not use set_key_state handler to update my > "global_keystate" array, as I have no idea which key actually has been > changed. > > Do you see some nice solution for this problem? You can send the whole array (256 bytes isn't all that much, but on every key event - an overkill). Or you can send changes only all at once (comparing arrays isn't all that hard). Lastly you can use Xi2 to receive all key changes, however this won't pick up any injected key events (this is how it works in Wine anyway, so not a big loss of functionality). Vitaliy.

Aug. 18, 2010

Re: winex11.drv: Fix uninitialised values. (valgrind) (try 2)

by Austin English

On Tue, Aug 10, 2010 at 4:28 PM, Dan Kegel <dank(a)kegel.com> wrote: > That's for http://bugs.winehq.org/show_bug.cgi?id=20335 , right? > > Alexandre's reply to that was > "It sounds like it's hashing padding bytes. Probably should be reported to the > X.org folks." FWIW, I reported it here: https://bugs.freedesktop.org/show_bug.cgi?id=29600 -- -Austin

Aug. 17, 2010

Re: Should we expect Liberation fonts to be installed?

by Juan Lang

>> Is there a meaningful difference in the two licenses for fonts? LGPL >> is necessary for code, which gets loaded at runtime to a closed-source >> executable, but fonts contain no code, and thus aren't loaded. > > A good point, but I'm not qualified to answer that. I suspect that the > SFC would be able to answer it, if it's a serious consideration. > > FWIW, a couple links: > http://www.gnu.org/licenses/gpl-faq.html#FontException > http://www.gnu.org/licenses/license-list.html#Fonts > > and the actual license: > http://git.fedorahosted.org/git/?p=liberation-fonts.git;a=blob_plain;f=sour… The actual license contains the font exception. IANAL, but that would appear to resolve any transitive license problem that might otherwise arise from including Liberation fonts. --Juan

Aug. 17, 2010

Re: Should we expect Liberation fonts to be installed?

by Austin English

On Tue, Aug 17, 2010 at 10:38 AM, Juan Lang <juan.lang(a)gmail.com> wrote: >>> Along those lines, the hard drive space is cheap on this one. Seems >>> like Wine packagers could just include the fonts and install them >>> locally in c:\windows\fonts. >> >> The Liberation fonts are GPL licensed, Wine is LGPL. > > Is there a meaningful difference in the two licenses for fonts? LGPL > is necessary for code, which gets loaded at runtime to a closed-source > executable, but fonts contain no code, and thus aren't loaded. A good point, but I'm not qualified to answer that. I suspect that the SFC would be able to answer it, if it's a serious consideration. FWIW, a couple links: http://www.gnu.org/licenses/gpl-faq.html#FontException http://www.gnu.org/licenses/license-list.html#Fonts and the actual license: http://git.fedorahosted.org/git/?p=liberation-fonts.git;a=blob_plain;f=sour… -- -Austin

Aug. 17, 2010

Re: Wine64 debugger

by David Laight

On Tue, Aug 17, 2010 at 05:51:55PM +0200, Marcus Meissner wrote: > > The Wine code is correct as-is, but perhaps the Windows win64 code generates > only handles with 32bit. That it very likely. There are windows #defines/inline functions that convert HANDLE <=> long. Remember there are some functions that return handles as long (not void *) Also, when the windows kernel generates a HANDLE it is unlikely to know whether the app is 32bit or 64bit - so will only generate 32bit values. I also remember reading somewhere that the kernel handle table is limited to 2^24 entries - even in 64bit mode. David -- David Laight: david(a)l8s.co.uk

Aug. 17, 2010

Re: Wine64 debugger

by Marcus Meissner

On Wed, Aug 18, 2010 at 01:00:35AM +1000, Peter Urbanec wrote: > Hi, > > I'm trying to get a fairly complex Win64 application to work with > wine. I'm seeing crashes in FindNextFileW/FindNextFileA due to what > looks like a 64 bit HANDLE value being truncated to 32 bits. I > thought that I would employ winedbg to help me, but I can't get very > far. I don't have any luck with winedbg even on a simple x64 Win32 > app. Check if your code uses "int" in its FindNextFile or findfirst things. I fixed ioquake3 for this for instance. The Wine code is correct as-is, but perhaps the Windows win64 code generates only handles with 32bit. Ciao, Marcus

Aug. 17, 2010

Re: Should we expect Liberation fonts to be installed?

by Juan Lang

>> Along those lines, the hard drive space is cheap on this one. Seems >> like Wine packagers could just include the fonts and install them >> locally in c:\windows\fonts. > > The Liberation fonts are GPL licensed, Wine is LGPL. Is there a meaningful difference in the two licenses for fonts? LGPL is necessary for code, which gets loaded at runtime to a closed-source executable, but fonts contain no code, and thus aren't loaded. --Juan

Aug. 17, 2010

Wine64 debugger

by Peter Urbanec

Hi, I'm trying to get a fairly complex Win64 application to work with wine. I'm seeing crashes in FindNextFileW/FindNextFileA due to what looks like a 64 bit HANDLE value being truncated to 32 bits. I thought that I would employ winedbg to help me, but I can't get very far. I don't have any luck with winedbg even on a simple x64 Win32 app. For my simplified test, I used MSVC2005 to generate an x64 executable created from the standard MSVC2005 template Win32 application. This is a simple app that just creates an empty window. As simple as one could get for a Win32 test and it executes correctly when run as "./wine Test1.exe". When I try to execute this test app under winedbg, I get an assert failure: ./wine winedbg Test1.exe WineDbg starting on pid 001a ./programs/winedbg/memory.c:37: be_cpu_linearize: Assertion `addr->Mode == AddrModeFlat' failed. wine: Assertion failed at address 0x7fec2fa657c5 (thread 0009), starting debugger... Unhandled exception: assertion failed in 64-bit code (0x00007fec2fa657c5). Any ideas about why I can not use winedbg to run Win32 x64 code? Thanks, Peter Urbanec

Aug. 17, 2010

Re: kernel32: add stub for SetFileValidData

by Alexandre Julliard

Austin English <austinenglish(a)gmail.com> writes: > @@ -1001,6 +1001,16 @@ error: > } > > /*********************************************************************** > + * SetFileValidData (KERNEL32.@) > + */ > +BOOL WINAPI SetFileValidData( HANDLE hFile, LONGLONG ValidDataLength ) > +{ > + FIXME("stub: %p, %llu\n", hFile, ValidDataLength); You can't use %ll formats. -- Alexandre Julliard julliard(a)winehq.org

Aug. 17, 2010

Re: user32, GetUserObjectInformation implementation with index=UOI_USER_SID (try2, resend)

by Alexandre Julliard

Wolfgang Schwotzer <wolfgang.schwotzer(a)gmx.net> writes: > New patch after rebase. > Always checks return values. > Tested with Polar Protrainer 5, updater.exe > From dcb91595b33513f8df2cf4d439221d3143c8fac1 Mon Sep 17 00:00:00 2001 > From: Wolfgang Schwotzer <wolfgang.schwotzer(a)gmx.net> > Date: Sat, 24 Jul 2010 17:12:05 +0200 > Subject: GetUserObjectInformation UOI_USER_SID (try 2) This should be retrieved from the server, based on the object security token or something along those lines. -- Alexandre Julliard julliard(a)winehq.org

Aug. 17, 2010

Re: shdocvw: Remove useless menu separator

by Alexander Nicolaysen Sørnes

Tirsdag 17 august 2010 01:42:21 skrev Frédéric Delanoy : > On Mon, Aug 16, 2010 at 23:28, Octavian Voicu <octavian.voicu(a)gmail.com> wrote: > > Not sure if it's useless. I thing it's intended to separate the static > > part of the menu (Add to favorites) from the dynamically generated > > list of favorite items that follows (which isn't implemented yet). > > In that case, shouldn't the menu separator also be auto-generated when > the list of (>=1) favorite items is generated? > How about when there's no favorite at all? > Separators should only be used to separate non-empty "sections" IMO; > otherwise they just look out of place. > > Frédéric Ideally, there would be a single grayed menu item with the text "(empty)" after the separator if no Favorites are present. This would should users where they are supposed to find favorites, and is also what native IE does. Anyway, I think this patch should be discarded. Alexander

Aug. 17, 2010

Re: [PATCH 1/4] msvcp90: Added allocator<char> 64-bit exports

by Alexandre Julliard

Piotr Caban <piotr(a)codeweavers.com> writes: > @@ -35,6 +35,12 @@ char* __stdcall MSVCP_allocator_char_address(void *this, char *ptr) > return ptr; > } > > +/* ?address@?$allocator(a)D@std@@QEBAPEADAEAD(a)Z */ > +char* __cdecl MSVCP64_allocator_char_address(void *this, char *ptr) > +{ > + return MSVCP_allocator_char_address(this, ptr); > +} > + stdcall and cdecl are equivalent on 64-bit, so you don't need the extra wrappers. -- Alexandre Julliard julliard(a)winehq.org

Aug. 17, 2010

Re: avifil32: Fix EditStreamSetInfo wine checks [try 2]

by Alexandre Julliard

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > +#define TEST_SETINFO_(m) \ > + hres = EditStreamSetInfo(stream, &info, sizeof(AVISTREAMINFO) ); \ > + ok( hres == 0, "got 0x%08X, expected 0\n", hres); \ > + hres = AVIStreamInfo(stream, &info2, sizeof(AVISTREAMINFO) ); \ > + ok( hres == 0, "got 0x%08X, expected 0\n", hres); \ > + ok( info2.m == info.m, "EditStreamSetInfo did not update "#m" parameter\n" ); > + > +#define TEST_SETINFO(m) \ > + info.m++; \ > + TEST_SETINFO_(m); \ > + \ > + info.m = 0; \ > + TEST_SETINFO_(m); Please avoid that sort of macros. Add a helper function if necessary, or just spell things out explicitly. -- Alexandre Julliard julliard(a)winehq.org

Aug. 17, 2010

Re: iPod synced with iTunes v7.6!

by Damjan Jovanovic

When Wine supports kernel USB drivers, it might be something to try. I plan to continue my work on that - some time. IIRC usbaapl.sys uses usbstor.sys, so we'd have to write a version of that for Wine as well. Damjan Jovanovic On Tue, Aug 17, 2010 at 12:33 PM, Ben Peddell <klightspeed(a)netspace.net.au> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 15/08/2010 4:28 PM, Russ Mannex wrote: >> Hello Maarten! >> >> I read your post on the WineHQ site. I was wondering if you know whether >> I am attempting something that simply will not work yet. I am running >> iTunes 7.7.1 on Wine 1.1.42. These are running on Ubuntu 10.04. iTunes >> is not showing my iPod. I have tried setting an autodetect drive E: to >> /media/IPOD, but iTunes seems to not see it there. Any help will be >> greatly appreciated, even if the answer is "will not work." Thanks. > > Apple iTunes uses a kernel-mode device driver (usbaapl.sys) to talk to > the iPod. It'd be a project all of its own (perhaps bigger than trying > to make a native clone) to try to get iTunes to talk to the iPod under Wine. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkxqZWwACgkQTHDAI68NsukS+ACgkRjYFLQB1XOtSH1N3mFOqOX+ > m58AoIees4mig4aU1StBaZHy4vbytr+g > =Ez7t > -----END PGP SIGNATURE----- > > >

Aug. 17, 2010

Re: iPod synced with iTunes v7.6!

by Ben Peddell

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15/08/2010 4:28 PM, Russ Mannex wrote: > Hello Maarten! > > I read your post on the WineHQ site. I was wondering if you know whether > I am attempting something that simply will not work yet. I am running > iTunes 7.7.1 on Wine 1.1.42. These are running on Ubuntu 10.04. iTunes > is not showing my iPod. I have tried setting an autodetect drive E: to > /media/IPOD, but iTunes seems to not see it there. Any help will be > greatly appreciated, even if the answer is "will not work." Thanks. Apple iTunes uses a kernel-mode device driver (usbaapl.sys) to talk to the iPod. It'd be a project all of its own (perhaps bigger than trying to make a native clone) to try to get iTunes to talk to the iPod under Wine. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxqZWwACgkQTHDAI68NsukS+ACgkRjYFLQB1XOtSH1N3mFOqOX+ m58AoIees4mig4aU1StBaZHy4vbytr+g =Ez7t -----END PGP SIGNATURE-----

Aug. 17, 2010

Re: [PATCH 1/5] wined3d: separate driver info from GPU info

by Henri Verbeet

On 17 August 2010 03:52, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > --- > dlls/wined3d/directx.c | 276 +++++++++++++++++++++------------------ > dlls/wined3d/wined3d_private.h | 14 ++ > 2 files changed, 163 insertions(+), 127 deletions(-) > This will return inconsistent driver version numbers for Vista, Win7 and 95/98/NT4.

Aug. 17, 2010

Re: [PATCH 1/6] winealsa.drv: Init mixer on cards with a single Mic control, like snd_usb_audio mics (try 2)

by sudemon

On 03.08.2010 04:36, Jeff Cook wrote: > What compiler are you running? It works fine for me and I don't see > any errors or warnings. I also don't see any errors or warnings. Аfter 6120d7cc14522983fbc38026ab4fcb6e4a68cdf0 commit - my games just crash on start without errors (windows version is win98). Found by Regression test (16 august master VS wine-1.3.0). After this commands games don't crash: $ git bisect reset $ git show 6120d7cc14522983fbc38026ab4fcb6e4a68cdf0 | patch -p1 -R

Aug. 17, 2010

Re: Should we expect Liberation fonts to be installed?

by Austin English

On Mon, Aug 9, 2010 at 10:59 PM, Brian Vincent <brian.vincent(a)gmail.com> wrote: > Along those lines, the hard drive space is cheap on this one. Seems > like Wine packagers could just include the fonts and install them > locally in c:\windows\fonts. The Liberation fonts are GPL licensed, Wine is LGPL. -- -Austin

Aug. 17, 2010

Re: [2/2] gdiplus: Implement multi-frame image loading.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4486 Your paranoid android. === WVISTAADM (32 bit image) === No test summary line found

Aug. 17, 2010

Re: shdocvw: Remove useless menu separator

by Frédéric Delanoy

On Mon, Aug 16, 2010 at 23:28, Octavian Voicu <octavian.voicu(a)gmail.com> wrote: > Not sure if it's useless. I thing it's intended to separate the static > part of the menu (Add to favorites) from the dynamically generated > list of favorite items that follows (which isn't implemented yet). In that case, shouldn't the menu separator also be auto-generated when the list of (>=1) favorite items is generated? How about when there's no favorite at all? Separators should only be used to separate non-empty "sections" IMO; otherwise they just look out of place. Frédéric

Aug. 16, 2010

Re: shdocvw: Remove useless menu separator

by Octavian Voicu

Not sure if it's useless. I thing it's intended to separate the static part of the menu (Add to favorites) from the dynamically generated list of favorite items that follows (which isn't implemented yet). Octavian

Aug. 16, 2010