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

Re: shell32: only fill used pointers
by Nikolay Sivov April 16, 2009

April 16, 2009

André Hentschel wrote: > This is needed to bring up IE8. Otherwise there is a Backtrace: > =>0 0x7e80198d SHDefExtractIconW+0x7d(pszIconFile=0x32e310, iIndex=0, > uFlags=0, phiconLarge=(nil), phiconSmall=0x32e30c, nIconSize=1048592) > > --- > dlls/shell32/iconcache.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > I think you're leaking here: + if (phiconLarge) *phiconLarge = hIcons[0]; /* 'else' should DestroyIcon(hIcons[0]) */ + if (phiconSmall) *phiconSmall = hIcons[1]; /* 'else' should DestroyIcon(hIcons[1]) */ cause these handles won't come to caller. P.S. What about a test for that? I've tested the same patch some times ago with IE8 RC1 and it definitely goes further with it (on 1.1.19 git) but tests are required I think.

2 2

Re: dlls/shell32: Fixed Dutch translations
by Paul Vriens April 16, 2009

April 16, 2009

Frans Kool wrote: > > ------------------------------------------------------------------------ > > You're mixing tabs and spaces. -- Cheers, Paul.

1 0

Re: try4 [2/3] kernel32: Fix GetVolumeInformation[AW] to require trailing \
by Austin English April 16, 2009

April 16, 2009

On Tue, Apr 14, 2009 at 11:17 PM, Guy Albertelli <galberte(a)neo.rr.com> wrote: > MSDN and test verify the valid "root dirs" for GetVolumeInformation[AW] > must end in trailing '\' and if not then return ERROR_INVALID_NAME > > Changelog > - Return correct error if GetVolumeInformation[AW] "root dir" does not end with '\' > --- > dlls/kernel32/volume.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > > Can you add a testcase for this? -- -Austin

2 2

Re: try4 [1/3] kernel32/tests: Add tests for GetVolumeInformationA and QueryDosDevice
by Paul Vriens April 16, 2009

April 16, 2009

Guy Albertelli wrote: > Fixed memory leak and changed skip to win_skip in this patch. > > Changelog: > - Enhance QueryDosDevice test for attempting to return all devices. > - Add tests for GetVolumeInformationA testing the different root dir formats. > --- > dlls/kernel32/tests/volume.c | 137 ++++++++++++++++++++++++++++++++++++++++- > 1 files changed, 133 insertions(+), 4 deletions(-) > > > > ------------------------------------------------------------------------ > > One of the tests fails here: volume.c:290: Test failed: GetVolumeInformationA w/o '\' did not fail, last error 2 I just ran the tests as your second mail/patch suggested it fixed something. That patch however didn't contain a change to the tests. If you add tests that fail on Wine and you don't include a fixed implementation in the same patch you should mark these with todo_wine(). If you fix the implementation in a later patch you should remove the todo_wine() again if needed. Bottom line: after each patch all tests should still succeed. -- Cheers, Paul.

2 1

Re: [1/2] msi/tests: Test MsiRecordGetString on null and empty strings.
by James Hawkins April 16, 2009

April 16, 2009

On Wed, Apr 15, 2009 at 4:34 PM, Nicolas Le Cam <niko.lecam(a)gmail.com> wrote: > While trying to solve ACTION_AppSearchDr problem revealed by my previous > patch, I discovered that MSI_RecordGetStringW was returning a buffer > length of 1 on null and empty strings. > > Here is the test, the fix follows. > > Tested on WinXP and Wine. > This patch has 39 lines of test code without a single empty line. Unit tests test one thing at a time and should be well documented and easy to read. -- James Hawkins

3 4

RFC: Resource editing and validation
by Reece Dunn April 16, 2009

April 16, 2009

Hi, This is something I have been thinking about for a while and is triggered by a comment by Austin on the "How can we improve WINE" thread that is floating around. In short, this is aiming to discuss and seek a resolution to issues encountered when editing resource files -- in particular dialogs -- and how to resolve them. There is also the wider issue of improving the warnings produced by the resource compiler to cover usability errors, like specifying duplicate mnemonics (clashing mnemonics on a dialog), multiple mnemonics (a control having two or more mnemonics) and partial mnemonics (a control ending in an '&' character). = EDITING RESOURCES = There are various issues that need addressing here (feel free to add any more that you find): 1. editing resources - especially dialogs - is hard without some sort of graphical editor; 2. not everyone has access to graphical resource editors (e.g. Visual Studio), so it is harder for people to make dialog changes; 3. graphical resource editors tend to mess up resource files, moving things around at random (Visual Studio, I'm looking at you); 4. it is difficult to make a layout change and apply it across the various language blocks consistently; 5. resource translators would like to use a gettext-style of resource translation; 6. people editing resources don't usually follow Windows resource layout guidelines and usability guidelines. What I want to propose is to write a resource editor for Wine that follows best layout and usability guidelines, that makes it easier for people editing the resources to do so. I would like to have this handle various control sizes, borders and padding and make it simple and intuitive where Visual Studio is not. There are some questions around this on whether to have these resource representations checked into the git repository and auto-generate the RC files at build time (preferrable), or whether to keep the RC files and have the editor process them to/from the editor format. What I am thinking of at the moment is to use XUL to represent the resources and gettext po to handle the translation. The build-time tools would then handle the translation to keep the dialogs consistent. There should also be a mechanism to adjust a dialog on a specific language -- but if this is just relative size and positioning, that should be handled by the XUL+PO -> RC transformation tool. Initially, a XUL+PO <==> RC conversion utility can be written to transform between the two. A graphical editor can then be built on top of this as desired. = Layout Guidelines (Example set) = - Dialog boxes have a 7 DLU inner border. - Command buttons are 50x14 DLUs. - Any control without an explicit name (e.g. a text edit box or list view) must have a static text label that is immediately before it in tab order (for accessibility requirements). NOTE: There are various dialogs (e.g. on Winecfg) that use different spacing between controls. This gives an inconsistent look, and adds to the "Wine is ugly" effect. Thoughts? Suggestions? - Reece

3 2

Re: start: correct German translation
by Stefan Leichter April 15, 2009

April 15, 2009

Am Tuesday 14 April 2009 19:43:13 schrieb Dawncrow: > --- > programs/start/De.rc | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) Please send patches with your real name. -- Stefan

1 0

Re: ntdll: Improve stubs for NtGet/SetInformationToken(TokenDefaultDacl).
by Rob Shearman April 15, 2009

April 15, 2009

2009/4/15 Hans Leidekker <hans(a)codeweavers.com>: > @@ -441,6 +441,23 @@ NTSTATUS WINAPI NtQueryInformationToken( > } > SERVER_END_REQ; > break; > + case TokenDefaultDacl: > + if (tokeninfo) > + { > + TOKEN_DEFAULT_DACL *token = (TOKEN_DEFAULT_DACL *)tokeninfo; > + ACL *acl; > + > + FIXME("returning empty DACL\n"); > + > + acl = token->DefaultDacl = (ACL *)token + sizeof(TOKEN_DEFAULT_DACL); > + > + acl->AclRevision = ACL_REVISION; > + acl->Sbz1 = 0; > + acl->AclSize = sizeof(ACL); > + acl->AceCount = 0; > + acl->Sbz2 = 0; > + } > + break; > default: > { > ERR("Unhandled Token Information class %d!\n", tokeninfoclass); The server already tracks the default DACL of the token in the token object, so implementing these functions properly shouldn't be much more work than writing the code to marshall and unmarshall the ACL to and from the server, with two new trivial functions in the server for getting and setting the default_dacl field. -- Rob Shearman

1 0

Compile error in taskmgr before 1.1.14
by David Lee Lambert April 15, 2009

April 15, 2009

I'm trying to use a git tree to do a regression-test for something that seems to have gotten broken somewhere between 1.0 and 1.1.19; but when I do a full "git reset _version_ ; git checkout -f ; ./configure CC='ccache gcc-3.4' ; make depend ; make" I get the following error before about 1.1.14: ccache gcc-3.4 -c -I. -I. -I../../include -I../../include -I../../include/msvcrt -DNO_LIBWINE_PORT -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -fno-builtin -o about.o about.c In file included from about.c:29: ../../include/msvcrt/memory.h:27: error: redefinition of 'memicmp' ../../include/msvcrt/string.h:132: error: previous definition of 'memicmp' was here ../../include/msvcrt/memory.h:28: error: redefinition of 'memccpy' ../../include/msvcrt/string.h:131: error: previous definition of 'memccpy' was here make[2]: *** [about.o] Error 1 make[2]: Leaving directory `/usr/src/wine-git/programs/taskmgr' make[1]: *** [taskmgr] Error 2 make[1]: Leaving directory `/usr/src/wine-git/programs' make: *** [programs] Error 2 Does anyone remember seeing this error, or is it likely to be the result of misusing git? Build system is Debian 4.0 with gcc 3.3, 3.4 and 4.1 available. -- David Lee Lambert ... Software Developer, member IEEE, ACM Cell phone: +1 586-873-8813 GPG key at http://www.lmert.com/keyring.txt IM: davidleelambert (Yahoo!) or lamber45(a)cse.msu.edu (MSN)

3 2

Re: gdi32: Don't add duplicate system_links entries
by Dmitry Timoshkov April 15, 2009

April 15, 2009

"Paul TBBle Hampson" <Paul.Hampson(a)Pobox.com> wrote: > + /* Make sure we haven't already got an entry for this due to substitution */ > + duplicate = FALSE; > + LIST_FOR_EACH_ENTRY(system_font_link, &system_links, SYSTEM_LINKS, entry) > + { > + if(!strcmpW(system_font_link->font_name, font_link->font_name)) > + { > + duplicate = TRUE; > + break; > + } > + } Font name comparison should be case insensitive. If there are other places that do that they should be fixed. > + if(duplicate) > + { > + TRACE("\tDuplicate font_link entry, ignoring\n"); > + HeapFree(GetProcessHeap(), 0, font_link); > + continue; > + } A '\t' at the start of a trace message doesn't improve readability. -- Dmitry.

2 1