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

Possible issue in dlls/d3dx9_36/surface.c?
by Gerald Pfeifer April 3, 2011

April 3, 2011

Matteo et al, there is some code in dlls/d3dx9_36/surface.c which GCC struggles with (in the sense of warning about it), and so do I, so I am wondering whether you can have a look? Specifically, in point_filter_simple_data we have: DWORD val = 0, pixel; /* extract source color components */ if(srcformat->type == FORMAT_ARGB) { pixel = dword_from_bytes(srcptr, srcformat->bytes_per_pixel); get_relevant_argb_components(&conv_info, pixel, channels); } So, pixel is uninitialized, except when we have FORMAT_ARGB. However, directly below we then have /* recombine the components */ if(destformat->type == FORMAT_ARGB) val = make_argb_color(&conv_info, channels); if(colorkey) { get_relevant_argb_components(&ck_conv_info, pixel, channels); where pixel is passed to get_relevant_argb_components. This is guarded by colorkey, a parameter to this function, so indeed I can see pixel being unused here. (I'd naively propose a patch like the one below; this may not be sufficient though.) Gerald diff --git a/dlls/d3dx9_36/surface.c b/dlls/d3dx9_36/surface.c index a3e6e68..cc36818 100644 --- a/dlls/d3dx9_36/surface.c +++ b/dlls/d3dx9_36/surface.c @@ -701,7 +701,7 @@ static void copy_simple_data(CONST BYTE *src, UINT srcpitch, POINT srcsize, DWORD val = 0; for(x = 0;x < minwidth;x++) { - DWORD pixel; + DWORD pixel = 0xFFFFFFFF; /* extract source color components */ if(srcformat->type == FORMAT_ARGB) { @@ -768,7 +768,7 @@ static void point_filter_simple_data(CONST BYTE *src, UINT srcpitch, POINT srcsi for(x = 0;x < destsize.x;x++) { const BYTE *srcptr = bufptr + (x * srcsize.x / destsize.x) * srcformat->bytes_per_pixel; - DWORD val = 0, pixel; + DWORD val = 0, pixel = 0xFFFFFFFF; /* extract source color components */ if(srcformat->type == FORMAT_ARGB) {

2 1

Re: msvcp90: Implement basic_string and cstring versions of basic_string::find.
by Piotr Caban April 2, 2011

April 2, 2011

Hi, On 04/02/11 08:49, Vincent Pelletier wrote: > +size_t __thiscall MSVCP_basic_string_char_find_cstr( > + basic_string_char *this, const char *str, size_t offset) > +{ > + const char *this_str = basic_string_char_const_ptr(this); > + const char *found = strstr(this_str+offset, str); > + if (found) > + return found - this_str; > + return MSVCP_basic_string_char_npos; > +} It's better to implement basic_string<char>::find(const char *str, size_t offset, size_t count) first and then call it in MSVCP_basic_string_char_find_cstr implementation. basic_string may contain nullbytes, your implementation will not work in this case. cstr may contain nullbytes as well when length is specified. Adding some tests similar to following code may be useful: basic_string<char> test = basic_string<char>("aaa"); test += '\0'; test += "bbb"; basic_string<char> test2 = basic_string<char>(test); test2 += '\0'; printf("%d %s\n", test.length(), test.c_str()); printf("%d\n", test.find("bbb", 0)); printf("%d\n", test.find(test, 0)); printf("%d\n", test.find(test.c_str(), 0, test.length())); printf("%d\n", test.find(test2, 0)); printf("%d\n", test.find(test2.c_str(), 0, test2.length())); Cheers, Piotr

1 0

Why do the wintab32 tests load the dll at runtime?
by Francois Gouget April 2, 2011

April 2, 2011

The subject says it all. Why do the wintab32 tests load the dll at runtime instead of simply linking with wintab32.dll? Is it to make it easier to compile it with Visual C++ in case the system does not have wintab32.dll? (already the SDKs don't seem to have wintab.h) -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U

2 2

Re: ntdll: Remove more path trailing chars.
by Marvin April 2, 2011

April 2, 2011

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=10288 Your paranoid android. === WNT4WSSP6 (32 bit file) === file.c:2261: Test failed: FindFirstFile on test-dir// should fail file.c:2262: Test failed: FindFirstFile on test-dir</ should fail file.c:2263: Test failed: FindFirstFile on test-dir>/ should fail file.c:2264: Test failed: FindFirstFile on test-dir"/ should fail file.c:2267: Test failed: FindFirstFile on test-dir\/ should fail file.c:2275: Test failed: FindFirstFile on test-dir/ should fail file.c:2277: Test failed: FindFirstFile on ./test-dir/ should fail

1 0

Re: kernel32: add test for FindFirstFileA with a path ending with "/>"
by Austin English April 2, 2011

April 2, 2011

On Fri, Apr 1, 2011 at 23:14, Vincent Pelletier <plr.vincent(a)gmail.com> wrote: > Fixes bug 22635. > --- > dlls/kernel32/tests/file.c | 119 > ++++++++++++++++++++++++++++++++++++++++++++ > dlls/ntdll/path.c | 8 +++- > 2 files changed, 126 insertions(+), 1 deletions(-) Your patch changelog is misleading. You're not just adding tests, but fixing the bug. Either send the tests as a single patch and the fix separately(and removing any todo_wine()'s that it fixes) or change the summary to describe the fix. -- -Austin

2 1

Re: kernel32: add test for FindFirstFileA with a path ending with "/>"
by Marvin April 1, 2011

April 1, 2011

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

1 0

Re: msvcp90: Implement basic_string and cstring versions of basic_string::find.
by Marvin April 1, 2011

April 1, 2011

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

1 0

RFC: Standardising the Help menus
by Francois Gouget April 1, 2011

April 1, 2011

I am in the process of reviewing Wine's resource files and more specifically the menus of its applications, and even more specifically the Help menu for now. Currently they are a bit inconsistent and I propose to standardise them by following the GNOME interface guidelines. That is use the following structure: Help Contents F1 About So here is the data I gathered on this eminently critical issue ;-) Windows User Experience Interaction Guidelines ---------------------------------------------- * The section about standard menus say we should use: http://msdn.microsoft.com/en-us/library/aa511502.aspx Help <program name> help F1 <separator> About <program name> * All applications seem to conform to the specification for the 'About' menu (except Sound Recorder which uses 'About' and Disk Management which incorrectly adds an ellipsis). * But for the 'Help' menu there is a lot of inconsistency. In Windows 7 I got: 'View Help': Notepad, Solitaire, Mine Sweeper, Calculator, FreeCell, Internet Backgammon, Spider Solitaire '<program name> Help': Internet Explorer 8 '<program name> Help Topics': Task Manager 'Help Topics': Regedit, Task Scheduler, Disk Management 'Help': Sound Recorder 'Contents': msinfo32 'None' (replaced by a toolbar icon): Explorer, Paint, XPS Viewer, Windows Media Player, Backup and Restore, Sync Center * From the point above I conclude that following the Microsoft Guidelines will not particularly help consistency with other Windows applications, nor help meet the users expectations. * Putting the program name in the menu name means we will have as many strings to translate as there are programs. This is more work for translators and can yield inconsistencies from one program to the next. * Putting the program name in the menu name also feels redundant to me. Does one really expect Regedit to give you the help for Notepad? Similarly one would expect an 'About' menu to be about the current program, although in Wine's case it's more a generic About dialog. Unix Interface Guidelines ------------------------- * The GNOME Human Interface Guidelines specify: http://library.gnome.org/devel/hig-book/2.32/hig-book.html#menu-standard-he… Help Contents F1 About * This allows sharing of the translations across programs. * It would make Wine's applications consistent with the system ones... as long as one uses Gnome. * Because unfortunately this is a case where the KDE User Interface Guidelines differ: http://developer.kde.org/documentation/standards/kde/style/menus/help.html Help <program name> Handbook... F1 What's This? Shift+F1 <separator> About <program name>... About KDE... * Using ellipses as specified for these menus makes absolutely no sense and is inconsistent with their own guidelines regarding them. Fortunately this seems to be a bug in the specification and the applications don't uses ellipses (feel free to report this bug). * Both GNOME and KDE applications follow their guidelines pretty well. (except Gnome's Network Tools app which uses 'Help Ctrl+H' instead of 'Contents F1', maybe another bug to report) * However other applications, specifically FireFox and OpenOffice seem to follow the Windows guidelines. VMware Workstation follows them for the About menu, but follows GNOME's guidelines for the 'Contents' help menu. * So given that we cannot be consistent with all Unix applications I propose to pick the scheme that requires the less work for us, which is GNOME's scheme. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Stolen from an Internet user: "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"

3 2

Re: [3/3] wined3d: Get rid of context_validate.
by Alexandre Julliard April 1, 2011

April 1, 2011

Matteo Bruni <matteo.mystral(a)gmail.com> writes: > It should not be needed anymore, now the wined3d context is implicitly > validated on GL context activation. The check itself wasn't reliable > because of some threading issues and it also brought a small performance hit. It crashes here (nvidia driver 256.53): ../../../tools/runtest -q -P wine -M d3d8.dll -T ../../.. -p d3d8_test.exe.so visual.c && touch visual.ok visual.c:949: Tests skipped: D3DFMT_P8 textures not supported wine: Unhandled page fault on read access to 0x00000004 at address 0x564def4d (thread 0044), starting debugger... Unhandled exception: page fault on read access to 0x00000004 in 32-bit code (0x564def4d). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:564def4d ESP:0032f110 EBP:7e27f248 EFLAGS:00010246( R- -- I Z- -P- ) EAX:00000000 EBX:682e96c0 ECX:00000000 EDX:00000000 ESI:56d8f000 EDI:00000000 Stack dump: 0x0032f110: 56d8f000 00000000 00000004 02000007 0x0032f120: 556be000 02000007 7df05fa0 5572fc1e 0x0032f130: 7e27f270 556be000 56d8f000 02000007 0x0032f140: 00000000 00000014 00000000 7e0db298 0x0032f150: 02000007 02000007 7df05fa0 56d8f000 0x0032f160: 7e27f270 7e0db1a0 7e27f248 5572fdbf Backtrace: =>0 0x564def4d in libnvidia-glcore.so.256.53 (+0xd38f4d) (0x7e27f248) 1 0x00000000 (0x7e106410) 0x564def4d: testl $0xe000000,0x4(%edi) -- Alexandre Julliard julliard(a)winehq.org

1 0

About Wine/Gecko/MSHTML
by Artem S. Tashkinov April 1, 2011

April 1, 2011

Hi, I have no idea to what extent and how Mozilla's Gecko library is being used in Wine (all I know is that it's used in Wine's MSHTML component), but recently a Mozilla developer made a very unsettling announcement: groups dot google dot com/d/topic/mozilla.dev.embedding/c_NMcO-N8wo/discussion I wonder if this announcement has any adverse effects on Wine's future. Best wishes, Artem

2 1

Re: [PATCH] user32/tests: Fixed SetParent test on 64bit Vista
by Marvin March 31, 2011

March 31, 2011

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

1 0