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

Re: [02/12] fusion: Add tests for the IAssemblyEnum interface.

by Alexandre Julliard

Hans Leidekker <hans(a)codeweavers.com> writes: > Some tests in James' original patch failed here, which I have fixed. I still see failures: ../../../tools/runtest -q -P wine -M fusion.dll -T ../../.. -p fusion_test.exe.so asmenum.c && touch asmenum.ok asmenum.c:430: Test failed: Expected "wine, Version=1.0.1.2, Culture=neutral, PublicKeyToken=123456789abcdef0" or "wine, Version=1.0.1.2, Culture=neutral, PublicKeyToken=16a3fcd171e93a8d", got "wine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=16a3fcd171e93a8d" asmenum.c:573: Test failed: Expected "wine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=16a3fcd171e93a8d", got "wine, Version=1.0.1.2, Culture=neutral, PublicKeyToken=123456789abcdef0" asmenum.c:586: Test failed: Expected "wine, Version=1.0.1.2, Culture=neutral, PublicKeyToken=123456789abcdef0" or "wine, Version=1.0.1.2, Culture=neutral, PublicKeyToken=16a3fcd171e93a8d", got "wine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=16a3fcd171e93a8d" make[2]: *** [asmenum.ok] Error 3 -- Alexandre Julliard julliard(a)winehq.org

Feb. 18, 2009

Re: [5/6]wininet: handle cookie expiration

by Aric Stewart

Wonderful, I was looking for a function JUST like that. Reworked patch coming up shortly. -aric Hans Leidekker wrote: >>> + LPCWSTR ptr,ptr2; >>> + SYSTEMTIME tm; >>> + int i; >>> + >>> + memset(&tm,0,sizeof(tm)); >>> + >>> + ptr = expiry; >>> + for (i = 0; i < 7; i++) >>> + { >>> + if (strncmpiW(day[i],ptr,3)==0) >>> + { >>> + tm.wDayOfWeek = i; >>> + break; >>> + } >>> + } >>> + ptr += 5; >>> + tm.wDay = strtolW(ptr,(LPWSTR*)&ptr2,10); >>> + ptr = ptr2+1; >> You should handle the various possible parsing errors, not just assume >> that you have a well-formatted string. > > Or use InternetTimeToSystemTimeW which does that already. > > -Hans >

Feb. 18, 2009

Re: [5/6]wininet: handle cookie expiration

by Hans Leidekker

> > + LPCWSTR ptr,ptr2; > > + SYSTEMTIME tm; > > + int i; > > + > > + memset(&tm,0,sizeof(tm)); > > + > > + ptr = expiry; > > + for (i = 0; i < 7; i++) > > + { > > + if (strncmpiW(day[i],ptr,3)==0) > > + { > > + tm.wDayOfWeek = i; > > + break; > > + } > > + } > > + ptr += 5; > > + tm.wDay = strtolW(ptr,(LPWSTR*)&ptr2,10); > > + ptr = ptr2+1; > > You should handle the various possible parsing errors, not just assume > that you have a well-formatted string. Or use InternetTimeToSystemTimeW which does that already. -Hans

Feb. 18, 2009

Re: Win to Lin Library Wrapper

by Henri Verbeet

2009/2/18 Jérôme Gardou <jerome.gardou(a)gmail.com>: > Out of curiosity, would moving to this sort of architecture > http://msdn.microsoft.com/en-us/library/ms799715.aspx be possible? That > may give manufacturer the possibility to develop wine-direct3d drivers > and support what wine does not support. This would require a major > architecture change in the current wine's d3d implementation though. > Possible sure, but I don't think it would be worth the effort. IIRC ddraw support might be a problem as well.

Feb. 18, 2009

Re: Win to Lin Library Wrapper

by Jérôme Gardou

Stefan Dösinger a écrit : > Am Mittwoch, 18. Februar 2009 10:06:03 schrieb King InuYasha: > >> So it wouldn't be possible to hook Wine's Direct3D implementation into >> Gallium3D on Linux and use the hardware directly instead of translating it >> to OpenGL and then sending it to the hardware? >> > Possible yes. I don't know if its gains anything though. We can never use the > hardware directly, we always have to bother the Linux/Mac/Whatever driver. > > If we go D3D->Gallium3D->Driver->HW or D3D->GL->Driver->HW doesn't make too > much difference, and Gallium3D is a driver specific API. It won't work on the > proprietary drivers or on MacOS, so I don't think it is worth the effort. > > The one big advantage of Gallium3D is that its interface is more flexible, and > it is easier to implement certain things that opengl doesn't have yet(e.g. > the color selection for flat shading). > > The bottom line is that if anybody implements a Gallium3D backend and it is > well-written and has a reasonable design it will most likely be accepted. I > personally don't have any plans to do that right now though. > > > > Out of curiosity, would moving to this sort of architecture http://msdn.microsoft.com/en-us/library/ms799715.aspx be possible? That may give manufacturer the possibility to develop wine-direct3d drivers and support what wine does not support. This would require a major architecture change in the current wine's d3d implementation though.

Feb. 18, 2009

Re: [5/6]wininet: handle cookie expiration

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > + LPCWSTR ptr,ptr2; > + SYSTEMTIME tm; > + int i; > + > + memset(&tm,0,sizeof(tm)); > + > + ptr = expiry; > + for (i = 0; i < 7; i++) > + { > + if (strncmpiW(day[i],ptr,3)==0) > + { > + tm.wDayOfWeek = i; > + break; > + } > + } > + ptr += 5; > + tm.wDay = strtolW(ptr,(LPWSTR*)&ptr2,10); > + ptr = ptr2+1; You should handle the various possible parsing errors, not just assume that you have a well-formatted string. -- Alexandre Julliard julliard(a)winehq.org

Feb. 18, 2009

Re: Win to Lin Library Wrapper

by Stefan Dösinger

Am Mittwoch, 18. Februar 2009 10:06:03 schrieb King InuYasha: > So it wouldn't be possible to hook Wine's Direct3D implementation into > Gallium3D on Linux and use the hardware directly instead of translating it > to OpenGL and then sending it to the hardware? Possible yes. I don't know if its gains anything though. We can never use the hardware directly, we always have to bother the Linux/Mac/Whatever driver. If we go D3D->Gallium3D->Driver->HW or D3D->GL->Driver->HW doesn't make too much difference, and Gallium3D is a driver specific API. It won't work on the proprietary drivers or on MacOS, so I don't think it is worth the effort. The one big advantage of Gallium3D is that its interface is more flexible, and it is easier to implement certain things that opengl doesn't have yet(e.g. the color selection for flat shading). The bottom line is that if anybody implements a Gallium3D backend and it is well-written and has a reasonable design it will most likely be accepted. I personally don't have any plans to do that right now though.

Feb. 18, 2009

Re: Wine & viruses

by Ben Klein

2009/2/18 Marcus Meissner <meissner(a)suse.de>: > On Wed, Feb 18, 2009 at 09:33:01PM +1100, Ben Klein wrote: >> 2009/2/18 IneedAname <wineappdb(a)googlemail.com>: >> > Why not make Wine honor the noexe flag on the mount? >> >> This might not be a bad idea, if it's possible. Make Wine refuse to >> run apps on noexec filesystems. > > Likely will break installing all DVD/CD Software ;) Depends on the mount flags ;) So possibly distro-dependant. noexec flag would still stop binfmt-misc, though ... > Ciao, Marcus

Feb. 18, 2009

Re: Wine & viruses

by Paul Chitescu

On Wednesday 18 February 2009 12:33:01 Ben Klein wrote: > 2009/2/18 IneedAname <wineappdb(a)googlemail.com>: > > Why not make Wine honor the noexe flag on the mount? > > This might not be a bad idea, if it's possible. Make Wine refuse to > run apps on noexec filesystems. It is usual to mount FAT filesystems noexec (since there are no POSIX executables on them anyway). That would prevent Wine running any EXE files off them. What is the user supposed to do, copy the files somewhere else? It is already bad enough if users (or their "helpful" distro) delete the Z: drive and they can't execute files from outside drive_c. BTW, this is enough "protection" against removable media too.

Feb. 18, 2009

Re: Wine & viruses

by Marcus Meissner

On Wed, Feb 18, 2009 at 09:33:01PM +1100, Ben Klein wrote: > 2009/2/18 IneedAname <wineappdb(a)googlemail.com>: > > Why not make Wine honor the noexe flag on the mount? > > This might not be a bad idea, if it's possible. Make Wine refuse to > run apps on noexec filesystems. Likely will break installing all DVD/CD Software ;) Ciao, Marcus

Feb. 18, 2009