March 2011 - Wine-Devel - list.winehq.org

Re: programs/dxdiag: beginnings of support for /t option

by Drew Goodwin

Thanks for the feedback Henri! Andrew Nguyen also gave some comments. We address the issue and resubmit today or over the weekend. On Fri, Mar 11, 2011 at 7:20 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 10 March 2011 20:35, Drew Goodwin <drew(a)drewgoodwin.com> wrote: > > + length = MultiByteToWideChar(0, 0, name, -1, NULL, 0)+1; > > + { > > + /* Allocate on the stack */ > > + WCHAR nameW[length]; > Oh, and variable length arrays are a C99 feature, Wine tries to mostly > stick to C89. >

March 11, 2011

Re: programs/dxdiag: beginnings of support for /t option

by Henri Verbeet

On 10 March 2011 20:35, Drew Goodwin <drew(a)drewgoodwin.com> wrote: > + length = MultiByteToWideChar(0, 0, name, -1, NULL, 0)+1; > + { > + /* Allocate on the stack */ > + WCHAR nameW[length]; Oh, and variable length arrays are a C99 feature, Wine tries to mostly stick to C89.

March 11, 2011

New winetricks 20110311b: winetricks is dead, long live winetricks

by Dan Kegel

winetricks-20110311b is now released. Changes since winetricks-20110123 (for anyone who has not been using the alpha versions): - manages multiple wineprefixes - apps are now installed into separate wineprefixes by default - gui now split into separate pages for games, benchmarks, apps, dlls, fonts - gui now shows approximate disk requirement and install times - gui now lets you pick silent installation mode - apps that are broken (e.g. have drm that wine can't handle) are now hidden by default, gui has a button to reveal them - 70 games added, including Dragon Age II demo, Starcraft II demo, Mass Effect 2, and Mass Effect 2 demo - many updates and bugfixes Changes since winetricks-alpha-20110310: - mdac25, mdac27 removed, as downloads no longer available - mdac28: updated to sp1 - sizes/times in gui updated. (Most show download + install time; a future release will show just install time.) For bug tracker, mailing lists, and wiki, see http://winetricks.org Download url: http://winetricks.org/winetricks

March 11, 2011

Re: [PATCH 1/6] user32: Add get/release routines for accessing cursor frames.

by Alexandre Julliard

Erich Hoover <ehoover(a)mines.edu> writes: > @@ -135,6 +139,16 @@ static void release_icon_ptr( HICON handle, struct cursoricon_object *ptr ) > release_user_handle_ptr( ptr ); > } > > +struct static_cursoricon_object *get_icon_data( struct cursoricon_object *obj, int istep ) > +{ > + return &obj->frames[istep]; > +} > + > +void release_icon_data( struct cursoricon_object *obj, int istep, struct static_cursoricon_object *icon_data ) > +{ > + /* placeholder */ > +} I find your data structures confusing. You add a concept of icon_data separate from icon_ptr, but it doesn't correspond to the data structures, there's no such thing as an icon_data. There should be a way of making this clearer. -- Alexandre Julliard julliard(a)winehq.org

March 11, 2011

re: links down

by Dan Kegel

Looks like 2.8 sp1 is still up, though: http://www.microsoft.com/downloads/en/details.aspx?familyid=78cac895-efc2-4… I'll update winetricks, thanks. (And I'll put together a fast link checker for winetricks; doing a full run with an empty cache takes too long to be a good way of noticing broken links.) Wish I'd noticed this sooner!

March 11, 2011

Re: programs/dxdiag: beginnings of support for /t option

by Henri Verbeet

On 10 March 2011 20:35, Drew Goodwin <drew(a)drewgoodwin.com> wrote: > I'm a CS student at UCLA. I and some classmates are adding features to > wine's dxdiag. Here's the first patch, with code by Steve Feng, Andrew > Freer, and myself, properly copyrighted and licensed under the LGPL. Once > this is accepted, we will send a series of patches to support the remaining > sections in the /t option and the /x option, and add a working gui. > Just some random comments, this is by no means a proper review: > -EXTRADEFS = -DWINE_NO_UNICODE_MACROS > +EXTRADEFS = -DWINE_NO_UNICODE_MACROS -D__WINE__ What do you need __WINE__ for? > +IMPORTS = advapi32 comdlg32 comctl32 d3d9 d3dx9 ddraw dsound dxguid gdi32 kernel32 ole32 oleaut32 shell32 user32 winmm > + That's a lot of imports, do you really need all of those in this patch? > +HINSTANCE g_hinstance; The way you're using this, that's just a slightly odd way to write "NULL". > + sysinfo = malloc(sizeof(DxDiag_SystemInfo)); You should typically use HeapAlloc() for memory allocation in Wine, except for rare cases where you pass the result to a library function that free()'s it. You also leak the sysinfo, but perhaps that's ok as long as you exit right after being done with it. The "g_dxdiagcom_root" global isn't very useful, just pass it to OutputPlainFile() directly.

March 11, 2011

Re: include: Add rmxftmpl.h header.

by Alexandre Julliard

Dylan Smith <dylan.ah.smith(a)gmail.com> writes: > Manually parsed a hexdump of D3DRM_XTEMPLATES from the native header; > comments to show the corresponding text encoding. I used a test > application to dump D3DRM_XTEMPLATES with this header and the native > header to confirm that this header binary compatible with the native one. That stuff needs to be generated from source, you can't just copy the native header contents. -- Alexandre Julliard julliard(a)winehq.org

March 11, 2011

re: wineport: Use a lookup table to make our slow ffs() a bit faster.

by Dan Kegel

Do you actually have a system that doesn't have HAVE_FFS set? On my machine, int main(int argc, char **argv) { return ffs(argc); } compiles to pushl %ebp movl %esp, %ebp movl $-1, %edx bsfl 8(%ebp), %eax cmove %edx, %eax addl $1, %eax popl %ebp ret which is probably pretty fast. Large lookup tables can dirty the L1 cache and slow other things down. See also http://stackoverflow.com/questions/757059/position-of-least-significant-bit…

March 11, 2011

Re: cryptnet/tests: Partially revert commit de6e33f306a3b1b424ad1a9c41e85d3692ef9e4d

by Joris Huizer

Hello, I found a small (copy/paste) mistake in this patch: - /* w2k3,XP, newer w2k: CRYPT_E_NO_MATCH */ - ok(!ret && (GetLastError() == CRYPT_E_NO_MATCH), + /* w2k3,XP, newer w2k: CRYPT_E_NO_MATCH, older w2k: CRYPT_E_ASN1_BADTAG */ + ok(!ret && (GetLastError() == CRYPT_E_NO_MATCH || + broken(GetLastError() == CRYPT_E_NO_MATCH)), The comment indicates the alternative error, but the actual code doesn't check that one HTH, Joris

March 11, 2011

Re: wineport: Add fast builtin & asm versions of ffs() + ctz() where supported.

by Alexandre Julliard

Adam Martinson <amartinson(a)codeweavers.com> writes: > @@ -236,7 +241,40 @@ extern int getopt_long_only (int ___argc, char *const *___argv, > #endif /* HAVE_GETOPT_LONG */ > > #ifndef HAVE_FFS > -int ffs( int x ); > + #if defined(__i386__) || defined(__x86_64__) > + #define HAVE_FFS > + static inline int ffs( int x ) > + { > + if (!x) > + { > + return 0; > + } > + else > + { > + int ret; > + __asm__("bsfl %1, %0; incl %0" : "=r" (ret) : "r" (x)); > + return ret; > + } > + } > + #elif defined(__GNUC__) && GCC_VERSION >= 29503 > + #define HAVE_FFS > + #define ffs(x) __builtin_ffs(x) > + #else > + int ffs( int x ); > + #endif > +#endif You'd have to show benchmarks to prove that this complexity is necessary. Given that ffs() should already be inlined on all decent platforms, I doubt you'd be able to demonstrate a difference (if anything, your version would be slower because of the extra increment). -- Alexandre Julliard julliard(a)winehq.org

March 11, 2011

Re: wineport: Use a lookup table to make our slow ffs() a bit faster.

by Alexandre Julliard

Henri Verbeet <hverbeet(a)gmail.com> writes: > Something like the following may be faster: > > static const int bit_pos[] = > { > 0x00, 0x01, 0x0e, 0x02, 0x0f, 0x1b, 0x12, 0x03, > 0x1e, 0x10, 0x1c, 0x16, 0x18, 0x13, 0x0a, 0x04, > 0x1f, 0x0d, 0x1a, 0x11, 0x1d, 0x15, 0x17, 0x09, > 0x0c, 0x19, 0x14, 0x08, 0x0b, 0x07, 0x06, 0x05, > }; > const unsigned int c = 0x7dc4d65; > return bit_pos[((x & -x) * c) >> 27]; > > I'd expect that mostly due to eliminating the branches and the > implicit shift & mask operations in something like "y.c[1]". Maybe, but there's no point. This is just a fallback implementation for broken platforms, any platform that we care about should never use this. -- Alexandre Julliard julliard(a)winehq.org

March 11, 2011

Re: wineport: Use a lookup table to make our slow ffs() a bit faster.

by Henri Verbeet

Something like the following may be faster: static const int bit_pos[] = { 0x00, 0x01, 0x0e, 0x02, 0x0f, 0x1b, 0x12, 0x03, 0x1e, 0x10, 0x1c, 0x16, 0x18, 0x13, 0x0a, 0x04, 0x1f, 0x0d, 0x1a, 0x11, 0x1d, 0x15, 0x17, 0x09, 0x0c, 0x19, 0x14, 0x08, 0x0b, 0x07, 0x06, 0x05, }; const unsigned int c = 0x7dc4d65; return bit_pos[((x & -x) * c) >> 27]; I'd expect that mostly due to eliminating the branches and the implicit shift & mask operations in something like "y.c[1]".

March 11, 2011

Re: wined3d/context: Remove a trivial call to context_validate_onscreen_formats() in context_apply_blit_state().

by Henri Verbeet

On 10 March 2011 20:22, Adam Martinson <amartinson(a)codeweavers.com> wrote: > - context_validate_onscreen_formats(device, context, NULL); > + /* It's silly to call context_validate_onscreen_formats() with a NULL depth_stencil. */ Sigh. I've asked you a very simple question about the performance impact of these changes *twice* now, and you ignored the question both times. Unless you have evidence that the compiler fails to eliminate the call by itself, and this actually makes any kind of difference, consistency is more important. The same goes for the IWineD3DDeviceImpl_MarkStateDirty() change, though at least in that case there's somewhat of a remote chance of it making a difference.

March 11, 2011

Re: wininet(4/7): Implement commiting a url cache entry that already existed (try 2)

by Alexandre Julliard

Juan Lang <juan.lang(a)gmail.com> writes: > With the previous patches applied, this no longer fails for me on > Alexandre's apparently corrupt index.dat. Note that the index.dat I sent you was created from scratch, by running the wininet tests in an empty wineprefix. So if it's really corrupt it means wininet has corrupted it. It would probably be a good idea to fix this first. -- Alexandre Julliard julliard(a)winehq.org

March 11, 2011

Re: msxml3: Ignore XML Property ResolveExternals

by Nikolay Sivov

On 3/11/2011 13:46, Alistair Leslie-Hughes wrote: > Hi, > > > Changelog: > msxml3: Ignore XML Property ResolveExternals Please correct naming: static const WCHAR PropertyNewParserW[] = {'N','e','w','P','a','r','s','e','r',0}; static const WCHAR PropValueXPathW[] = {'X','P','a','t','h',0}; static const WCHAR PropValueXSLPatternW[] = {'X','S','L','P','a','t','t','e','r','n',0}; +static const WCHAR PropValueResolveExternalsW[] = {'R','e','s','o','l','v','e','E','x','t','e','r','n','a','l','s',0}; It's not a value, it's a property with boolean value, so it's PropertyResolveExternalsW. > > > Best Regards > Alistair Leslie-Hughes

March 11, 2011

Re: correct comctl32 implementation

by Nikolay Sivov

On 3/11/2011 06:22, Andrew Green wrote: > I have been researching how i could implement the gsoc Theming - > Implement Wine theming support. > Though I'm a bit confused what is wanted. > So is the case that completely separate dll's should be written for > different versions and be loaded by side-by-side assembly. > So you would end up with "comctl32v5.dll","comctl32v6.dll","comctl32v7.dll"? > Would these be 3 different code basses or should they be made to share > most of there code? Multiple comctl32 should be the last thing to think about, only if there's absolutely no way to implement everything needed in one comctl32. > > From what I understand uxtheme already loads XP theme files. So would > all the work be isolated to creating different versions of comdlg32 > and comctl32? No sure what you mean. uxtheme purpose is to load theme data, draw theme primitives and retrieve theme components data. Client dll such as comctl32 should only use that public api when drawing controls, that's all. Also comdlg32 was never a question, cause it doesn't provide new controls. > Also does wine support side by side assembly? I did a very quick > google search and i didn't see anything. Yes wine does support installation and loading of SxS assemblies, and by assembly I mean native dlls installed in SxS directory and referenced with embedded or external manifest file. Loader supports manifest files, not fully but simple things should work. > I hope I'm not asking too much at once and/or too silly questions. No, it's not silly to ask at all. But one of the most important things to be done for that is to implement support of window class redirection. In version 6 all user32 controls are reimplemented with theme support in comctl32, while user32 classes are kept of course. This is done with specific entries in comctl32 manifest, on load comctl32 all builtin classes are re-registered to the ones from comctl32. I definitely want to see some solution for that, having themed comctl32 controls while scrollbars and buttons are drawn with default appearance makes theme support kind of useless.

March 11, 2011

correct comctl32 implementation

by Andrew Green

I have been researching how i could implement the gsoc Theming - Implement Wine theming support. Though I'm a bit confused what is wanted. So is the case that completely separate dll's should be written for different versions and be loaded by side-by-side assembly. So you would end up with "comctl32v5.dll","comctl32v6.dll","comctl32v7.dll"? Would these be 3 different code basses or should they be made to share most of there code? >From what I understand uxtheme already loads XP theme files. So would all the work be isolated to creating different versions of comdlg32 and comctl32? Also does wine support side by side assembly? I did a very quick google search and i didn't see anything. I hope I'm not asking too much at once and/or too silly questions.

March 11, 2011

Re: wininet(7/7): Delete the cache file when it's no longer referenced (resend)

by Marvin

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=9868 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

March 11, 2011

Re: wininet(6/7): Delete cache entries when their use count reaches 0

by Marvin

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=9867 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

March 11, 2011

Re: [PATCH 6/6] user32: Add support for sequence-based animated cursors.

by Erich Hoover

On Thu, Mar 10, 2011 at 9:41 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 10 March 2011 07:42, Erich Hoover <ehoover(a)mines.edu> wrote: > > @@ -940,6 +954,7 @@ done: > > #define ANI_seq__ID RIFF_FOURCC('s', 'e', 'q', ' ') > > ... > > +#define ANI_seq_ID RIFF_FOURCC('s', 'e', 'q', ' ') > Just happened to notice this, but I doubt there's much point in having > two different defines for sequence chunks. Thank you for spotting this mistake, I must have a looked right over it. Erich Hoover ehoover(a)mines.edu

March 11, 2011

Re: Failing kernel32:change and ntdll:change tests on Mac OS

by Ken Thomases

On Mar 10, 2011, at 4:20 PM, Ken Thomases wrote: > I doubt Alexandre would accept reworking wineserver around CFRunLoop, but I can think of several alternatives: > > 1) Have the wineserver spin off a secondary thread to run the CFRunLoop and then communicate to the main thread via a file descriptor. I think, though, that keeping the wineserver single-threaded is important, too. > > 2) Do this in Wine's userland, like in a service. > > 3) Do this in a non-Wine process spun off from the wineserver for the sole purpose of bridging the notifications from a CFRunLoop/Mach port-based mechanism to a file descriptor. 4) Use kqueue directly, with its vnode filter. It would entail opening every directory in a hierarchy, which might be deemed prohibitive. -Ken

March 10, 2011

Re: [4/4] d3d8: Test depth stencil size mismatches

by Stefan Dösinger

Am Donnerstag 10 März 2011, 22:15:39 schrieb Henri Verbeet: > You could just ask wined3d for the surface size. Yes, with the overhead of two Surface::GetDesc calls per SetRenderTarget call.

March 10, 2011

Re: Failing kernel32:change and ntdll:change tests on Mac OS

by Ken Thomases

On Mar 10, 2011, at 2:47 PM, Charles Davis wrote: > The Change Notification tests all fail miserably on my machine (a 2009 > Mac Pro with Mac OS X 10.6), because that feature hasn't been > implemented on Mac yet. > > I could implement it for 10.5 up, but the problem is that the "public" > API for Change Notifications on Mac (the "FSEvents" API, in > CoreServices.framework) expects clients to either use a CFRunLoop or (on > 10.6 and up) a GCD dispatch queue. I'm sure this won't sit well with AJ. > I guess the real question is, which way should we do this? If we do it > the first way (using the public and documented but kqueue-unfriendly > Carbon API), wineserver has to use a CFRunLoop (or, if we're no longer > concerned about Leopard, a GCD dispatch queue) in its main loop, and if > we do it the second way (using the undocumented and unstable but > kqueue-friendly Unix API), wineserver needs to run as root, and may need > to cope with API changes. Based on what I've heard, I'm leaning toward > the second way, but I want your guys' input before I go ahead. The second way strikes me as truly hideous. I doubt Alexandre would accept reworking wineserver around CFRunLoop, but I can think of several alternatives: 1) Have the wineserver spin off a secondary thread to run the CFRunLoop and then communicate to the main thread via a file descriptor. I think, though, that keeping the wineserver single-threaded is important, too. 2) Do this in Wine's userland, like in a service. 3) Do this in a non-Wine process spun off from the wineserver for the sole purpose of bridging the notifications from a CFRunLoop/Mach port-based mechanism to a file descriptor. Regards, Ken

March 10, 2011

Re: [PATCH 3/4] mshtml: Added IHTMLPrivateWindow_GetAddressBarUrl implementation

by Marvin

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=9859 Your paranoid android. === WXPPROSP3 (32 bit htmldoc) === htmldoc.c:3564: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3526: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3557: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3564: Test failed: unexpected address bar url: L"about:replace" === WVISTAADM (32 bit htmldoc) === htmldoc.c:3564: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3526: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3557: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3564: Test failed: unexpected address bar url: L"about:replace" === W7PRO (32 bit htmldoc) === htmldoc.c:3564: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3526: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3557: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3564: Test failed: unexpected address bar url: L"about:replace" === W7PROX64 (32 bit htmldoc) === htmldoc.c:3564: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3526: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3557: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3564: Test failed: unexpected address bar url: L"about:replace" === W7PROX64 (64 bit htmldoc) === htmldoc.c:3564: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3526: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3557: Test failed: unexpected address bar url: L"about:blank" htmldoc.c:3564: Test failed: unexpected address bar url: L"about:replace"

March 10, 2011

Re: [4/4] d3d8: Test depth stencil size mismatches

by Henri Verbeet

On 10 March 2011 22:58, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -264,6 +264,8 @@ struct IDirect3DSurface8Impl > > /* If set forward refcounting to this object */ > IUnknown *forwardReference; > + > + UINT width, height; > }; You could just ask wined3d for the surface size.

March 10, 2011