zig
zig copied to clipboard
ziglang
Minimum Supported Windows Version
Today I realized that zig build no longer works on Windows 7. The standard library is now using features that were not introduced until Windows 8. Microsoft has officially dropped Windows 7 support earlier this year (2020), however, according to some "googling", Windows 7 appears to hold a desktop share of 18%. Because of issues with Windows 10, many users continue to use this older version of the OS. I propose that because of it's apparent high market share, Zig continues to officially support Windows 7.
Windows 7 market share has been steadily declining over the years. Windows 10 finally overtook it around the beginning of 2018. Based on these numbers, Windows 7 will probably drop it's usage into the single digits sometime in 2022. Based on these estimates, extending support until 2022 could be a reasonable cut-off date.
Just for information purposes, here's where Windows 7 stopped working: https://github.com/ziglang/zig/pull/5993#issuecomment-693126335
If that's all it takes, it should be done. Since Windows 7 is not supported yet, it's not urgent though. It's worth it.
This is the kind of thing I mean by "non invasive". Even without explicit support, non invasive patches to widen support are welcome. They won't be tested by the CI though and will be maintained on best effort, but without mandatory testing.
@andrewrk
Our customers tend to keep using their base 24x7 systems longer than Microsoft EOLs. They expect us to keep their systems running with our latest enhancements.
Supporting an older windows platform gives some sort of trust the end solution will work on new platforms under certain conditions. It also keeps Multiplatform developer's VM's small/fast.
In our case we try to ship as much as possible 32-bit versions of our solutions to keep compatibility with working 32-bit third-party components as well.
Already created a small utility using zig 0.9 dev under windows 7 64-bit and Apple M1.
Thanks again for the zig language, I really think you will succeed in a better C! Looking forward to keep using it !
Hello, i'm also getting this error please solve this error i want to use zig please
I am able to build the latest master branch on Windows 7 using Option 2 here: https://github.com/ziglang/zig/wiki/Building-Zig-on-Windows
Despite Windows 7 not being officially supported by zig, I thought it would continue to work there. So I saw no issue with zig 0.8.0 and 0.8.1 failing to run with GetSystemTimePreciseAsFileTime error, as 0.9.0-dev was working fine, yet I see the same GetSystemTimePreciseAsFileTime error on officially released 0.9.0, so I'm somewhat worried. I thought that if 0.9.0-dev was working, then final release will do so too. Strangely, zig 0.10.0-dev.2+ea913846c does not exhibit this issue and works fine AFAICT on Windows 7. (Tested on Windows 7 Pro SP1 64-bit.)
Are release and dev builds vastly different?
We all understand that W7 is past its EOL time, but there are still hosts running it. Even if W7 remains not officially supported, Windows builds (including release ones) working in W7 would be beneficial for zig adoption.
Hello, i'm also getting this error please solve this error i want to use zig please
Update:
I'm updated from Operating System from windows 7 32 bit to windows 7 64 bit, and now zig works perfectly fine.
@AKDev21 Which zig version do you use exactly? From https://ziglang.org/download/ or built on your own? Release or dev (from master)?
I tested zig 0.8.1, zig 0.9.0-dev (.1622+71388b980), zig 0.9.0, and zig 0.10.0-dev (.2+ea913846c, .36+6fdf7ce0a) from ziglang.org on two Windows 7 Pro SP1 64-bit hosts (laptop with PL version of W7, desktop with EN version of W7).
Only dev builds start properly, 0.9.0 release build complains about GetSystemTimePreciseAsFileTime.
@marler8997 Are you maybe aware what makes the different behavior between release and dev builds? Where build settings for zig release and dev builds for ziglang.org are kept? Is it something that could be improved so that future zig releases from ziglang.org would run on W7?
As far as I'm aware there's no difference between a release build and a dev build other than that they are builds of different revisions. If the release build fails, my guess is that revision from which 0.9.0 is built uses that function, whereas the other revisions didn't. Try checking out each revision and grepping the std directory for GetSystemTimePreciseAsFileTime.
Which zig version do you use exactly?
I'm on windows 7 ultimate 64 bit.
If i use the 0.9.0 release, i get that GetSystemTime... error.
If i use the master release, i don't get that error.
Just here to +1 for restoring Win7 support, even in 2023, if still feasible. (First-time user here trying the latest build -- but failing on GetSystemTimePreciseAsFileTime.)
Probably no need to campaign, but: ZIG is exactly the kind of friendly, minimalist, low-dep. tool that's a perfect match for devs like myself using other frugal, robust, self-containing, long-lived tools like e.g. legacy Win7 nodes (for multiple reasons, of which minimizing infrastructure burden (complexity, cost etc.) and "change flux" are just two examples).
Thanks a lot!
PS: I saw somewhere that zig.exe only seemed to miss GetSystemTimePreciseAsFileTime, but I've just realized it was 8.1. And sure enough, the latest build also imports e.g. RtlWaitOnAddress, among others then, probably.
As far as I can tell GetSystemTimePreciseAsFileTime is likely only pulled in via mingw, as it's not directly referenced by any Zig code, so a Zig that's compiled targeting msvc might still work (or setting the Windows version as mentioned here).
Moving the discussion at https://github.com/ziglang/zig/pull/20511#discussion_r1698143979 here. Please check that comment thread for prior context.
@notcancername
I don't agree, because people still using Windows 7 will simply not use Zig when they discover it doesn't work on their machine and use C instead. That's worse for everyone involved, and certainly not serving the users.
But you just provided evidence of said users existing, so what's the problem? :slightly_smiling_face:
The problem with not requiring some evidence of Zig users on a platform, such as this, is that we can then justify adding support for any OS version that has ever been produced. As a 'fun' anecdote here, my partner's employer has her logging her work hours in a DOS program. :sweat_smile: But I don't think that's a good enough reason for Zig to support DOS.
At least as of 2021, Windows XP and older still sees widespread use in lots of infrastructure, such as public displays or ATMs:
I think the likelihood of Zig code ever being deployed to these, even if Zig supported XP, is approximately zero. If they can't be bothered to upgrade their OS, there's no reason to think they can be bothered to migrate to a completely different language and/or development toolchain.
One very notable case is that of Armenia, where Windows XP is the most popular OS, enjoying a share of 53.5% among Windows users.
Wikipedia claims that under 0.6% of Windows PCs globally are running XP. So while "53.5% of Windows PCs in Armenia run XP" sounds like a lot, in the grand scheme of things, it really isn't. My bet would be that, like quite a few other countries, a lot of Armenians have moved to smartphones, and the number you're seeing here is just ancient PCs on their last legs.
https://gs.statcounter.com/windows-version-market-share/desktop/worldwide/#yearly-2009-2024
Fair point on the need for demonstrating the existence of Zig users on platforms and ATMs, public displays.
So while "53.5% of Windows PCs in Armenia run XP" sounds like a lot, in the grand scheme of things, it really isn't.
Yes, it isn't, but it does highlight the regional difference, especially in countries that may not be able to upgrade to a newer Windows version, be it for hardware reasons or other.
My bet would be that, like quite a few other countries, a lot of Armenians have moved to smartphones, and the number you're seeing here is just ancient PCs on their last legs.
Good guess, but that isn't supported by any data. Statcounter places the percentage of website visits (including smartphones) through Windows in Armenia at 71%, and 80% of those visits used Windows XP:
https://gs.statcounter.com/os-market-share/all/armenia https://gs.statcounter.com/os-version-market-share/windows/desktop/armenia
Good guess, but that isn't supported by any data. Statcounter places the percentage of website visits (including smartphones) through Windows in Armenia at 71%, and 80% of those visits used Windows XP:
Do we have any idea how they define "website visit" in this context? That term seems a bit nebulous; I can think of multiple valid interpretations that would all likely give very different results. ("Market share" is by no means perfect either, but I would think it's a lot less ambiguous, since all you really need to do is fingerprint a visitor and determine their OS.)
In any case, supposing I take that statistic at face value, this percentage is just a portion of the aforementioned global 0.6%. When I look at it through that lens, it's still just not very convincing. We're talking about a closed-source OS that is no longer developed nor serviced by its creator (who would much prefer if people stopped using it), and is almost certainly full of security holes.
It would take active effort by the Zig team and contributors to keep support for that OS working during other development. It would require constantly thinking about whether new functionality added to the standard library can be made to work on that OS. It would require dedicating time to bug reports from users of that OS. And all that would have to be done while having no CI coverage, because I don't think there's any version of reality where the ZSF runs publicly accessible CI on an OS that insecure - and that's ignoring the funds required, and whether all the software needed for Zig CI can even run on that OS anymore (I'd bet money that the answer is no without even checking). Supporting old systems is never as simple as "just retain some code paths for it".
On top of all that, we're still probably quite a few years from Zig 1.0. We don't even know if that global 0.6% would run Zig software today if they could, let alone by the time we hit 1.0.
It's not as if I have zero sympathy with folks who are unable to upgrade because of factors outside their control (e.g. a poor economy), but at some point we have to acknowledge that we can't solve all the world's ills, and our time would be better spent doing the good that we can.
@alexrp commented 3 days ago:
I think the likelihood of Zig code ever being deployed to these, even if Zig supported XP, is approximately zero. If they can't be bothered to upgrade their OS, there's no reason to think they can be bothered to migrate to a completely different language and/or development toolchain.
Now that was offensive. Why upgrade the OS if it perfectly suits the user's setup / limited resources? Do we really need a religion war? :)
And then it discriminates the @reactOS project which targets NT 5.2 architecture.
It would take active effort by the Zig team and contributors to keep support for that OS working during other development. It would require constantly thinking about whether new functionality added to the standard library can be made to work on that OS. It would require dedicating time to bug reports from users of that OS.
I don't see it that way. I liked summary from @andrewrk written on Dec 1, 2020:
Even without explicit support, non invasive patches to widen support are welcome. They won't be tested by the CI though and will be maintained on best effort, but without mandatory testing.
PS. When I read "best effort" an addendum "from what is left" immediately occurs to me which then means "worst effort" (more and more with every day of my life). And that's fine.
Small effort is expected and appreciated. :)
Now that was offensive. Why upgrade the OS if it perfectly suits the user's setup / limited resources?
Knowingly running an outdated, insecure, and closed-source operating system with a massive attack surface is irresponsible. It's also unreasonable to expect FOSS ecosystems to continue to support it a decade after even the corporation that created it has ceased their extended support for it.
I also don't think "limited resources" has anything to do with the specific example of public displays. You can't claim to have limited resources and then run a whole Windows operating system for something that simple. The math don't math here.
Do we really need a religion war? :)
There has been nothing religious about the style of argumentation used by anyone in this discussion so far.
And then it discriminates the @reactos project which targets NT 5.2 architecture.
ReactOS aims to support NT 6+ APIs with an NT 5 kernel; it isn't frozen in time on NT 5.2. Also, ReactOS is an active, open source project with ongoing development. It does not suffer from the same security or stagnation concerns.
I think ReactOS support is entirely reasonable.
I don't see it that way. I liked summary from @andrewrk written on Dec 1, 2020:
That comment was made in the context of Windows 7 support, 4 years ago. Seems like a stretch to extrapolate that to Windows XP support today; I would like clarification from Andrew that that's actually what he meant.
Knowingly running an outdated, insecure, and closed-source operating system with a massive attack surface is irresponsible.
This is true if you're connecting to the internet through an old browser. Not true if network-facing code is limited to a secure subset, or in my case, if the device never connects to the internet. I have an old Windows 7 machine for my live music performance that never connects to the internet (I learned my lesson after an automatic update broke USB). I transfer files manually via USB and I keep an old version of Zig to compile my Zig code on the device. This is a self-contained system that I consider "finished" aside from any new Zig programs I might want to write for it in the future. It will never be updated and will run with it's current OS until the hardware fails or I do :)
That being said I don't expect Zig to support Windows 7 moving forward. I think support for older versions of Windows and other less-popular platforms can/should be maintained by the community. I think the best things Zig can do is help direct/guide people to those community spaces that would maintain these things and also keep these use cases in mind to help make it easy to plug in and integrate support for these kinds of system.
Contributions to handle OS versions below the minimum supported version are welcome, provided that they are non-invasive: minimal impact on the maintenance cost of the standard library, and no impact on the runtime properties of compiled code that has the OS minimum version set to exclude the old versions.
The Windows 8.1 page size check thing seems fine to me. Why would you depend on a new API to learn the page size anyway, that should be a super old API.
Please don't accuse each other of being offensive or irresponsible, it's off topic.
Contributions to handle OS versions below the minimum supported version are welcome, provided that they are non-invasive: minimal impact on the maintenance cost of the standard library, and no impact on the runtime properties of compiled code that has the OS minimum version set to exclude the old versions.
Would you say that 4e5068c actually went too far then? For example, while fallbacks for lack of statx() would be quite invasive, and the copy_file_range() version check logic was a bit gnarly, the fallback for getrandom() was just a fairly innocuous one-liner. I can restore that if desired.
Please don't accuse each other of being offensive or irresponsible, it's off topic.
I'll mark this comment as off-topic, but I just wanted to make clear that this was not intended as a personal attack. 🙂 This was specifically meant to be taken in the context of my earlier comments re: organizations whose leadership refuses to upgrade their long-EOL OS.
Here's my nickel to add to the justification box: the ability to build applications with a guarantee of launching (not running! - this is a programmer's headache) on older systems would be a killer feature and a serious claim to the status of a language that competes directly with C in this regard (Rust? what Rust? 🤭). The point here is not about supporting outdated systems (although being able to write an application compatible with the entire Windows line would also be cool), but about ensuring that the system requirements of the application shall not increase with the compiler version. Because this is regression, not progress. Now it is effectively impossible for customers to write system applications with long-term support even as a special paid option, because each new version of the compiler may simply force a further choice: either the client's desires or language improvements.
That being said, it would be great to have a non-monolithic standard library in Zig, where each imported system function would specify the minimum target system version that is suitable for it to be used. The ability to specify a minimum required system version during compilation, resulting in errors if a function from a newer one was accidentally used, would solve the compatibility problem completely and would not require any additional investment.
If I'm not the only one who likes this idea, then I suppose this issue could be dedicated to it. Keep in mind that Windows 10 will reach end-of-life in October 2025, and that's Not Fun (at all), while the combined market share of legacy Windows is still comparable to that of MacOS.
Workaround for zig on win7 SP1
TL;DR: VxKex (https://github.com/i486/VxKex) provides support for ZigLang on Win7 SP1
Details:
I left message in this ticket for all folks, who, like me, failed to google easy-to-use support of zig on win7. I Provide detailed baby steps so unexperienced users will not be confused.
Downside is for every exe file VxKex should be enabled.
Env:
windows:
$ wmic os get Caption,CSDVersion /value
Caption=Microsoft Windows 7 Ultimate
CSDVersion=Service Pack 1
$ ver
Microsoft Windows [Version 6.1.7601]
zig: https://ziglang.org/download/0.13.0/zig-windows-x86_64-0.13.0.zip taken from https://ziglang.org/download/#release-0.13.0
vxkex:
in my local machine ver 1.1.1.1375 was installed a year ago but I suspect latest ver should be fine as well
https://github.com/i486/VxKex/releases/download/Version1.1.1.1375/KexSetup_Release_1_1_1_1375.exe
taken from https://github.com/i486/VxKex/releases/
Steps:
-
Install VxKex and restart machine. It will add new tab "VxKex" in properties of executable files. Unzip zig somewhere
-
By default zig shows error:
zig.exe version
message box "The procedure entry point GetSystemTimePreciseAsFileTime could not be located in the dynamic link library KERNEL32.dll."
Click right mouse button on zig.exe -> Properties -> "VxKex" tab -> "Enable VxKex for this program" Now it works as expected
zig.exe version
0.13.0
- Also any zig file will work: Create file "main.zig" with content
const std = @import("std");
pub fn main() void { std.debug.print("Hello, {s}!\n", .{"World"}); }
run it
zig.exe run main.zig
Hello, World!
Hovewer executable will fault untill VxKex is enabled:
zig build-exe main.zig
New file main.exe will be created but it will not work: You will see error message box "The procedure entry point RtlWaitOnAddress could not be located in the dynamic link library ntdll.dll."
Click right mouse button on main.exe -> Properties -> "VxKex" tab -> "Enable VxKex for this program". Now main.exe works and prints "Hello, World!" in console.
-
If executable is copied to new location VxKex should be enabled again.
-
Windows specific things works as well, for example you could build exe from the content of a file: https://github.com/bg-thompson/window-spawning-examples-in-zig-for-windows/blob/main/question-prompt.zig Winapi MessageBoxA is used there:
extern "user32" fn MessageBoxA(?HWND, LPCSTR, LPCSTR, UINT) callconv(WINAPI) INT;
- Under the hood VxKex uses Image File Execution Options So for example if I marked 2 instances of main.exe as VxKex I could see corresponding entities in registy
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\main.exe]
"UseFilter"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\main.exe\VxKex_1B64BF3776BBFFBD]
"FilterFullPath"="C:\\Tools\\zig-0.13\\main.exe"
"KEX_DisableForChild"=dword:00000000
"KEX_DisableAppSpecific"=dword:00000000
"KEX_WinVerSpoof"=dword:00000000
"KEX_StrongVersionSpoof"=dword:00000000
"GlobalFlag"=dword:00000100
"VerifierFlags"=dword:80000000
"VerifierDlls"="kexdll.dll"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\main.exe\VxKex_3C36AB814210A1DA]
"FilterFullPath"="D:\\123\\main.exe"
"KEX_DisableForChild"=dword:00000000
"KEX_DisableAppSpecific"=dword:00000000
"KEX_WinVerSpoof"=dword:00000000
"KEX_StrongVersionSpoof"=dword:00000000
"GlobalFlag"=dword:00000100
"VerifierFlags"=dword:80000000
"VerifierDlls"="kexdll.dll"
That is a hint how to automate deployment of zig executables w/o user interaction
P.S. Despite https://github.com/i486/VxKex directly states support for Zig I didn't see it. Could somebody puts explicit information of Win7 support in documentation?
there is a project YY-thunks
Isn't there a solution to quickly deal with the problem that the old system can't find the API?
YY-Thunks can solve these kinds of problems quickly and without changing the code. These compatibility issues
can be resolved automatically by tweaking the linker. It's easier to make your apps compatible with older versions
of Windows!
rust program can use this project to support win xp/2003, even support libraries such as tokio and slint.
but, it only works with msvc toolchain. I think this is the right way to do that a program language want to support older version system.
rust program can use this project to support win xp/2003, even support libraries such as tokio and slint.
There's even a Cargo extension already exists, exactly for this: https://github.com/felixmaker/thunk.
(marking as offtopic)
Try VxKex-NEXT, since big-corp seems to have put a stop on original VxKex.
After installing VxKex, Windows 7 support is as simple as opening .exe file's properties, then in VxKex tab, check Enable VxKex NEXT for this program.
On the other hand, waiting for the day that YY-Thunks gets used by Zig is an option as well, or, the day that my polyfill gets merged.
