January 2014 - Wine-Devel - list.winehq.org

Re: [PATCH 5/5] d3dx9_36/tests: Use NAN.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-01-03 22:15, schrieb Stefan Dösinger: > NAN was available, and I assumed that I got the one from port.h. > Admittedly I didn't check where exactly it came from. Maybe msvc > 2013 added a NAN definition. I got the NAN definition from the system math.h, which is included unconditionally by d3dx9math.h, which is included by d3dx9.h, which is included by the test. NAN is defined as INFINITY * 0.0. So I guess a NAN definition was introduced in the Windows headers at some point. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSxyx+AAoJEN0/YqbEcdMwfuoP/1MWm9B+BPW7Z5XgeW535YdN WUdwDOj3ltBJ/JT1DRW7UyfFoff1ZHWG5s0WI3Tc2RdvkNlZJO+OkqY58uH7fEFk 0hW9MgMaAzfbWbZKExFm99bQYMWseYkoarA5v+1yMW/jj2f/+rsJmyg4FKlKaATX iN54cS9/P4W4lrrHf8/eyl6IiC5y1MeufdRgL4wKuyry1zUCGcsjtQwbWmBnWDl7 Y+MJx/G8iqXcCS25RbjXIuSC+1q4rtfD26hPPgkYjaZ9Kk7uyHpUHd4sOpzvr7zc KkB0h6+IdvM7H92ku4z0XBtKCO5/D++5T91CdegulGAQ57Q/G4xkU5VD4SwqyuYF vGI5B8gkpQE20B2TIRJDaBEmCH59wgHYFsGsGtD0rTXO0mm5eQuHI0PMnh89l28t sBLwek5RmxPxlhNYTtOBog+b5L1nexn1Fzo9svD/jPu8dskfz5ydocPEK+7IX99t I66chDh6zmtgLSNvjfk+9zRR1t4LbIh+c6hqZbs46j4bb325X2BPfoF6E73uoAHB Lo08fsn11It0EyK/u4/Gyi6KwCxhpsXnn+/dRUB8vesY4eHOvFhfQyDBT7G1cFT6 w7sV00CTTGJEVJY745/sf/djIRinlRQXC2se+cH0dUncac+kEyDotaQJOnjMCVAr 1wpIwgC/9jlQCC8n1naL =34Zm -----END PGP SIGNATURE-----

Jan. 3, 2014

Re: [PATCH 5/5] d3dx9_36/tests: Use NAN.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-01-03 20:39, schrieb Francois Gouget: > But independently from that I think it's wrong because one should > be able to compile the conformance tests on Windows. The purpose of this patch was to be able to compile the tests in msvc. But there may be some quirks in the build setup, see below. > So one solution would be to revert the patch. Another would be to > copy wine/port.h's __port_nan() definition. Yet another might be to > add xmath.h and a dependency on msvcrt.dll. But maybe there's a > better way still? NAN was available, and I assumed that I got the one from port.h. Admittedly I didn't check where exactly it came from. Maybe msvc 2013 added a NAN definition. My msvc build setup is a bit quirky. I wanted to avoid needing a full mingw setup, so I ended up (over time, adding one detail after another) cloning a part of the Wine build system as a msvc project. I'll boot Windows and see where the NAN comes from exactly. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSxyh6AAoJEN0/YqbEcdMw1IoP/1XIKj13LgyQTLznU3wzwgNx s3lt2S02Y1Im35dWig6ekCIIB4AriFIZ/mMPCXCxwbadklxXe7w/Y8bjDG+o+lCy rtIRnveotgtSSF8G6MMtIByDWhro1EeYRv93YXpjIZsIJTg50GWUxf61RLh6YFII 5Y4VRS8pBg3+UgVHGgutHqrbuGIuJo0Dk7eVpMjwOSMkseH/egvjqWVuJRe/aTAm cMkIGi78i9XwICKiMoXODin6Ipv3KMxul0uNTHJYcc7QqUdRt/US8ME5B2UJr6ek BjkGthNrOEvQl+EjBz5HaX5pLuUUWGDH/PfVwiPMm9jC0oCDVGuTnCweA964cSZE msdImJOJ1rrOIFT+Xk4YZkIjMf/Mr7TYKNCUoBJVNb4SP+pJNvyfBgWx/s9bGMo4 7DZvIRGXCrZqmvK0e0Q3JyPohW4jMYIOei6yxBK5OtctnxO7MmuOQIYC/XVxGbJH E/KjqbLsk/xwYavXNbirn1kS97neyEgguPZCXg1/lVCPHlmRu+96BmHlf5RvwzUb BGvSjm0WsmBcsDj/Fa5D8Q6n586oeek9q2KTGGwq5wPxLtznq/eArR/U0u9JACGR +7fxFRkjdHJvtKaLohw4B/AOTijRiDwg1iMxGecpqye5Grg7JAKsjcA3EcTxsX3S /ssXcB1sNA2wuAT6CJwU =ScXv -----END PGP SIGNATURE-----

Jan. 3, 2014

Re: [PATCH 5/5] d3dx9_36/tests: Use NAN.

by Francois Gouget

On Thu, 2 Jan 2014, Stefan Dösinger wrote: [...] > --- a/dlls/d3dx9_36/tests/mesh.c > +++ b/dlls/d3dx9_36/tests/mesh.c > @@ -4800,7 +4800,7 @@ static void test_create_skin_info(void) [...] > - exp_weights[1] = 0.0f / 0.0f; /* NAN */ > + exp_weights[1] = NAN; This patch breaks the compilation on Solaris because it does not define NAN (except in math_c99.h but we cannot use that, see below). But independently from that I think it's wrong because one should be able to compile the conformance tests on Windows. This means we cannot use things like config.h or port.h and should only use stuff that's defined in Windows headers. But as far as I can tell the Windows SDK does not define NAN. There is a definition of NAN in the CRT xmath.h header but Wine does not have that header and we're obviously not including it here. So one solution would be to revert the patch. Another would be to copy wine/port.h's __port_nan() definition. Yet another might be to add xmath.h and a dependency on msvcrt.dll. But maybe there's a better way still? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The nice thing about meditation is that it makes doing nothing quite respectable -- Paul Dean

Jan. 3, 2014

Re: strmbase: Store BasePinFuncTable inside Base*PinFuncTable structs.

by Aric Stewart

On 1/3/14, 10:08 AM, Jacek Caban wrote: > --- > dlls/amstream/mediastreamfilter.c | 15 +++++++-------- > dlls/qcap/avico.c | 32 ++++++++++++++------------------ > dlls/qcap/avimux.c | 32 ++++++++++++++------------------ > dlls/qcap/vfwcapture.c | 15 +++++++-------- > dlls/quartz/filesource.c | 15 +++++++-------- > dlls/quartz/parser.c | 15 +++++++-------- > dlls/strmbase/pin.c | 24 ++++++++++++------------ > dlls/strmbase/renderer.c | 17 ++++++++--------- > dlls/strmbase/transform.c | 30 ++++++++++++++---------------- > include/wine/strmbase.h | 7 +++++-- > 10 files changed, 95 insertions(+), 107 deletions(-) > Also just so you are aware, all the strmbase stuff is based off actual microsoft strmbase stuff for directshow http://msdn.microsoft.com/en-us/library/windows/desktop/dd318897%28v=vs.85%… Not that this patch specifically breaks that, I have not dug that much, but just so that you are aware of the base for the implementation. -aric

Jan. 3, 2014

Re: strmbase: Store BasePinFuncTable inside Base*PinFuncTable structs.

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/amstream/mediastreamfilter.c | 15 +++++++-------- > dlls/qcap/avico.c | 32 ++++++++++++++------------------ > dlls/qcap/avimux.c | 32 ++++++++++++++------------------ > dlls/qcap/vfwcapture.c | 15 +++++++-------- > dlls/quartz/filesource.c | 15 +++++++-------- > dlls/quartz/parser.c | 15 +++++++-------- > dlls/strmbase/pin.c | 24 ++++++++++++------------ > dlls/strmbase/renderer.c | 17 ++++++++--------- > dlls/strmbase/transform.c | 30 ++++++++++++++---------------- > include/wine/strmbase.h | 7 +++++-- > 10 files changed, 95 insertions(+), 107 deletions(-) There are other users, like winegstreamer and wineqtdecoder. -- Alexandre Julliard julliard(a)winehq.org

Jan. 3, 2014

Re: [PATCH] Add support for GNU/Hurd

by André Hentschel

Am 03.01.2014 16:49, schrieb Svante Signell: > Hi, > > On Fri, 2014-01-03 at 15:35 +0100, André Hentschel wrote: >> Am 03.01.2014 12:32, schrieb Svante Signell: >>> Hi, >>> >>> Currently wine-1.6.1 FTBFS on Debian GNU/Hurd, see >>> https://buildd.debian.org/status/fetch.php?pkg=wine&arch=hurd-i386&ver=1.6.… >> >> This winterbreak i looked into this again, too. I was quite suprised >> that i had no problems with socket credentials, but it might still be a >> problem in other hurd distros. > > The only credentials needed by wine is SCM_RIGHTS, and that is already > supported. The problem was with *context functions and TLS. Since they > are now supported, wine runs :) Which *context functions do you mean? > Just FYI: There is no current Hurd distro except Debian. Arch Hurd > exists, but is now outdated. Efforts are ongoing however, to re-vitalise > it. > >>> Attached is a patch enabling the build: >>> >>> - dlls/ntdll/directory.c: Define a character array on the heap of size >>> 4096 instead of using PATH_MAX, which is not defined for GNU/Hurd. This >>> approach was used in dlls/ntdll/file.c:server_get_unix_name() where an >>> array of size 1024 was defined. In case this solution is not OK, a fixed >>> size array on the stack could be used, or as a last resort adding >>> #ifndef PATH_MAX; #define PATH_MAX 4096 to that file (not recommended, >>> at least from a GNU/Hurd aspect). >> >> I recently sent a patch for this and failed, problem is that you can't >> allocate memory inside an APC callback. I think we should address this >> first before the other issues. > > If not possible to use the heap, then the stack should be used: > preferably a fixed size array of 4096 bytes (not PATH_MAX). AJ didn't like that approach back then... >>> - libs/wine/ldt.c: Add LDT support for GNU/Hurd >>> >>> - dlls/ntdll/signal_i386.c: Add i386 signal handling support for >>> GNU/Hurd >> >> The interesting part of these patches were made by Andrew Nguyen some >> years ago, i already contacted him some days ago to ask how he wants to >> proceed with this, no response yet. > > Yes I know, they should hopefully have been integrated upstream a long > time ago. > >>> Applications tested so far (slow to start) include cmd, hostname, clock, >>> winemine, wineconsole, notepad, wordpad and explorer. >> >> These are winelib apps and a bad indicator for functionality. I tried >> PowerPointViewer here for this reason and it installs and runs. > > I did only try the functions available under .wine/drive_c, and did not > find any PowerPointViewer application. Is that an M$ application? It is, the challange is to run real PE files :)

Jan. 3, 2014

Re: kernel32/tests: Add test for FindFirstFileA()

by Marvin

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 https://newtestbot.winehq.org/JobDetails.pl?Key=3963 Your paranoid android. === wxppro (32 bit file) === file.c:2452: Test failed: FindFirstFile on C:\fooD.tmp should Fail file.c:2453: Test failed: Bad Error number 0 file.c:2459: Test failed: Bad Error number 267 === wvista (32 bit file) === file.c:2452: Test failed: FindFirstFile on C:\fooFB6A.tmp should Fail file.c:2453: Test failed: Bad Error number 0 file.c:2459: Test failed: Bad Error number 267 === w2008s64 (32 bit file) === file.c:2452: Test failed: FindFirstFile on C:\foo9FA.tmp should Fail file.c:2453: Test failed: Bad Error number 0 file.c:2459: Test failed: Bad Error number 267 === w7pro64 (32 bit file) === file.c:2452: Test failed: FindFirstFile on C:\foo580A.tmp should Fail file.c:2453: Test failed: Bad Error number 0 file.c:2459: Test failed: Bad Error number 267 === w2008s64 (64 bit file) === file.c:2452: Test failed: FindFirstFile on C:\foo93F.tmp should Fail file.c:2453: Test failed: Bad Error number 0 file.c:2459: Test failed: Bad Error number 267 === w7pro64 (64 bit file) === file.c:2452: Test failed: FindFirstFile on C:\fooF4B6.tmp should Fail file.c:2453: Test failed: Bad Error number 0 file.c:2459: Test failed: Bad Error number 267

Jan. 3, 2014

Re: ntdll/tests: Add test for deleting via NtOpenFile

by Marvin

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 https://newtestbot.winehq.org/JobDetails.pl?Key=3962 Your paranoid android. === w7pro64 (32 bit file) === file.c:331: Test failed: open L"system32" failed c000003b file.c:338: Test failed: open L"SYSTEM32" failed c000003b file.c:346: Test failed: open L"\\SYSTEM32" failed c0000034 file.c:356: Test failed: open L"\\SYSTEM32" failed c000003b

Jan. 3, 2014

Re: Bug#733605: [pkg-wine-party] Bug#733605: [PATCH] Add support for GNU/Hurd

by Svante Signell

On Fri, 2014-01-03 at 10:18 -0500, Michael Gilbert wrote: > On Fri, Jan 3, 2014 at 6:32 AM, Svante Signell wrote: > > - dlls/ntdll/directory.c: Define a character array on the heap of size > > 4096 instead of using PATH_MAX, which is not defined for GNU/Hurd. This > > approach was used in dlls/ntdll/file.c:server_get_unix_name() where an > > array of size 1024 was defined. In case this solution is not OK, a fixed > > size array on the stack could be used, or as a last resort adding > > #ifndef PATH_MAX; #define PATH_MAX 4096 to that file (not recommended, > > at least from a GNU/Hurd aspect). > > This version of the patch still hard-codes data_size. The Debian hurd > porting guide requires paths to be dynamically allocated. >From the reply by André Hentschel: > I recently sent a patch for this and failed, problem is that you can't > allocate memory inside an APC callback. > I think we should address this first before the other issues. > Additionally, the code mentioned in dlls/ntdll/file.c also use a hardcoded array size.

Jan. 3, 2014

Re: [PATCH] Add support for GNU/Hurd

by Svante Signell

Hi, On Fri, 2014-01-03 at 15:35 +0100, André Hentschel wrote: > Am 03.01.2014 12:32, schrieb Svante Signell: > > Hi, > > > > Currently wine-1.6.1 FTBFS on Debian GNU/Hurd, see > > https://buildd.debian.org/status/fetch.php?pkg=wine&arch=hurd-i386&ver=1.6.… > > This winterbreak i looked into this again, too. I was quite suprised > that i had no problems with socket credentials, but it might still be a > problem in other hurd distros. The only credentials needed by wine is SCM_RIGHTS, and that is already supported. The problem was with *context functions and TLS. Since they are now supported, wine runs :) Just FYI: There is no current Hurd distro except Debian. Arch Hurd exists, but is now outdated. Efforts are ongoing however, to re-vitalise it. > > Attached is a patch enabling the build: > > > > - dlls/ntdll/directory.c: Define a character array on the heap of size > > 4096 instead of using PATH_MAX, which is not defined for GNU/Hurd. This > > approach was used in dlls/ntdll/file.c:server_get_unix_name() where an > > array of size 1024 was defined. In case this solution is not OK, a fixed > > size array on the stack could be used, or as a last resort adding > > #ifndef PATH_MAX; #define PATH_MAX 4096 to that file (not recommended, > > at least from a GNU/Hurd aspect). > > I recently sent a patch for this and failed, problem is that you can't > allocate memory inside an APC callback. I think we should address this > first before the other issues. If not possible to use the heap, then the stack should be used: preferably a fixed size array of 4096 bytes (not PATH_MAX). > > - libs/wine/ldt.c: Add LDT support for GNU/Hurd > > > > - dlls/ntdll/signal_i386.c: Add i386 signal handling support for > > GNU/Hurd > > The interesting part of these patches were made by Andrew Nguyen some > years ago, i already contacted him some days ago to ask how he wants to > proceed with this, no response yet. Yes I know, they should hopefully have been integrated upstream a long time ago. > > Applications tested so far (slow to start) include cmd, hostname, clock, > > winemine, wineconsole, notepad, wordpad and explorer. > > These are winelib apps and a bad indicator for functionality. I tried > PowerPointViewer here for this reason and it installs and runs. I did only try the functions available under .wine/drive_c, and did not find any PowerPointViewer application. Is that an M$ application?

Jan. 3, 2014