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

[PATCH] [RFC] Make drive C always a "Local disk"
by Ben Klein March 10, 2009

March 10, 2009

This patch should fix 17619 for new wineprefixes and other cases where C: is created. The logic is that C: should never be registered as a network share, which is the issue in 17619. It was suggested as a response to a previous patch that this should be relative to %SYSTEM% or something along those lines, but I believe that C: is a true special case, similar to how A: and B: are always reserved for floppy drives. I'm not sure if this is the right way to go, so I'd like comments :) Thanks

9 15

Re: [6/6] d3d8: Handles aren't supposed to be pointers.
by Paul Vriens March 10, 2009

March 10, 2009

Henri Verbeet wrote: > > ------------------------------------------------------------------------ > > Hi, + EnterCriticalSection(&d3d8_cs); + *pToken = d3d8_allocate_handle(&This->handle_table, object); LeaveCriticalSection(&d3d8_cs); Is there a need for that extra EnterCriticalSection() (in _EndStateBlock)? There is one a few lines up. -- Cheers, Paul.

1 0

Re: [PATCH 1/4] mshtml: Added IHTMLElement::put_innerHTML implementation.
by Alistair Leslie-Hughes March 9, 2009

March 9, 2009

Hi Jacek, Jacek Caban wrote: > --- > dlls/mshtml/htmlelem.c | 33 +++++++++++++++++++++++++++++++-- > dlls/mshtml/tests/dom.c | 42 ++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 73 insertions(+), 2 deletions(-) > > > static const WCHAR xW[] = {'x',0}; + static const WCHAR yW[] = {'x',0}; > ------------------------------------------------------------------------ Should this be = {'y', 0}? Best Regards Alistair Leslie-Hughes

2 1

shlwapi/shreg test: difference in results when crosscompiling just the test and the full winetest (Win95)
by Paul Vriens March 9, 2009

March 9, 2009

Hi, I'm trying to fix the last remaining test failures for shlwapi/shreg on my Win95 box. When I crosscompile the full winetest and run "winetest shlwapi:shreg" on my Win95 box the test results are: shreg.c:248: Test failed: Expected ERROR_MORE_DATA, got (127) shreg.c:274: Test failed: Expected ERROR_MORE_DATA, got (127) When I now build just the shlwapi test the tests succeed (dwRet = 203) Any idea where these differences could come from? '203' is ERROR_ENVVAR_NOT_FOUND btw. '127' is ERROR_PROC_NOT_FOUND. Only ERROR_ENVVAR_NOT_FOUND sounds at least a little bit like a proper result as we are dealing with expanding envvars. ERROR_PROC_NOT_FOUND doesn't make sense at all. -- Cheers, Paul.

2 2

Process elevation
by Luke Benstead March 9, 2009

March 9, 2009

Hi all, I was going to post this to #winehackers but it became too long so I'll post here instead :) When trying to run IE8 under Wine, you are greeted with the following error: err:ntdll:NtQueryInformationToken Unhandled Token Information class 18! In the TOKEN_INFORMATION_CLASS enum, 18 refers to TokenElevationType. The error occurs in NtQueryInformationToken which *should* set the value of a TOKEN_ELEVATION_TYPE ( http://msdn.microsoft.com/en-us/library/bb530718(VS.85).aspx ) instance. This basically returns whether or not a user is elevated, or can be elevated. I was going to have a go at fixing it, but I'm not sure what is the best value to set. Should Wine class a user as an admin and all processes run elevated? If so, then some applications may refuse to run as admin, and definitely the same is true that if the user isn't elevated, so programs will not run. I don't really know much about this elevation stuff (aside what I've read in the last half an hour) but I can't seem to work out what value NtQueryInformationToken should return out of: TokenElevationTypeDefault - User is a normal user and can't elevate TokenElevationTypeFull - User can and is elevated TokenElevationTypeLimited - User can elevate, but isn't currently elevated Should perhaps the elevation level be set by an environment variable, or registry setting? Luke.

2 1

Re: msi: Trace the username to help debug test failures on certain machines.
by Paul Vriens March 9, 2009

March 9, 2009

James Hawkins wrote: > --- > dlls/msi/tests/source.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > > ------------------------------------------------------------------------ > > Hi, The issue seems to be present on boxes that are part of a domain. I guess we have to check for domain and use that in the passed username. -- Cheers, Paul.

1 0

Re: [1/6] wined3d: Buffer object ID's are supposed to be unsigned.
by Stefan Dösinger March 9, 2009

March 9, 2009

Am Montag, 9. März 2009 14:36:57 schrieb Henri Verbeet: > - int VBO; /* Vertex buffer object this data is in */ > + unsigned int VBO; /* Vertex buffer object this data is in */ Wouldn't the really correct type be GLuint?

2 1

Re: shell32: szFullPath is needed even for SHGFI_PIDL and SHGFI_USEFILEATTRIBUTES flags combination (bug 17633)
by Alexandre Julliard March 9, 2009

March 9, 2009

Petr Sumbera <Petr.Sumbera(a)Sun.COM> writes: > dlls/shell32/shell32_main.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/dlls/shell32/shell32_main.c b/dlls/shell32/shell32_main.c > index 78a2d57..f2f5924 100644 > --- a/dlls/shell32/shell32_main.c > +++ b/dlls/shell32/shell32_main.c > @@ -370,6 +370,8 @@ DWORD_PTR WINAPI SHGetFileInfoW(LPCWSTR path,DWORD dwFileAttributes, > { > lstrcpynW(szFullPath, path, MAX_PATH); > } > + } else { > + ILGetDisplayNameExW(NULL, (LPCITEMIDLIST)path, szFullPath, 0); It seems to me you are just hiding the problem. If we have a pidl we shouldn't access the path directly. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/3] user32: Button should lose highlighting on focus loss (try2)
by Alexandre Julliard March 9, 2009

March 9, 2009

Nikolay Sivov <bunglehead(a)gmail.com> writes: > You could easily reproduce this issue: > - highlight any checkbox with space key > - keep space pressed and changed focus (with arrows or tab) > After that checkbox will be unfocused but still highlighted wich is a bug. > The same applies of course to radiobuttons too. > > Changelog: > - Button should lose highlighting on focus loss It doesn't seem right to do this in two separate steps and repaint the button twice. This would need a test case. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: dlls/iphlpapi/ipstats.c: #ifdef __linux__
by Austin English March 9, 2009

March 9, 2009

On Sun, Mar 8, 2009 at 6:28 PM, Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > ChangeLog: > append_udp_row is only used on Linux. > > Index: dlls/iphlpapi/ipstats.c > =================================================================== > RCS file: /home/wine/wine/dlls/iphlpapi/ipstats.c,v > retrieving revision 1.71 > diff -u -3 -p -r1.71 ipstats.c > --- dlls/iphlpapi/ipstats.c 6 Mar 2009 16:00:36 -0000 1.71 > +++ dlls/iphlpapi/ipstats.c 8 Mar 2009 23:27:39 -0000 > @@ -1269,7 +1269,7 @@ done: > return ret; > } > > - > +#ifdef __linux__ > static MIB_UDPTABLE *append_udp_row( HANDLE heap, DWORD flags, MIB_UDPTABLE *table, > DWORD *count, const MIB_UDPROW *row ) > { > @@ -1289,6 +1289,7 @@ static MIB_UDPTABLE *append_udp_row( HAN > memcpy( &table->table[table->dwNumEntries++], row, sizeof(*row) ); > return table; > } > +#endif > > static int compare_udp_rows(const void *a, const void *b) > { > > > I already submitted this patch, but it was rejected. The function should be used on BSD, but needs to be implemented. See: http://www.winehq.org/pipermail/wine-devel/2009-March/073723.html http://www.winehq.org/pipermail/wine-devel/2009-March/073730.html -- -Austin

1 0