introduce operating system version ranges as part of the target

[andrewrk]

On Linux we have kernel versions: 3.14, 4.14, 4.18, etc.

On Windows we have versions, e.g.

• XP
• Vista
• 7
• 8
• 10

FreeBSD has the concept of versions: most recent e.g. 12.0

MacOS / iOS has the concept of versions too - e.g. 10.14.3

I propose for OS minimum version and maximum version to be part of the target. When you specify an OS minimum version as part of the target, it is telling userland code what ABI it can rely on. Each OS will have a default minimum version. Some standard library functions (or functions from third party packages) may give a @compileError("this API supported only on OS version xyz and later"). The OS minimum version will be available for userland code to observe in @import("builtin").

Maximum version is also useful, because it can avoid code bloat, when it is compile-time known that the code will not be able to take advantage of newer OS features.

When compiling for the native target, the minimum and maximum OS versions will be the same.

[bfloch]

I believe the story with windows is a bit more complicated than just using the "marketing" version:

https://docs.microsoft.com/en-us/windows/desktop/SysInfo/operating-system-version

It all started by genius marketing to call API version 6.1 "Windows 7" and went downhill from there. I guess after some negative press they just decided to re-version their 6.4 API to 10 [1].
To make things better the Version API in Windows 10 will return Windows 8 if the app was not manifested for 8.1 or 10, which I assume is done to solve backwards compatibility (?).

What does that mean in terms of target version? Not sure but I have the feeling that the API version is more useful then the marketing version.

Is Windows XP really more like a distro label, while 5.1/5.2 is what matters as platform/API?
Maybe a Windows dev can clarify this further.

[1] https://www.digitaltrends.com/computing/windows-10-kernel-to-leapfrog-from-6-4-directly-to-10-0/

[daurnimator]

Is Windows XP really more like a distro label, while 5.1/5.2 is what matters as platform/API?

Usually _WIN32_WINNT is what really matters

[shawnl]

It all started by genius marketing to call API version 6.1 "Windows 7"

We use to call it "Vista 7".

[andrewrk]

For macOS, there's an important linker flag -mmacos_version_min. 5784631 bumped the default from 10.10 to 10.14, but the better solution will be to have this as part of the target. And then the native target should use the current OS version for this value.

[andrewrk]

Regarding the Windows stuff, people in this thread who have a better understanding than me, can you help me come up with the enum that represents Windows API versions? Here's what I would do on first guess:

const WindowsVersion = enum {
    Legacy, /// Represents a version that is unsupported due to being too old.
    v7,
    v8,
    v10,
    v10_2015LTSB,
    v10_2016LTSB,
    v10_2019LTSC,
    Unreleased, /// Represents a version of windows not yet released.
};

The compiler will also need a way to detect the version of the native target.

[shawnl]

Linux has a special ELF section for this (and file reads it[1]), however it is not enforced for static binaries, so we would have to enforce it ourselves (which I think is a good idea). https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/noteabitag.html

Example: qt/qtbase@bb8a618#diff-e4c3c13b1c7ed0faa458312ad4d5c1da

[1] a.out: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=64dbf5608aa84b8eff7ced72abd13868652890e5, for GNU/Linux 5.3.28, not stripped
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=5b9ea55987638c03288db9433abad05bd0621111, for GNU/Linux 5.3.28, not stripped

[daurnimator]

can you help me come up with the enum that represents Windows API versions?

From window's sdkddkver.h: (see also https://docs.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt?view=vs-2019 )

#define _WIN32_WINNT_NT4                    0x0400
#define _WIN32_WINNT_WIN2K                  0x0500
#define _WIN32_WINNT_WINXP                  0x0501
#define _WIN32_WINNT_WS03                   0x0502
#define _WIN32_WINNT_WIN6                   0x0600
#define _WIN32_WINNT_VISTA                  0x0600
#define _WIN32_WINNT_WS08                   0x0600
#define _WIN32_WINNT_LONGHORN               0x0600
#define _WIN32_WINNT_WIN7                   0x0601
#define _WIN32_WINNT_WIN8                   0x0602
#define _WIN32_WINNT_WINBLUE                0x0603
#define _WIN32_WINNT_WINTHRESHOLD           0x0A00 /* ABRACADABRA_THRESHOLD*/
#define _WIN32_WINNT_WIN10 0x0A00 /* ABRACADABRA_THRESHOLD*/

I think that should translate to the following zig definition:

const WindowsVersion = enum(u16) {
	WindowsNT4 = 0x0400,
	Windows2000 = 0x0500,
	WindowsXP = 0x0501,
	WindowsServer2003 = 0x0502,
	WindowsVista = 0x0600,
        WindowsServer2008 = 0x0600, // are duplicate enums allowed?
	Windows7 = 0x0601,
	Windows8 = 0x0602,
	Windows8_1 = 0x0603,
	Windows10 = 0x0A00,
}

[emekoi]

@daurnimator see #2115