AppVeyor/MSVC: Use Windows XP toolset

[dannyedel]

This should™ only use Windows functions that are also available on Windows XP.

If nothing else, this allows me to run dspdfviewer under ReactOS and WinXP VM's which need a lot less system resources than Win7 or higher. So far, I have not seen any indicator that something would not work.

This has no effect on compiling dspdfviewer, since MSVC2013 won't run on XP.

[dannyedel]

@projekter what do you think? Could this go into the next official windows binary build?

I have not had any problems, and was able to run a (dynamic) executable after copying all those dll's on both a WinXP SP3 and a ReactOS VM. No Idea if static-build makes any difference, but personally I find it nice to create the executable as compatible as possible, and it seems this one line changes the compatiblity from "windows 7 and up" to "windows xp and up".

Note I did not recompile any of the other libraries, I just used the already-built DLLs. It seems they all don't use any "only-windows-7" APIs.

[projekter]

When I dropped support for IE6, I also removed my XP VM, so I cannot tell you whether it works, perhaps you can try. But honestly, you really have to do very OS specific things in order not to be backwards-compatible. None of my applications so far had the problem of not running on XP; some of them would probably even do on Win95, if they do not use Unicode. Testsuite works; this time, I also run testswapscreen, which gives lots of warnings, which I have put in a gist. The release is uploaded.

[dannyedel]

The setup.exe works on XP, but trying to start dspdfviewer.exe gives error 193. I got the same error on the dynamic executable before I deleted the cmake-build-dir and re-created it with the cmake -T v120_xp setting (see e88963e for the exact position). I suppose between winxp and win7 something in the .exe header changed, and this flag tells the linker to make "old-style" executables.

[projekter]

I made the changes in cmake and reuploaded the release. Does it now work?

[dannyedel]

Yes it does! Including chinese letters btw : )

Regarding the error output:

WARNING RenderThread for [page 2/both/456x204] failed

I will look into why this happens. Testswapscreen uses the images.pdf file which only has one page, and it does set command line parameters to prerender only zero pages, so the question is why is page 2 requested in the first place.

[projekter]

Well, testswapscreen always crashed for me, until I found out that I had to supply a PDF file name. I did not chose images.pdf but instead one of my presentations.

[dannyedel]

until I found out that I had to supply a PDF file name.

The test programs are supposed to be executed using ctest -- on Windows, a command like

ctest . --output-on-failure -C Release

should do the trick, executed inside the build-dir. On AppVeyor I just called msbuild on the RUN_TESTS.vcxproj target, but there msbuild carries the "Release/Debug" flag internally. (On Linux, the Makefiles generated by CMake are specific to Release or Debug)

For reference: the command-line parameters that CTest uses are specified in testing/CMakeLists.txt, but this shouldn't be necessary.

[projekter]

Ah, I always use Visual Studio to compile and then run the tests from the command line. Using ctest, all of them passed without warning.

[dannyedel]

When I loaded the cmake-generated dspdfviewer.sln file, I could see the RUN_TESTS target inside Visual Studio. I just had to set it to the "default execution target" or something like that.