Building Wine conformance tests on Windows

[Albert Szilvasy]

Hello there,

It appears that it is not possible to build the Wine conformance tests on Windows as described here:
http://www.winehq.org/site/docs/winedev-guide/testing-windows

In particular, when I try to build against the latest Windows SDK I get all sorts of errors.

Take for example, kernel32/tests/loader.c. It refers to IMAGE_FILE_MACHINE_ARM64. This symbol does not exist in winnt.h from Microsoft but does exist in the wine version.

How do people build the conformance tests? Cross compile on Linux?

Thanks,
albert

[Dmitry Timoshkov]

Albert Szilvasy  wrote:
> Take for example, kernel32/tests/loader.c. It refers to IMAGE_FILE_MACHINE_ARM64.
> This symbol does not exist in winnt.h from Microsoft but does exist in the wine
> version.

In this particular case the test needs to be fixed. Another solution is
to build with Wine headers.

[Albert Szilvasy]

Thanks Dimitry,

I'm new to wine so please excuse my naïveté and ignorance.

RE: the test needs to be fixed

There are lots of other errors. It looks like nobody has tried to build against the windows sdk headers for some time. I could try to fix it but if this isn't the way people work then it will get broken again and again. I'd rather stay on the beaten path than bushwhack on some old overgrown trail.

RE: Another solution is to build with the Wine headers

I've also tried this and it gets me further but not all the way. I'm just trying to build the kernel32 tests for now and I get a linker error:
volume.obj : error LNK2019: unresolved external symbol _strcasecmp referenced in function _test_GetVolumePathNameA

This is expected since _strcasecmp is called stricmp on Windows.

This really makes me wonder if building these tests on Windows is at all viable. It seems that people use some other method to build this stuff. I've checked winetest64.exe from http://test.winehq.org/data/ and it definitely wasn't built with the Microsoft toolset. I think I'll move on and try to cross compile on Linux, I suspect that's the beaten path.

albert

-----Original Message-----
From: Dmitry Timoshkov [mailto:[e-mail]] On Behalf Of Dmitry Timoshkov
Sent: Thursday, May 1, 2014 22:40
To: Albert Szilvasy
Cc: [e-mail]
Subject: Re: Building Wine conformance tests on Windows

Albert Szilvasy  wrote:
> Take for example, kernel32/tests/loader.c. It refers to IMAGE_FILE_MACHINE_ARM64.
> This symbol does not exist in winnt.h from Microsoft but does exist in 
> the wine version.

In this particular case the test needs to be fixed. Another solution is to build with Wine headers.

--
Dmitry.

[Henri Verbeet]

On 2 May 2014 19:34, Albert Szilvasy  wrote:
> This really makes me wonder if building these tests on Windows is at all viable. It seems that people use some other method to build this stuff. I've checked winetest64.exe from http://test.winehq.org/data/ and it definitely wasn't built with the Microsoft toolset. I think I'll move on and try to cross compile on Linux, I suspect that's the beaten path.

If you only care about building the tests to run them on Windows (as
opposed to building the tests on Windows specifically), I think "make
crosstest" is the easiest way. You may have to install mingw-w64 for
that to work.

[Michael Stefaniuc]

On 05/02/2014 07:44 PM, Henri Verbeet wrote:
> On 2 May 2014 19:34, Albert Szilvasy  wrote:
> > This really makes me wonder if building these tests on Windows is at all viable. It seems that people use some other method to build this stuff. I've checked winetest64.exe from http://test.winehq.org/data/ and it definitely wasn't built with the Microsoft toolset. I think I'll move on and try to cross compile on Linux, I suspect that's the beaten path.
>
> If you only care about building the tests to run them on Windows (as
> opposed to building the tests on Windows specifically), I think "make
> crosstest" is the easiest way. You may have to install mingw-w64 for
> that to work.

In that case there is even an easier solution:
Just throw the patch at the WineTestBot https://testbot.winehq.org/
You can then download the binary from there in addition to have the
testbot run it on its Windows VMs.

bye
    michael

[Stefan Dösinger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 2014-05-02 19:34, schrieb Albert Szilvasy:
> There are lots of other errors. It looks like nobody has tried to 
> build against the windows sdk headers for some time. I could try to
>  fix it but if this isn't the way people work then it will get
> broken again and again. I'd rather stay on the beaten path than
> bushwhack on some old overgrown trail.

I am building the d3d tests and libraries with Visual Studio 2013. I
sent a number of patches to fix them, but I am sure many more remain
outside the d3d code. I'm also using Wine's headers because I am
building parts of the implementation as well.

I am using Microsoft's import libraries where possible. This currently
fails for d3d8 (because it doesn't exist any longer) and d3dcompiler
(because D3DDisassemble is a private export).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTY/HcAAoJEN0/YqbEcdMwUIgP/39a8gnOG6Q4ZOsjkdUNf7Eg
cLlSB7FBaH+ePPC/7dxExYAvov7rPFMF1n7L9Wr4zSJTiffEEWZE1NPYsscrVZvS
SJxB/tbHZNIDwVhf7+cs2Un8ExtUG9YMj0kL8B2KCyikiY5fa2vi+mgOuO1uIzPP
GnKmuySPFtMyUGYtohvPlh1y2qOgWbAFgLuXTx4wtpJx/DMNmzs8escbIeEvhXmT
BO5QuF6BFDawMq1k5pSW7UFezHp7gsoNj8OeuI2iJNEp/QilZtl0JJoRNo7ePrKc
K86f1EW5KbsbHElnNFL/QiselAyGdTpyWIjXvVuX7sDM+sQQCKg2LZjWcx72svk/
LULZ9GZo/816ZHHKhoAnMCZyEf1D8qwMe1lnwkv4aZKmt0//+imSNQrZfctkpF/S
sNnRwDPdGKKuzsCyZrK16FetYSwjHKC6gHKEDEnIL/lL41nsoshrkjCPZub+cdT/
g5waUORYUGmgQ7pUuv/UD8umFTwLqlR8j7SMa/aaPtsKN/o4TlO2OrN23USha3ds
0MXYAkZxgQdoQWBENbNdub76FYH/45furiCtXkbpfvNeUENuXbHCVA5o9M7TGU7I
2gpLvukO3AoXEkh1XM8VU5SZJCGl9G2o7HwbxOSyY0k/GAJNNY1uS+l3MScVOk03
wmcivp9mstSOrINl7g5H
=J/JN
-----END PGP SIGNATURE-----

[Julius Schwartzenberg]

Albert Szilvasy wrote:
> RE: the test needs to be fixed
>
> There are lots of other errors. It looks like nobody has tried to build against the windows sdk headers for some time. I could try to fix it but if this isn't the way people work then it will get broken again and again. I'd rather stay on the beaten path than bushwhack on some old overgrown trail.

At least the avifil32 tests were known not to build on Windows and it is
not trivial to fix the problem.

If you just need the tests, cross-compilation is easy. If you really
need to build on Windows, I suspect that getting at least the most
important tests to build would be possible without much effort, but I
could be completely wrong.

Best regards,
Julius

[Dmitry Timoshkov]

Albert Szilvasy  wrote:
> RE: the test needs to be fixed
>
> There are lots of other errors. It looks like nobody has tried to build
> against the windows sdk headers for some time. I could try to fix it but
> if this isn't the way people work then it will get broken again and again.
> I'd rather stay on the beaten path than bushwhack on some old overgrown
> trail.

I routinely build Wine tests with PSDK headers and tools when I start
working on some area in Wine which needs tests. Probably a few other
people build Wine tests under Windows as well, but probably most of
developers simply crosscompile since it's way easier.
> RE: Another solution is to build with the Wine headers
>
> I've also tried this and it gets me further but not all the way. I'm just
> trying to build the kernel32 tests for now and I get a linker error:
> volume.obj : error LNK2019: unresolved external symbol _strcasecmp
> referenced in function _test_GetVolumePathNameA
>
> This is expected since _strcasecmp is called stricmp on Windows.

A test failing to compile with PSDK is a bug, and eventually should be
fixed. I'd suggest to limit the effort by the tests you really need at
this point and make only them build with PSDK as an exersize, once you
do it fixing other tests will be much easier.