[vlc-devel] [PATCH] vlc_fixups: allow overriding the minimum Windows SDK for certain files
Steve Lhomme
robux4 at ycbcr.xyz
Sat Mar 7 07:58:12 CET 2020
On 2020-03-06 17:18, Remi Denis-Courmont wrote:
> Le 2020-03-06 17:06, Steve Lhomme a écrit :
>>> I don't see how that would actually work. <vlc_fixups.h> could end up
>>> defining stuff which conflicts with newer Windows versions and the
>>> build would fail.
>>
>> We have never had the case so far and since at least 3.0 we compile
>> some C file with a different _WIN32_WINNT than the project one.
>
> IIRC, it did happen in the past. But anyway, I don't think we should be
> defining a custom way to set the Windows version. That will cause
> confusion and problems sooner or later.
>
> Just define the version before you include config.h if that's what you
> need. The current #undef style is anyway invalid, as you're not supposed
> to be able to change the version half-way through your #include's.
>
>> In 4.0 it's currently not an issue, we don't support anything older
>> than Win7 so all of these defines have actually no effect. The idea
>> here is to have a common way to do it so it can be backported to 3.0.
>
> I don't think we should be making potentially dangerous changes to the
> build system in 3.0 at this point.
The thing is, mingw64 is getting cleaner headers everyday. Things that
used to be available all the time are only available depending on the
version you pick. (something that was already clean in MS headers and
also got further cleaning)
So we need to find a clean way to be able to used newer APIs even though
we target an older version of Windows. Typically D3D11 is not available
in XP but yet we want it to build for users on Windows 10. Dynamic
loading of DLL is one step in that way. But we still need to access the
structures/defines in the headers. I think it's a fairly common thing on
Windows to force the SDK version for a specific file. I agree it's not
100% proof as theoretically you might be using structures/defines that
are different from the rest of the code (function signatures are
unlikely, they usually add a new API). But given that's how the OS
evolved over the years, it's designed to be pretty safe in that regard.
More information about the vlc-devel
mailing list