Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Windows: Prefer the Native API over Win32

codeberg.org

Post reply on HN
Print view View original

31–40 of 99 posts

Re: Windows: Prefer the Native API over Win32

#31

Post by eps »

cmovq wrote: 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…

> Microsoft are free to change the Native API at will,...

But they won't, because if there is one thing that Microsoft has always been extremely good at and cared for is backward compatibility. And changing Native API will break a ton of existing software, because even though undocumented it is very widely used.

Re: Windows: Prefer the Native API over Win32

#33

Post by qq66 »

> 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.

Zig clearly doesn't actually care that much about building robust and reusable software if they're going to forgo Microsoft's decades-long backwards compatibility functionality for the dubious gains of using bare-metal APIs.

Re: Windows: Prefer the Native API over Win32

#34

Post by eps »

pseudohadamard wrote: post #2

For people not familiar with Windows development, another name for the NT native API is "the API that pretty much every document on Windows programming tells you not to use". It's like coding to the Linux syscall interface instead of libc.

"Every document" notwithstanding, Native API is very widely used in practice and generally considered stable.

If in doubt, try and find examples of its breakage, semantic changes, etc.

Re: Windows: Prefer the Native API over Win32

#35

Post by koakuma-chan »

usrnm wrote: post #23
koakuma-chan wrote: post #10

Earlier quoted context omitted.

> It's like coding to the Linux syscall interface instead of libc. The right thing to do? I don't see why I would want to use libc.

> I don't see why I would want to use libc To make your code portable? Linux-only software is even worse than Windows-only

Let me narrow down the scope here. I am a Rust developer, developing software that will run on my Linux server. Why would I want to use libc? Why does Rust standard library use libc? Zig, for example, doesn't.

Re: Windows: Prefer the Native API over Win32

#36

Post by blibble »

eps wrote: post #31
cmovq wrote: 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…

> Microsoft are free to change the Native API at will,... But they won't, because if there is one thing that Microsoft has always been extremely good at and cared for is backward compatibility. And changing Native API will break a ton of existing software, because even though undocumented it is very widely used.

you are confusing the ntdll interface (which is undocumented and subject to change), and win32 (which is stable, mostly)

they tell you not to use ntdll, and say they will change it whenever they want

and they have in the past

(they have had to moderate this policy with "containers", but it's still what they say)

Re: Windows: Prefer the Native API over Win32

#37

Post by advisedwang »

I'm really struggling to see the pros of this:

> Performance - using the native API bypasses the standard Windows API, thus removing a software layer, speeding things up.

But the article cites no bemchmarks

> Power - some capabilities are not provided by the standard Windows API, but are available with the native API.

Makes sense when you are doing something that needs that power, but that makes more sense as an exception to prefering win32 than a general reason to prefer native.

> Dependencies - using the native API removes dependencies on subsystem DLLs, creating potentially smaller, leaner executables.

Linking win32 is a miniscule cost. (unless you have a benchmark to show me...)

> Flexibility - in the early stages of Windows boot, native applications (those dependent on NtDll.dll only) can execute, while others cannot.

Is Zig being used for such applications? If so, why are the calls that the document says will be kept on win32 not an issue?

Re: Windows: Prefer the Native API over Win32

#40

Post by dleslie »

roelschroeven wrote: post #12

> > 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…

Yup. This sentiment expresses quite clearly how Zig has no significant understanding or interest in being a language used for widely distributed applications, like video games.

There's no way I can ship a binary that flags the scanners. This wouldn't be the first language I've avoided because it has this unfortunate behaviour.

And expecting virus scanner developers to relax their rules for Zig is a bit arrogant. Some virus scanners started flagging software built with Nim simply because Nim became popular with virus authors as a means to thwart scanners!

Post reply on HN