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

Re: [PATCH(1/1)] wininet: TLS fallback mechanism
by Alexandre Julliard 25 Oct '12

25 Oct '12

"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 25 Oct '12

25 Oct '12

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 25 Oct '12

25 Oct '12

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 25 Oct '12

25 Oct '12

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 25 Oct '12

25 Oct '12

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 24 Oct '12

24 Oct '12

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) 24 Oct '12

24 Oct '12

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 24 Oct '12

24 Oct '12

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 24 Oct '12

24 Oct '12

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 24 Oct '12

24 Oct '12

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