Force _WIN32_WINNT variable

[Gazyi]

Fixes #612.
Compiled on Win 10, launches and works fine on Win 7.

[p0358]

This should be fine tbh probably, as long as it doesn't break newer Windowses (also shouldn't).

Although ngl a cleaner solution would probably to define a shim for CreateFile2 that'd in turn call CreateFileW instead with the right params, as chances are this might be the only cause and place it breaks. Then our own CreateFile2 replacement would be used instead of linking it from Windows... This would be simpler and less risky of potential unknown breakage somewhere else.

[p0358]

Also also also also: zlib-ng/minizip-ng@9829913

You should create an issue in the original repo mentioning that since they don't do a check for WinRT API anymore at all, they should just junk that check before CreateFile2 and simply just use CreateFileW, there's ZERO reason for them to use CreateFile2 now to begin with (apart from old limited WinRT API that isn't checked for anymore?), especially that they DON'T use the last LPCREATEFILE2_EXTENDED_PARAMETERS pCreateExParams param of CreateFile2, passing NULL there, meaning they literally could just use CreateFileW...

[p0358]

As for the shim func, just do this:

HANDLE CreateFile2(LPCWSTR lpFileName, DWORD dwDesiredAccess, DWORD dwShareMode, DWORD dwCreationDisposition, LPCREATEFILE2_EXTENDED_PARAMETERS pCreateExParams)
{
    return CreateFileW(lpFileName, dwDesiredAccess, dwShareMode, NULL, dwCreationDisposition, NULL, NULL);
}

[p0358]

And actually, if we go this way (of this PR), it would be preferred to have this define set only when compiling the actual files of minizip library itself, instead of applying it to main project and all children...

[Gazyi]

I found a way to define variable only for Minizip lib.

As for the shim func, just do this:

HANDLE CreateFile2(LPCWSTR lpFileName, DWORD dwDesiredAccess, DWORD dwShareMode, DWORD dwCreationDisposition, LPCREATEFILE2_EXTENDED_PARAMETERS pCreateExParams)
{
    return CreateFileW(lpFileName, dwDesiredAccess, dwShareMode, NULL, dwCreationDisposition, NULL, NULL);
}

I'm not sure where to do that. Should it be a WinAPI hook or something else?

[p0358]

I'm not sure where to do that. Should it be a WinAPI hook or something else?

Technically in any file that's getting compiled in, and that should then cause it to be linked (I'm hoping the linker won't complain about symbol duplication though...). As for particular place, perhaps a new file under /primedev/windows/?

[ASpoonPlaysGames]

Code looks fine as far as I'm aware. I'm no expert on this topic though.

[p0358]

This is fine imo with this method, where the variable is limited just to the dependent library and thus limits possible impact of side effects its definition might had otherwise imposed in main project. I assume that the PR author checked that it still works on Win7 with the latter changes xd

[Gazyi]

This is fine imo with this method, where the variable is limited just to the dependent library and thus limits possible impact of side effects its definition might had otherwise imposed in main project. I assume that the PR author checked that it still works on Win7 with the latter changes xd

Current main branch build is working fine.

[GeckoEidechse]

For testing, I assume just join a server that requires a mod through MAD and make sure it extracts correctly, right?

[p0358]

Yeah you might do that. But original issue was with linking and bailing out on missing symbol. So just ensuring the game still starts up to begin with on Win10 is enough. If you don't test on actual Win7, then check with some tool like Detect-It-Easy or whatever else (PE Explorer etc) whether in Imports section from iirc kernel32.dll whether there's just CreateFile and not CreateFile2. For extra scrutiny you can confirm that CreateFile2 import is there on DLL before this PR is applied

[Alystrasz]

For testing, I assume just join a server that requires a mod through MAD and make sure it extracts correctly, right?

Btw, I tested joining a server with mad and this PR, and everything went fine.

[GeckoEidechse]

Aight given that this appears to have no effect on newer Windows versions then, I'm fine with merging this even if we don't support older Windows version.

The suggested solution for issues with older Windows versions is of course to switch to Linux update to a supported Windows version, however I also don't see a need to actively oppose a community contribution, given that it has no (negative) effect on supported platforms.