October 2012 - Wine-Devel - list.winehq.org

Re: [PATCH(1/1)] wininet: TLS fallback mechanism
by Alexandre Julliard Oct. 25, 2012

Oct. 25, 2012

"Hiroshi Miura(@osmf)" <miurahr(a)osmf.jp> writes: > OpenSSL 1.0.x now support TLSv1.1 and TLSv1.2. > Sometimes TLSv1.1/1.2 negotiation fails because of combination > of server/client ssl library versions. > It fixes the error connecting Evernote server with evernote client. > http://bugs.winehq.org/show_bug.cgi?id=30598 > > It has a mechanism to fallback to SSLv3/TLSv1 when fails with TLSv1.1/1.2. > > It has also mechanism enable/disable TLSv1.1/1.2 by registry entry under > SYSTEM/CurrentControlSet/Control/SecurityProvider/SCHANNEL/Protocols/ > where is as same place as Windows7. > TLSv1.1/1.2 is enabled when the registry entry does not exist. It doesn't build on older openssl: gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_WINX32_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wwrite-strings -gstabs+ -fno-omit-frame-pointer -Wpointer-arith -I/usr/local/include/freetype2 -I/usr/local/include -g -O2 -o netconnection.o netconnection.c netconnection.c: In function 'get_tls_option': netconnection.c:478: error: 'SSL_OP_NO_TLSv1_2' undeclared (first use in this function) netconnection.c:478: error: (Each undeclared identifier is reported only once netconnection.c:478: error: for each function it appears in.) netconnection.c:486: error: 'SSL_OP_NO_TLSv1_1' undeclared (first use in this function) netconnection.c: In function 'NETCON_secure_connect': netconnection.c:925: error: 'SSL_OP_NO_TLSv1_1' undeclared (first use in this function) netconnection.c:925: error: 'SSL_OP_NO_TLSv1_2' undeclared (first use in this function) make[1]: *** [netconnection.o] Error 1 -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH 3/5] d3dx9_36: Implement ID3DXFileImpl_CreateEnumObject with stubbed ID3DXFileEnumObject interface. (try 5)
by Nikolay Sivov Oct. 25, 2012

Oct. 25, 2012

On 10/25/2012 10:34, Christian Costa wrote: > --- > dlls/d3dx9_36/xfile.c | 172 ++++++++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 170 insertions(+), 2 deletions(-) > > diff --git a/dlls/d3dx9_36/xfile.c b/dlls/d3dx9_36/xfile.c > index ebaefaf..32c3edd 100644 > --- a/dlls/d3dx9_36/xfile.c > +++ b/dlls/d3dx9_36/xfile.c > @@ -32,12 +32,123 @@ typedef struct { > IDirectXFile *dxfile; > } ID3DXFileImpl; > > +typedef struct { > + ID3DXFileEnumObject ID3DXFileEnumObject_iface; > + LONG ref; > + IDirectXFileEnumObject *dxfile_enum_object; > +} ID3DXFileEnumObjectImpl; You remove that field in next patch anyway.

2 1

Re: [PATCH 4/5] d3dx9_36: Implement ID3DXFileEnumObjectImpl_GetChildren & ID3DXFileEnumObjectImpl_GetChild and add stubbed interface for ID3DXFileData. (try 4)
by Nikolay Sivov Oct. 25, 2012

Oct. 25, 2012

On 10/25/2012 10:34, Christian Costa wrote: > > + > +static HRESULT WINAPI ID3DXFileDataImpl_Create(IDirectXFileObject *dxfile_object, ID3DXFileData **ret_iface) > +{ > + ID3DXFileDataImpl *object; > + > + TRACE("(%p, %p)\n", dxfile_object, ret_iface); > + > + *ret_iface = NULL; > + > + object = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*object)); > + if (!object) > + { > + ERR("Out of memory\n"); > + return E_OUTOFMEMORY; > + } > + > + object->ID3DXFileData_iface.lpVtbl = &ID3DXFileData_Vtbl; > + object->ref = 1; > + object->dxfile_object = (IDirectXFileData*)dxfile_object; > + > + *ret_iface = &object->ID3DXFileData_iface; > + > + return S_OK; > +} > + You don't need WINAPI for it. > > + ret = ID3DXFileDataImpl_Create((IDirectXFileObject*)data_object, &object->children[object->nb_children]); It seems you're casting it back and forth, is it possible to use proper type for data_object? > + { > + (&object->ID3DXFileEnumObject_iface)->lpVtbl->Release(&object->ID3DXFileEnumObject_iface); Hmm, what's wrong with object->ID3DXFileEnumObject_iface.lpVtbl->Release ?

2 1

Re: [PATCH 5/5] d3dx9_36: Implement ID3DXFileDataImpl_GetType. (try 5)
by Nikolay Sivov Oct. 25, 2012

Oct. 25, 2012

On 10/25/2012 10:34, Christian Costa wrote: > --- > dlls/d3dx9_36/xfile.c | 14 ++++++++++++-- > 1 file changed, 12 insertions(+), 2 deletions(-) > > diff --git a/dlls/d3dx9_36/xfile.c b/dlls/d3dx9_36/xfile.c > index a1e0596..4c216da 100644 > --- a/dlls/d3dx9_36/xfile.c > +++ b/dlls/d3dx9_36/xfile.c > @@ -154,9 +154,19 @@ static HRESULT WINAPI ID3DXFileDataImpl_Unlock(ID3DXFileData *iface) > > static HRESULT WINAPI ID3DXFileDataImpl_GetType(ID3DXFileData *iface, GUID *guid) > { > - FIXME("(%p)->(%p): stub\n", iface, guid); > + ID3DXFileDataImpl *This = impl_from_ID3DXFileData(iface); > + const GUID *dxfile_guid; > + HRESULT ret; > > - return E_NOTIMPL; > + TRACE("(%p)->(%p)\n", iface, guid); > + > + ret = IDirectXFileData_GetType(This->dxfile_object, &dxfile_guid); > + if (ret != S_OK) > + return ret; > + > + *guid = *dxfile_guid; > + > + return S_OK; > } > Why not simply forward to IDirectXFileData here? What is all the surrounding code for?

2 1

Add tests fo D3DXSHRotateZ
by Nozomi Kodama Oct. 25, 2012

Oct. 25, 2012

Hello, Is this patch not good enough to be commited? Nozomi

1 0

Re: [PATCH 1/5] d3dx9_36: Implement D3DXFileCreate. (try 3)
by Dmitry Timoshkov Oct. 25, 2012

Oct. 25, 2012

Christian Costa <titan.costa(a)gmail.com> wrote: > +static HRESULT WINAPI ID3DXFileImpl_QueryInterface(ID3DXFile *iface, REFIID riid, void **ret_iface) > +{ > + TRACE("(%p)->(%s, %p)\n", iface, debugstr_guid(riid), ret_iface); > + > + if (IsEqualGUID(riid, &IID_IUnknown) || > + IsEqualGUID(riid, &IID_ID3DXFile)) > + { > + iface->lpVtbl->AddRef(iface); Isn't there an appropriate xxx_AddRef() macro? > + *ret_iface = iface; > + return S_OK; > + } > + > + ERR("(%p)->(%s, %p), not found\n", iface, debugstr_guid(riid), ret_iface); FIXME seems more appropriate here. > + *ret_iface = NULL; > + return E_NOINTERFACE; > +} ... > +HRESULT WINAPI D3DXFileCreate(ID3DXFile **dxfile) > +{ > + ID3DXFileImpl *object; > + > + TRACE("(%p)\n", dxfile); > + > + object = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*object)); What's the reason for HEAP_ZERO_MEMORY here? > + if (!object) > + { > + ERR("Out of memory\n"); > + return E_OUTOFMEMORY; > + } The ERR() is useless here, just return E_OUTOFMEMORY in such situations. -- Dmitry.

5 13

[PATCH(0/1)] wininet: TLS fallback mechanism
by Hiroshi Miura(＠osmf) Oct. 24, 2012

Oct. 24, 2012

Hi, Evernote windows client on Wine/OpenSSL 1.0.1/Ubuntu12.04/12.10 cannot connect its server. It is caused by server is only support TLS1.0/SSL3.0, but client ask TLS1.1/1.2 and then server returns that session is fails. A wininet in Microsoft Windows7 implementation has a behavior to re-try by TLS1.0 after TLS1.2 fails and got FIN from server. This patch enabled fall back mechanism to SSLv3/TLSv1. It is also a response for Alexandre's suggestion. >> How do you think whether we should implement similar way or not? >> If we adopt similar fall back mechanism, compatibility may become well, >> but is it good behavior? > > If it's possible to implement some sort of automatic fall back, that > would certainly be preferable. > > -- > Alexandre Julliard Hiroshi Hiroshi Miura (1): wininet: TLS fallback mechanism dlls/wininet/netconnection.c | 163 ++++++++++++++++++++++++++++++++---------- 1 file changed, 124 insertions(+), 39 deletions(-) -- 1.7.9.5

2 1

windowscodecs questions.
by Max TenEyck Woodbury Oct. 24, 2012

Oct. 24, 2012

Background: I am trying to improve the performance/reliability of GuildWars2 under wine. In particular, PNG handling seems very slow, so I am looking at windowscodecs and I seem to be misunderstanding some things. I have read the PNG spec. First: The CRC check. The spec says that a 'chunk' contains a four byte size of data field, a four byte 'chunk identifier', the data and a CRC32 of the data. I found some code that reads a generic chunk. I see where the size and type are read, where a correctly sized record is allocated and where the data is read into the record. There is a 'FIXME' that asks about checking the CRC, but no code to actually read or check the CRC. I added code to read and check the CRC to my working copy of the git tree. That threw off the block synchronization, so I think there is code someplace else that either checks or skips the CRC, but I have not found it after a few hours searching for it. An indication on where to look and other advice would be very helpful at this time. Second: At least two of the methods GuildWars2 wants to use are stubbed. To implement those methods, the frame section of the WIC object should contain an array (or something with similar properties) of pointers to chunks. From what I have read about WIC, other formats could use a similar array. Some could even use an array of pointers to frames. Before I go messing with that level of change, I think I should listen to other peoples opinions of the subject. Third: On a very broad level, the whole OLE implementation seems to be very messed up. In particular, the usual practice for doing inheritance in C does not seem to be being used. That practice is to have the elements common to the base and extending object be placed at the beginning of the implementing data structures. While the member names need not be the same in all instances, the function, type and order of the common elements must be the same for economical implementation. This has been done for the basic object; all start with a pointer to the 'vtable'. What I think should follow is the critical section lock structure and, for 'IUnknown', the reference count. What I see is that these common elements are placed more or less at random in each extended object. Is there any reason, other than inertia, that at least these two fields should not be moved to the beginning of implementing objects. This can be done one object at a time and would allow the changed objects to use a common implementation of 'AddRef' at least, and another common routine or macro that handles the critical part of 'Release'.

2 2

[PATCH 5/6] dsound: rework ugly mixer logic
by Joerg-Cyril.Hoehle＠t-systems.com Oct. 24, 2012

Oct. 24, 2012

Hi, Maarten Lankhorst wrote: >only oss4 and (maybe, just guessing?) coreaudio don't support float MacOS' CoreAudio supports floats. Actually, given that it's an entire audio pipeline like quartz, I bet it even prefers floats. >I also refer you to GetStreamLatency where I was getting the period from, >Please take it from me: IT'S OK TO FAIL THOSE MMDEVAPI PERIOD TESTS, I agree that some tests are extremely strict and that a "good enough" driver could work extremely well in practice despite failing some tests. However, please specify exactly which tests you have in mind so that we all talk about the same set. >BUT PLEASE DON'T LIE ABOUT THE HARDWARE CAPABILITIES REGARDING >TO MINIMUM PERIOD, DEFAULT PERIOD AND STREAM LATENCY. The reasoning is as follows: First, tests show that native exhibits a 10ms period, hence we can assume that every PC SW has been tested with that period only. Using another period in Wine might reveal bugs in the apps, but users would blame Wine. This is why I've been arguing no later than last week in bug #28622, comment #58 that Wine should fully decouple ALSA/OSS periods from the published 10ms mmdevapi periods. OTOH, winecoreaudio has been using 20ms periods since day 1 in 2011. I'm not aware of bugs in bugzilla caused by that deviation. Second, the shared mode audio engine IMHO presents an abstraction over any particular HW, providing the same behviour on all machines and eliminating the need for app X to talk to or work around bugs in sound driver Y. Thus I wonder why you talk about hardware capabilities at all. IOW the shared mode caps are: fixed period=10ms and unlimited buffer (MSDN says 2s). a) Minimum Period Why do you care? It's only relevant in exclusive mode. I'd say that minimum = shared mode default period is a reasonable value. And if default=10ms, minimum = 5ms seems ok if it has been tested and works well. OTOH, 200 periods and wakeups per second may be unrealistic as we alreadty struggle to sustain 100. Do you know an app that uses mmdevapi in exclusive mode? b) Default Period == shared mode audio engin period The target is 10ms, see above. Yet we could make exemptions: for instance, we might observe that all apps using mmdevapi use it via the XAudio2 libraries and that XA2 is well debugged and would bear a larger period, e.g. 50ms. There should be a registry setting for users to play with. I'm not happy with Wine's DSound+WinMM->mmdevapi. That may be a good move for MS, but it's a bad move for Wine. Wine's audio drivers don't bang the HW, they have huge SW stacks like PA or Jack in their back. c) Stream Latency Bear in mind that the mmdevapi stream latency is a static property of an audio SW transformation graph. It does not vary if some buffer is full or empty. It is unlike snd_pcm_delay. I believe winealsa outputs a reasonable stream latency. One may argue that it is too low: as winealsa always buffers 3 periods internally the latency should count those. I kept it low because native's mmdevapi is reported to introduce 30-40ms delays yet its GetStreamLatency ignores that and reports values like 10.6666ms. Perhaps we are wrong about GetStreamLatency. Perhaps it's always a local call to one element of the audio transformation graph and should never sum other elements itself. Perhaps the app should use some enumeration facility to walk the audio graph and sum each element's latency? Perhaps there's some native graph element that would report said 30-40ms latency? Regards, Jörg Höhle

4 4

vcomp: single-threaded implementation of _vcomp_fork (try 6)
by Joerg-Cyril.Hoehle＠t-systems.com Oct. 24, 2012

Oct. 24, 2012

Hi, Alexandre Julliard wrote: > +void WINAPIV _vcomp_fork(BOOL ifval, int nargs, void *wrapper, ...) > + __ms_va_list valist; >it's ugly to use varargs only as a hack to get a pointer to the first >argument. Would taking the address of &wrapper (as in asm("...","r=&wrapper") or any C code like "void* stack = &wrapper") suffice to tell the x64 compiler to save register parameters into their allocated stack locations? My belief was that this is specifically the magic performed when the compiler sees a [__ms_]va_list. You seem to imply that va_list is superfluous and that taking the address of any parameter (not necessarily &wrapper but &ifval or &nargs too) would achieve the same effect: all 4 registers rcx, rdx, r8 and r9 get saved to the stack such that the & abstraction works even when the user performs pointer arithmetic. This is the effect that Dan Kegel needs for vcomp. In such a case he would use &wrapper, bypass va_list and correct the stack-relative offsets in the x86 and x64 assembly code by one pointer unit. Regards, Jörg Höhle

3 3

Re: [PATCH] user32: Fix error handling in MapWindowPoints, ClientToScreen and ScreenToClient and add tests for them. (try 3)
by Dmitry Timoshkov Oct. 24, 2012

Oct. 24, 2012

Christian Costa <titan.costa(a)gmail.com> wrote: > BOOL WINAPI ClientToScreen( HWND hwnd, LPPOINT lppnt ) > { > + DWORD error = GetLastError(); > + > + if (!hwnd) > + { > + SetLastError( ERROR_INVALID_WINDOW_HANDLE ); > + return FALSE; > + } > + > + SetLastError( 0xdeadbeef ); > MapWindowPoints( hwnd, 0, lppnt, 1 ); > + > + if (GetLastError() != 0xdeadbeef) > + return FALSE; > + > + SetLastError(error); > return TRUE; > } As been said before these games with saving/restoring last error value are broken. -- Dmitry.

3 3

Re: [PATCH 1/2] user32: Remove redundant sizeof check.
by Ken Thomases Oct. 24, 2012

Oct. 24, 2012

On Oct 24, 2012, at 3:24 AM, Michael Stefaniuc wrote: > @@ -1330,9 +1330,6 @@ static HICON CURSORICON_LoadFromFile( LPCWSTR filename, > } > > dir = (const CURSORICONFILEDIR*) bits; > - if ( filesize < sizeof(*dir) ) > - goto end; > - > if ( filesize < (sizeof(*dir) + sizeof(dir->idEntries[0])*(dir->idCount-1)) ) > goto end; > That doesn't seem redundant to me. It's not safe to access dir->idCount if the file isn't known to be big enough. Regards, Ken

2 1

Re: d3dx9_36/tests: Fix sizeof to be more portable (coverity)
by Henri Verbeet Oct. 24, 2012

Oct. 24, 2012

On 24 October 2012 02:05, André Hentschel <nerv(a)dawncrow.de> wrote: > face_remap = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, > - tc[i].num_faces*sizeof(face_remap)); > + tc[i].num_faces*sizeof(DWORD*)); > I'm don't know what Coverity actually says about this, but this looks just as wrong to me. It's probably supposed to be "sizeof(*face_remap)".

2 1

Re: [PATCH 3/3] ntdll: Add NULL test for NtQuerySystemInformation with SystemProcessInformation.
by Marvin Oct. 23, 2012

Oct. 23, 2012

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=22435 Your paranoid android. === W7PROX64 (32 bit info) === info.c:297: Test failed: Expected STATUS_ACCESS_VIOLATION got c0000017 === TEST64_W7SP1 (32 bit info) === info.c:297: Test failed: Expected STATUS_ACCESS_VIOLATION got c0000017

1 0

Re: [PATCH 3/3] mshtml: Added HTML comments in VBScript code tests
by Marvin Oct. 23, 2012

Oct. 23, 2012

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

1 0

Re: [PATCH 1/3] ntdll: Implement nanosecond precision file time storage (try 2).
by Alexandre Julliard Oct. 23, 2012

Oct. 23, 2012

"Erich E. Hoover" <ehoover(a)mymail.mines.edu> writes: > @@ -2048,17 +2048,26 @@ NTSTATUS WINAPI NtSetInformationFile(HANDLE handle, PIO_STATUS_BLOCK io, > > if (info->LastAccessTime.QuadPart || info->LastWriteTime.QuadPart) > { > +#ifdef HAVE_FUTIMENS > + struct timespec tv[2]; > +#else > struct timeval tv[2]; > +#endif > + int ret; > > if (!info->LastAccessTime.QuadPart || !info->LastWriteTime.QuadPart) > { > - > - tv[0].tv_sec = tv[0].tv_usec = 0; > - tv[1].tv_sec = tv[1].tv_usec = 0; > + memset(&tv, 0x0, sizeof(tv)); > if (!fstat( fd, &st )) > { > tv[0].tv_sec = st.st_atime; > tv[1].tv_sec = st.st_mtime; > +#if defined(HAVE_FUTIMENS) && defined(HAVE_STRUCT_STAT_ST_ATIM) > + tv[0].tv_nsec = st.st_atim.tv_nsec; > +#endif > +#if defined(HAVE_FUTIMENS) && defined(HAVE_STRUCT_STAT_ST_MTIM) > + tv[1].tv_nsec = st.st_mtim.tv_nsec; > +#endif You want UTIME_OMIT. Also please try to cut down on the number of #ifdefs. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 5/5] d3dx9_36: Implement ID3DXFileDataImpl_GetType. (try 2)
by Rico Schüller Oct. 23, 2012

Oct. 23, 2012

On 22.10.2012 23:57, Christian Costa wrote: > -static HRESULT WINAPI ID3DXFileDataImpl_GetType(ID3DXFileData *iface, GUID* guid) > +static HRESULT WINAPI ID3DXFileDataImpl_GetType(ID3DXFileData *iface, GUID *guid) > > - ID3DXFileDataImpl* object; > + ID3DXFileDataImpl *object; One minor thing: I'd put that fixes in patch 4/5. It doesn't make much sense to add a line and change the style in the next patch from the same series. I think it's better to correct this when it is added in the first place. Cheers Rico

1 0

Re: [PATCH 1/5] d3dx9_36: Implement D3DXFileCreate.
by Jacek Caban Oct. 23, 2012

Oct. 23, 2012

On 10/22/12 10:13 PM, Rico Schüller wrote: > On 22.10.2012 21:27, Christian Costa wrote: >> +static HRESULT WINAPI ID3DXFileImpl_QueryInterface(ID3DXFile *iface, REFIID riid, LPVOID *ret_iface) >> + ID3DXFileImpl *This = impl_from_ID3DXFile(iface); >> + ID3DXFileImpl* object; > Please be a bit more consistent across your patch... There are a lot more occurrences where you mix both usages. His usage seems natural when you think about using 'This' as analogy to 'this' in C++ implementation. That said, it's really a matter of taste, but such analogy feels natural when you work with COM. And by that logic, the patch is consistent. It uses 'object' as name of global function, which is not member of any class-like thing. Christian, there were some informal attempts to limit usage of stuff like LPVOID (and really any LP* types). It would be nice if you could avoid it in your patches. Jacek

4 3

Re: [PATCH 4/5] d3dx9_36: Implement ID3DXFileEnumObjectImpl_GetChildren & ID3DXFileEnumObjectImpl_GetChild and add stubbed interface for ID3DXFileData.
by Rico Schüller Oct. 23, 2012

Oct. 23, 2012

On 22.10.2012 21:28, Christian Costa wrote: > +static HRESULT WINAPI ID3DXFileDataImpl_GetType(ID3DXFileData *iface, GUID* guid) Spacing. msdn says "const GUID *pType" see http://msdn.microsoft.com/en-us/library/windows/desktop/bb205843%28v=vs.85%…. Is it a bug in msdn? > + ID3DXFileDataImpl* object; *object? > + object = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(ID3DXFileDataImpl)); I'd use sizeof(*object), but that's probably only a matter of taste.

3 3

Re: winex11: Never use a surface for embedded windows, even for the parents. (Regression)
by Christian Inci Oct. 22, 2012

Oct. 22, 2012

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, this patch is causing CS:GO (Counter Strike: Global Offensive) to exit silently on startup. (Commit: 5fae649bdf14fb63b8d44984eda6edd1094a3314) - -Chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQhbWdAAoJEC7OUg5VIFIFgw8QAI+9slyGg+G5T6mEEq1O5f3l 3AMOqCBVQ7F8mhBCqC8JhiMkjJRnJ8cRupXflPl5+iugXrhxHWxM49G/stJ9kqeQ m/uSwX+CSBUR/I2kBeYYljJtD28QEthjUP/X6VMTHsQKvInmyjZKXN5PXuLWwmq4 p1ZayBAixRNu0sLEDkH2vsRjRm0Ehla3YMFU6JkAH9mQcBl6x4V8Ii6E89onAC1i sV4x8ASHnnb8p4/I9m/mScmO1WAN/TnCQyh/QEXCgA/FFHvkSWNN7liDqRgRbNeM Ozx2Cj6UctzQpeHH7XeTzFQRHXY37cRcRvVVKU56yOC3N5hxK0ncXVWD2BflqBYZ C2cOwZpmzw3iG00csDjEWoLsZH0jw0foQNl5Nx/DWPyqqtY6hVT8++F80b1WroIM 47AcNeY9NakaDkBVnvmy0YeiVH0QIhZlT2L6h4LlogjIF6gl4m5kVBcGKCYAgF9C kqcGCg+CIlRqbDeEBto07GnDDDeuvG5NoCU3W2iB6xydBsEAfzj5xyOafbmueJuc JN7pBPgMfONmpg3RhkZgkiGFKlkA7URxTxHuQZsElBeKJiE2VkeZ4obXOf+YbPkc pTtQBIhkSXlStnxSJtKc6sY683YSoQinewGgHVV3qrbWhpPlz6ONQJjfifFhY3DO Vyakqk3iDicIg76kVuM6 =WTR3 -----END PGP SIGNATURE-----

1 0

Re: [PATCH 2/5] d3dx9_36: Implement ID3DXFileImpl_RegisterTemplates.
by Rico Schüller Oct. 22, 2012

Oct. 22, 2012

On 22.10.2012 21:28, Christian Costa wrote: > } ID3DXFileImpl; > > > - > static inline ID3DXFileImpl *impl_from_ID3DXFile(ID3DXFile *iface) It doesn't make much sense to add an empty line and remove it in the next patch.

1 0

Re: [PATCH 5/5] d3dx9_36: Implement ID3DXFileDataImpl_GetType.
by Rico Schüller Oct. 22, 2012

Oct. 22, 2012

On 22.10.2012 21:28, Christian Costa wrote: > static HRESULT WINAPI ID3DXFileDataImpl_Unlock(ID3DXFileData *iface) > { > + > FIXME("(%p)->(): stub\n", iface); Why?

1 0

Re: [PATCH 1/5] d3dx9_36: Implement D3DXFileCreate.
by Rico Schüller Oct. 22, 2012

Oct. 22, 2012

On 22.10.2012 21:27, Christian Costa wrote: > +static HRESULT WINAPI ID3DXFileImpl_QueryInterface(ID3DXFile *iface, REFIID riid, LPVOID *ret_iface) > > + ID3DXFileImpl *This = impl_from_ID3DXFile(iface); > > + ID3DXFileImpl* object; Please be a bit more consistent across your patch... There are a lot more occurrences where you mix both usages.

1 0

Re: [PATCH 6/8] ntdll: Standardize on sysconf to detect the number of processors for all platforms.
by Alexandre Julliard Oct. 22, 2012

Oct. 22, 2012

James Eder <jimportal(a)gmail.com> writes: > @@ -1010,6 +1010,16 @@ static inline void get_cpuinfo(SYSTEM_CPU_INFORMATION* info) > */ > void fill_cpu_info(void) > { > + long num; > + > + num = sysconf(_SC_NPROCESSORS_ONLN); > + if (num < 1) > + { > + num = 1; > + WARN("Failed to detect the number of processors.\n"); > + } > + NtCurrentTeb()->Peb->NumberOfProcessors = num; Have you verified that this works correctly on all the platforms you are changing? -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH] user32: Fix error handling in MapWindowPoints, ClientToScreen and ScreenToClient and add tests for them. (try 2)
by Alexandre Julliard Oct. 22, 2012

Oct. 22, 2012

Christian Costa <titan.costa(a)gmail.com> writes: > @@ -236,20 +236,32 @@ BOOL WINAPI GetClientRect( HWND hwnd, LPRECT rect ) > > > /******************************************************************* > - * ClientToScreen (USER32.@) > + * ClientToScreen (USER32.@) > */ > BOOL WINAPI ClientToScreen( HWND hwnd, LPPOINT lppnt ) > { > + if (!IsWindow( hwnd )) > + { > + SetLastError( ERROR_INVALID_WINDOW_HANDLE ); > + return FALSE; > + } > + You should never use IsWindow(). Handles should be checked at the point where they are used. -- Alexandre Julliard julliard(a)winehq.org

2 1