Live data from Hacker News

Windows: Prefer the Native API over Win32

codeberg.org

41–50 of 99 posts

Re: Windows: Prefer the Native API over Win32

#41
> the worst case scenario is really mild: A new version of windows comes out, breaking ntdll compatibility. Zig project adds a fix to the std lib. Application developer recompiles their zig project from source, and ships an update to their users.

The ~only good thing that programmers have achieved in the past ~60 years has been Windows stability.

Create a popular programming language, and then make programs written in it not run on newer Windowses is just something else. I so hate this.

Was "robust, optimal and reusable" always "run an older Windows on your newer Windows to run Zig software"?

Re: Windows: Prefer the Native API over Win32

#42
Go famously tried to bypass macOS's libc and directly use the underlying syscall ABI, which is unstable, and then a macOS update came out and broke everything, which taught them the error of their ways (https://github.com/golang/go/issues/17490). I wonder if this will happen to Zig too.

Re: Windows: Prefer the Native API over Win32

#43

> > Won't this get flagged by anti-virus scanners as suspicious? > Unfortunately, yes. We consider this a problem for the anti-virus scanners to solve. I don't think the anti-virus scanners consider Zig important enough, or even know about. They will not be the ones experiencing problems. Having executables quarantined and similar problems will fall on Zig developers and users of their software. That seems like a maj…

>> Unfortunately, yes. We consider this a problem for the anti-virus scanners to solve.

In reality it will be a problem for the developers to solve, and the solution will be to use a different language lol

Re: Windows: Prefer the Native API over Win32

#44
post #33

> Comparing the comprehensive Win32 API reference against the incidentally documented Native APIs, its clear which one Microsoft would prefer you use. The native API is treated as an implementation detail, whilst core parts of Windows' backwards compatibility strategy are implemented in Windows subsystem. > A general-purpose programming language and toolchain for maintaining robust, optimal, and reusable software. Zi…

lately it feels like zig is attempting to speed run irrelevance. which is a shame.

Re: Windows: Prefer the Native API over Win32

#45
post #29

>> Microsoft are free to change the Native API at will, and you will be left holding both pieces when things break. > [...] the worst case scenario is really mild: A new version of windows comes out, breaking ntdll compatibility. Zig project adds a fix to the std lib. Application developer recompiles their zig project from source, and ships an update to their users. That assumes the application developer will continu…

Sounds like the iOS model: your app only exists as long as you are alive and able to pay $99/year. This mentality is a nightmare for software preservation.

Re: Windows: Prefer the Native API over Win32

#46
post #16

Why not use both DLLs? Prefer win32 wherever possible and use the lower level APIs only if absolutely necessary. Benchmark after you have figured this out. Performance is probably not a thing at this level of abstraction.

What makes you think they haven't benchmarked? Here's one fun example from following development on Zulip: advapi.dll loads bcrypt.dll, which loads bcryptprimitives.dll. bcryptprimitives.dll runs an internal test suite every time it's loaded into any process. So if you can avoid loading advapi.dll, your process will start faster.

Is there a source for this? My Google- and GitHub-fu turns up nothing.

Re: Windows: Prefer the Native API over Win32

#47

Earlier quoted context omitted.

Have you tried code-signing with an EV certificate? If so, did it help? Asking for a friend.

Statistically notable improvement, but it didn't help a whole lot.

I always upload a copy to https://www.virustotal.com to help combat the false positives.

It was really bad a couple years ago because anything wrapped in Inno Setup kept being flagged. Now maybe one or two flag vendors do; Bkav Pro and CrowdStrike Falcon are the dominate culprits always.

Re: Windows: Prefer the Native API over Win32

#48
Anyone who has some experience with native apis knows that a standard library should never rely on unstable apis. Ntdll is not "stable" as in Microsoft can change it at any time since they expect anyone to use kernel32. It's questionable that they referenced a random book on this top claiming that ntdll is more performant than kernel32 which is doubtful. There are some specific cases where this is true (the ntfs stuff), but, in general, it's not, at least not in a significant matter. A standard library should never do this, it might break binaries for no reason, other than making a cool blog post. I, as a developer, can choose to use ntfs, but a standard library should never.

https://news.ycombinator.com/item?id=25997506 https://github.com/golang/go/issues/68678

Re: Windows: Prefer the Native API over Win32

#49
post #33

> Comparing the comprehensive Win32 API reference against the incidentally documented Native APIs, its clear which one Microsoft would prefer you use. The native API is treated as an implementation detail, whilst core parts of Windows' backwards compatibility strategy are implemented in Windows subsystem. > A general-purpose programming language and toolchain for maintaining robust, optimal, and reusable software. Zi…

lately it feels like zig is attempting to speed run irrelevance. which is a shame.

I don't know, everyone here seems plenty okay to tolerate worse levels of instability from Linux binaries. :)

Re: Windows: Prefer the Native API over Win32

#50
post #41

> the worst case scenario is really mild: A new version of windows comes out, breaking ntdll compatibility. Zig project adds a fix to the std lib. Application developer recompiles their zig project from source, and ships an update to their users. The ~only good thing that programmers have achieved in the past ~60 years has been Windows stability. Create a popular programming language, and then make programs written i…

... this is just Linux binaries. It's humorous to me that we literally do exactly this, for Linux, with even less stability, but heaven forbid we do something approaching that on Windows despite the snobbery against Windows.
Post reply on HN