- wine-devel - winehq.org

Re: [3/4] msxml3: Fix IXMLDOMNode::get_namespaceURI() for empty URIs
by testbot＠testbot.winehq.org 14 Sep '10

14 Sep '10

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=5208 Your paranoid android. === W98SE (32 bit domdoc) === domdoc.c:6187: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === WNT4WSSP6 (32 bit domdoc) === domdoc.c:6187: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === W2KPROSP4 (32 bit domdoc) === domdoc.c:6187: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154

1 0

Re: [2/4] msxml3: Fix IXMLDOMNode::get_prefix() for empty prefix
by testbot＠testbot.winehq.org 14 Sep '10

14 Sep '10

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=5207 Your paranoid android. === W98SE (32 bit domdoc) === domdoc.c:6187: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === WNT4WSSP6 (32 bit domdoc) === domdoc.c:6187: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === W2KPROSP4 (32 bit domdoc) === domdoc.c:6187: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154

1 0

Re: [1/4] msxml3: Support elements with namespaces
by testbot＠testbot.winehq.org 14 Sep '10

14 Sep '10

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=5206 Your paranoid android. === W98SE (32 bit domdoc) === domdoc.c:6141: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === WNT4WSSP6 (32 bit domdoc) === domdoc.c:6141: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === W2KPROSP4 (32 bit domdoc) === domdoc.c:6141: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154

1 0

Re: [2/2] ws2_32: Fail when select is called with an invalid fd.
by Mike Kaplinskiy 14 Sep '10

14 Sep '10

On Sun, Sep 12, 2010 at 5:23 PM, Vincent Povirk <vincent(a)codeweavers.com> wrote: > > > > > > > @@ -3193,6 +3193,10 @@ int WINAPI WS_select(int nfds, WS_fd_set *ws_readfds, > return SOCKET_ERROR; > } > > + for (i=0; i<count; i++) > + if (pollfds[i].fd == -1) > + return SOCKET_ERROR; You're leaking pollfds here. (As a nitpick - braces for for's that contain more than one line are nice) Mike.

1 0

Re: [Wine] [1.2]-S.T.A.L.K.E.R.:SoC - Remapping keys?
by Jesse Palser 14 Sep '10

14 Sep '10

On 9/9/10 8:48 AM, Jesse Palser wrote: > > [1.2]-S.T.A.L.K.E.R.:SoC - Remapping keys? > > Hi, > > I am running Wine 1.2 on Ubuntu 10.04 32bit Linux. > > I wish to remap the movement keys in: > S.T.A.L.K.E.R.: Shadow of Chernobyl, > but when I try, it always maps "Pause" ? You will have to ask this in the Steam support forums. Wine does not activate or deactivate keys. James McKenzie ------------------------------------------------------------------------------------------------------- Hi, I am not talking about activating/deactivating registration keys. I am talking about the control mapping of keyboard keys in the game. Currently when I try to remap a keyboard key in this game, it always selects "Pause" regardless of which keyboard key I press. I would like to map the arrow key for movement, and can not do that. Any ideas? Using Wine 1.2 on Ubuntu 10.04 32bit Linux. Thanks! Jesse

2 1

Re: Release plans
by Luis Carlos Busquets Pérez 13 Sep '10

13 Sep '10

As a user that only uses wine for playing games built for the Windows platform what I would like the most is d3d10, d3d10.1 and d3d11. It seems that these API's are more similar between themselves than what is the difference between d3d9 and d3d10.

1 0

Re: Release plans
by Dan Kegel 13 Sep '10

13 Sep '10

Looks like Alexandre must have fired up his time machine again :-) And as long as it's up and running, how about a look forward at the 1.4 release plans?

5 6

Re: d3d9/tests: Test NVDB (depth bounds test) behavior
by Henri Verbeet 13 Sep '10

13 Sep '10

This is fine, except for the 8 space indentation. I wonder though if perhaps it would be more interesting to start with a quad with a depth gradient from 0.0 to 1.0, bottom to top, then set the min/max depth bounds, and draw another fullscreen quad. That way you could easily verify the cutoffs are in roughly the right spots.

1 0

Re: wined3d: Add NVDB support
by Henri Verbeet 13 Sep '10

13 Sep '10

2010/9/12 Ričardas Barkauskas <miegalius(a)gmail.com>: > Looks reasonable in general, though there are a few minor issues: > + /* Depth bound test. To query if the card supports instancing CheckDeviceFormat with the special Instancing doesn't have anything to do with this. > + union { > + DWORD d; > + float f; > + } zmin, zmax; Four space indent is enough. You do this in the test patch as well. > + if(stateblock->renderState[WINED3DRS_ENABLEADAPTIVETESSELLATION]) > + FIXME("(WINED3DRS_ENABLEADAPTIVETESSELLATION,%d) not yet implemented\n", stateblock->renderState[WINED3DRS_ENABLEADAPTIVETESSELLATION]); Note that you can just call state_tessellation() here. > { STATE_RENDER(WINED3DRS_ADAPTIVETESS_W), { STATE_RENDER(WINED3DRS_ENABLEADAPTIVETESSELLATION), NULL }, WINED3D_GL_EXT_NONE }, > + { STATE_RENDER(WINED3DRS_ENABLEADAPTIVETESSELLATION), { STATE_RENDER(WINED3DRS_ENABLEADAPTIVETESSELLATION), state_tessellnvdb }, EXT_DEPTH_BOUNDS_TEST }, You have two extra spaces here.

1 0

re: [PATCH 2/7] d3dx9_36/tests: Added HLSL test suite
by Dan Kegel 13 Sep '10

13 Sep '10

Henri wrote: > You still have basic formatting errors like trailing spaces, mixing > tabs and spaces, inconsistent "*" placement, etc. > ... unnecessary cast... > wine-patches reviews are supposed to catch non-trivial interactions with > other parts of the code, not trivial whitespace errors. Looking at http://wiki.winehq.org/SubmittingPatches, I didn't see a nice, concise checklist of things to check for, so I added one at the top, and linked to Henri's post. Improvements welcome. - Dan

3 2

Suggestion for the Game Explorer implementation
by אלעד 13 Sep '10

13 Sep '10

I have a little suggestion: integrate the Game Explorer with the Games menu of the desktop, so that games i install in wine will be added to the Games menu automaticlly.

2 1

ptrace, pokerstars and Ubuntu 10.10
by Michael Fox 13 Sep '10

13 Sep '10

Hi all, There's a problem running wine under the new Ubuntu 10.10 (Maverick). They have enabled kernel security to prevent processes from using ptrace. This affects any wine programs which use ptrace which is surprisingly common. For example I found this bug because PokerStars wouldn't connect to the network. I have filed this as a bug with Ubuntu, but they might choose not to fix it depending on how committed they are to this new security measure. It is filed as: https://bugs.launchpad.net/ubuntu/+source/wine1.2/+bug/636278 There is a simple workaround and it is to add the ptrace capability to wineserver using the command: sudo setcap cap_sys_ptrace=eip /usr/bin/wineserver I tried to submit this as a bug for wine, but it was closed because the maintainer felt there was nothing the wine people could do about the way Ubuntu sets their security. I would like to make the following suggestions: 1. Add a winetricks trick to fix wine on Maverick by executing: "sudo apt-get install setcap; sudo setcap cap_sys_ptrace=eip /usr/bin/wineserver" 2. Add an error message in wine when ptrace fails with error EPERM. This message should suggest the winetrick so the user will find it quickly. In my case it took quite a while to figure out exactly what was going wrong because there is no more terminal output when ptrace fails than when it succeeds. -- - Michael

4 5

Re: [PATCH 2/3] wined3d: store amount of video memory in gpu_description_table
by Roderick Colenbrander 13 Sep '10

13 Sep '10

Hi Jesse, I think the 465 change should go in after the gpu table patch. The gpu table patch could be modified but then it would essentially contain two patches (makes regression testing more complicated, though I doubt that would be an issue here). It is trivial to submit a patch after this is in. If you want I can do that. Roderick On Sat, Sep 11, 2010 at 9:34 AM, Evil Jay <evil(a)eternaldusk.com> wrote: > Roderick, > > Would you add the GTX 465 (1GB) to this table? That way the patch I > submitted to add the 465 just 30 minutes earlier can be safely ignored. > > -Jesse > > >

2 1

Running GDI32 tests for Wine on MacOSX 10.6
by James McKenzie 13 Sep '10

13 Sep '10

On 9/7/10 11:37 AM, doh123 wrote: > James Mckenzie wrote: >> I agree with both Ryan and you, LD_LIBRARY_PATH is supposed to do absolutely NOTHING under MacOSX. However, Wine needs it for some strange reason. If I leave it out, the built dependency libraries are not found for freetype and fontconfig (and I know that fontconfig is included with MacOSX 10.6 now.) Otherwise, I get a series of freetype cannot be found, install freetype 2.0.5 or higher. I'll look at the Fink setup script to see how they did this. >> > This error can be fixed with DYLD_FALLBACK_LIBRARY_PATH... > > I've uploaded three logging files to pastebin.com: Part #1 of running the gdi32 tests with LD_LIBRARY_PATH set to: $HOME/darwine/wineEnv/usr/lib:/usr/X11R6/lib http://pastebin.com/NyrQxE4Q Part # 2 of the same test http://pastebin.com/dF1PwvHJ Log of running the same tests with DYLD_LIBRARY_PATH set to: $HOME/darwine/wineEnv/usr/lib:/usr/X11R6/lib and DYLD_FALLBACK_LIBRARY_PATH set to: /usr/lib:$HOME/darwine/wineEnv/usr/lib:/usr/X11R6/lib http://pastebin.com/i3Mfh7NB The $HOME/darwine/wineEnv/usr/lib directory contains unaltered builds of the dependencies for Wine (freetype, libgphoto2, etc.) that are separate from Fink builds. Any clue as to why the LD_LIBRARY_PATH is working and the DYLD paths are not? Thank you.

1 0

Re: kernel32: add a stub for GetSystemDEPPolicy()
by Marcus Meissner 12 Sep '10

12 Sep '10

On Sun, Sep 12, 2010 at 12:50:39PM -0500, Austin English wrote: > -- > -Austin > diff --git a/dlls/kernel32/kernel32.spec b/dlls/kernel32/kernel32.spec > index 8a33013..43e339b 100644 > --- a/dlls/kernel32/kernel32.spec > +++ b/dlls/kernel32/kernel32.spec > @@ -624,6 +624,7 @@ > @ stdcall GetSystemDefaultLCID() > @ stdcall GetSystemDefaultLangID() > @ stdcall GetSystemDefaultUILanguage() > +@ stdcall GetSystemDEPPolicy() > @ stdcall GetSystemDirectoryA(ptr long) > @ stdcall GetSystemDirectoryW(ptr long) > @ stdcall GetSystemInfo(ptr) > diff --git a/dlls/kernel32/process.c b/dlls/kernel32/process.c > index c1816a8..5990943 100644 > --- a/dlls/kernel32/process.c > +++ b/dlls/kernel32/process.c > @@ -3385,3 +3385,14 @@ DWORD WINAPI WTSGetActiveConsoleSessionId(void) > FIXME("stub\n"); > return 0; > } > + > +/********************************************************************** > + * GetSystemDEPPolicy (KERNEL32.@) > + */ > +DEP_SYSTEM_POLICY_TYPE WINAPI GetSystemDEPPolicy(void) > +{ > + FIXME("stub\n"); > + return 0; better return one of the Enum values here ... "AlwaysOff" probably, instead of 0 (AlwaysOn). Ciao, Marcus > +} > + > + > diff --git a/include/winbase.h b/include/winbase.h > index ea10696..d8dba1d 100644 > --- a/include/winbase.h > +++ b/include/winbase.h > @@ -1230,6 +1230,13 @@ typedef struct tagHW_PROFILE_INFOW { > DECL_WINELIB_TYPE_AW(HW_PROFILE_INFO) > DECL_WINELIB_TYPE_AW(LPHW_PROFILE_INFO) > > +typedef enum _DEP_SYSTEM_POLICY_TYPE { > + AlwaysOn, > + AlwaysOff, > + OptIn, > + OptOut > +} DEP_SYSTEM_POLICY_TYPE; > + > /* Event Logging */ > > #define EVENTLOG_FULL_INFO 0 >

3 2

RE: Problem with getting account at testbot
by Greg Geldorp 12 Sep '10

12 Sep '10

Hi Mariusz, > From: Mariusz Pluciński > > I have a problem with my account at testbot.winehq.org. Long time ago, I > registered my account. To this day I have not received an activation > e-mail. I thought it was maybe rejected, because I was not "well-known > member of the Wine community" that time. > > Today I noticed that I can not send request for account, because "User > already exists". Trying to use "forgotten password" feature gave me > information that my account was not activated. What could I do with > this? I was working on Wine some time without this, but now testbot > account would be very helpful for me. Sorry about that, I must have missed the notification when you first registered. I have now activated your account (you should have received an e-mail about it), just let me know if you still encounter problems. You can either reply directly to this email or use the Feedback link on the website to contact me. Ge.

1 0

Assertion in winebuild
by André Hentschel 12 Sep '10

12 Sep '10

Hi, I run in the assertion in function output_stubs in winebuild/import.c obsiouly not on x86/x86_64, but in my rebased(to a more recent wine tree) ARM build in dlls like msvcp80, msvcp90 and up, but not msvcirt or msvcrt and the normal others like ntdll and so on. So i wonder: - how x86/x86_64 are treated different. (really couldn't trace that down, see below) - what is different with e.g. msvcp80 so that non-x86/x86_64 builds get into the assertion? As i can see it is always called in function BuildSpec32File in spec32.c, so some values seem to be modified on non-x86/x86_64 e.g. odp->type -- Best Regards, André Hentschel

1 0

Problem with geting account at testbot
by Mariusz Pluciński 12 Sep '10

12 Sep '10

Hello I have a problem with my account at testbot.winehq.org. Long time ago, I registered my account. To this day I have not received an activation e-mail. I thought it was maybe rejected, because I was not "well-known member of the Wine community" that time. Today I noticed that I can not send request for account, because "User already exists". Trying to use "forgotten password" feature gave me information that my account was not activated. What could I do with this? I was working on Wine some time without this, but now testbot account would be very helpful for me. Mariusz Pluciński

2 1

Release plans
by Alexandre Julliard 12 Sep '10

12 Sep '10

Folks, There won't be a release this week, since I'll be spending my Friday on an airplane. Release 1.1.44 will be next Friday. If all goes well and I can finish the few remaining bits of 64-bit support, it should be the last release of the 1.1.x series. We'll then enter code freeze and start the 1.2-rc series. The 1.2 final release should thus happen hopefully sometime in June. -- Alexandre Julliard julliard(a)winehq.org

1 0

Macro names instead of numbers in logs
by Florian Köberle 12 Sep '10

12 Sep '10

Hello when running a program using wine it's possible to log +message to get informed about all the messages which get sent. This debug channel displays the macro names like WM_NOTIFY instead of numbers. The most other debug channels and the regression tests however display numbers. Functions like SPY_GetMsgName which can make window messages more human readable can be found in dlls/user32/spy.c. Is there a acceptable way of making functions like SPY_GetMsgName available to other libraries and tests? There are about 80 TRACE/trace lines which could be improved: egrep "trace.*hwnd.*lParam" dlls/ -R -i -I|grep -v user32|wc Best regards, Florian

5 10

Keeping people from trying iTunes in Wine?
by Dan Kegel 11 Sep '10

11 Sep '10

Watching Twitter, one fairly frequently seems people trying and failing to run iTunes 10 and the like in Wine. Should we let them bash their heads against the wall like that? Maybe we should detect the top ten apps that don't work with Wine, and put up a warning dialog saying they are known not to work, and people shouldn't try. (Kind of like what Windows 7 does when you do something dangerous, e.g. try to look at the contents of drive C:.)

15 19

Re: [PATCH 2/3] wined3d: store amount of video memory in gpu_description_table
by Rico Schüller 11 Sep '10

11 Sep '10

Am 11.09.2010 03:59, schrieb Roderick Colenbrander: > /* Geforce 300 midend mobile (Geforce GT 325M/330M use the same core) */ > if (strstr(gl_renderer, "GT 325M") > || strstr(gl_renderer, "GT 330M")) > { > - *vidmem = 1024; > - return CARD_NVIDIA_GEFORCE_GT325M; > + return CARD_NVIDIA_GEFORCE_GT325M; > } > > /* Geforce 200 - midend */ > if (strstr(gl_renderer, "GT 240")) > { > - *vidmem = 512; > return CARD_NVIDIA_GEFORCE_GT240; > } > > /* Geforce 200 lowend */ > if (strstr(gl_renderer, "GT 220")) > { > - *vidmem = 512; /* The GT 220 has 512-1024MB */ > return CARD_NVIDIA_GEFORCE_GT220; > } > /* Geforce 200 lowend (Geforce 305/310 use the same core) */ > @@ -1461,7 +1459,6 @@ static enum wined3d_pci_device select_card_nvidia_binary(const struct wined3d_gl > || strstr(gl_renderer, "Geforce 305") > || strstr(gl_renderer, "Geforce 310")) > { > - *vidmem = 512; > return CARD_NVIDIA_GEFORCE_210; > } > > Hi Roderick, you probably might fix the whitespaces for all occurrences. Cheers Rico

1 0

Does testbot's MingW miscompile winmm:midi tests?
by Joerg-Cyril.Hoehle＠t-systems.com 11 Sep '10

11 Sep '10

Hi, on test.winehq, WinME systems always report 8 rc=MMSYSERR_INVALPARAM errors. However, when running a MSVC compiled binary (as found in testbot job #4990), no such error occurs. Paul Vriens wrote: >I only see those 8 errors with the winetest executable from >test.winehq.org. My own cross-compiled version is fine, no errors there. Likewise, Octavian Voicu's machines saw no failure with the MSVC binary, but constantly produce red color on testbot. This could - Either be a bug in testbot's MingW (compilation or includes)? What's the difference between testbot compilation and Paul Vriens'? - Some weird memory corruption affecting only WinME? - a bug in my tests? Those INVALPARAM errors happen since May. However my May-19 patch did not change the tests that since fail, so it must be a side effect of something else. 1. dwBytesRecorded is left uninitialised, which may produce random results -- if it were used. 2. dwOffset is now set to 0xDEADBEEF; previously uninitialised. Yet that does not explain why MSVC's and Paul's cross compiled binary succeed. Paul and I found a bug in the mingw includes once. Perhaps that's another instance? How to proceed from here? Jörg Höhle

3 4

Re: msxml3: Implement property SelectionNamespaces for XPath (try #2)
by testbot＠testbot.winehq.org 10 Sep '10

10 Sep '10

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=5183 Your paranoid android. === W98SE (32 bit domdoc) === domdoc.c:6044: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === WNT4WSSP6 (32 bit domdoc) === domdoc.c:6044: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === W2KPROSP4 (32 bit domdoc) === domdoc.c:6044: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154

1 0

Re: [PATCH] Fixed a couple of cases where the console was not reset in cooked mode after a bare console has been created
by Juan Lang 10 Sep '10

10 Sep '10

Hi Eric, minor quibble on this patch: #ifdef HAVE_TERMIOS_H # include <termios.h> #endif +#ifdef HAVE_TERMIOS_H +#include <termios.h> +#endif This hunk isn't needed. --Juan

1 0

re: UCS-4 hack not working in resource files.
by Dan Kegel 10 Sep '10

10 Sep '10

Please file a bug with a simple example of an rc file that doesn't work.

1 0

UCS-4 hack not working in resource files.
by carlo.bramix＠libero.it 10 Sep '10

10 Sep '10

Hello friends, I would like to talk a bit about a (probable) limitation with unicode names when they are used for creating embedded controls in resource files. Let's take for example this piece of code from richedit.h: #if defined(__GNUC__) # define RICHEDIT_CLASS20W (const WCHAR []){ 'R','i','c','h','E','d','i','t','2','0','W',0 } #elif defined(_MSC_VER) # define RICHEDIT_CLASS20W L"RichEdit20W" #else static const WCHAR RICHEDIT_CLASS20W[] = { 'R','i','c','h','E','d','i','t','2','0','W',0 }; #endif Because the famous UCS-4 "issue", the control name is splitted in its single letters. While this can work in almost all situations with C/C++ sources, it is absolutely not possible to put a richedit control in RC files. For example, if I put a Richedit control into a dialog box, it will crash since the letter by letter format won't be recognized by the resource compiler. >From the above example, I was wondering what you think about doing a change like this one: #if defined _MSC_VER || defined RC_INVOKED || sizeof(wchar_t) == 2 # define RICHEDIT_CLASS20W L"RichEdit20W" #elif defined(__GNUC__) # define RICHEDIT_CLASS20W (const WCHAR []){ 'R','i','c','h','E','d','i','t','2','0','W',0 } #else static const WCHAR RICHEDIT_CLASS20W[] = { 'R','i','c','h','E','d','i','t','2','0','W',0 }; #endif We will fall in the first case when the name expressed as string is currently recognized: 1) because we are running under Microsoft Visual C++ 2) because it is used by resource compiler 3) because the string format is currently safe since we are under UCS-2 instead of UCS-4. Perhaps this point is not written as good as you want... I do not know if you prefer to use some informations emitted by configure script or you will prefer to simply check the size of wchar_t. The second case is the specific hack normally used until now with GCC. The third case is the last chance solution, as it was before. I moved the __GNUC__ case after the one used by _MSC_VER because __GNUC__ and RC_INVOKED are both declared in windres. Now I took this fragment from richedit.h as example, but perhaps I have also seen other places where the resource compiler could be "rejected". I believe that this fix actually seems to be very helpful for porting some win32 apps. What do you think? Sincerely, Carlo Bramini.

1 0

Re: fusion:asmname Improve parse_display_name
by Alexandre Julliard 10 Sep '10

10 Sep '10

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > @@ -522,8 +522,18 @@ static HRESULT parse_display_name(IAssemblyNameImpl *name, LPCWSTR szAssemblyNam > if (!str) > return E_OUTOFMEMORY; > > - ptr = strstrW(str, separator); > - if (ptr) *ptr = '\0'; > + ptr = strchrW(str, ','); > + > + if(ptr && *ptr != ' ') > + *ptr = '\0'; It's unlikely that you would get a space here... -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: user32: Update Italian translation (try 2)
by Paul Vriens 10 Sep '10

10 Sep '10

On 09/09/2010 07:52 PM, Luca Bennati wrote: > Fix for Paul's comment > Hi Luca, You forgot the patch. -- Cheers, Paul.

1 0

dogfood report: Safari runs youtube, firefox doesn't
by Dan Kegel 09 Sep '10

09 Sep '10

So I wanted to quickly try youtube in wine to verify sound was working. I think I used to use Firefox for this, so I did sh winetricks firefox flash and fired it up... but it hung. (And it even hung my desktop once; had to use CTL ALT F1, kill firefox, and ALT F7 to recover. It must have hung while holding an X grab, that mysterious problem described in http://bugs.winehq.org/show_bug.cgi?id=23439#c7 ) Sad face. Happily, sh winetricks safari got me a working browser that can do youtube just fine.

3 3

Re: winedbg: Only add ContextFlags which are defined
by Dmitry Timoshkov 09 Sep '10

09 Sep '10

André Hentschel <nerv(a)dawncrow.de> wrote: > CONTROL and INTEGER are standard defines, but ia64 and ARM don't define CONTEXT_FLOATING_POINT ia64 does define CONTEXT_FLOATING_POINT, ARM probably should also do. -- Dmitry.

2 3

Re: user32: Update Italian translation
by Paul Vriens 09 Sep '10

09 Sep '10

On 09/09/2010 04:09 PM, Luca Bennati wrote: > Hi Luca, You need to add the UTF-8 pragma: Warning: string "&Sì" seems to be UTF-8 but codepage 1252 is in use. Warning: string "&Più finestre..." seems to be UTF-8 but codepage 1252 is in use. -- Cheers, Paul.

1 0

Re: msxml3: Implement property SelectionNamespaces for XPath
by Alexandre Julliard 09 Sep '10

09 Sep '10

Adam Martinson <amartinson(a)codeweavers.com> writes: > +extern inline const struct list* nsList_from_xmlDocPtr(xmlDocPtr doc); Declaring an extern function inline doesn't make much sense. Also it would be more generally useful if it didn't return a const pointer. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [2/7] urlmon/tests: Removed no longer needed todo_wine's
by Paul Vriens 09 Sep '10

09 Sep '10

On 09/09/2010 02:46 AM, Thomas Mullaly wrote: > These todo's should have been removed as I implemented each of the > IUriBuilder_{Get/Set}* functions, but, I forgot about them. Hi Thomas, todo_wine's that succeed are marked as failures so that means these are not fixed on (at least) AJ's box as otherwise previous patches would have been rejected. Judging by the test.winehq.org results there are only todo_wine's and no failures on Wine. -- Cheers, Paul.

2 1

Re: msxml3/tests: add lastChild tests
by testbot＠testbot.winehq.org 09 Sep '10

09 Sep '10

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=5160 Your paranoid android. === W98SE (32 bit domdoc) === domdoc.c:6040: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === WNT4WSSP6 (32 bit domdoc) === domdoc.c:6040: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === W2KPROSP4 (32 bit domdoc) === domdoc.c:6040: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154

1 0

Re: d3dx9_36: Implement D3DXCreateMesh and initial ID3DXMesh methods. (try 2)
by Henri Verbeet 09 Sep '10

09 Sep '10

On 9 September 2010 02:40, Misha Koshelev <misha680(a)gmail.com> wrote: > + while (count < MAX_FVF_DECL_SIZE && (count == 0 || declaration[count-1].Stream != 0xFF)) > + { > + count++; > + } > + if (count > 1) > + { > + vertex_size = declaration[count-2].Offset + d3dx_decltype_size[declaration[count-2].Type]; > + } You may want to consider using D3DXGetDeclVertexSize() there.

1 0

Re: dlls/rstrtmgr: add stubs for RmGetList and RmRegisterResources
by Paul Vriens 09 Sep '10

09 Sep '10

On 09/09/2010 07:41 AM, Austin English wrote: > +@ stdcall RmGetList(long ptr ptr ptr) Hi Austin, This function has 5 parameters. -- Cheers, Paul.

1 0

Re: msxml3: Implement property SelectionNamespaces for XPath
by testbot＠testbot.winehq.org 09 Sep '10

09 Sep '10

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=5150 Your paranoid android. === W98SE (32 bit domdoc) === domdoc.c:6002: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === WNT4WSSP6 (32 bit domdoc) === domdoc.c:6002: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === W2KPROSP4 (32 bit domdoc) === domdoc.c:6002: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154

1 0

Re: shdocvw: Fixed tests on IE <6.
by testbot＠testbot.winehq.org 09 Sep '10

09 Sep '10

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=5149 Your paranoid android. === WVISTAADM (32 bit webbrowser) === webbrowser.c:1210: Test failed: unexpected call UpdateUI webbrowser.c:289: Test failed: unexpected nsCmdID 21 webbrowser.c:233: Test failed: unexpected call QueryStatus_STOP

1 0

Re: [try 2] [1/3] dsound: Add support for 32-bit IEEE float buffers
by Chris Robinson 08 Sep '10

08 Sep '10

On Wednesday, September 08, 2010 11:02:27 am Owen Rudge wrote: > + *(BYTE *) dst = (clamp(le32(*(const float *)src), -1, 1)) * 127 + > 0.5; Is it safe to call le32 on a float? Especially one that's going to be used more? If the system is big-endian, the float/integer will need to be in big- endian to be processed. I'm also not sure that the conversion math is correct. In this case, -1.0 would get converted to -126.5 (or -32766.5, etc), instead of -128 (or -32768, etc). As well, I don't think the rules for converting a negative float value to an unsigned integer are that straight forward. I seem to recall mention that some systems will actually give 0 in that case. You may have to go the long way and do something like: float v = *(const float*)src; if(v < -1.0f) *(__int8*)dst = -128; if(v < 0.0f) *(__int8*)dst = v*128.0f; if(v > 1.0f) *(__int8*)dst = 127; if(v >= 0.0f) *(__int8*)dst = v*127.0f; ..and similarly for 16/24/32 bit.

2 1

Mistake in : msxml3: Don't use xmlnode's IXMLDOMNode iface in get_[first|last]Node implementations.
by Joris Huizer 08 Sep '10

08 Sep '10

Hello, I noticed some copy/paste mistake in this patch; A number of functions for *get_lastChild now call node_get_first_child. HTH, Joris

2 1

daily wine clang tests
by Austin English 08 Sep '10

08 Sep '10

Howdy all, I've added a daily test of wine/winetest compiled using clang (tag wine_ae-ub1004-clang). I fixed the first bug it found (http://source.winehq.org/git/wine.git/?a=commitdiff;h=7f30ae6349e01095823e6…), but there are a few more failures that look interesting (interesting = crashes with clang, but not gcc): http://test.winehq.org/data/ec382f43452890354b9edd30ecb7d293045bb8c2/wine_a… http://test.winehq.org/data/ec382f43452890354b9edd30ecb7d293045bb8c2/wine_a… http://test.winehq.org/data/ec382f43452890354b9edd30ecb7d293045bb8c2/wine_a… http://test.winehq.org/data/ec382f43452890354b9edd30ecb7d293045bb8c2/wine_a… http://test.winehq.org/data/ec382f43452890354b9edd30ecb7d293045bb8c2/wine_a… http://test.winehq.org/data/ec382f43452890354b9edd30ecb7d293045bb8c2/wine_a… msi in particular doesn't seem to like clang. Anywho, if you want traces/patches tested, drop me a line. Cheers! -- -Austin

1 0

Re: [1/3] msi: Set more 64-bit properties.
by Alexandre Julliard 08 Sep '10

08 Sep '10

Hans Leidekker <hans(a)codeweavers.com> writes: > --- > dlls/msi/package.c | 43 ++++++++++++++++++++++++++++++++----------- > 1 files changed, 32 insertions(+), 11 deletions(-) This breaks the tests on 64-bit: ../../../../wine/tools/runtest -q -P wine -M msi.dll -T ../../.. -p msi_test.exe.so ../../../../wine/dlls/msi/tests/automation.c && touch automation.ok automation.c:2505: Test failed: File not installed automation.c:2506: Test failed: File not installed automation.c:2507: Test failed: File not installed automation.c:2508: Test failed: File not installed automation.c:2509: Test failed: File not installed automation.c:2510: Test failed: File not installed automation.c:2511: Test failed: File not installed automation.c:2512: Test failed: File not installed automation.c:2513: Test failed: File not installed automation.c:2514: Test failed: File not installed automation.c:2515: Test failed: File not installed make: *** [automation.ok] Error 11 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: user32: Right text placement (Bugfix for #22109)
by Alexandre Julliard 08 Sep '10

08 Sep '10

Wolfgang Schwotzer <wolfgang.schwotzer(a)gmx.net> writes: > Much thanks to Konstantin Kondratyuk. He is the brain behind this bugfix. > > --- a/dlls/user32/text.c 2010-06-01 18:14:04.000000000 +0200 > +++ b/dlls/user32/text.c 2010-06-01 18:15:37.000000000 +0200 > @@ -954,8 +954,12 @@ > > if (flags & DT_SINGLELINE) > { > - if (flags & DT_VCENTER) y = rect->top + > - (rect->bottom - rect->top) / 2 - size.cy / 2; > + if (flags & DT_VCENTER) > + { > + int sign = 1; > + if (rect->top < 0 && rect->bottom < 0) sign = -1; > + y = rect->top + (rect->bottom - rect->top) / 2 - sign * size.cy / 2; This doesn't make sense, the sign should depend on the viewport mappings, not on the position being negative. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: usp10: we are unable to shape non TMPF_TRUETYPE fonts
by Alexandre Julliard 08 Sep '10

08 Sep '10

Aric Stewart <aric(a)codeweavers.com> writes: > So return a proper error instead of generating unexpected garbage > --- > dlls/usp10/usp10.c | 5 ++++- > 1 files changed, 4 insertions(+), 1 deletions(-) It fails the tests: ../../../tools/runtest -q -P wine -M usp10.dll -T ../../.. -p usp10_test.exe.so usp10.c && touch usp10.ok usp10.c:907: Test failed: ScriptShape should return 0 not (80040200) make[1]: *** [usp10.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: dnsapi: Remove the critical section around res_query on Linux.
by Alexandre Julliard 08 Sep '10

08 Sep '10

Hans Leidekker <hans(a)codeweavers.com> writes: > glibc's resolver supports threads since 2.3.2, released in 2003. > Fixes http://bugs.winehq.org/show_bug.cgi?id=24180 It seems to me this would affect all platforms. Why fix it only for Linux? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [2/3] msi/test: Test more combinations of platforms and installer properties.
by testbot＠testbot.winehq.org 08 Sep '10

08 Sep '10

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=5136 Your paranoid android. === W7PROX64 (64 bit package) === package.c:8393: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8404: Test failed: Expected "C:\winetest\", got "" package.c:8415: Test failed: Expected "C:\winetest\", got "" package.c:8465: Test failed: Expected "C:\winetest\FileName3.dll", got "" package.c:8476: Test failed: Expected "C:\winetest\FileName5.dll", got "" package.c:8485: Test failed: Expected "C:\", got "" package.c:8491: Test failed: Expected "C:\winetest\", got "" package.c:8512: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8521: Test failed: Expected "C:\winetest\FileName1", got ""

1 0

Re: [PATCH 2/5] d3d8.h: undefine INTERFACE before defining it
by Alexandre Julliard 08 Sep '10

08 Sep '10

Roderick Colenbrander <thunderbird2k(a)gmail.com> writes: > @@ -129,6 +129,7 @@ typedef struct IDirect3DVolumeTexture8 *LPDIRECT3DVOLUMETEXTURE8, *PDIRECT3DVOLU > /***************************************************************************** > * IDirect3D8 interface > */ > +#undef INTERFACE > #define INTERFACE IDirect3D8 > DECLARE_INTERFACE_(IDirect3D8,IUnknown) > { The standard pattern is that it's undefined right after being used. Places that don't do that should be fixed. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: Ongoing Debian package maintenance.
by Ben Klein 08 Sep '10

08 Sep '10

Sorry, Octavian, for sending this only to you. On 8 September 2010 06:00, Octavian Voicu <octavian.voicu(a)gmail.com> wrote: > On Tue, Sep 7, 2010 at 9:42 PM, Lei Zhang <thestig(a)google.com> wrote: >> >> It would be helpful if you provide the content of your debian/ >> directory. Mainly you want my control and rules files. I'll get these to you soon :) >> I wrote my own debian/control file and what not and built a >> wine-gecko-1.1.0 .deb over the weekend. I haven't finished working on >> the main Wine packages, but I'll take a look at your suggestions and >> reconsider how to structure the packages. As much as the final structure for the new packages is up to the official maintainer, I'm very interested in that decision and the reasoning behind it. Keep me posted! > It would be cool to also have wine1.3-64, wine1.3-gecko64 for amd64 builds, > besides the standard wine1.3, wine1.3-gecko :) 1) I do not like those package names at all. It should be the Debian-style names, wine-unstable/wine64-unstable. 2) Wine Gecko has its own versions. I had previously built a package called wine-gecko-1.0, IIRC. This naming convention should be continued, IMO, as different Gecko versions could be required at different points for wine (stable) and wine-unstable versions. Package names should be uniform and I suggest they should look like this: wine[64][-unstable][-<module>] where <module> is one of: * dbg * dev * gecko etc. > Octavian >

1 0

Re: [PATCH 2/9] CMD : Correct support for cmd.exe /C string [try 2]
by Alexandre Julliard 08 Sep '10

08 Sep '10

Jason Edmeades <jason.edmeades(a)googlemail.com> writes: > Note1: Tested manually on windows with procmon, windows does indeed do > the same as this patch, ie a double path/pathext search. You can't look at the internal behavior of the tool you are implementing, it needs to be treated as a black box. I'm afraid I can't accept that code. -- Alexandre Julliard julliard(a)winehq.org

1 0

Importing strchrnul() from gnulib?
by Wolfram Sang 08 Sep '10

08 Sep '10

Hi, taking another approach at Bug 19070, I noticed that dlls/hhctrl.ocx/hhctrl.c has even more problems with commandline-handling. All three invocations of strchr() should better be strchrnul(). (Compare calling hh.exe with '-mapid' and '-mapid ' to see one difference). strchrnul ist protected by _GNU_SOURCE, though. Because I could imagine there are more places throughout the source needing a fix like this, I think about importing strchrnul() directly from gnulib into libs/wine/string.c (most appropriate place I could find). The function is LGPLv2+, of course. Objections? Regards, Wolfram

2 1

Re: [PATCH 2/2] d3dx9: Implement D3DXCreateMesh and initial ID3DXMesh methods.
by Henri Verbeet 08 Sep '10

08 Sep '10

You have leaks in your error paths. On 8 September 2010 02:33, Misha Koshelev <misha680(a)gmail.com> wrote: > + /* Create vertex buffer */ > + hr = IDirect3DDevice9_CreateVertexBuffer(device, > + numvertices * sizeof(D3DXVECTOR3) * 2, > + 0, /* Usage */ > + fvf, > + D3DPOOL_MANAGED, > + &vertex_buffer, > + NULL); Tests for that would be nice. E.g., I don't believe for a second the buffer length is really calculated that way, and does it really create an FVF vertex buffer?

1 0

Re: [3/3] msi/tests: Fix some test failures on 64-bit.
by testbot＠testbot.winehq.org 08 Sep '10

08 Sep '10

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=5126 Your paranoid android. === W7PROX64 (64 bit package) === package.c:8361: 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\"

1 0

Re: [PATCH 4/5] ddraw: Remove some stray tabs.
by testbot＠testbot.winehq.org 08 Sep '10

08 Sep '10

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=5122 Your paranoid android. === W98SE (32 bit dsurface) === No test summary line found

2 1

mshtml: Correct test for unknown dispID
by Alistair Leslie-Hughes 08 Sep '10

08 Sep '10

Changelog: mshtml: Correct test for unknown dispID Best Regards Alistair Leslie-Hughes

1 0

Re: [PATCH 5/5] Add some more schannel tests
by testbot＠testbot.winehq.org 07 Sep '10

07 Sep '10

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=5096 Your paranoid android. === W98SE (32 bit schannel) === Failure running script in VM: Exceeded timeout limit of 315 sec === WNT4WSSP6 (32 bit schannel) === Timeout === W2KPROSP4 (32 bit schannel) === Timeout

1 0

Re: [PATCH] Add some more schannel tests
by testbot＠testbot.winehq.org 07 Sep '10

07 Sep '10

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=5095 Your paranoid android. === WNT4WSSP6 (32 bit schannel) === No test summary line found

1 0

Re: [PATCH] Add some more schannel tests
by testbot＠testbot.winehq.org 07 Sep '10

07 Sep '10

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=5092 Your paranoid android. === WNT4WSSP6 (32 bit schannel) === No test summary line found

1 0

Re: kernel32/tests: typo fixes
by Nicolas Le Cam 07 Sep '10

07 Sep '10

2010/9/7 Austin English <austinenglish(a)gmail.com> > I initially noticed the wrong hemisphere label, but then the > capitalization was bugging me :-) > > -- > -Austin Hi Austin, @@ -449,18 +449,18 @@ static void test_TzSpecificLocalTimeToSystemTime(void) > tzW.DaylightBias=-60; > tzW.StandardDate.wMonth=10; > tzW.StandardDate.wDayOfWeek=0; /*sunday */ > > You missed that one! -- Nicolas Le Cam

1 0

Re: [PATCH] Fill a SECBUFFER_MISSING buffer if the message is not complete
by Hans Leidekker 07 Sep '10

07 Sep '10

Hi Mikko, > diff --git a/dlls/secur32/schannel.c b/dlls/secur32/schannel.c > index 78757ac..192f9cb 100644 > --- a/dlls/secur32/schannel.c > +++ b/dlls/secur32/schannel.c > @@ -1244,6 +1244,15 @@ static SECURITY_STATUS SEC_ENTRY schan_DecryptMessage(PCtxtHandle context_handle > if(buffer->cbBuffer < expected_size) > { > TRACE("Expected %u bytes, but buffer only contains %u bytes\n", expected_size, buffer->cbBuffer); > + buffer->BufferType = SECBUFFER_MISSING; > + buffer->cbBuffer = expected_size - buffer->cbBuffer; > + > + // This is a bit weird, but windows does it too > + idx = schan_find_sec_buffer_idx(message, 0, SECBUFFER_EMPTY); > + buffer = &message->pBuffers[idx]; > + buffer->BufferType = SECBUFFER_MISSING; > + buffer->cbBuffer = expected_size - buffer->cbBuffer; > + > TRACE("Returning SEC_E_INCOMPLETE_MESSAGE\n"); > return SEC_E_INCOMPLETE_MESSAGE; > } You should resend this with the patches it depends on and give the patches a sequence number.

2 1

Re: [PATCH] Add some more schannel tests
by Hans Leidekker 07 Sep '10

07 Sep '10

> @@ -116,6 +128,10 @@ static void InitFunctionPtrs(void) > if(!secdll) > secdll = LoadLibraryA("security.dll"); > advapi32dll = GetModuleHandleA("advapi32.dll"); > + wsockdll = LoadLibraryA("ws2_32.dll"); > + > + if(!wsockdll) > + printf("Couldn't open ws2_32.dll\n"); > Why are you loading ws2_32 dynamically? > + desc->pBuffers[0].cbBuffer = size; > + desc->pBuffers[0].pvBuffer = malloc(size); Use HeapAlloc/Free instead of malloc/free. > +static int receive_data(SOCKET sock, SecBuffer *buf) > +{ > + unsigned received = 0; > + > + while(1) > + { > + unsigned char *data = buf->pvBuffer; > + unsigned expected = 0; > + int ret; Please stick to 4 space indentation like the rest of the file. > + addr.sin_family = AF_INET; > + addr.sin_addr.s_addr = htonl(0xD1558712); > + addr.sin_port = htons(443); > + ret = pconnect(sock, (struct sockaddr *)&addr, sizeof(struct sockaddr_in)); > + if(ret==SOCKET_ERROR) > + { > + skip("Can't connect to mail.google.com\n"); > + return; > + } You should properly resolve mail.google.com.

2 1

Re: [PATCH] Fill a SECBUFFER_MISSING buffer if the message is not complete
by Juan Lang 07 Sep '10

07 Sep '10

Hi Mikko, + // This is a bit weird, but windows does it too You can't use C++-style comments in Wine. You do the same in your tests patch, too. --Juan

2 1

specfiles containing 'str' instead of 'wstr' for some W-functions
by Paul Vriens 07 Sep '10

07 Sep '10

Hi, I see some specfiles that contain 'str' instead of the correct 'wstr'. Is it worth sending a patch to fix these? If so, only one? -- Cheers, Paul.

1 0

Re: [PATCH] Fill a SECBUFFER_MISSING buffer if the message is not complete
by Austin English 07 Sep '10

07 Sep '10

On Tue, Sep 7, 2010 at 10:44 AM, Mikko Rasa <tdb(a)tdb.fi> wrote: > --- > dlls/secur32/schannel.c | 9 +++++++++ > 1 files changed, 9 insertions(+), 0 deletions(-) Howdy Mikko, > diff --git a/dlls/secur32/schannel.c b/dlls/secur32/schannel.c > index 78757ac..192f9cb 100644 > --- a/dlls/secur32/schannel.c > +++ b/dlls/secur32/schannel.c > @@ -1244,6 +1244,15 @@ static SECURITY_STATUS SEC_ENTRY schan_DecryptMessage(PCtxtHandle context_handle > if(buffer->cbBuffer < expected_size) > { > TRACE("Expected %u bytes, but buffer only contains %u bytes\n", expected_size, buffer->cbBuffer); > + buffer->BufferType = SECBUFFER_MISSING; > + buffer->cbBuffer = expected_size - buffer->cbBuffer; > + > + // This is a bit weird, but windows does it too I can't comment on the rest of the patch, but please use C89 /* comments */, not C99 (//). -- -Austin

1 0

Re: ntdll: Don't cancel loading on IMAGE_FILE_RELOCS_STRIPPED
by Greg Geldorp 07 Sep '10

07 Sep '10

> From: Paul Chitescu <paulc(a)voip.null.ro> > > In a typical Win32 environment the executables don't have relocations since > they load at a fixed address. Old (Visual C 4.x and older) executables had > relocations so they could run on Win32s. Not all that relevant to the patch, but... Newer executables do tend to have relocations. This allows ASLR (Address Space Layout Randomization) on Vista and higher to work. Ge.

1 0

Re: Wine Introduction Page
by James Mckenzie 07 Sep '10

07 Sep '10

Ken Thomases <ken(a)codeweavers.com> wrote: >Sent: Sep 7, 2010 9:17 AM >To: James McKenzie <jjmckenzie51(a)earthlink.net> >Cc: "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> >Subject: Re: Wine Introduction Page > >On Sep 4, 2010, at 2:20 PM, James McKenzie wrote: > >> I know it is in git. I don't want to give out bogus information, that's why the question. I don't have an Intel system >>here with MacOSX 10.4 installed anymore, all of mine are at 10.6.4 >> >> Same thing with XCode. I know that the 2.x is at 2.5 but can Wine still be built with 2.4? I don't have the resources >>available to test. > >It still builds on Tiger, although maintaining that may become problematic over time. > >I don't know about Xcode 2.4, but I'm not aware of any breaking changes between 2.4 and 2.5. I expect it still builds >with 2.4 if that's what a user has. > Thank you. No update necessary for this information then. James McKenzie

1 0

[Fwd: Re: Wine Introduction Page]
by James McKenzie 07 Sep '10

07 Sep '10

To the list as well. Can we fix this so that replies go to the list rather than the sender? James McKenzie -------- Original Message -------- Subject: Re: Wine Introduction Page Date: Sat, 04 Sep 2010 12:18:42 -0700 From: James McKenzie <jjmckenzie51(a)earthlink.net> To: Roderick Colenbrander <thunderbird2k(a)gmail.com> References: <4C8286F5.7090207(a)earthlink.net> <AANLkTikVVEyKVSMb17NePtBvW+pHC3tsmvuYYvF_HVWr(a)mail.gmail.com> Roderick Colenbrander wrote: > On Sat, Sep 4, 2010 at 7:50 PM, James McKenzie > <jjmckenzie51(a)earthlink.net> wrote: > >> I was just going over this page and found a few things that I don't know >> about but have questions on for building Wine on the Mac: >> >> The lowest MacOSX version that Wine will build on from the native package is >> stated to be 10.4 (Tiger). Is this still true? >> >> The lowest XCode required is 2.4. Apple stopped supporting this a long time >> ago. I had XCode 2.5 for Tiger. >> >> Can anyone update these? >> >> James McKenzie >> >> >> >> >> > > The website is in git, so feel free to submit patches ;) > I know it is in git. I don't want to give out bogus information, that's why the question. I don't have an Intel system here with MacOSX 10.4 installed anymore, all of mine are at 10.6.4 Same thing with XCode. I know that the 2.x is at 2.5 but can Wine still be built with 2.4? I don't have the resources available to test. James McKenzie

2 1

Re: ntdll: Don't cancel loading on IMAGE_FILE_RELOCS_STRIPPED
by Marcus Meissner 07 Sep '10

07 Sep '10

On Tue, Sep 07, 2010 at 04:37:49PM +0200, André Hentschel wrote: > give the file a try when it only links to ordinals instead of just stopping execution here. > --- > dlls/ntdll/virtual.c | 4 ---- > 1 files changed, 0 insertions(+), 4 deletions(-) > > diff --git a/dlls/ntdll/virtual.c b/dlls/ntdll/virtual.c > index a42ed5f..0bd3023 100644 > --- a/dlls/ntdll/virtual.c > +++ b/dlls/ntdll/virtual.c > @@ -1232,12 +1232,8 @@ static NTSTATUS map_image( HANDLE hmapping, int fd, char *base, SIZE_T total_siz > const IMAGE_DATA_DIRECTORY *relocs; > > if (nt->FileHeader.Characteristics & IMAGE_FILE_RELOCS_STRIPPED) > - { > WARN_(module)( "Need to relocate module from %p to %p, but there are no relocation records\n", > base, ptr ); > - status = STATUS_CONFLICTING_ADDRESSES; > - goto error; > - } > > TRACE_(module)( "relocating from %p-%p to %p-%p\n", > base, base + total_size, ptr, ptr + total_size ); Have you seen a program needing this? Which? "links to ordinals" is also a wrong comment, as RELOCS are used for relocation addresses within the binary itself (not imports). Ciao, Marcus

3 2

Must copy static const D3DVERTEXELEMENT9 into dynamically alllocated D3DVERTEXELEMENT9 * before pointer passed correctly in Wine?
by misha680 07 Sep '10

07 Sep '10

Sorry for reposting - apparently my original nabble link did not work :( --- Dear All: Sorry to bother... I am working on a D3DXCreateMesh/ID3DXMesh patch, and I encountered a very strange error. Specifically, it seems that when passing a LPD3DVERTEXELEMENT9 * parameter to D3DXCreateMesh, a) in Windows - one can create static const D3DVERTEXELEMENT9 decl1[3] = { {0, 0, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_POSITION, 0}, {0, 0xC, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_NORMAL, 0}, D3DDECL_END(), }; and pass (LPD3DVERTEXELEMENT9 *)&decl1 directly. b) in Wine tests - I must first allocate a D3DVERTELEMENT9 *, then call HeapAlloc, and finally copy my original decl1 and pass &decl (pointer to newly allocated structure) for it to work. Any ideas? Here is my git diff http://wine.1045685.n5.nabble.com/file/n2805603/patch patch Thx Misha -- View this message in context: http://wine.1045685.n5.nabble.com/Must-copy-static-const-D3DVERTEXELEMENT9-… Sent from the Wine - Devel mailing list archive at Nabble.com.

4 4

Re: msi/tests: Fix compilation on systems that don't support nameless unions or structs.
by testbot＠testbot.winehq.org 07 Sep '10

07 Sep '10

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=5078 Your paranoid android. === W7PROX64 (64 bit package) === package.c:8387: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8398: Test failed: Expected "C:\winetest\", got "" package.c:8409: Test failed: Expected "C:\winetest\", got "" package.c:8459: Test failed: Expected "C:\winetest\FileName3.dll", got "" package.c:8470: Test failed: Expected "C:\winetest\FileName5.dll", got "" package.c:8479: Test failed: Expected "C:\", got "" package.c:8485: Test failed: Expected "C:\winetest\", got "" package.c:8506: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8515: Test failed: Expected "C:\winetest\FileName1", got ""

1 0

Re: [PATCH 2/6] gameux: initial implementation of IGameExplorer::AddGame
by Nikolay Sivov 07 Sep '10

07 Sep '10

On 9/3/2010 13:25, Mariusz Pluciński wrote: > --- > dlls/gameux/Makefile.in | 2 +- > dlls/gameux/gameexplorer.c | 254 > +++++++++++++++++++++++++++++++++++++- > dlls/gameux/gameux_private.h | 63 ++++++++++ > dlls/gameux/tests/gameexplorer.c | 18 ++-- > 4 files changed, 322 insertions(+), 15 deletions(-) > +/******************************************************************************* > + * _initGameData > + * > + * Internal helper function. Description available in gameux_private.h file > + */ > +void _initGameData(struct GAME_DATA *GameData) > +{ > + GameData->sGDFBinaryPath = NULL; > + GameData->sGameInstallDirectory = NULL; > +} Do you really need another helper for that? Please use better naming like GAMEUX_* for example. > +void _uninitGameData(struct GAME_DATA *GameData) > +{ > + CoTaskMemFree(GameData->sGDFBinaryPath); > + CoTaskMemFree(GameData->sGameInstallDirectory); > +} Any specific reason you need CoTaskMem* here and not a process heap? > + WCHAR sInstanceId[40]; > + WCHAR sRegistryPath[8192]; Where does this come from? Sizes I mean.

2 2

Re: kernel32: forward GetThreadUILanguage() to GetUserDefaultUILanguage() (try 2)
by Alexandre Julliard 07 Sep '10

07 Sep '10

Austin English <austinenglish(a)gmail.com> writes: > @@ -658,6 +658,7 @@ > @ stdcall GetTimeFormatA(long long ptr str ptr long) > @ stdcall GetTimeFormatW(long long ptr wstr ptr long) > @ stdcall GetTimeZoneInformation(ptr) > +@ stdcall GetThreadUILanguage() GetUserDefaultUILanguage You can't do that, the functions are not identical. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 3/6] gameux: add support of loading Application Id into registry
by Nikolay Sivov 07 Sep '10

07 Sep '10

On 9/3/2010 13:25, Mariusz Pluciński wrote: > +static HRESULT _ParseGameDefinition( > + IXMLDOMElement *lpXMLGameDefinitionElement, > + struct GAME_DATA *GameData) > +{ > + static const WCHAR sGameId[] = {'g','a','m','e','I','D',0}; > + > + HRESULT hr = S_OK; > + BSTR bstrAttribute = NULL; > + VARIANT variant; No need for initializers here. > + hr = IXMLDOMElement_getAttribute(lpXMLGameDefinitionElement, bstrAttribute,&variant); > + if(hr != S_OK || V_VT(&variant) != VT_BSTR) hr = E_FAIL; No need to test for hr != S_OK and alter failure code after that I guess. > + /* load MSXML parser */ > + hr = CoCreateInstance(&CLSID_DOMDocument30, NULL, CLSCTX_INPROC_SERVER, > +&IID_IXMLDOMDocument, (LPVOID*)&lpXMLDocument); Use neutral CLSID_DOMDocument. Minor things - useless comment, and LPVOID* -> void**. > + IXMLDOMDocument *lpXMLDocument = NULL; > + IXMLDOMNode *lpXMLGameDefinitionNode = NULL; > + IXMLDOMElement *lpXMLRootElement = NULL, *lpXMLGameDefinitionElement = NULL; Same here, you don't need to initialize that. Please use shorter names, like 'root', 'document' or something. > + hr = IXMLDOMDocument_get_documentElement(lpXMLDocument,&lpXMLRootElement); > + if(hr == S_FALSE) > + hr = E_FAIL; hr != S_OK works. P.S. it makes sense to test xml parsing part with native msxml first. This will hopefully show some problems with builtin msxml.

2 1

Typo in : wined3d: Translate before scaling for rhw as well in transform_projection().
by Joris Huizer 07 Sep '10

07 Sep '10

While skimming through recently committed patches, I noticed this piece: + /* Window Coord 0 is the middle of the first pixel, so translate by 1/2 pixels */ + glTranslatef(63.0f / 128.0f, 63.0f / 128.0f, 0.0f); + checkGLcall("glTranslatef(63.0f / 128.0f, -63.0f / 128.0f, 0.0f)"); In the checkGLcall you changed the sign of the second parameter, but you didn't do this in the glTranslatef call. This seemed a bit strange (and I don't know which one would be right). HTH, Joris

2 1

Using the eventlog API for Wine errors
by Paul Vriens 07 Sep '10

07 Sep '10

Hi, I was just reading the emails about the winediag stuff and more particularly AJ's remark about the 'hypothetical GUI'. Would it make sense to really start fleshing out the eventlog API so we can/could log errors (or whatever) in that way? The GUI (or commandline app) could then 'easily' connect to the appropriate eventlog(s). The benefit is that it will make sure the eventlog API is actually implemented and the GUI could tap into historical (until .wine is cleaned) information as well. -- Cheers, Paul.

1 0

Re: [PATCH 2/5] winex11.drv: Complain a bit about missing s3tc support.
by Alexandre Julliard 07 Sep '10

07 Sep '10

Henri Verbeet <hverbeet(a)codeweavers.com> writes: > Note that personally I don't think it's appropriate for "winediag" to abuse > the __WINE_DBCL_ERR debug class for diagnostic messages. Nothing says that winediag messages have to be ERR. If it's not an important failure that all users have to see, it can be a WARN or a TRACE. The hypothetical diagnostic GUI tool can then display those differently. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: oleaut32: Handle TKIND_COCLASS subtype for VT_PTR/VT_USERDEFINED.
by Vincent Povirk 07 Sep '10

07 Sep '10

+ // Use IID of the coclass' default interface Don't use C++ comments. On Mon, Sep 6, 2010 at 10:31 AM, Jan Ohlsen <jan.t.ohlsen(a)gmail.com> wrote: > > --- > dlls/oleaut32/tmarshal.c | 69 > ++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 69 insertions(+), 0 deletions(-) > > > > >

3 2

Must copy static const D3DVERTEXELEMENT9 into dynamically alllocated D3DVERTEXELEMENT9 * before pointer passed correctly in Wine?
by misha680 07 Sep '10

07 Sep '10

Dear All: Sorry to bother... I am working on a D3DXCreateMesh/ID3DXMesh patch, and I encountered a very strange error. Specifically, it seems that when passing a LPD3DVERTEXELEMENT9 * parameter to D3DXCreateMesh, a) in Windows - one can create static const D3DVERTEXELEMENT9 decl1[3] = { {0, 0, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_POSITION, 0}, {0, 0xC, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_NORMAL, 0}, D3DDECL_END(), }; and pass (LPD3DVERTEXELEMENT9 *)&decl1 directly. b) in Wine tests - I must first allocate a D3DVERTELEMENT9 *, then call HeapAlloc, and finally copy my original decl1 and pass &decl (pointer to newly allocated structure) for it to work. Any ideas? Here is my git diff http://wine.1045685.n5.nabble.com/file/n2805542/patch patch Thx Misha -- View this message in context: http://wine.1045685.n5.nabble.com/Must-copy-static-const-D3DVERTEXELEMENT9-… Sent from the Wine - Devel mailing list archive at Nabble.com.

2 1

Wine & .NET app
by Vassilis Virvilis 07 Sep '10

07 Sep '10

Hi everybody, My name is Vassilis Virvilis and I am trying to get .net app to run under wine. The objective of the questions below is to determine what needs to be implemented in wine in order to support the app. So the app bring its window momentarily and then it crashes with a 'Unsupported color conversion request' How difficult to implement are the following error messages? 1) Where is the code that prints 'Unsupported color conversion request'. I can't find it 2) JpegDecoder_Frame_GetResolution doesn't look terribly difficult to implement. Am I completely misguided? 3) URL_ParseUrl lives in in dlls/shwapi/url.c around 1979. The implementation looks fleshed enough. What is the problem? 4) The GUID are referring to IManaged, IProvideClassInfo, IMarshal, IRpcOptions. What is the implementation scope of these? Here is the log: fixme:actctx:parse_manifest_buffer root element is L"asmv1:assembly", not <assembly> fixme:sync:CreateMemoryResourceNotification (0) stub fixme:shell:URL_ParseUrl failed to parse L"Microsoft.VisualBasic" fixme:shell:URL_ParseUrl failed to parse L"System" fixme:shell:URL_ParseUrl failed to parse L"System.Windows.Forms" fixme:shell:URL_ParseUrl failed to parse L"System.Drawing" fixme:shell:URL_ParseUrl failed to parse L"System.Runtime.Remoting" fixme:shell:URL_ParseUrl failed to parse L"System.Configuration" fixme:shell:URL_ParseUrl failed to parse L"System.Xml" fixme:shell:URL_ParseUrl failed to parse L"mscorlib.resources" fixme:shell:URL_ParseUrl failed to parse L"mscorlib.resources" fixme:shell:URL_ParseUrl failed to parse L"System.Drawing.resources" fixme:shell:URL_ParseUrl failed to parse L"System.Drawing.resources" fixme:gdiplus:GdipGetFamilyName No support for handling of multiple languages! fixme:shell:URL_ParseUrl failed to parse L"LMA.resources" fixme:shell:URL_ParseUrl failed to parse L"LMA.resources" fixme:shell:URL_ParseUrl failed to parse L"LMA.resources" fixme:gdiplus:GdipCreateHalftonePalette stub fixme:shell:URL_ParseUrl failed to parse L"System.Xml.XmlSerializers" fixme:shell:URL_ParseUrl failed to parse L"LMA.resources" fixme:wincodecs:JpegDecoder_Frame_GetResolution (0x16d2dc,0x32dd48,0x32dd40): stub fixme:shell:URL_ParseUrl failed to parse L"LMA.resources" fixme:ole:OLEPictureImpl_QueryInterface () : asking for un supported interface {c3fcc19e-a970-11d2-8b5a-00a0c9b7c9c4} fixme:ole:OLEPictureImpl_QueryInterface () : asking for un supported interface {b196b283-bab4-101a-b69c-00aa00341d07} fixme:ole:OLEPictureImpl_QueryInterface () : asking for un supported interface {00000003-0000-0000-c000-000000000046} fixme:ole:OLEPictureImpl_QueryInterface () : asking for un supported interface {00000144-0000-0000-c000-000000000046} fixme:wincodecs:JpegDecoder_Frame_GetResolution (0x1a9924,0x32de38,0x32de30): stub Unsupported color conversion request Thanks in advance Vassilis Virvilis

4 6

d3dx9: D3DXCreateEffectxx
by Luis Busquets 07 Sep '10

07 Sep '10

Please note that the current implementation of the functions D3DXCreateEffectFromFileExW, D3DXCreateEffectFromFileExA, D3DXCreateEffectFromResourceExW, D3DXCreateEffectFromResourceExA returns D3DERR_INVALIDCALL if defines are NULL. Actually, defines is an optional parameter and can indeed be NULL and return D3D_OK if everything else is correct. I guess that that is the same for D3DXCreateEffectCompilerFromFileA, D3DXCreateEffectCompilerFromFileW

1 0

Re: winebuild: Don't segfault when running without arguments
by Dmitry Timoshkov 07 Sep '10

07 Sep '10

André Hentschel <nerv(a)dawncrow.de> wrote: > - if (!spec->dll_name) /* set default name from file name */ > + if (!spec->dll_name && spec->dll_name) /* set default name from file name */ > { > char *p; > spec->dll_name = xstrdup( spec->file_name ); Did you intend to check for spec->file_name? -- Dmitry.

1 0

Re: [6/6] urlmon: Implemented IUriBuilder_{Get/Set}UserName
by testbot＠testbot.winehq.org 07 Sep '10

07 Sep '10

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=5069 Your paranoid android. === WXPPROSP3 (32 bit uri) === uri.c:5204: Test failed: Expected http://gov.uk/ but got L"http://@gov.uk/" on uri_tests[135].str_props[0]. uri.c:5204: Test failed: Expected http://gov.uk/ but got L"http://:@gov.uk/" on uri_tests[136].str_props[0]. uri.c:5381: Test failed: Error: Expected http://gov.uk/ but got L"http://@gov.uk/" on uri_tests[135]. uri.c:5381: Test failed: Error: Expected http://gov.uk/ but got L"http://:@gov.uk/" on uri_tests[136]. uri.c:5880: Test failed: Error: Expected a length of 14 but got 15 on uri_tests[135].str_props[0]. uri.c:5880: Test failed: Error: Expected a length of 14 but got 16 on uri_tests[136].str_props[0]. === WVISTAADM (32 bit uri) === uri.c:5204: Test failed: Expected http://gov.uk/ but got L"http://@gov.uk/" on uri_tests[135].str_props[0]. uri.c:5204: Test failed: Expected http://gov.uk/ but got L"http://:@gov.uk/" on uri_tests[136].str_props[0]. uri.c:5381: Test failed: Error: Expected http://gov.uk/ but got L"http://@gov.uk/" on uri_tests[135]. uri.c:5381: Test failed: Error: Expected http://gov.uk/ but got L"http://:@gov.uk/" on uri_tests[136]. uri.c:5880: Test failed: Error: Expected a length of 14 but got 15 on uri_tests[135].str_props[0]. uri.c:5880: Test failed: Error: Expected a length of 14 but got 16 on uri_tests[136].str_props[0]. === W2K8SE (32 bit uri) === uri.c:5204: Test failed: Expected http://gov.uk/ but got L"http://@gov.uk/" on uri_tests[135].str_props[0]. uri.c:5204: Test failed: Expected http://gov.uk/ but got L"http://:@gov.uk/" on uri_tests[136].str_props[0]. uri.c:5381: Test failed: Error: Expected http://gov.uk/ but got L"http://@gov.uk/" on uri_tests[135]. uri.c:5381: Test failed: Error: Expected http://gov.uk/ but got L"http://:@gov.uk/" on uri_tests[136]. uri.c:5880: Test failed: Error: Expected a length of 14 but got 15 on uri_tests[135].str_props[0]. uri.c:5880: Test failed: Error: Expected a length of 14 but got 16 on uri_tests[136].str_props[0].

1 0

Re: [5/6] urlmon: Some IUri's don't include the userinfo component in the absolute URI string
by testbot＠testbot.winehq.org 07 Sep '10

07 Sep '10

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=5068 Your paranoid android. === WXPPROSP3 (32 bit uri) === uri.c:5172: Test failed: Expected http://gov.uk/ but got L"http://@gov.uk/" on uri_tests[135].str_props[0]. uri.c:5172: Test failed: Expected http://gov.uk/ but got L"http://:@gov.uk/" on uri_tests[136].str_props[0]. uri.c:5349: Test failed: Error: Expected http://gov.uk/ but got L"http://@gov.uk/" on uri_tests[135]. uri.c:5349: Test failed: Error: Expected http://gov.uk/ but got L"http://:@gov.uk/" on uri_tests[136]. uri.c:5848: Test failed: Error: Expected a length of 14 but got 15 on uri_tests[135].str_props[0]. uri.c:5848: Test failed: Error: Expected a length of 14 but got 16 on uri_tests[136].str_props[0]. === WVISTAADM (32 bit uri) === uri.c:5172: Test failed: Expected http://gov.uk/ but got L"http://@gov.uk/" on uri_tests[135].str_props[0]. uri.c:5172: Test failed: Expected http://gov.uk/ but got L"http://:@gov.uk/" on uri_tests[136].str_props[0]. uri.c:5349: Test failed: Error: Expected http://gov.uk/ but got L"http://@gov.uk/" on uri_tests[135]. uri.c:5349: Test failed: Error: Expected http://gov.uk/ but got L"http://:@gov.uk/" on uri_tests[136]. uri.c:5848: Test failed: Error: Expected a length of 14 but got 15 on uri_tests[135].str_props[0]. uri.c:5848: Test failed: Error: Expected a length of 14 but got 16 on uri_tests[136].str_props[0]. === W2K8SE (32 bit uri) === uri.c:5172: Test failed: Expected http://gov.uk/ but got L"http://@gov.uk/" on uri_tests[135].str_props[0]. uri.c:5172: Test failed: Expected http://gov.uk/ but got L"http://:@gov.uk/" on uri_tests[136].str_props[0]. uri.c:5349: Test failed: Error: Expected http://gov.uk/ but got L"http://@gov.uk/" on uri_tests[135]. uri.c:5349: Test failed: Error: Expected http://gov.uk/ but got L"http://:@gov.uk/" on uri_tests[136]. uri.c:5848: Test failed: Error: Expected a length of 14 but got 15 on uri_tests[135].str_props[0]. uri.c:5848: Test failed: Error: Expected a length of 14 but got 16 on uri_tests[136].str_props[0].

1 0

Re: [4/4] msxml3/tests: Basic test for ::setAttributeNode()
by testbot＠testbot.winehq.org 07 Sep '10

07 Sep '10

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=5062 Your paranoid android. === W98SE (32 bit domdoc) === domdoc.c:5998: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === WNT4WSSP6 (32 bit domdoc) === domdoc.c:5998: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === W2KPROSP4 (32 bit domdoc) === domdoc.c:5998: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154

1 0

Re: [3/4] msxml3/tests: Some tests for ::get_ownerDocument() returned document instance
by testbot＠testbot.winehq.org 07 Sep '10

07 Sep '10

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=5061 Your paranoid android. === W98SE (32 bit domdoc) === domdoc.c:5947: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === WNT4WSSP6 (32 bit domdoc) === domdoc.c:5947: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === W2KPROSP4 (32 bit domdoc) === domdoc.c:5947: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154

1 0

Re: [2/4] msxml3/domdoc: Implement IXMLDOMNamedNodeMap::removeQualifiedItem()
by testbot＠testbot.winehq.org 07 Sep '10

07 Sep '10

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=5060 Your paranoid android. === W98SE (32 bit domdoc) === domdoc.c:5869: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === WNT4WSSP6 (32 bit domdoc) === domdoc.c:5869: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === W2KPROSP4 (32 bit domdoc) === domdoc.c:5869: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154

1 0

Re: [1/4] msxml3/tests: Add a helper to create document instance, remove useless output
by testbot＠testbot.winehq.org 07 Sep '10

07 Sep '10

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=5059 Your paranoid android. === W98SE (32 bit domdoc) === domdoc.c:5804: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === WNT4WSSP6 (32 bit domdoc) === domdoc.c:5804: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === W2KPROSP4 (32 bit domdoc) === domdoc.c:5804: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154

1 0

Re: [PATCH 2/2] include: Define C++ operators inside extern "C++" blocks.
by Octavian Voicu 06 Sep '10

06 Sep '10

d3c4106d6f6d587ec4b9013692dc1cf6da29c279 still doesn't fix the initial problem (see log below). There is still another problem in shlobj.h caused by the inclusion on shobjidl.h from an extern C block: http://source.winehq.org/git/wine.git/?a=blob;f=include/shlobj.h;h=cda13060… Should I send a patch to move the three includes before extern C? How to reproduce the problem: $ cat test.cpp #include <shlobj.h> $ wineg++ test.cpp In file included from /usr/local/include/wine/windows/propsys.h:164, from /usr/local/include/wine/windows/shobjidl.h:368, from /usr/local/include/wine/windows/shlobj.h:39, from test.cpp:1: /usr/local/include/wine/windows/propkeydef.h: In function ‘bool operator==(const PROPERTYKEY&, const PROPERTYKEY&)’: /usr/local/include/wine/windows/propkeydef.h:61: error: declaration of C function ‘bool operator==(const PROPERTYKEY&, const PROPERTYKEY&)’ conflicts with /usr/local/include/wine/windows/guiddef.h:110: error: previous declaration ‘bool operator==(const GUID&, const GUID&)’ here /usr/local/include/wine/windows/propkeydef.h: In function ‘bool operator!=(const PROPERTYKEY&, const PROPERTYKEY&)’: /usr/local/include/wine/windows/propkeydef.h:65: error: declaration of C function ‘bool operator!=(const PROPERTYKEY&, const PROPERTYKEY&)’ conflicts with /usr/local/include/wine/windows/guiddef.h:114: error: previous declaration ‘bool operator!=(const GUID&, const GUID&)’ here winegcc: g++ failed

1 0

Re: [PATCH 2/2] shlwapi: Improved UrlEscapeW implementation (try2)
by testbot＠testbot.winehq.org 06 Sep '10

06 Sep '10

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=5040 Your paranoid android. === W98SE (32 bit url) === url.c:742: Test failed: UrlCanonicalizeA dwFlags 0x00000000 url 'c:dir\file' Expected "file:///c:dir/file", but got "file:///c:/dir/file", index 42

2 1

Re: setupx.dll16: Handle the error case for VCPM_VSTATWRITE in vcpUICallbackProc16. (RESEND)
by Alexandre Julliard 06 Sep '10

06 Sep '10

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > Just realized I did not see a response to this patch. Based on > feedback I received for a different patch, I looked at this patch > again and believe it indeed is easier. > > 1. We only set, but never used cbres, so removing it loses nothing. > 2. With this patch we now set the return value to VCPN_FAIL in this > case. However, this is not the only case in vcpUICallbackProc16; > for example, in another case in this function we pass the return > value of VCP_UI_CopyStart and that returns VCPN_FAIL all over the > place. That doesn't mean it's appropriate in this case. Unless there is evidence that a zero return from VCPM_DISKPREPINFO is supposed to cause an error, it's better not to change the current behavior. -- Alexandre Julliard julliard(a)winehq.org

2 1

msvcrt unimplemented function calls
by Peter Urbanec 06 Sep '10

06 Sep '10

I see calls to the following two functions just prior to a crash when testing wine64. Any idea what these are? wine: Call from 0x7b8497d9 to unimplemented function msvcp80.dll.??0?$complex@N@std@@QEAA@AEBN0@Z, aborting wine: Call from 0x7f7b04cf40d9 to unimplemented function MSVCR80.dll.__C_specific_handler, aborting err:seh:setup_exception stack overflow 2432 bytes in thread 0009 eip 00007f7b04d32341 esp 00007f7b03b10c80 stack 0x7f7b03b10000-0x7f7b03b11000-0x7f7b03c10000 Segmentation fault Thanks.

1 0

Re: wined3d: separate driver info from GPU info (try4)
by Henri Verbeet 06 Sep '10

06 Sep '10

On 6 September 2010 00:45, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > - driver_info->version_low = MAKEDWORD_VERSION(8, 6); /* Nvidia RIVA TNT, arbitrary */ > + } You messed up the indentation here, but otherwise I think this looks reasonable.

1 0

re: [PATCH 1/3] Validate buffers passed to schan_DecryptMessage
by Dan Kegel 06 Sep '10

06 Sep '10

Mikko wrote: > Communicating with an external server is an option, but I don't > know which would be a good server for testing. https://mail.google.com ? Be sure to skip if you can't connect.

1 0

Re: [2/2] attrib/tests: added tests for some flags
by testbot＠testbot.winehq.org 05 Sep '10

05 Sep '10

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=5041 Your paranoid android. === W98SE (32 bit attrib) === attrib.c:43: Test failed: Cannot set read-only mode! attrib.c:69: Test failed: Cannot set hidden mode! attrib.c:82: Test failed: Cannot set systen file mode! attrib.c:95: Test failed: Cannot set compressed mode! attrib.c:109: Test failed: Cannot change mode when using wildcard '?'! attrib.c:118: Test failed: Cannot change mode when using wildcard '*'! attrib.c:120: Test failed: Cannot change mode when using wildcard '*'! attrib.c:133: Test failed: Cannot change mode on directories! Timeout Failure running script in VM: Exceeded timeout limit of 315 sec === WNT4WSSP6 (32 bit attrib) === attrib.c:43: Test failed: Cannot set read-only mode! attrib.c:69: Test failed: Cannot set hidden mode! attrib.c:82: Test failed: Cannot set systen file mode! attrib.c:95: Test failed: Cannot set compressed mode! attrib.c:109: Test failed: Cannot change mode when using wildcard '?'! attrib.c:118: Test failed: Cannot change mode when using wildcard '*'! attrib.c:120: Test failed: Cannot change mode when using wildcard '*'! attrib.c:133: Test failed: Cannot change mode on directories! === W2KPROSP4 (32 bit attrib) === attrib.c:43: Test failed: Cannot set read-only mode! attrib.c:69: Test failed: Cannot set hidden mode! attrib.c:82: Test failed: Cannot set systen file mode! attrib.c:95: Test failed: Cannot set compressed mode! attrib.c:109: Test failed: Cannot change mode when using wildcard '?'! attrib.c:118: Test failed: Cannot change mode when using wildcard '*'! attrib.c:120: Test failed: Cannot change mode when using wildcard '*'! attrib.c:133: Test failed: Cannot change mode on directories! === WXPPROSP3 (32 bit attrib) === attrib.c:43: Test failed: Cannot set read-only mode! attrib.c:69: Test failed: Cannot set hidden mode! attrib.c:82: Test failed: Cannot set systen file mode! attrib.c:95: Test failed: Cannot set compressed mode! attrib.c:109: Test failed: Cannot change mode when using wildcard '?'! attrib.c:118: Test failed: Cannot change mode when using wildcard '*'! attrib.c:120: Test failed: Cannot change mode when using wildcard '*'! attrib.c:133: Test failed: Cannot change mode on directories! === W2K3R2SESP2 (32 bit attrib) === attrib.c:43: Test failed: Cannot set read-only mode! attrib.c:69: Test failed: Cannot set hidden mode! attrib.c:82: Test failed: Cannot set systen file mode! attrib.c:95: Test failed: Cannot set compressed mode! attrib.c:109: Test failed: Cannot change mode when using wildcard '?'! attrib.c:118: Test failed: Cannot change mode when using wildcard '*'! attrib.c:120: Test failed: Cannot change mode when using wildcard '*'! attrib.c:133: Test failed: Cannot change mode on directories! === WVISTAADM (32 bit attrib) === attrib.c:43: Test failed: Cannot set read-only mode! attrib.c:69: Test failed: Cannot set hidden mode! attrib.c:82: Test failed: Cannot set systen file mode! attrib.c:95: Test failed: Cannot set compressed mode! attrib.c:109: Test failed: Cannot change mode when using wildcard '?'! attrib.c:120: Test failed: Cannot change mode when using wildcard '*'! attrib.c:133: Test failed: Cannot change mode on directories! === W2K8SE (32 bit attrib) === attrib.c:43: Test failed: Cannot set read-only mode! attrib.c:69: Test failed: Cannot set hidden mode! attrib.c:82: Test failed: Cannot set systen file mode! attrib.c:95: Test failed: Cannot set compressed mode! attrib.c:109: Test failed: Cannot change mode when using wildcard '?'! attrib.c:118: Test failed: Cannot change mode when using wildcard '*'! attrib.c:120: Test failed: Cannot change mode when using wildcard '*'! attrib.c:133: Test failed: Cannot change mode on directories! === W7PRO (32 bit attrib) === attrib.c:43: Test failed: Cannot set read-only mode! attrib.c:69: Test failed: Cannot set hidden mode! attrib.c:82: Test failed: Cannot set systen file mode! attrib.c:95: Test failed: Cannot set compressed mode! attrib.c:120: Test failed: Cannot change mode when using wildcard '*'! attrib.c:133: Test failed: Cannot change mode on directories! === W7PROX64 (32 bit attrib) === attrib.c:43: Test failed: Cannot set read-only mode! attrib.c:69: Test failed: Cannot set hidden mode! attrib.c:82: Test failed: Cannot set systen file mode! attrib.c:95: Test failed: Cannot set compressed mode! attrib.c:120: Test failed: Cannot change mode when using wildcard '*'! attrib.c:133: Test failed: Cannot change mode on directories! === W7PROX64 (64 bit attrib) === attrib.c:43: Test failed: Cannot set read-only mode! attrib.c:69: Test failed: Cannot set hidden mode! attrib.c:82: Test failed: Cannot set systen file mode! attrib.c:95: Test failed: Cannot set compressed mode! attrib.c:109: Test failed: Cannot change mode when using wildcard '?'! attrib.c:118: Test failed: Cannot change mode when using wildcard '*'! attrib.c:120: Test failed: Cannot change mode when using wildcard '*'! attrib.c:133: Test failed: Cannot change mode on directories!

1 0

Re: [PATCH 1/2] shlwapi: Improved UrlCanonicalize implementation (try2)
by testbot＠testbot.winehq.org 05 Sep '10

05 Sep '10

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=5039 Your paranoid android. === W98SE (32 bit url) === url.c:742: Test failed: UrlCanonicalizeA dwFlags 0x00000000 url 'c:dir\file' Expected "file:///c:dir/file", but got "file:///c:/dir/file", index 42

1 0

Re: [PATCH 2/2] shlwapi: Improved UrlEscapeW implementation
by testbot＠testbot.winehq.org 05 Sep '10

05 Sep '10

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=5038 Your paranoid android. === W98SE (32 bit url) === url.c:742: Test failed: UrlCanonicalizeA dwFlags 0x00000000 url 'c:dir\file' Expected "file:///c:dir/file", but got "file:///c:/dir/file", index 42 url.c:742: Test failed: UrlCanonicalizeA dwFlags 0x00000000 url ' c :dir\file' Expected "file:///c:dir/file", but got "file:///c:/dir/file", index 43

1 0

Re: [PATCH 1/2] shlwapi: Improved UrlCanonicalize implementation
by testbot＠testbot.winehq.org 05 Sep '10

05 Sep '10

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=5037 Your paranoid android. === W98SE (32 bit url) === url.c:742: Test failed: UrlCanonicalizeA dwFlags 0x00000000 url 'c:dir\file' Expected "file:///c:dir/file", but got "file:///c:/dir/file", index 42 url.c:742: Test failed: UrlCanonicalizeA dwFlags 0x00000000 url ' c :dir\file' Expected "file:///c:dir/file", but got "file:///c:/dir/file", index 43

1 0

Re: [1/5] urlmon: Implemented IUriBuilder_{Get/Set}Fragment (try 2)
by Jacek Caban 05 Sep '10

05 Sep '10

Hi Thomas, On 9/5/10 8:10 PM, Thomas Mullaly wrote: > Changes since previous attempt: > > 1. Perform lazy allocation/copy of a URI property when the > IUriBuilder_Get* function is called, instead of always allocating when > the IUriBuilder is created (addresses Jacek's comments). > > 2. Created helper functions for Get/Set calls to the IUriBuilder to cut > back on code duplication. > > 3. Added a bit flag member to the UriBuilder object, so that it can store > which properties have been changed. It looks much better now. There is one problem remaining (that I think can be fixed in a follow-up patch): + This->modified_props |= Uri_HAS_FRAGMENT; + return set_builder_component(&This->fragment,&This->fragment_len, pwzNewValue, '#'); The modifier_props should be set only on success. To achieve so, I think it would be cleaner to pass a flag to be set to set_buildier_component. Jacek

1 0

Re: gdi32/tests: Fix a typ description in test_logpen.
by James McKenzie 05 Sep '10

05 Sep '10

Gerald Pfeifer wrote: > winebot claims this is causing a tons of test failures on W98SE, > but that doesn't make sense at all. > > Gerald: What is the job id on the testbot? I don't see a failure message in Wine-Devel. James McKenzie

1 0

Re: [PATCH 1/3] Validate buffers passed to schan_DecryptMessage
by Mikko Rasa 05 Sep '10

05 Sep '10

The patch list requests me to write tests for this patch. I would do that, but there is a problem: I need a fully initialized schannel security context to use DecryptMessage. To acquire one I need to communicate with a server component. Wine is lacking an implementation of at least the AcceptSecurityContext function, so at the moment I cannot do a self-contained test. Communicating with an external server is an option, but I don't know which would be a good server for testing. Implementing the server-side stuff is another, but might take quite a while and I'd like to see this patch applied soon as it's required to play several recent Ubisoft games. Mikko On 30.08.2010 19:37, Mikko Rasa wrote: > --- > dlls/secur32/schannel.c | 50 ++++++++++++++++++++++++++++++++++++++++++---- > 1 files changed, 45 insertions(+), 5 deletions(-)

1 0

Re: msxml3: IXMLDOMText_get_text return trimmed text when XML_TEXT_NODE
by Alexandre Julliard 05 Sep '10

05 Sep '10

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > @@ -181,6 +181,30 @@ static inline BSTR bstr_from_xmlChar(const xmlChar *str) > return ret; > } > > +static inline BSTR bstr_trim(const BSTR str) > +{ > + UINT i, j, len = SysStringLen(str); > + BSTR new_str = NULL; > + > + /* str empty or NULL */ > + if(!len) > + goto err; > + > + for(i=0; isspaceW(str[i]) && i<len; i++); > + for(j=len-1; isspaceW(str[j]) && j>=i; j--); > + > + new_str = SysAllocStringLen(str+i, j-i+1); > + if(!new_str) > + goto err; > + > + SysFreeString(str); > + return new_str; > + > + err: > + SysFreeString(str); > + return SysAllocStringLen(NULL, 0); > +} That's ugly and inefficient, especially since the common case is to not modify it. -- Alexandre Julliard julliard(a)winehq.org

6 7

Re: msvcp90: Fix 64-bit compilation warnings
by Alexandre Julliard 05 Sep '10

05 Sep '10

Piotr Caban <piotr(a)codeweavers.com> writes: > @@ -596,7 +596,7 @@ DEFINE_THISCALL_WRAPPER(MSVCP_basic_string_char_erase, 12) > basic_string_char* __thiscall MSVCP_basic_string_char_erase( > basic_string_char *this, size_t pos, size_t len) > { > - TRACE("%p %d %d\n", this, pos, len); > + TRACE("%p %d %d\n", this, (int)pos, (int)len); You should be casting to long, otherwise you'll potentially truncate the value. -- Alexandre Julliard julliard(a)winehq.org

3 3

Re: winealsa.drv: remove unused variable
by Chris Robinson 05 Sep '10

05 Sep '10

On Saturday, September 04, 2010 11:09:03 pm Austin English wrote: > - frames_per_period = snd_pcm_bytes_to_frames(wwi->pcm, > wwi->dwPeriodSize); > + snd_pcm_bytes_to_frames(wwi->pcm, wwi->dwPeriodSize); The whole call can probably be removed if the result isn't used anywhere. The function just returns the number of frames that would fit in the specified byte count for the specified device's format.

1 0

Re: [setupapi] added tests for SetupDiGetINFClassA (try2)
by testbot＠testbot.winehq.org 04 Sep '10

04 Sep '10

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=5026 Your paranoid android. === WNT4WSSP6 (32 bit devinst) === No test summary line found

1 0

Re: attrib.exe: extendended from stub
by Austin English 04 Sep '10

04 Sep '10

On Sat, Sep 4, 2010 at 1:53 PM, Konrad Wartke <kwartke(a)googlemail.com> wrote: > attrib.exe: extendended from stub > is now parsing arguments and implements them partly + // FIXME: only display attributes Please use C89 /* comments */. A testsuite for attrib.exe (look at cmd.exe and regedit.exe) would also be helpful. -- -Austin

1 0

Re: [setupapi] added tests of SetupDiGetINFClassA
by testbot＠testbot.winehq.org 04 Sep '10

04 Sep '10

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=5023 Your paranoid android. === WNT4WSSP6 (32 bit devinst) === No test summary line found === W2K3R2SESP2 (32 bit devinst) === devinst.c:1465: Test failed: expected error ERROR_INSUFFICIENT_BUFFER, got 87 === WVISTAADM (32 bit devinst) === devinst.c:1465: Test failed: expected error ERROR_INSUFFICIENT_BUFFER, got 87 === W2K8SE (32 bit devinst) === devinst.c:1465: Test failed: expected error ERROR_INSUFFICIENT_BUFFER, got 87 === W7PRO (32 bit devinst) === devinst.c:1465: Test failed: expected error ERROR_INSUFFICIENT_BUFFER, got 87 devinst.c:1476: Test failed: expected error RPC_S_INVALID_STRING_UUID, got 87 === W7PROX64 (32 bit devinst) === devinst.c:1465: Test failed: expected error ERROR_INSUFFICIENT_BUFFER, got 87 devinst.c:1476: Test failed: expected error RPC_S_INVALID_STRING_UUID, got 87 === W7PROX64 (64 bit devinst) === devinst.c:1465: Test failed: expected error ERROR_INSUFFICIENT_BUFFER, got 87 devinst.c:1476: Test failed: expected error RPC_S_INVALID_STRING_UUID, got 87

1 0

Wine Introduction Page
by James McKenzie 04 Sep '10

04 Sep '10

I was just going over this page and found a few things that I don't know about but have questions on for building Wine on the Mac: The lowest MacOSX version that Wine will build on from the native package is stated to be 10.4 (Tiger). Is this still true? The lowest XCode required is 2.4. Apple stopped supporting this a long time ago. I had XCode 2.5 for Tiger. Can anyone update these? James McKenzie

2 1

Wine Gecko 1.1.0 RC1
by Jacek Caban 04 Sep '10

04 Sep '10

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

4 7

New winetricks 20100904: lots of little fixes. New verbs comdlg32.ocx, vcrun2010
by Dan Kegel 04 Sep '10

04 Sep '10

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.) Winetrickstest really paid off this time... it caught three problems before release. Changes: Dan Kegel: update shockwave sha1sum stop using busted sourceforge mirror revert change that broke dinput8 (unfixed issue 149) use XDG_CACHE_HOME. Fixes issue 124. fix checksum on macosx (thanks to slevytam for logs) add catchall dll-disabling verb, foo=disabled remove fakeie6, it hasn't been needed for a long time. Fred Joseph Ladd: nicer title and text for zenity dialog fix typo, misc string fixes (issue 146) add comdlg32.ocx add vcrun2010 add ISBn for 'Portable Shell Programming'. Austin English: add xapofx as a synonym to xact. (Issue 133) delete .Net registry keys before installing .Net. (Issue 158) remove ancient Mono versions add a synonym for wsh56js (jscript) Andrew Nguyen: add support for new gecko for wine-1.3.2 and up. (Note: gecko-dbg might not be happy yet, it fails winetrickstest.)

1 0

Re: [PATCH 7/7] CMD: Change the parameterization to be correct
by testbot＠testbot.winehq.org 04 Sep '10

04 Sep '10

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=5018 Your paranoid android. === WNT4WSSP6 (32 bit) === batch.c:185: Test failed: unexpected char 0x43 position 0 in line 59 (got 'CD:''', wanted 'CD:'@pwd@'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 60 (got 'CD:''', wanted 'CD:'@pwd@\testdir'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 61 (got 'CD end:''', wanted 'CD end:'@pwd@\testdir'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 62 (got 'C:\winetest\testdir', wanted 'CD:'@pwd@'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 63 (got 'CD end:''', wanted 'CD:'@pwd@\testdir'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 64 (got 'C:\winetest\testdir', wanted 'CD end:'@pwd@'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 65 (got 'CD end:''', wanted 'CD:'@pwd@'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 66 (got 'C:\winetest\testdir', wanted 'CD:'@pwd@\testdir'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 67 (got 'CD end:''', wanted 'CD end:'@pwd@'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 68 (got 'C:\winetest\testdir', wanted 'CD:'@pwd@'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 69 (got 'CD end:''', wanted 'CD:'@pwd@\testdir'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 70 (got 'C:\winetest\testdir', wanted 'CD end:'@pwd@'') batch.c:185: Test failed: unexpected char 0x2d position 0 in line 71 (got '-----------Testing parameterization -----------', wanted 'CD:'@pwd@'') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 72 (got 'p1: '1'', wanted 'CD:'@pwd@\testdir'') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 73 (got 'p2: ''', wanted 'CD end:'@pwd@'') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 74 (got 'p3: ''', wanted '-----------Testing parameterization -----------') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 76 (got 'p2: '2'', wanted 'p2: ''') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 80 (got 'p3: '3'', wanted 'p3: ''') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 81 (got 'p1: '"b"'', wanted 'p1: '1'') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 82 (got 'p2: ''', wanted 'p2: '2'') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 83 (got 'p3: ''', wanted 'p3: '3'') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 84 (got 'p1: 'a"b"c'', wanted 'p1: '"b"'') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 87 (got 'p1: '"a"bc'', wanted 'p1: 'a"b"c'') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 90 (got 'p1: 'a'', wanted 'p1: '"a"bc'') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 91 (got 'p2: 'bc'', wanted 'p2: ''') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 93 (got 'p1: '"a=bc d'', wanted 'p1: 'a'') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 94 (got 'p2: ''', wanted 'p2: 'bc'') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 96 (got 'p1: 'a""b'', wanted 'p1: '"a=bc d'') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 99 (got 'p1: 'a'', wanted 'p1: 'a""b'') batch.c:185: Test failed: unexpected char 0x70 position 0 in line 100 (got 'p2: 'b'', wanted 'p2: ''') batch.c:185: Test failed: unexpected char 0x69 position 0 in line 102 (got 'if exist test failed', wanted 'p1: 'a'') batch.c:196: Test failed: unexpected end of output in line 102, missing p2: 'b'

1 0

re: Opinions on priority for an enhancement that Dan suggested some time ago?
by Dan Kegel 04 Sep '10

04 Sep '10

Tom Spear wrote: > I believe it would be prudent to have some warning appear when > certain native dll's are missing which required by the app being > run, and which we do not implement builtins for. I suppose a +winediag message might be appropriate for some commonly-needed DLLs. Probably there'd be a table of which DLLs to warn for. Nobody has hooked +winediag up to any flag-the-user system yet, but that's what I had in mind in http://bugs.winehq.org/show_bug.cgi?id=657#c39 I'm more focused on the idea of reducing the need for native DLLs than making it easy to install them. (Um, well, except for winetricks, which seems good enough for the moment.)

1 0

Re: [PATCH 6/7] CMD: Current directory needs saving in the environment even for cmd /c
by testbot＠testbot.winehq.org 04 Sep '10

04 Sep '10

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=5017 Your paranoid android. === WNT4WSSP6 (32 bit batch) === batch.c:185: Test failed: unexpected char 0x43 position 0 in line 59 (got 'CD:''', wanted 'CD:'@pwd@'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 60 (got 'CD:''', wanted 'CD:'@pwd@\testdir'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 61 (got 'CD end:''', wanted 'CD end:'@pwd@\testdir'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 62 (got 'C:\winetest\testdir', wanted 'CD:'@pwd@'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 63 (got 'CD end:''', wanted 'CD:'@pwd@\testdir'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 64 (got 'C:\winetest\testdir', wanted 'CD end:'@pwd@'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 65 (got 'CD end:''', wanted 'CD:'@pwd@'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 66 (got 'C:\winetest\testdir', wanted 'CD:'@pwd@\testdir'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 67 (got 'CD end:''', wanted 'CD end:'@pwd@'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 68 (got 'C:\winetest\testdir', wanted 'CD:'@pwd@'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 69 (got 'CD end:''', wanted 'CD:'@pwd@\testdir'') batch.c:185: Test failed: unexpected char 0x43 position 0 in line 70 (got 'C:\winetest\testdir', wanted 'CD end:'@pwd@'') batch.c:196: Test failed: unexpected end of output in line 70, missing CD:'@pwd@'

1 0

Re: [PATCH 5/7] CMD: Add support for echo "on"
by testbot＠testbot.winehq.org 04 Sep '10

04 Sep '10

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=5016 Your paranoid android. === WNT4WSSP6 (32 bit) === batch.c:188: Test failed: unexpected end of output in line 53, expected 0x30

1 0

Opinions on priority for an enhancement that Dan suggested some time ago?
by Tom Spear 04 Sep '10

04 Sep '10

Hi all, so it has been a long time since I have posted here. Much has changed; I now have 3 little ones. :-) Anyways, right to the point: I stumbled on an old bug of mine this evening while doing some long overdue mailbox maintenance. Bug 657: http://bugs.winehq.org/show_bug.cgi?id=657 Dan made a very good point back in 2007 that I believe now is the right time to possibly look at beginning an implementation of: [1] To summarize: Similar to the way that we now have a popup about wine-gecko missing, I believe it would be prudent to have some warning appear when certain native dll's are missing which required by the app being run, and which we do not implement builtins for. Similarly, I feel that it would be prudent for warnings to appear if certain linux shared objects are missing. More to the point is that there are quite a number of DLL's which won't be implemented soon, if ever, but yet we support running wine from the GUI both through shortcuts, and through binfmt_misc, thereby completely bypassing any hope of a user ever seeing some pretty critical errors that may occur. These errors could, if popped up on their screen, prevent a bunch of duplicates from appearing in Bugzilla, because the user can google for the error and be directed directly to a bug which someone else made, as opposed to not seeing anything and having no idea what to try googling for other than "app x does this +wine" As an example on the shared object side, on FC13 x86_64, using the rpm from the yum repo that RH provides, I can install wine, but since there is no RPM dependency currently for OpenAL (i686), I get "no such file/directory" warnings about the OpenAL shared objects when running certain programs (specifically, World of Warcraft and Starcraft II). Now granted the fact that OpenAL is not installed is, debatibly something to take up with the wine packager for RedHat and derivatives; I wanted to point out that with the way wine is at present, if I didn't run wine from a console, I would never have known that, and probably would still not have working sound, because there is nothing that says "Hey! You're missing OpenAL!" I'd like to hear opinions from others about what it might take, time-wise, if someone were to start now, to have something like this implemented. And also what kind of a priority this type of thing should have. Sure it is an enhancement, and so is naturally lower priority than, say a segfault in ntdll, but (imho) it's a pretty critical enhancement that is (again, imho) long overdue. Thoughts? Questions? [1] http://bugs.winehq.org/show_bug.cgi?id=657#c37 Also see comments of his below #37. Thanks Tom

1 0

Re: [PATCH 4/7] CMD: echo command needs to ignore whitespace
by testbot＠testbot.winehq.org 04 Sep '10

04 Sep '10

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=5015 Your paranoid android. === WNT4WSSP6 (32 bit) === batch.c:188: Test failed: unexpected end of output in line 51, expected 0x30

1 0

Re: [PATCH 3/7] CMD: cmd /c cannot use argv/argc to walk the arguments
by testbot＠testbot.winehq.org 04 Sep '10

04 Sep '10

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=5014 Your paranoid android. === WNT4WSSP6 (32 bit) === batch.c:188: Test failed: unexpected end of output in line 49, expected 0x30

1 0

Re: [PATCH 2/7] CMD: echo.word should echo back the word without the . [bug21130]
by testbot＠testbot.winehq.org 04 Sep '10

04 Sep '10

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=5013 Your paranoid android. === WNT4WSSP6 (32 bit) === batch.c:188: Test failed: unexpected end of output in line 49, expected 0x30

1 0

Re: [PATCH 1/7] CMD : Correct support for cmd.exe /C string [bug 21927]
by testbot＠testbot.winehq.org 04 Sep '10

04 Sep '10

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=5012 Your paranoid android. === WNT4WSSP6 (32 bit) === batch.c:188: Test failed: unexpected end of output in line 47, expected 0x30

1 0

Please report mcicda (CDROM audio) test results
by Joerg-Cyril.Hoehle＠t-systems.com 03 Sep '10

03 Sep '10

Saulius, Saulius Krasuckas wrote: >It would be nice to indicate disks containing tracks of different types >(sessions) in the log and to extract some info from the data track. >Drive info would be also interesting to see in the log. It is on purpose that I did not write too specific info to the log. I don't want logs posted to the Internet to contain (too much) sensitive information, violating your privacy. No CDDB ID. >Then we would know for sure :) As far as MCICDA is concerned, it doesn't look like it knows about multi-sessions. All it offers is to play music. Therefore the mcicda tests is not the right place to look for a disc utility that'll show you information about your drive and disc. >me_s2-clean-updated/winmm:mcicda.html Ah, that's you, good to know. You can help me debug the ME-only errors in winmm:midi midioutXyz returns rc=MMSYSERR_INVALPARAM Paul Vriens found out that the binary he compiled does not produce such errors on WinMe, while testbot's binary does. What about your machine? In testbot job #4990, you'll find a MSVC compiled 150KB binary. Please run the MIDI tests with it on your WinME machine. wintest.exe midi Non-ME output is: midi.c:298: Test failed: no PARAM error, now setting BytesRecorded too large testbot would instead trigger ok(0,"PARAM error, setting BytesRecorded\n"); Thank you, Jörg Höhle

2 1

kernel32: Add tests for SetHandleCount + make tests pass for winversions >WINNT
by Louis Lenders 03 Sep '10

03 Sep '10

Hi Juan, >Since we don't have the same limitation in Wine, >applications can call it or not, but it won't have any effect. Hence >maintaining a version-dependent external behavior, while not behaving >differently internally, doesn't make sense to me. Ok, thanks for the info, then i'll just let it return 'count', that should be ok then for apps that use this function (and fixes the bug for Street Fighter). I'll send a new patch tomorrow.

1 0

Script for finding references to stub functions
by Dan Kegel 03 Sep '10

03 Sep '10

I threw together a perl script this morning to scan a wineprefix for references to MS dlls. It's at http://code.google.com/p/winezeug/source/browse/trunk/mscodescan.pl It's pretty crufty, but might still be handy. For a working install of Sam and Max episode 304 (with native vcrun80 installed), it outputs Found 24 bundled MS modules: ./windows/winsxs/x86_Microsoft.VC80.OpenMP_1fc8b3b9a1e18e3b_8.0.50727.4053_x-ww_e79c4723/vcomp.dll ./windows/winsxs/x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.4053_x-ww_e6967989/msvcr80.dll ... ./windows/winsxs/x86_Microsoft.VC80.MFC_1fc8b3b9a1e18e3b_8.0.50727.4053_x-ww_b77cec8e/mfc80u.dll ./windows/system32/xinput9_1_0.dll ./windows/system32/xinput1_1.dll ./windows/system32/d3dx9_27.dll ./windows/system32/xinput1_2.dll ./windows/system32/d3dx9_41.dll ./windows/system32/xinput1_3.dll ./Program Files/Telltale Games/Sam and Max - The Devil's Playhouse/Beyond the Alley of the Dolls/QtCore4.dll imports following stub symbols: msvcp80:??0?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@PBDI@Z ... msvcp80:?uncaught_exception@std@@YA_NXZ ./Program Files/Telltale Games/Sam and Max - The Devil's Playhouse/Beyond the Alley of the Dolls/QtWebKit4.dll imports following stub symbols: msvcp80:?max@?$numeric_limits@I@std@@SAIXZ msvcp80:?quiet_NaN@?$numeric_limits@N@std@@SANXZ msvcp80:_FInf msvcp80:_Inf msvcp80:_Nan ./Program Files/Telltale Games/Sam and Max - The Devil's Playhouse/Beyond the Alley of the Dolls/QtGui4.dll imports following stub symbols: msvcr80:?_type_info_dtor_internal_method@type_info@@QAEXXZ msvcr80:_crt_debugger_hook ./Program Files/Telltale Games/Sam and Max - The Devil's Playhouse/Beyond the Alley of the Dolls/QtCore4.dll imports following stub symbols: msvcr80:?_type_info_dtor_internal_method@type_info@@QAEXXZ msvcr80:_crt_debugger_hook msvcr80:_fseeki64 msvcr80:_ftelli64 msvcr80:_get_tzname msvcr80:_localtime64_s msvcr80:_putenv_s msvcr80:_wassert msvcr80:getenv_s ./Program Files/Telltale Games/Sam and Max - The Devil's Playhouse/Beyond the Alley of the Dolls/QtNetwork4.dll imports following stub symbols: msvcr80:?_type_info_dtor_internal_method@type_info@@QAEXXZ msvcr80:_crt_debugger_hook ./Program Files/Telltale Games/Sam and Max - The Devil's Playhouse/Beyond the Alley of the Dolls/QtWebKit4.dll imports following stub symbols: msvcr80:?_type_info_dtor_internal_method@type_info@@QAEXXZ msvcr80:_crt_debugger_hook msvcr80:_localtime64_s

1 0

Re:kernel32: Add tests for SetHandleCount + make tests pass for winversions >WINNT
by Louis Lenders 03 Sep '10

03 Sep '10

>It's pretty unlikely that count would be larger than 0xffffffff. I agree, but i thought we should mimic Windows-behaviour, and the tests showed that such large values are at least allowed. If this value is too large could you suggest another one? > Also I don't think we need a version check. The check is there as the tests show that there is a difference between ver < win98 and ver > WINNT. I don't know if there a are applications that depend on this difference really. Anyway, i could return something like min(65536,count) for all versions, is that ok? (i'll strip out the tests then, as they won't be passing then anymore)

3 2

Re: [PATCH 3/3] winmm: Implement MCIERR_DUPLICATE_ALIAS and MCIERR_DEVICE_OPEN.
by testbot＠testbot.winehq.org 03 Sep '10

03 Sep '10

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=4989 Your paranoid android. === W98SE (32 bit mci) === mci.c:903: Test failed: not enough time elapsed 58ms

1 0

Re: [PATCH 2/3] winmm: GetDeviceID only considers a single name per entry.
by testbot＠testbot.winehq.org 03 Sep '10

03 Sep '10

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=4988 Your paranoid android. === W98SE (32 bit mci) === mci.c:1001: Test failed: mci pause wait returned MMSYSERR 5 mci.c:1015: Test failed: mci pause (space) wait returned MMSYSERR 5 mci.c:1018: Test failed: mci pause wait returned MMSYSERR 5 mci.c:1032: Test failed: Expect message 0004 from play (aborted by close)

1 0

Re: [1/4] urlmon: Implemented IUriBuilder_{Get/Set}Fragment
by Jacek Caban 03 Sep '10

03 Sep '10

Hi Thomas, On 9/3/10 1:19 AM, Thomas Mullaly wrote: > --- > dlls/urlmon/tests/uri.c | 22 ++++++++++++- > dlls/urlmon/uri.c | 80 > ++++++++++++++++++++++++++++++++++++++++++---- > 2 files changed, 93 insertions(+), 9 deletions(-) > +static HRESULT setup_builder_properties(UriBuilder*builder, const Uri* uri) { + if(uri->fragment_start> -1) { + builder->fragment = heap_alloc((uri->fragment_len+1)*sizeof(WCHAR)); + if(!builder->fragment) + return E_OUTOFMEMORY; + + memcpy(builder->fragment, uri->canon_uri+uri->fragment_start, uri->fragment_len*sizeof(WCHAR)); + builder->fragment[uri->fragment_len] = '\0'; + builder->fragment_len = uri->fragment_len; + } + + return S_OK; +} I don't think it's a good idea. It should be possible to avoid fetching all URI properties here. You can do it, eg. on demand, when you get a call to GetFragment and the fragment is not everwriten by SetFragment call. Thinking about it, the way these APIs work suggests that Uri object should store null-terminated properties that we could return here, but it may be too far conclusion. Jacek

1 0

Fwd: [PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit.
by Joerg-Cyril.Hoehle＠t-systems.com 03 Sep '10

03 Sep '10

Octavian, >I just looked in mmddk.h and they have this: >#define MCI_INTEGER64 13 It's good you found out about MCI_INTEGER64. Yet it's completely crazy because googling it yields 6 hits in total, all about Wine bug 22146. Bing shows nothing at all. How can such a name be that invisible? >So, do you want to fix your patches and send them, or do you want me >to continue working on this patch set? I'm fine if you do (as I've plenty of other patches in my queue) especially if you also fix the parser to handle MCI_HWND (another DWORD_PTR), which is the second half needed for 64bit as I mention in http://bugs.winehq.org/show_bug.cgi?id=22146#c12 GetDWORD also needs some change to be able to parse DWORD_PTR things, e.g. window handles. I've not yet written a single test for that (no mciavi tests). I'll send you all the MCI tests I have written ASAP. Even without written tests, one can use WINEDEBUG=+mci and analyse the parser logs for individual commands sent e.g. via the interactive MCI shell you'll find in http://bugs.winehq.org/show_bug.cgi?id=20232#c10 You obviously own a 64bit system so it's easier for you to test. I don't and had to beg. Regards, Jörg Höhle

2 3

Re: shell32/tests: Test that a folder can be named when clicking "Make New Folder"
by Frank Richter 03 Sep '10

03 Sep '10

On 10.08.2010 20:22, Michael Mc Donnell wrote: > When a user clicks the "Make New Folder" button a new folder is created. > The name of the folder is selected, and the dialog box waits for the user > to either accept the name or type in a new one. The test types in a > new folder name and checks that the new folder gets that name. Also, you seem to emit “Alt+M” as part of the test. This is rather fragile, as the hotkey for “Make new folder” is most likely _not_ M on Windows or Wine translated to other than English. I believe the safe way to deal with that is to send a WM_COMMAND message with the ID of the “Make new folder” button. Wine test bot has a number of non-English VMs, so make sure you try your patches there. -f.r.

2 1

Re: [PATCH 1/3] winmm: Correctly parse the MCI Sysinfo command.
by testbot＠testbot.winehq.org 03 Sep '10

03 Sep '10

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=4987 Your paranoid android. === W98SE (32 bit mci) === mci.c:889: Test failed: not enough time elapsed 58ms mci.c:945: Test failed: mci status position: 58 mci.c:992: Test failed: mci pause wait returned MMSYSERR 5 mci.c:1006: Test failed: mci pause (space) wait returned MMSYSERR 5 mci.c:1009: Test failed: mci pause wait returned MMSYSERR 5 mci.c:1023: Test failed: Expect message 0004 from play (aborted by close)

1 0

Re: msvcrt:string Fix codepage table 1361 (Korean Johab) [try3]
by Alexandre Julliard 03 Sep '10

03 Sep '10

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > @@ -1563,8 +1564,16 @@ sub HANDLE_FILE(@) > } > printf OUTPUT "#include \"wine/unicode.h\"\n\n"; > > + @lb_ranges = get_lb_ranges(); > + > + if( $codepage == 1361 ) > + { > + $lb_ranges[0] = 0x81; > + $lb_ranges[2] = 0xd8; > + } A quick test on Windows shows that this isn't correct as far as the kernel32 info is concerned. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [PATCH 4/6] gameux: add storing Title registry value
by Nikolay Sivov 03 Sep '10

03 Sep '10

On 9/3/2010 13:25, Mariusz Pluciński wrote: > + hr = IXMLDOMElement_get_text(lpXMLElement,&bstrValue); > + if(SUCCEEDED(hr)) > + { > + nValueLen = SysStringLen(bstrValue)+1; > + > + GameData->sName = CoTaskMemAlloc(nValueLen*sizeof(WCHAR)); > + if(GameData->sName == NULL) > + hr = E_OUTOFMEMORY; > + > + if(SUCCEEDED(hr)) > + lstrcpynW(GameData->sName, bstrValue, nValueLen); > + > + SysFreeString(bstrValue); > + } Maybe it's better to store it as BSTR to avoid such checks/allocations.

1 0

Re: shell32: Import ole32 directly
by Alexandre Julliard 03 Sep '10

03 Sep '10

André Hentschel <nerv(a)dawncrow.de> writes: > ole32 function CoTaskMemAlloc is already used in DLL_PROCESS_ATTACH > (SIC_Initialize -> SIC_IconAppend -> SHAlloc -> CoTaskMemAlloc) A better fix would be to avoid initializing unneeded stuff in process attach. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: kernel32: Add tests for SetHandleCount + make tests pass for winversions >WINNT
by Alexandre Julliard 03 Sep '10

03 Sep '10

Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> writes: > @@ -1192,7 +1192,10 @@ BOOL WINAPI UnlockFileEx( HANDLE hFile, DWORD reserved, DWORD count_low, DWORD c > */ > UINT WINAPI SetHandleCount( UINT count ) > { > - return min( 256, count ); > + if (GetVersion() & 0x80000000) > + return min( 0x100, count ); > + else > + return min( 0xffffffff, count ); It's pretty unlikely that count would be larger than 0xffffffff. Also I don't think we need a version check. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: kernel32: add a stub for GetThreadUILanguage
by Dmitry Timoshkov 03 Sep '10

03 Sep '10

Austin English <austinenglish(a)gmail.com> wrote: > +LANGID WINAPI GetThreadUILanguage( void ) > +{ > + FIXME(": stub, returning LOCALE_USER_DEFAULT.\n"); > + return LOCALE_USER_DEFAULT; > +} The API is supposed to return a language id, not the locale id. Calling GetUserDefaultUILanguage() may be what you need. -- Dmitry.

1 0

banning spammer from the forum
by Rosanne DiMesio 03 Sep '10

03 Sep '10

Can someone with forum admin rights please ban user Eden1023? I've had to delete multiple spam posts by this user every day for the past few days. -- Rosanne DiMesio <dimesio(a)earthlink.net>

4 5

Re: [2/3] dsound/tests: Add IEEE float buffer tests
by testbot＠testbot.winehq.org 02 Sep '10

02 Sep '10

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=4950 Your paranoid android. === W98SE (32 bit dsound) === dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D407F4 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D554 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D56C 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D624 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D614 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D614 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D5F4 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D630 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D60C 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D628 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D628 00000000 dsound.c:748: Test failed: Creating 32 bpp buffer on dx < 8 returned: 82D3D628 00000000

1 0

RFC: Compiling as 16 bit
by Morten Rønne 02 Sep '10

02 Sep '10

This is related to the creation of the DOS test programs for which I have sent another mail. But this is a more generic question relating to the fact that openwatcom is a 16 bit compiler while gcc (of course) is a 32 bit compiler. Currently this have lead me to drop the inclusion of the files windef.h and winbase.h, because the definitions created aren't of the correct size (int is 16 bit, not 32 bit and so on). I am looking for a way to change windef.h so that it will create the correct base types for both 16 and 32 bit compile. Openwatcom defines the symbol __I86__ while compiling for 16 bit, is it acceptable that I use that to create 16 bit types? It seems that _MSC_VER will change a few cases of int to long, but far from enough. Is _MSC_VER intended to be a 16 bit compile flag? Or should I use something else more wine like (e.g. __WINE_16BIT_COMPILE). Also compiling 16 bit give some errors in other include files (after I have defined proper sizes for the 16 bit compile) ../../../include/winnt.h(3529): Error! E1040: Field width too large #ifdef BITFIELDS_BIGENDIAN unsigned NameIsString:1; unsigned NameOffset:31; #else unsigned NameOffset:31; unsigned NameIsString:1; #endif As it can be seen the include file uses unsigned directly and not a type like DWORD or ULONG that would be a "safe" 32 bit. Would it be acceptable to change this and others to a "proper" type which I know to be size safe? Best Regards Morten Rønne

2 4

Re: [1/3] dsound: Add support for 32-bit IEEE float buffers
by Chris Robinson 02 Sep '10

02 Sep '10

On Thursday, September 02, 2010 1:38:29 pm Owen Rudge wrote: > These patches add support to DirectSound that allow the conversion of > 32-bit IEEE float audio buffers to PCM. Some games (e.g., Call of Duty > 5) output their audio in this format, and media players such as > foobar2000 have support for it too. You'll probably want to make sure the float values are clamped between -1 and +1 before converting, otherwise they'll wrap and cause bad static noise.

1 0

Re: RFC: test of 16 bit wine (DOS)
by Dan Kegel 02 Sep '10

02 Sep '10

On Thu, Sep 2, 2010 at 7:50 PM, Morten Rønne <morten.roenne(a)tdcadsl.dk> wrote: >> Oh, right, win16test's Makefile and probably its test.h are kind of >> simpleminded. >> You probably want to have just one 16 bit test app per dll. >> Hopefully the test cases from win16test will be a useful starting point >> aside from their wimpy build system. > > I would like to avoid the dll part as DOS doesn't know about that and > "simply" run the program directly with tools/run_test. You might have misunderstood. By DLL I just meant the part of Wine that you're testing. In the case of DOS, the tests should probably go in krnl386.exe16/tests. > I will make some tests to see what I can fit into the test system, so it > works the same way other tests do, but as a "standalone" test. Good. That's exactly what I did with win16test. The missing part is integrating into the Wine build sytem. - Dan

1 0

re: RFC: test of 16 bit wine (DOS)
by Dan Kegel 02 Sep '10

02 Sep '10

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

2 5

Please report mcicda (CDROM audio) test results
by Joerg-Cyril.Hoehle＠t-systems.com 02 Sep '10

02 Sep '10

Hi, Wine's testbt job #4280 http://testbot.winehq.org/JobDetails.pl?Key=4280 contains both a patch and a binary for new MCICDA=MCI CD-audio tests. It already contains most of what I want in the initial release but would benefit from testing on a broad range of native MS systems. Please invoke it as: mcicda_test.exe mcicda (it generates many failures on Wine but I already wrote several patches to fix them.) Some failures are still possible as there are a few rough edges, e.g. mcicda.c:222: Test failed: info upc: 0=NOERROR mcicda.c:322: Test failed: PLAY data to 00291d10: MCIERR_OUTOFRANGE mcicda: 98 tests executed (0 marked as todo, 2 failures), 0 skipped. It skips tests if - there's no disk in drive; - there are no audio tracks; Untested: blank RW disk Questions: - Is this patch right in mcicda/tests/ or should it be part of winmm/tests/? - Which kind of tests should I restrict to WINETEST_INTERACTIVE mode only? People may start to complain in the near future that running the Wine testsuite starts spinning their CD-ROM and even play music. (like somebody observed that the MIDI testsuite plays a few notes). Thank you for your contributions, Jörg Höhle

5 12

Re: winmm/tests: Share common function dbg_mcierr.
by testbot＠testbot.winehq.org 02 Sep '10

02 Sep '10

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=4939 Your paranoid android. === W98SE (32 bit mci) === mci.c:613: Test failed: Expect message 0001 from play to 250 wait notify mci.c:620: Test failed: got 0004 instead of MCI_NOTIFY_xyz 0000 from command after close

1 0

Our wiki disallows chinese text?
by Dan Kegel 02 Sep '10

02 Sep '10

The chap I mentioned earlier is starting off by trying to translate wiki pages into Chinese. http://wiki.winehq.org/FrontPage now has a Chinese entry at the bottom, but there's a hitch: when I try putting a bit of chinese text into http://wiki.winehq.org/Chinese the wiki refuses to save it, saying Sorry, can not save page because "葡" is not allowed in this wiki Is that because we don't have anyone who can monitor the wiki for chinese spam? How can we allow creation of Chinese pages? - Dan

3 2

Re: [PATCH 5/6] winmm/tests: MCI_STATUS returns DWORD_PTR, unlike other commands.
by testbot＠testbot.winehq.org 02 Sep '10

02 Sep '10

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=4901 Your paranoid android. === W98SE (32 bit mci) === mci.c:714: Test failed: Expect message 0001 from play to 250 wait notify mci.c:721: Test failed: got 0004 instead of MCI_NOTIFY_xyz 0000 from command after close mci.c:782: Test failed: not enough time elapsed 58ms mci.c:838: Test failed: mci status position: 58

2 1

Mono integration, and when do we ship Mono with Wine?
by Vincent Povirk 02 Sep '10

02 Sep '10

Dan Kegel recently listed this as a possible 1.4 goal: > Mono integration similar to the current Gecko integration He may have meant one or both of the following things: 1. A more-or-less complete mscoree.dll that works based on the mono embedding api, as well as replacements for all the utilities that ship with .NET. 2. A wine-mono package similar to the current wine-gecko package to be installed automatically in new prefixes. I am making very slow progress with 1. I believe the current major shortcomings are functions that create COM wrappers for managed objects (ClrCreateManagedInstance and DllGetClassObject) and functions that search for and load different .NET versions (I believe these will be needed so that the managed objects we create will load and function properly). Mono already provides COM wrappers, so all we have to do is create the objects and pass COM wrappers to applications. I'm making this judgment based on the limited pool of mscoree bugs in the Wine bugzilla. I wish more people would file bugs when Mono doesn't work. I figure 2 can't be very technically difficult in and of itself, but when will we be ready to do that? What are the requirements? Do we want to go the "offer to download and install on first use" route first, and if so when will we be ready for that? Do those functions I mentioned earlier have to actually work first? The one hard requirement I have and have not met is that a working mono package can be built by me using only free software and that I can explain the build process to other people. I can do this for the core runtime and libraries, but I cannot do this for the gluezilla dependency. This gluezilla thing is sort of explained here: http://www.mono-project.com/WebBrowser Basically, .NET provides a web browser control, which Mono implements based on Gecko (or, optionally, WebKit). The official installer of Mono for Windows, which is what anyone who uses Mono in Wine uses, ships with Mozilla. It also ships with gluezilla, which is a C++ library that helps the managed code link Gecko. I don't think it'd be acceptable to leave out WebBrowser support. I am not currently able to create a Windows build of gluezilla or gecko using only free software. As I understand it, the official Windows build relies on Visual Studio. I do not know whether it's feasible for gluezilla to link to wine gecko, so that we don't have to install two versions of gecko. I also know that shipping gluezilla and gecko on Windows is wrong. Mono's wiki tells me that it's possible in .NET to access the underlying IE embedding objects through the winforms api, and those only exist if we're embedding IE. So the correct approach is to embed IE (in this case, Wine's IE replacement) by writing another WebBrowser backend. I don't know how hard that is. Maybe it'd make a good Summer of Code project? So, does anyone have other requirements, or thoughts on resolving the WebBrowser requirement?

5 4

Re: [5/5] msi/test: Add tests for 64-bit properties.
by testbot＠testbot.winehq.org 02 Sep '10

02 Sep '10

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=4928 Your paranoid android. === W7PROX64 (64 bit package) === package.c:8387: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8398: Test failed: Expected "C:\winetest\", got "" package.c:8409: Test failed: Expected "C:\winetest\", got "" package.c:8459: Test failed: Expected "C:\winetest\FileName3.dll", got "" package.c:8470: Test failed: Expected "C:\winetest\FileName5.dll", got "" package.c:8479: Test failed: Expected "C:\", got "" package.c:8485: Test failed: Expected "C:\winetest\", got "" package.c:8506: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8515: Test failed: Expected "C:\winetest\FileName1", got ""

1 0

Re: [PATCH 3/3] include: Add MCI_INTEGER64 and MCI_INTEGER3264 mci types. (try 2)
by Jacek Caban 02 Sep '10

02 Sep '10

Hi Octavian, On 9/1/10 7:45 PM, Octavian Voicu wrote: > MCI_INTEGER64 is only defined for _WIN64 in DDK. > > MCI_INTEGER3264 is wine specific and will be needed because MCI_STATUS > return type is MCI_INTEGER64 in 64-bit winmm.dll, and MCI_INTEGER > in 32-bit winmm.dll. That's not a reason to add Wine-specific defines in public header. Jacek

3 3

Re: msvcrt:string Fix codepage table 1361 (Korean Johab) [try2]
by Alexandre Julliard 02 Sep '10

02 Sep '10

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > @@ -1563,8 +1564,11 @@ sub HANDLE_FILE(@) > } > printf OUTPUT "#include \"wine/unicode.h\"\n\n"; > > + if( $codepage == 1361 ) { @lb_ranges = ( 0x81, 0xd3, 0xd8, 0xde, 0xe0, 0xf9 ); } > + else { @lb_ranges = get_lb_ranges(); } There's no reason to hardcode the whole thing. If some lead bytes aren't detected properly you can add just those. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 6/6] winmm/tests: Add MCI parser tests.
by testbot＠testbot.winehq.org 01 Sep '10

01 Sep '10

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=4902 Your paranoid android. === W98SE (32 bit mci) === mci.c:926: Test failed: mci status position: 128

1 0

Re: [PATCH 2/3] winmm: Replace command ids with symbolic constants in mci command resources.
by Octavian Voicu 01 Sep '10

01 Sep '10

In order to prevent copy-paste errors, the changes were generated using the following script, executed from git root (there are two very long lines, might not work if they're wrapped): for i in MCI_OPEN MCI_CLOSE MCI_ESCAPE MCI_PLAY MCI_SEEK MCI_STOP MCI_PAUSE MCI_INFO MCI_GETDEVCAPS MCI_SPIN MCI_SET MCI_STEP MCI_RECORD MCI_SYSINFO MCI_BREAK MCI_SOUND MCI_SAVE MCI_STATUS MCI_CUE MCI_REALIZE MCI_WINDOW MCI_PUT MCI_WHERE MCI_FREEZE MCI_UNFREEZE MCI_LOAD MCI_CUT MCI_COPY MCI_PASTE MCI_UPDATE MCI_RESUME MCI_DELETE; do j=`egrep "^#define $i\\W" include/mmsystem.h | awk '{print $3}' | sed 's/0x0/0x00000/g'`; k=`echo $i | sed 's/MCI_//g'`; sed -i "s/${j}L, MCI_COMMAND_HEAD,/$i, 0, MCI_COMMAND_HEAD,/ig" dlls/mciavi32/mciavi_res.rc dlls/mciqtz32/mciavi_res.rc dlls/winmm/winmm_res.rc; done for i in MCI_CAPTURE MCI_MONITOR MCI_RESERVE MCI_SETAUDIO MCI_SIGNAL MCI_SETVIDEO MCI_QUALITY MCI_LIST MCI_UNDO MCI_CONFIGURE MCI_RESTORE; do j=`egrep "^#define $i\\W" include/digitalv.h | awk '{print $3}' | sed 's/0x0/0x00000/g'`; k=`echo $i | sed 's/MCI_//g'`; sed -i "s/${j}L, MCI_COMMAND_HEAD,/$i, 0, MCI_COMMAND_HEAD,/ig" dlls/mciavi32/mciavi_res.rc dlls/mciqtz32/mciavi_res.rc dlls/winmm/winmm_res.rc; done

1 0

Re: d3dx9: Implement D3DXFVFFromDeclarator. (try 2)
by Henri Verbeet 01 Sep '10

01 Sep '10

On 1 September 2010 02:40, Misha Koshelev <misha680(a)gmail.com> wrote: > + while (texture <= 8) What is the "texture == 8" case for? Also, it seems to me FVFs require texcoords to be assigned to consecutive texture units.

2 1

Re: [PATCH 4/6] winmm/tests: Add a few Open/Close MCI tests.
by testbot＠testbot.winehq.org 01 Sep '10

01 Sep '10

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=4900 Your paranoid android. === W98SE (32 bit mci) === mci.c:637: Test failed: Expect message 0001 from play to 250 wait notify mci.c:644: Test failed: got 0004 instead of MCI_NOTIFY_xyz 0000 from command after close

1 0

Re: [PATCH 2/6] winmm: Close MCI device after immediate auto-open commands.
by testbot＠testbot.winehq.org 01 Sep '10

01 Sep '10

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=4899 Your paranoid android. === W98SE (32 bit mci) === mci.c:613: Test failed: Expect message 0001 from play to 250 wait notify mci.c:620: Test failed: got 0004 instead of MCI_NOTIFY_xyz 0000 from command after close

1 0

Re: [PATCH 1/6] winmm: MCI open always creates an alias for subsequent commands.
by testbot＠testbot.winehq.org 01 Sep '10

01 Sep '10

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=4898 Your paranoid android. === W98SE (32 bit mci) === mci.c:681: Test failed: not enough time elapsed 58ms mci.c:737: Test failed: mci status position: 58

1 0

Re: [PATCH] wined3d: Add missing ckey, fx, and pal directdraw caps.
by Stefan Dösinger 01 Sep '10

01 Sep '10

Looks OK to me. (unless there are whitespace issues which I can't see in my current mail client) Am 01.09.2010 um 06:44 schrieb Octavian Voicu: > Fixes regression described in bug 24226. > --- > dlls/wined3d/directx.c | 7 ++++++- > 1 files changed, 6 insertions(+), 1 deletions(-) > > diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c > index 01b4e46..9e50f78 100644 > --- a/dlls/wined3d/directx.c > +++ b/dlls/wined3d/directx.c > @@ -4259,7 +4259,7 @@ static HRESULT WINAPI IWineD3DImpl_GetDeviceCaps(IWineD3D *iface, UINT Adapter, > int ps_selected_mode; > struct shader_caps shader_caps; > struct fragment_caps fragment_caps; > - DWORD ckey_caps, blit_caps, fx_caps; > + DWORD ckey_caps, blit_caps, fx_caps, pal_caps; > > TRACE_(d3d_caps)("(%p)->(Adptr:%d, DevType: %x, pCaps: %p)\n", This, Adapter, DeviceType, pCaps); > > @@ -4786,6 +4786,8 @@ static HRESULT WINAPI IWineD3DImpl_GetDeviceCaps(IWineD3D *iface, UINT Adapter, > WINEDDCAPS_COLORKEY | > WINEDDCAPS_COLORKEYHWASSIST | > WINEDDCAPS_ALIGNBOUNDARYSRC; > + pal_caps = WINEDDPCAPS_8BIT | > + WINEDDPCAPS_PRIMARYSURFACE; > > /* Fill the ddraw caps structure */ > pCaps->DirectDrawCaps.Caps = WINEDDCAPS_GDI | > @@ -4796,6 +4798,9 @@ static HRESULT WINAPI IWineD3DImpl_GetDeviceCaps(IWineD3D *iface, UINT Adapter, > WINEDDCAPS2_PRIMARYGAMMA | > WINEDDCAPS2_WIDESURFACES | > WINEDDCAPS2_CANRENDERWINDOWED; > + pCaps->DirectDrawCaps.CKeyCaps = ckey_caps; > + pCaps->DirectDrawCaps.FXCaps = fx_caps; > + pCaps->DirectDrawCaps.PalCaps = pal_caps; > pCaps->DirectDrawCaps.SVBCaps = blit_caps; > pCaps->DirectDrawCaps.SVBCKeyCaps = ckey_caps; > pCaps->DirectDrawCaps.SVBFXCaps = fx_caps; > -- > 1.7.0.4 > > >

1 0

Re: shell32: add stubbed SHGetKnownFolderPath
by Alexandre Julliard 01 Sep '10

01 Sep '10

Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> writes: > @@ -111,3 +111,8 @@ typedef [v1_enum] enum tagSHCOLSTATE > } SHCOLSTATE; > > typedef DWORD SHCOLSTATEF; > + > +typedef GUID KNOWNFOLDERID; > + > +typedef KNOWNFOLDERID *REFKNOWNFOLDERID; This doesn't match the PSDK definitions. -- Alexandre Julliard julliard(a)winehq.org

1 0

Fwd: [ANNOUNCE] Git User's Survey 2010
by Andrew Eikum 01 Sep '10

01 Sep '10

This mail was sent to the git mailing list today. Since we use Git here, I thought I'd bring it to everyone's attention. -------- Original Message -------- From: Jakub Narebski <jnareb(a)gmail.com> To: git(a)vger.kernel.org Subject: [ANNOUNCE] Git User's Survey 2010 Date: Tue, 31 Aug 2010 23:33:47 +0200 Hello all, We would like to ask you a few questions about your use of the Git version control system. This survey is mainly to understand who is using Git, how and why. The results will be published to the Git wiki on the GitSurvey2010 page (https://git.wiki.kernel.org/index.php/GitSurvey2010) and discussed on the git mailing list. The survey would be open from 1 September till 15 October 2010. Please devote a few minutes of your time to fill this simple questionnaire, it will help a lot the git community to understand your needs, what you like of Git, and of course what you don't like of it. The survey can be found here: http://tinyurl.com/GitSurvey2010 https://www.survs.com/survey/MUPYR8UJ4B

1 0

Re: user32: Add a bunch of GetWindowPlacement() tests, fix some simple cases.
by testbot＠testbot.winehq.org 01 Sep '10

01 Sep '10

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=4896 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

1 0

Re: msvcrt:string Fix codepage table 1361 (Korean Johab)
by GOUJON Alexandre 01 Sep '10

01 Sep '10

On 08/28/2010 02:12 PM, Alexandre Goujon wrote: > I know that libs/wine/c_1361.c is generated ("DO NOT EDIT!!"). > However (union cptable)cptable_1361.dbcs->lead_bytes needs to be modified according tests > [...] > diff --git a/libs/wine/c_1361.c b/libs/wine/c_1361.c > index b424cb1..50d2c47 100644 > --- a/libs/wine/c_1361.c > +++ b/libs/wine/c_1361.c > @@ -8902,6 +8902,6 @@ const struct dbcs_table cptable_1361 = > uni2cp_low, > uni2cp_high, > { > - 0x84, 0xd3, 0xd9, 0xde, 0xe0, 0xf9, 0x00, 0x00 > + 0x81, 0xd3, 0xd8, 0xde, 0xe0, 0xf9, 0x00, 0x00 > } > }; > May I ask some guidance to make this [1] patch accepted ? Tests prove that the values above needs to be modified. Actually, I don't know if "uni2cp_high" is generated from the Internet or cpmap.pl (maybe both) Anyway, I don't understand perl. May http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/KSC/JOHAB.TXT be wrong ? Or may Windows doesn't fully comply with unicode ? Thanks --- [1] : http://source.winehq.org/patches/data/65550

4 8

wanted: sample .avi file for MCI tests
by Joerg-Cyril.Hoehle＠t-systems.com 01 Sep '10

01 Sep '10

Hi, I'd like to perform perform some mciavi tests. For that I'd need a .avi with known characteristics, much like MS' clock.avi such as - known number of frames, e.g. 12 - visibly different frames for visual control (e.g. analog clock or digits 0-9) - audio channel not necessary (although the MCI can control it) Who could like to contribute such a file? There are already several dlls/tests/ that create .avis. I'm wondering what makes sense. - copy & paste useful code that creates one on the fly (like avifil32 seems to do?) - have it in a resource like qedit/tests/ does (if I understand it correctly?) - hook into one of the existing tests directories and add some mci tests there? - ...? For checking status position and seeking behaviour (hint: Wine differs from native), a file with known number of frames is best (unlike quartz/tests/ which seems to use whatever test.avi happens to lie in the directory, if any). I'd like to avoid skipping tests when a file is not present, unlike amstream/tests, quartz/tests/avisplitter and winmm/tests/mmio (skip => no coverage => regressions not found). Regards, Jörg Höhle

1 0

Chinese translation of key pages on wiki.winehq.org?
by Dan Kegel 01 Sep '10

01 Sep '10

Are there any Chinese speakers on the list? Any interest in starting a Chinese translation of wiki.winehq.org? I bring this up because a Chinese user/developer is asking for help getting started with submitting translations to Wine. I think he would find Chinese versions of http://wiki.winehq.org/SubmittingPatches and perhaps even http://wiki.winehq.org/Translating helpful. It seems strange for a translator to need help reading English documents, but perhaps it would help them come up the curve faster. - Dan

3 3

Wine 1.4 plans?
by Dan Kegel 01 Sep '10

01 Sep '10

I suppose we'll hear what the goals for 1.4 are at Wineconf, but here's my little wish list: Bug 6971, the mouse problem affecting many FPS-style games (Alexandre thinks it would take a month of his time?) Solving Wine's problems with Pulseaudio (bug #10495) Mono integration similar to the current Gecko integration (go Vincent!) Finishing d3dx9_36 and friends (i.e. getting rid of the need to run winetricks to load bits of Direct3D9) Excellent continuous build and test services at winehq.org, including performance tests (ok, this isn't really a wine feature) Move away from using 2D graphics acceleration, as Windows has done (this is both a superset and a subset of the DIBEngine idea) (heard this from Roderick)

4 3

Re: d3dx9: Implement D3DXFVFFromDeclarator.
by Henri Verbeet 31 Aug '10

31 Aug '10

On 30 August 2010 23:07, Misha Koshelev <misha680(a)gmail.com> wrote: > Looking forward to (constructive) comments. > Why are colors and normals special? What use is hasPosition? What happens when the source declaration has e.g. two color elements with usage index 0, or two position elements? Note that the booleans are redundant, you store that information in the FVF.

3 6

Re: kernel32/tests: Fix compilation on systems that don't support nameless unions or structs.
by testbot＠testbot.winehq.org 31 Aug '10

31 Aug '10

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=4872 Your paranoid android. === W98SE (32 bit process) === Failure running script in VM: Exceeded timeout limit of 315 sec

2 1

Re: [2/3] d3dx9: Implement D3DXCreateTextureFromFileInMemoryEx
by Henri Verbeet 31 Aug '10

31 Aug '10

On 26 July 2010 23:05, Owen Rudge <owen(a)owenrudge.net> wrote: > + if ((filter & 0xFFFF) > D3DX_FILTER_BOX && filter != D3DX_DEFAULT) > + return D3DERR_INVALIDCALL; > + > + if ((mipfilter & 0xFFFF) > D3DX_FILTER_BOX && mipfilter != D3DX_DEFAULT) > + return D3DERR_INVALIDCALL; > + > + if (!filter || !mipfilter) > + return D3DERR_INVALIDCALL; I think those should be handled implicitly by D3DXLoadSurfaceFromFileInMemory() / D3DXFilterTexture(). > + if (filter == D3DX_DEFAULT) > + filter = D3DX_FILTER_TRIANGLE | D3DX_FILTER_DITHER; > + > + if (mipfilter == D3DX_DEFAULT) > + mipfilter = D3DX_FILTER_BOX; Same. > + if (width == 0 || width == D3DX_DEFAULT_NONPOW2) > + width = imginfo.Width; Probably depends on the device supporting NPOT textures again. > + if ((pool != D3DPOOL_DEFAULT) && (usage != D3DUSAGE_DYNAMIC)) Dynamic textures are a device capability. (Yeah, this is a mostly unchanged copy of my earlier comments.)

2 1

Re: [PATCH 4/4] ws2_32: implement AcceptEx and GetAcceptExSockaddrs
by Alexandre Julliard 31 Aug '10

31 Aug '10

Mike Kaplinskiy <mike.kaplinskiy(a)gmail.com> writes: > /*********************************************************************** > + * WS2_async_recv_accept (INTERNAL) > + * > + * This function is used to finish the read part of an accept request. It is > + * needed to place the completion on the correct socket (listener). > + */ > +static NTSTATUS WINAPI WS2_async_recv_accept( void *arg, IO_STATUS_BLOCK *iosb, NTSTATUS status ) > +{ > + void *junk; > + struct ws2_accept_async *wsa = arg; > + > + status = WS2_async_recv( wsa->read, iosb, status, &junk ); > + if (status == STATUS_PENDING) > + return status; > + > + if (wsa->user_overlapped->hEvent) > + SetEvent(wsa->user_overlapped->hEvent); > + if (wsa->cvalue) > + WS_AddCompletion( HANDLE2SOCKET(wsa->listen_socket), wsa->cvalue, iosb->u.Status, iosb->Information ); > + HeapFree( GetProcessHeap(), 0, wsa->read ); > + HeapFree( GetProcessHeap(), 0, wsa ); > + > + return status; > +} > + > +/*********************************************************************** > + * WS2_async_accept (INTERNAL) > + * > + * This is the function called to satisfy the AcceptEx callback > + */ > +static NTSTATUS WINAPI WS2_async_accept( void *arg, IO_STATUS_BLOCK *iosb, NTSTATUS status ) > +{ These are not valid async callbacks, the way async callbacks work has changed since the patch was first written. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/3] Store header and trailer byte counts in schan_context for future use
by Henri Verbeet 31 Aug '10

31 Aug '10

On 30 August 2010 18:37, Mikko Rasa <tdb(a)tdb.fi> wrote: > + ctx->trailer_bytes = pgnutls_mac_get_key_size(pgnutls_mac_get(ctx->session)); ... > - stream_sizes->cbHeader = 5; > - stream_sizes->cbTrailer = mac_size + 256; /* Max 255 bytes padding + 1 for padding size */ > + stream_sizes->cbHeader = ctx->header_bytes; > + stream_sizes->cbTrailer = ctx->trailer_bytes; Does this imply TLS record padding should be disabled? I imagine an encrypted message may not fit in the application provided buffers otherwise.

2 1

Re: [PATCH] Only process full TLS frames in schan_DecryptMessage
by Hans Leidekker 31 Aug '10

31 Aug '10

On Mon, 2010-08-30 at 23:57 +0300, Mikko Rasa wrote: > + SIZE_T expected_size; > ssize_t received = 0; > ssize_t ret; > int idx; > - char *buf_ptr; > + unsigned char *buf_ptr; > unsigned int offset; > > TRACE("context_handle %p, message %p, message_seq_no %d, quality %p\n", > @@ -1230,12 +1243,22 @@ static SECURITY_STATUS SEC_ENTRY schan_DecryptMessage(PCtxtHandle context_handle > if (idx == -1) > return SEC_E_INVALID_TOKEN; > buffer = &message->pBuffers[idx]; > + buf_ptr = (unsigned char *)buffer->pvBuffer; > + > + expected_size = 5 + ((buf_ptr[3] << 8) | buf_ptr[4]); > + if(buffer->cbBuffer < expected_size) > + { > + TRACE("Expected %u bytes, but buffer only contains %u bytes\n", expected_size, buffer->cbBuffer); > + TRACE("Returning SEC_E_INCOMPLETE_MESSAGE\n"); > + return SEC_E_INCOMPLETE_MESSAGE; > + } This produces a compiler warning here: schannel.c: In function ‘schan_DecryptMessage’: schannel.c:1251: warning: format ‘%u’ expects type ‘unsigned int’, but argument 5 has type ‘SIZE_T’

1 0

Re: [PATCH 3/3] Fill buffers in schan_DecryptMessage the same way as windows does
by Hans Leidekker 31 Aug '10

31 Aug '10

On Mon, 2010-08-30 at 19:37 +0300, Mikko Rasa wrote: > - memcpy(buffer->pvBuffer, data, received); > - buffer->cbBuffer = received; > + buf_ptr = (char *)buffer->pvBuffer; You don't need this cast. > + offset = ctx->header_bytes; > + memcpy(buf_ptr + offset, data, received); > HeapFree(GetProcessHeap(), 0, data); > > + schan_decrypt_fill_buffer(message, SECBUFFER_DATA, buf_ptr + offset, received); > + offset += received; > + > + schan_decrypt_fill_buffer(message, SECBUFFER_STREAM_TRAILER, buf_ptr + offset, buffer->cbBuffer - offset); > + offset += ctx->trailer_bytes; > + > + if(buffer->cbBuffer > offset) > + schan_decrypt_fill_buffer(message, SECBUFFER_EXTRA, buf_ptr + offset, buffer->cbBuffer - offset); > + > + buffer->BufferType = SECBUFFER_STREAM_HEADER; > + buffer->cbBuffer = ctx->header_bytes; > + FWIW, this patch set passes my tests.

1 0

Re: widl: Added default __midl, _WIN32 and _WIN64 defines.
by Alexandre Julliard 31 Aug '10

31 Aug '10

Jacek Caban <jacek(a)codeweavers.com> writes: > They are defined by default by midl. __midl is supposed to be set to the midl compiler version, and I'm not entirely convinced it's appropriate for us to define it. Also, _WIN64 can't depend on how widl was built, since it can generate both 32-bit and 64-bit code. You'd have to parse everything twice if you wanted to make use of this. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: mmdevapi: Make MMDevice_[GS]etPropValue() static.
by Francois Gouget 31 Aug '10

31 Aug '10

http://source.winehq.org/patches/data/65442 According to http://source.winehq.org/patches/ this patch causes a build error (or maybe a new warning). However here (gcc 4.4) I see no warning at all. Does this patch cause warnings / errors for anyone? (it would be nice if the patches website could include the build error log<g>). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The nice thing about meditation is that it makes doing nothing quite respectable -- Paul Dean

3 3

Re: wined3d: separate driver info from GPU info (try3)
by Henri Verbeet 31 Aug '10

31 Aug '10

On 31 August 2010 00:46, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > In the previous version of this patch, no version info was returned > for Windows versions which were not in the table. I verified on > Vista/Win7 what version numbers, gpu names and driver strings are > returned to applications running in 9x/2k/xp compatibility mode. It > appears that by default (perhaps the shim database can override it?) > these applications receive information about the current drivers > instead of fake information. For now I'm returning XP driver info if > no match was found. > > Future patches will add the 9x/Vista/Win7 info. When we reach that > stage and a user uses a Geforce 8800 and winver=win98, it will behave > the same as Windows (I assume XP is the default version number). > No. This will simply break currently working functionality. Regardless, I think it's a design flaw anyway to require separate entries for different Windows versions even though they're using the same driver model.

1 0

Re: ddraw [patch 1/2]: SetCooperativeLevels with Normal+Fullscreen+Exclusive mode is authorized
by Octavian Voicu 31 Aug '10

31 Aug '10

Try running: git config --global color.ui auto This will activate colorful output for all git commands (in particular for `git diff' too). Then, when you run `git diff' from a terminal you will see whitespace errors (eg. trailing whitespace) highlighted with a red background. Hope it helps, Octavian

6 8

Re: [1/3] mscoree: Store the AppDomain from CorExeMain, for use in other functions.
by Juan Lang 30 Aug '10

30 Aug '10

Hi Vincent, + EnterCriticalSection(&mono_lib_cs); + if (!mono_handle) + { + ERR("CorExitProcess called on another thread?\n"); + return -1; you don't release mono_lib_cs here. Similarly, in patch 3, STDAPI ClrCreateManagedInstance(LPCWSTR pTypeName, REFIID riid, void **ppObject) (snip) + EnterCriticalSection(&mono_lib_cs); + if (!mono_handle) + { + ERR("CorExitProcess called on another thread?\n"); + return E_FAIL; you don't release mono_lib_cs here, and the error message looks suspicious. --Juan

2 2

DIB clarification
by Jeff Cook 30 Aug '10

30 Aug '10

I hate to stir the pot, especially as an unknown in the community, but I've spent the last few hours reading WINE's history regarding DIB engines and it is pretty distressing. I have seen expressions of frustration from many regarding the handling of the mostly-functional DIB engine that Massimo wrote. AJ's terseness on the issue is puzzling. I find it really weird that such a major and long-standing thing would just be left to languish without any detailed reasons. Though I do not believe it, you can start to see why the slashdotter described Codeweavers' corporate agenda as "evil"; it almost feels like Codeweavers is holding DIB hostage, just waiting for someone to get fed up and fork over the cash for it. This wouldn't be a problem of course if it appeared that Alexandre was willing to work with external developers on the DIB engine, but he has given very sparse criticism. Should we all just accept that Massimo's engine is yet another DIB engine gone to waste and there is no future hope for it at all? Max's statements to that effect can be confusing out of context because of his non-native English, but everything I have seen indicates that he is totally willing to work on upstream merging if Alexandre is willing to cooperate. All cases of saying "it won't get merged" etc. by Max seem to reference AJ's reluctance to provide useful criticism on the code that gets posted. It is not my intention to start another huge flamewar or thread on the matter. I just want to promote a reliable roadmap and help resolve this -- it seems like a total shame that there have been multiple DIB engines written and no parts of any of them were deemed worthy of inclusion in WINE. Max at least has indicated a desire to modify the code as necessary if a useful road map or ideation were provided, so why is it so hard to get the road map? Alexandre is right that the architecture is a lot of work, but I am not asking for him to write out a complete spec, and I don't think the community is, either; the main thing, as far as I can tell, is that the interaction and feedback on a major step forward for WINE has been minimal. People are still reporting major speedups on bug #421 so I don't think this is a lost cause unworthy of effort as some suggest. The most feedback I was able to find from Alexandre was on May 2009's DIB engine passing all tests thread at http://www.winehq.org/pipermail/wine-devel/2009-May/thread.html#75864 . Alexandre's single major standing complaints seem to be a lack of test cases and Massimo not establishing a good record with simple patches. Are those still valid reasons? The complaint regarding driver loading was addressed, but it sounds like Alexandre wants it in the opposite direction (forwarding calls from winex11.drv (or whatever driver) to winedib.drv instead of the other way around). Is that a very serious problem? So, if we can, let's get a few points down on what needs to be modified for DIB to make it into WINE, even as an experimental branch: 1) Write more gdi32 and any other relevant test cases to prove that the DIB engine is generally well-behaved 2) Reverse the DIB ordering and call winedib.drv only as needed, instead of passing everything through winedib.drv first. 3) ? Or, in the case that Max's DIB is gone forever and is considered irreparable, why don't we discuss what's needed for a different DIB engine? 1) Write more gdi32 and any other relevant test cases to prove that the DIB engine is generally well-behaved 2) Works well with any wine display driver. (already in Max's code) 3) Applied and developed cooperatively and incrementally with the WINE community 4) Easily disabled / non-disruptive (already in Max's code) 5) ? What else needs to go here? Is this accurate? Others mentioned that benchmarks that prove the usefulness of a DIB engine might help. Do those still need to be performed? Thanks for reading. From Jeff

10 10

Re: user32: Make GetWindowPlacement() work for other process windows. Take 2.
by Alexandre Julliard 30 Aug '10

30 Aug '10

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > This patch fixes the problem reported in the bug 12001. > > This version of the patch uses an internal message to fetch window state > from a foreign thread. Another aproach could be to store the window state in > the server, but that would require to introduce another server call for it. I'd be surprised if GetWindowPlacement required the other thread to be running a message loop on Windows... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 04/12] [Server]: enhanced the console input object so that it doesn't require a wineconsole to be running
by Alexandre Julliard 30 Aug '10

30 Aug '10

Eric Pouech <eric.pouech(a)orange.fr> writes: > + if (tcgetattr(fd, &term) < 0) fprintf(stderr, "Couldn't get termios\n"); > + console_input->termios = term; > + term.c_lflag &= ~(ECHO | ECHONL | ICANON | IEXTEN); > + term.c_iflag &= ~(BRKINT | ICRNL | INPCK | ISTRIP | IXON); Errors need to be handled properly in the server, you can't just print a message and continue as if nothing happened. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: DIB clarification
by James Mckenzie 30 Aug '10

30 Aug '10

Michael Stefaniuc <mstefani(a)redhat.com> wrote: > >Now that "that waive with $$$" isn't very likely as the cost/benefit >ratio isn't very good. More likely is that Codeweavers will start >working on a Quartz driver and that work will make the DIB engine >"cheaper" to implement. Again, this is my *personal* opinion. > I would like to add my *personal* comment to the above. Both the DIB engine and implementing Auqa/Quartz on Wine are HUGE projects that will take a lot of time. Huw Davis (sp?) and Max put a lot of time into the DIB project and according to Tom Wickline, Max is still working on it (see Tom's message on in this thread for more information.) Emmanual Mallard and others put in a lot of time on the Aqua/Quartz implementation without a full implementation and Emmanual (to my knowledge) stopped working on it almost two years ago. These both *appear* to be interlinked as the DIB engine has to be implemented before full functionality is available for Aqua/Quartz will work (these are not my words and this was posted here in the Wine Development List.) My words of caution were misread by others here. I was going to work on the Quartz project based upon work that I had participated in another FOSS project, but after looking it over very carefully, I decided to set it aside and work on other much smaller, bigger bang for the time, projects. One I have been working on for two years and that work had to be abandoned as the implementation was not correct (thank you AJ for pointing this out in very blunt words.) What to do about these two 'features' missing? Maybe CodeWeavers will pick them up (they may already have.) Maybe someone or a team will take them over. I will move onto fixing bugs and missing features that are 'important' to me and leave the rest to others who have more time and ambition. Thank everyone here for your words of encouragement and I will continue to work on the three functions I would like to see implemented that will make some of the 'fixmes' go away. James McKenzie

1 0

Re: [PATCH] winedbg: gdb proxy mode: support qAttached packet
by Eric Pouech 30 Aug '10

30 Aug '10

Paul Bolle a écrit : > Add support for the qAttached packet. Main benefit is that if gdb was > attached to a debuggee and it quits it will now ask if it should detach > from the debuggee instead of asking whether the debuggee should be > killed. (It still will ask whether the debuggee should be killed if it > launched the debuggee itself). > > Signed-off-by: Paul Bolle <pebolle(a)tiscali.nl> > --- > Would it be better to add a new member to gdbctx instead of using a > separate variable (qAttached_reply)? > yes, inclusion in gdbctx is preferred (and storage should rather be an integer rather than a string pointer) A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

2 1

Re: msvcrt:locale Properly fix setlocale and clean up tests
by Alexandre Julliard 30 Aug '10

30 Aug '10

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > I removed all broken() and ran the tests on all WineTestBot machines > (https://testbot.winehq.org/JobDetails.pl?Key=4829) > Then, I cleaned up tests accordingly : removed superflous broken() and extending ok(). > (https://testbot.winehq.org/JobDetails.pl?Key=4831) Now you are overdoing it. I said to remove broken() for minor spelling differences, not for everything. For instance confusing 936 and 950 codepages for Chinese is broken, it's not just a spelling difference. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 4/6] winealsa.drv: Append hw address to handle to prevent name collision. (resend)
by Vitaliy Margolen 30 Aug '10

30 Aug '10

On 08/02/2010 05:49 PM, Jeff Cook wrote: > --- > dlls/winealsa.drv/waveinit.c | 9 +++++++-- > 1 files changed, 7 insertions(+), 2 deletions(-) > + sprintf(description, "%s %d:%d", snd_pcm_info_get_name(infop), snd_pcm_info_get_card(infop), Please use snprintf to prevent possible buffer overflow. > + memcpy(ww->ds_desc.szDesc, description, > + min( (sizeof(ww->ds_desc.szDesc) - 1), strlen(description)) ); This does not guarantee that ww->ds_desc.szDesc will be \0 terminated. Vitaliy.

2 2

Re: ddraw [patch 1/2]: SetCooperativeLevels with Normal+Fullscreen+Exclusive mode is authorized
by James McKenzie 29 Aug '10

29 Aug '10

David Adam wrote: Looks like you are trying very hard to avoid the [try 4] moniker. Please add this to each version of the patch you are submitting. Use the notes feature of git commit to put in why you are submitting a new try. Second, if the patch will NOT apply due to whitespace issues, it will NOT be approved. Please read the Wiki page on Patches. Third, it really appears that you are avoiding the friendly advise given here. We are trying to help you prevent resubmit and then another resubmit for the same problem. You have already aggravated one reviewer that has attempted to help you get this patch accepted. James McKenzie

1 0

Re: ddraw [patch 1/2]: SetCooperativeLevels with Normal+Fullscreen+Exclusive mode is authorized
by Henri Verbeet 29 Aug '10

29 Aug '10

On 29 August 2010 20:45, David Adam <david.adam.cnrs(a)gmail.com> wrote: > - You clearly ignored my previous comments about trailing spaces. - This patch changes a lot more things than just allowing DDSCL_NORMAL | DDSCL_FULLSCREEN. E.g. the call to IWineD3DDevice_AcquireFocusWindow(). - Still needs more tests. For example, is the whole wndproc replacement stuff a property of DDSCL_EXCLUSIVE or a property of DDSCL_FULLSCREEN? - I'm not going to look at or comment on any patch with basic whitespace issues anymore.

1 0

Re: ddraw [patch 2/2]: Add more combinaison tests for SetCooperativeLevels
by testbot＠testbot.winehq.org 29 Aug '10

29 Aug '10

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=4844 Your paranoid android. === W98SE (32 bit ddrawmodes) === No test summary line found === W7PROX64 (64 bit ddrawmodes) === Timeout

1 0

Re: [PATCH 1/1] gameux/tests: verifying registry values created by GameExplorer (try 4)
by testbot＠testbot.winehq.org 29 Aug '10

29 Aug '10

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=4793 Your paranoid android. === W7PRO (32 bit gameexplorer) === gameexplorer.c:453: Test failed: failed while checking registry value (error 0x1) gameexplorer.c:471: Test failed: failed while checking registry value (error 0x1) === W7PROX64 (32 bit gameexplorer) === gameexplorer.c:453: Test failed: failed while checking registry value (error 0x1) gameexplorer.c:471: Test failed: failed while checking registry value (error 0x1) === W7PROX64 (64 bit gameexplorer) === gameexplorer.c:453: Test failed: failed while checking registry value (error 0x1) gameexplorer.c:471: Test failed: failed while checking registry value (error 0x1)

3 3

HEAP and FarCry installer
by wylda＠volny.cz 29 Aug '10

29 Aug '10

Hope i don't bother you much, but i guess you would tell me... I still have a problem with FarCry installer. During that i found HEAP issue - based on assumption, that message "Heap invalid in-use arena magic 00eefeee" is unhealthy. So program allocates 6fc bytes at 0x14c160 and free those bytes at the end of the following list, but immediately tries to free another heap at 14c188 which belongs to the freed area already, right?. Also there is no trace, that the program allocates that 14c188 memory. Is that bug or nothing unusual? Longer log attached. 0009:Call ntdll.RtlAllocateHeap(00110000,00000000,000006fc) ret=7dfef944 0009:Ret ntdll.RtlAllocateHeap() retval=0014c160 ret=7dfef944 0009:Call version.GetFileVersionInfoW(00157a88 L"C:\\Program Files\\Common Files\\InstallShield\\Driver\\9\\Intel 32\\IDriver.exe",00000000,000006fc,0014c160) ret=7dff45c1 ... 0009:Ret version.GetFileVersionInfoW() retval=00000001 ret=7dff45c1 0009:Call version.VerQueryValueW(0014c160,7e078b84 L"\\",0034beec,0034bee4) ret=7dff45e7 0009:Ret version.VerQueryValueW() retval=00000001 ret=7dff45e7 0009:Call ntdll.RtlFreeHeap(00110000,00000000,0014c160) ret=7dfefa1e 0009:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7dfefa1e 0009:Call ntdll.RtlFreeHeap(00110000,00000000,0014c188) ret=7dfefa1e warn:heap:HEAP_ValidateInUseArena Heap 0x110000: invalid in-use arena magic 00eefeee for 0x14c180 0009:Ret ntdll.RtlFreeHeap() retval=00000000 ret=7dfefa1e

2 1

d3d9 equivalent of D3DXFVFFromDeclarator?
by Misha Koshelev 29 Aug '10

29 Aug '10

Dear All: Thanks a lot Henri for your wonderful D3DXDeclaratorFromFVF patches. It is wonderful to be exposed to the "right" way to implement this function. I am starting to look at D3DXDeclaratorFromFVF, as this would be the next step before implementing ID3DXMesh. I am looking again at d3d9, but feel like I am running in circles a little bit trying to chase down where convFVF and convertedDecls is coming from. If you have any hints/advice, much appreciated. If there is a better place to look as well (like wined3d), please let me know. Thank you! Misha

2 3

Re: msvcrt:string Avoid size_t in ok()
by James McKenzie 29 Aug '10

29 Aug '10

Alexandre Goujon wrote: > --- > dlls/msvcrt/tests/string.c | 12 ++++++------ > 1 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/dlls/msvcrt/tests/string.c b/dlls/msvcrt/tests/string.c > index 94c2fa3..3c143d1 100644 > --- a/dlls/msvcrt/tests/string.c > +++ b/dlls/msvcrt/tests/string.c > @@ -1185,22 +1185,22 @@ static void test_mbstowcs(void) > mOut[4] = '!'; mOut[5] = '\0'; > > ret = mbstowcs(NULL, mSimple, 0); > - ok(ret == 4, "ret = %d\n", ret); > + ok(ret == 4, "mbstowcs did not returned 4\n"); > > Alexandre: Can we avoid a typo by substituting: "Did not returned <value>\n" with "Did not return <value>\n" for each instance in the file? Thank you. James McKenzie

2 1

Re: [PATCH 5/6] winealsa.drv: Don't open the same card on every loop. (resend)
by Alexandre Julliard 29 Aug '10

29 Aug '10

Jeff Cook <jeff(a)deserettechnology.com> writes: > @@ -753,7 +753,7 @@ static int ALSA_ScanDevices(int directhw, > char *pcmname = NULL; > snd_pcm_t *pcm; > > - sprintf(defaultpcmname, "default"); > + sprintf(defaultpcmname, "default:%d", card); We used to do that, but it was changed because it's not correct, cf. bug 10942. -- Alexandre Julliard julliard(a)winehq.org

2 1

HEAP corruption again?
by wylda＠volny.cz 29 Aug '10

29 Aug '10

Hi, i wonder what is wine trying to tell me by "just discovered" message: warn:heap:HEAP_ValidateInUseArena Heap 0x110000: invalid in-use arena magic 00555555 for 0x118c10 Is that some kind of corruption or harmless? I found out, that ARENA_INUSE_MAGIC should be 0x455355. Then ARENA_INUSE_FILLER is 0x55, so it looks to me, that wine overwrites 455355 by several 55 and then complains ;) What is it good for to put there 455355 and then intentionally overwrite(??) that by different value? W.

1 0

Help with 6120d7cc145, causing bugs
by Jeff Cook 29 Aug '10

29 Aug '10

Just wondering if I could get a bit more review on commit 6120d7cc145 which was committed in early August. Here's a link: http://source.winehq.org/git/wine.git/?a=commit;h=6120d7cc14522983fbc38026a… There have been a few bug reports filed against it recently, see http://bugs.winehq.org/show_bug.cgi?id=23902 and http://bugs.winehq.org/show_bug.cgi?id=24131 . It seems that in some relatively rare sound setups, an inappropriate sound element gets fed in to filllines_no_master which leads to a crash on audio initialize. To me this is weird because the program is currently written so that it flows into filllines_no_master only if there no is master control. A patch adding else if (micelem) instead of just else was recently committed and fixed at least one person's problem. Some people on the bug report are unable to provide full debug information so it makes this harder. If you have the time, please review the patch and let me know what errors you notice that may be causing the aforementioned bug. I am new to Wine dev so please forgive anything really stupid. :) Thanks From Jeff. -- Jeff Cook (801) 231-3157 jeff(a)deserettechnology.com

4 8

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

29 Aug '10

Jeff Cook <jeff(a)deserettechnology.com> writes: > @@ -245,6 +245,10 @@ static void fillcontrols(mixer *mmixer) > for (id = 0; id < mmixer->chans; ++id) > { > line *mline = &mmixer->lines[id]; > + if (!mline->elem) > + { > + break; > + } > int ofs = CONTROLSPERLINE * id; You can't do that: mixer.c: In function ‘fillcontrols’: mixer.c:252: error: ISO C90 forbids mixed declarations and code -- Alexandre Julliard julliard(a)winehq.org

5 5

Re: msvcrt:string Avoid size_t in ok()
by Jerome Leclanche 29 Aug '10

29 Aug '10

Not to be pedantic, but "did not return" is what you meant. J. Leclanche On Sat, Aug 28, 2010 at 2:38 PM, Alexandre Goujon <ale.goujon(a)gmail.com> wrote: > --- > dlls/msvcrt/tests/string.c | 12 ++++++------ > 1 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/dlls/msvcrt/tests/string.c b/dlls/msvcrt/tests/string.c > index 94c2fa3..3c143d1 100644 > --- a/dlls/msvcrt/tests/string.c > +++ b/dlls/msvcrt/tests/string.c > @@ -1185,22 +1185,22 @@ static void test_mbstowcs(void) > mOut[4] = '!'; mOut[5] = '\0'; > > ret = mbstowcs(NULL, mSimple, 0); > - ok(ret == 4, "ret = %d\n", ret); > + ok(ret == 4, "mbstowcs did not returned 4\n"); > > ret = mbstowcs(wOut, mSimple, 4); > - ok(ret == 4, "ret = %d\n", ret); > + ok(ret == 4, "mbstowcs did not returned 4\n"); > ok(!memcmp(wOut, wSimple, 4*sizeof(wchar_t)), "wOut = %s\n", wine_dbgstr_w(wOut)); > ok(wOut[4] == '!', "wOut[4] != \'!\'\n"); > > ret = wcstombs(NULL, wSimple, 0); > - ok(ret == 4, "ret = %d\n", ret); > + ok(ret == 4, "wcstombs did not returned 4\n"); > > ret = wcstombs(mOut, wSimple, 6); > - ok(ret == 4, "ret = %d\n", ret); > + ok(ret == 4, "wcstombs did not returned 4\n"); > ok(!memcmp(mOut, mSimple, 5*sizeof(char)), "mOut = %s\n", mOut); > > ret = wcstombs(mOut, wSimple, 2); > - ok(ret == 2, "ret = %d\n", ret); > + ok(ret == 2, "wcstombs did not returned 2\n"); > ok(!memcmp(mOut, mSimple, 5*sizeof(char)), "mOut = %s\n", mOut); > > if(!setlocale(LC_ALL, "Japanese_Japan.932")) { > @@ -1209,7 +1209,7 @@ static void test_mbstowcs(void) > } > > ret = mbstowcs(wOut, mHiragana, 6); > - ok(ret == 2, "ret = %d\n", ret); > + ok(ret == 2, "mbstowcs did not returned 2\n"); > ok(!memcmp(wOut, wHiragana, sizeof(wHiragana)), "wOut = %s\n", wine_dbgstr_w(wOut)); > > ret = wcstombs(mOut, wHiragana, 6); > -- > 1.7.0.4 > > > >

1 0

winebuild on sparc, RFC
by Austin English 28 Aug '10

28 Aug '10

Howdy, Out of curiosity, I've been testing compiling Wine on Sparc. I've sent a few patches to fix a few problems that have crept up over the years. There are two big bugs left though: http://bugs.winehq.org/show_bug.cgi?id=24050 and http://bugs.winehq.org/show_bug.cgi?id=24142 The first blocks running wine, the second blocks building it. For the second, however, I found an old patch: http://www.mail-archive.com/wine-devel@winehq.org/msg23307.html and rediffed it to current wine. With it, wine mostly compiles (mshtml gets a 'Bus error' when compiling, but no gcc warning/error). I'm not sure if the patch is correct, and I've contacted Eric to ask him to submit the patch, but didn't receive a reply. If it's correct, I'll send it in, with his name on it. So, those of you who know winebuild (or better yet, Sparc), would you please check the attached patch. Thanks! -Austin

2 1

dbghelp: Remove unused functions?
by Andrew Talbot 28 Aug '10

28 Aug '10

Hi, Static functions pe_get_sect() and pe_get_sect_size() in dbghelp/pe_module.c are not called. May I remove them or does anyone have plans for them? Thanks, Andy.

2 1

Re: [PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit.
by Octavian Voicu 27 Aug '10

27 Aug '10

On Fri, Aug 27, 2010 at 4:25 PM, Eric Pouech <eric.pouech(a)orange.fr> wrote: > 2010/8/27 Octavian Voicu octavian.voicu(a)gmail.com >> I didn't think it was necessary to test on native systems. The command >> parsing looks like internal winmm stuff, which makes no difference to >> the exported interfaces, as long as the command string is parsed into >> the corresponding MCI_ structures correctly. > > no the format of MCI string tables is public, and Wine aims at supporting > native MCI drivers (which can come with their own tables) > so binary compatibility in RC files is required We don't have this right now. Native winmm.dll uses integer resource ids (id 200 for core commands, and the MCI_DEVTYPE_ constants for the rest; can't figure what device is 524 though, last device is MCI_DEVTYPE_SEQUENCER which is 523). Wine currently uses string ids, with a table to map device ids to device name strings. Also, winmm_res.rc and others looks really bad because they use numeric constants (eg. 0x00000803L instead of MCI_OPEN, 0). >>In any case, using the MCI_XYZ_PARMS union looks much better :) Maybe >>also stick MCI_GENERIC_PARMS in there. > I don't agree here. IMO the parser should be the most agnostic possibly > against the real data structures (the MCI string table shall contain the > definition of the structures including type of data). so, using unions and > structures is going into the right direction (even if I agree that current > parser doesn't fully comply with that goal) Not sure if I understand exactly what you mean here. Bottom line is that unions & structures are the way to go, like in Joerg's patch, but maybe try to make it look prettier? Octavian PS: found this really useful pdf documenting MCI: http://mediaxw.sourceforge.net/files/tmp/Windows%20NT%20DDK%20-%20Multimedi…

1 0

Re: msvcrt:locale Properly fix setlocale()
by Alexandre Julliard 27 Aug '10

27 Aug '10

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > @@ -431,7 +431,7 @@ static void test_setlocale(void) > ret = setlocale(LC_ALL, "non"); > ok(ret != NULL || broken (ret == NULL), "ret == NULL\n"); > if(ret) > - todo_wine ok((!strcmp( ret, "Norwegian-Nynorsk_Norway.1252")) > + ok((!strcmp( ret, "Norwegian-Nynorsk_Norway.1252")) > || broken(!strcmp(ret, "Norwegian (Bokmål)_Norway.1252")) > || broken(!strcmp(ret, "Norwegian_Norway.1252")) > || broken(!strcmp(ret, "Norwegian (Nynorsk)_Norway.1252")), "ret = %s\n", ret); > @@ -453,7 +453,7 @@ static void test_setlocale(void) > ret = setlocale(LC_ALL, "norwegian-nynorsk"); > ok(ret != NULL || broken (ret == NULL), "ret == NULL\n"); > if(ret) > - todo_wine ok(!strcmp(ret, "Norwegian-Nynorsk_Norway.1252") > + ok(!strcmp(ret, "Norwegian-Nynorsk_Norway.1252") > || broken(!strcmp(ret, "Norwegian_Norway.1252")) > || broken(!strcmp(ret, "Norwegian (Nynorsk)_Norway.1252")) > || broken(!strcmp(ret, "Norwegian (Bokmal)_Norway.1252")) I don't think it makes sense to declare minor spelling differences as broken, or to change the kernel resources for this. -- Alexandre Julliard julliard(a)winehq.org

2 2

Fwd: [PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit.
by Octavian Voicu 27 Aug '10

27 Aug '10

For some reason I forgot to hit reply to all. ---------- Forwarded message ---------- From: Octavian Voicu <octavian.voicu(a)gmail.com> Date: Thu, Aug 26, 2010 at 2:15 PM Subject: Re: [PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit. To: Joerg-Cyril.Hoehle(a)t-systems.com On Thu, Aug 26, 2010 at 1:11 PM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > are you aware of bug http://bugs.winehq.org/show_bug.cgi?id=22146 > and the partial patch and additional test cases there? First of all, I wasn't aware of it, so thanks for pointing it out. I just saw the crash on my system and tried to fix it; to my shame, I didn't search wine bug database. Sorry for the duplicate work. >>winmm: Add MCI_INTEGER_PTR return type for DWORD_PTR return values. >>+#define MCI_INTEGER_PTR 13 > What kind of testing did you perform on native systems to derive the existence of this value? > If such value does not exist, then I fear your patch set looses the ability to > drop in native dlls for compatibility testing and validation. > If it exists, then it's good news you found it. The only testing I ran is winmm:mci tests. With my patch set, 27 tests fail on 64 bit (compared to 23 on 32bit). I'm guessing the 4 extra failures are in other parts of the code. Not sure about TODOs, as I had no tests marked as TODO when I ran the tests from command line (the 23 tests that also fail on 32-bit are definitely marked as TODOs on test.winehq.org). I didn't think it was necessary to test on native systems. The command parsing looks like internal winmm stuff, which makes no difference to the exported interfaces, as long as the command string is parsed into the corresponding MCI_ structures correctly. MCI_GetDWord, MCI_GetString, MCI_ParseOptArgs, MCI_HandleReturnValues, the functions which I modified, are explicitly listed as internal functions. I just looked in mmddk.h and they have this: #ifdef _WIN64 #define MCI_INTEGER64 13 #endif // _WIN64 Which is really funny, because I wrote that patch without knowing anything about that. Gonna take a look at resources inside a 64-bit winmm.dll and report back, but it is pretty obvious what I'll find -- they wouldn't define MCI_INTEGER64 for nothing. >>-static DWORD MCI_ParseOptArgs(DWORD_PTR* data, int _offset, LPCWSTR lpCmd, >>+static DWORD MCI_ParseOptArgs(BYTE* data, int _offset, LPCWSTR lpCmd, >>- if (!MCI_GetDWord(&(data[offset+0]), &args) || >>- !MCI_GetDWord(&(data[offset+1]), &args) || >>- !MCI_GetDWord(&(data[offset+2]), &args) || >>- !MCI_GetDWord(&(data[offset+3]), &args)) { >>+ if (!MCI_GetDWord(data+offset+0*sizeof(DWORD), &args) || >>+ !MCI_GetDWord(data+offset+1*sizeof(DWORD), &args) || >>+ !MCI_GetDWord(data+offset+2*sizeof(DWORD), &args) || >>+ !MCI_GetDWord(data+offset+3*sizeof(DWORD), &args)) { > > The MCI_XYZ_PARMS structures are neither DWORD_PTR, not BYTE*, > they are DWORD with some DWORD_PTR in between. > Wouldn't using DWORD* data help avoid such pointer arithmetic > and eliminate several hunks of the patch ? The reason for which I opted for a BYTE* is so that I can use sizeof() to increment the pointer correctly. DWORD_PTR has a different size of 32- and 64-bit systems, so using DWORD* would make it more complicated to increment with sizeof(DWORD_PTR). Another reason is that offset is now in bytes, so supplying a pointer of different size wouldn't make much sense. Argument type in MCI_GetDWord and MCI_GetString was changed for consistency, it wouldn't matter very much there. For the same reason I changed all the &data[offset] into data+offset. In any case, using the MCI_XYZ_PARMS union looks much better :) Maybe also stick MCI_GENERIC_PARMS in there.

2 1

Try 4: SetCooperative Levels with Normal+Fullscreen+Exclusive is authorized
by paulo lesgaz 27 Aug '10

27 Aug '10

Hello, I modified my patch to follow Henri's and Stefan's requests and hints. Do you have more observations to do with this one? As previously, all the tests go on passing. A+ David

2 1

Fwd: [PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit.
by Octavian Voicu 27 Aug '10

27 Aug '10

Same here. ---------- Forwarded message ---------- From: Octavian Voicu <octavian.voicu(a)gmail.com> Date: Thu, Aug 26, 2010 at 3:12 PM Subject: Re: [PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit. To: Joerg-Cyril.Hoehle(a)t-systems.com On Thu, Aug 26, 2010 at 2:15 PM, Octavian Voicu <octavian.voicu(a)gmail.com> wrote: > I just looked in mmddk.h and they have this: > > #ifdef _WIN64 > #define MCI_INTEGER64 13 > #endif // _WIN64 > > Which is really funny, because I wrote that patch without knowing > anything about that. Gonna take a look at resources inside a 64-bit > winmm.dll and report back, but it is pretty obvious what I'll find -- > they wouldn't define MCI_INTEGER64 for nothing. I can confirm it, the 64-bit dll uses MCI_INTEGER64 (0x0000000D), while the 32-bit one uses MCI_INTEGER. Maybe we should also have #ifdefs in mmddk.h and winmm_res.rc. So, do you want to fix your patches and send them, or do you want me to continue working on this patch set? You should also send the mciParser test (btw, I tested my patch set with your extra tests and they all pass). Octavian

1 0

Any idea how to solve that ?
by GOUJON Alexandre 27 Aug '10

27 Aug '10

Hi, No one have replied for my ["Spanish - Modern Sort_Spain.1252" locale on wine] mail. So I'm asking again if someone has an idea. If solved, msvcrt:locale test on wine will pass without any error. The situation is the following : setlocale(LC_ALL, "esn"); > ok(!strcmp(ret, "Spanish_Spain.1252") setlocale(LC_ALL, "spanish-modern"); > ok(!strcmp(ret, "Spanish - Modern Sort_Spain.1252") with static const char * const _country_synonyms[] = { ... "spanish-modern", "esn" } -> this has to be changed since above tests prove they're not the same I submitted a job for the WineTestBot for finding what esX '=' Spanish - Modern Sort_Spain.1252 And the result is : none. So, should I create another esX ? What template for this new one ? Another idea ? Each todo_wine we remove may resolve (or prevent) bugs.

1 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel