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

71–80 of 99 posts

Re: Windows: Prefer the Native API over Win32

#71

Post by CorrectHorseBat »

gjsman-1000 wrote: post #53
slopinthebag wrote: post #51

Earlier quoted context omitted.

im too much of a mac user to understand what this references :p

Take a random Linux binary which does anything non-trivial (has a GUI, does system monitoring, etc.), try running it on a different distribution from 3 years earlier without a packaging system, and tell me how it goes.

What confuses me the most is the kernel goes actually to great lengths not to break userspace, but if you rely on anything else than the kernel stuff breaks all the time, and distributions never update a released version to a newer kernel but just patch old kernels for years. So why do the kernel developers even bother?

Re: Windows: Prefer the Native API over Win32

#72

Post by nvme0n1p1 »

delta_p_delta_x wrote: post #46
nvme0n1p1 wrote: post #30

Earlier quoted context omitted.

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.

Join their Zulip and search for bcryptprimitives. That's where I got my info.

Re: Windows: Prefer the Native API over Win32

#73

Post by nvme0n1p1 »

lelanthran wrote: post #65
nvme0n1p1 wrote: post #30

Earlier quoted context omitted.

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.

Are you talking about the cipher tests that are run when any cipher library is loaded? There's a reason they do that and it's not for shits and giggles. You could find yourself with broken ciphers and not know it. Skipping the cipher (or hash - not sure now) tests seem like a good way to get exploited.

Zig doesn't run any code from the dll that never gets loaded, of course. Why run tests for code that is never called? If another part of your app does load the dll, the tests will still run.

Re: Windows: Prefer the Native API over Win32

#74

Post by lostmsu »

audunw wrote: post #70
lostmsu wrote: post #7

Fool's errand. Apps built with this will have to be maintained forever (vs the apps from Win 9x which still work in Windows 11).

The reason apps from Win 9x runs on Windows 11 is that MS puts a ton of effort into explicitly supporting old apps. For popular apps that includes supporting undocumented APIs and even app-specific bug compatibility. Putting it on app developers to account for infinite forward compatibility is not at all reasonable. The best outcome would be if many Zig apps become popular enough that Windows is forced to maintain ba…

> The reason apps from Win 9x runs on Windows 11 is that MS puts a ton of effort into explicitly supporting old apps.

No, that's one of the reasons. The other one is that public kernel32 -> private ntdll design works.

Re: Windows: Prefer the Native API over Win32

#75

Post by monocasa »

yndoendo wrote: post #47
monocasa wrote: post #25

Earlier quoted context omitted.

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.

Uploading to virustotal doesn't really do anything to combat false positives AFAICT. It only lets you test against many AV vendors at once.

Re: Windows: Prefer the Native API over Win32

#76

Post by renox »

thrwyexecbrain wrote: post #63
qq66 wrote: 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…

The Zig maintainers clearly think that keeping up with the undocumented native API is less headache than using the documented but notoriously inelegant win32 API. This might very well be a good idea. Microsoft is not going to change a vital piece of their OS just on a whim. I would wager that even if they wanted to, they would not be able to do so that easily. A large organization maintaining a large software with a…

It may gives them less headache but if the part about the antivirus flagging the exécutable as suspicious it may give the users headaches..

Re: Windows: Prefer the Native API over Win32

#77

Post by sebazzz »

advisedwang wrote: post #37

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

If I am not incorrect, for early boot applications, the application must be set to use the native subsystem.

Re: Windows: Prefer the Native API over Win32

#78

Post by usrnm »

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

Earlier quoted context omitted.

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

If you write your software only for yourself, do whatever you want, of course. If you want to share it with other people, artificially limiting it without a very good reason will make it less useful and popular.

Re: Windows: Prefer the Native API over Win32

#79

Post by rep_lodsb »

pjmlp wrote: post #22
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.

Nope, in UNIX proper syscalls and libc overlap, that is how C and UNIX eventually evolved side by side, in a way one could argue UNIX is C's runtime, and hence why most C deployments also expect some level of compatibility with UNIX/POSIX. Linux is the exception offering its guts to userspace with guarantees of stability.

But is the "proper UNIX way" a good thing?

Funny that you would be arguing for that (unless I misunderstood the intention), given your many other posts about how C is a horrible broken unsafe language that should not be used by anyone ever. I tend to agree with that, btw, even if not so much with the "memory safety" hysteria.

Should every program, now and in the future, be forced to depend on libc, just because it's "grandfathered in"?

IMO, Linux is superior because you are in fact free to ignore libc, and directly interface with the kernel. Which is of course also written in C, but that's still one less layer of crud. Syscalls returning error codes directly instead of putting them into a thread-local variable would be one example of that.

Should a hypothetical future OS written in Rust (or Ada, ALGOL-68, BLISS, ...) implement its own libc and force userspace appplications to go through it, just because that's "proper"?

Re: Windows: Prefer the Native API over Win32

#80

Post by wtetzner »

rep_lodsb wrote: post #79
pjmlp wrote: post #22

Earlier quoted context omitted.

Nope, in UNIX proper syscalls and libc overlap, that is how C and UNIX eventually evolved side by side, in a way one could argue UNIX is C's runtime, and hence why most C deployments also expect some level of compatibility with UNIX/POSIX. Linux is the exception offering its guts to userspace with guarantees of stability.

But is the "proper UNIX way" a good thing? Funny that you would be arguing for that (unless I misunderstood the intention), given your many other posts about how C is a horrible broken unsafe language that should not be used by anyone ever. I tend to agree with that, btw, even if not so much with the "memory safety" hysteria. Should every program, now and in the future, be forced to depend on libc, just because it's…

I don't think GP is arguing that's the best way to design an OS, just that interfacing with non-Linux Unixes is best done via libc, because that's the stable public interface.
Post reply on HN