[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