Zig vectors do not necessarily force data into SIMD registers; a scalar implementation would work equally well. This is not just a theoretical argument, because Zig code that uses `@Vector` also has to compile for architectures that do not have SIMD instructions.

That being said, the parent commenter is actually referring to other recent proposals as opposed to existing `@Vector` functionality:

https://codeberg.org/ziglang/zig/issues/32032

https://codeberg.org/ziglang/zig/issues/35376

Interesting, so zig might have both "vectors" and "vecs"? I guess naming is another thing to fix before 1.0 <g>

It's not designed for IoT devices per se, the naming is just terrible. A comparison to OpenWrt is not warranted here, although to reiterate, the naming is terrible.

>It's not designed for IoT devices per se, the naming is just terrible.

IoT was the buzzword of the year when W10 released.

Yeah, bad naming is all it is.

In a way, it is for "IoT" devices...but enterprisey things. Where I work we have it on a few devices that I guess you could call an "IoT" device. Unattended driver kiosks for truck scales, manufacturing equipment that requires windows, industrial control panels, etc.

That's what it is for. A lot of this stuff uses really old software, some of which the vendor doesn't even exist anymore, and it only runs on Windows so these control panels and devices need windows (unless you manage to get some of it working on wine but that's usually not viable in these cases).

So yeah, it's supposed to be a full desktop, because these devices often require it to some extent, albeit a little slimmed down and LTS.

I think HN would be surprised to learn just how many devices run windows out there in the world outside of silicon valley. Windows is everywhere you'd hope never to see it running at.

well, i am not surprised that anything with a GUI would run some form of windows, even ATMs. i would not have categorized them as IoT devices though, but fair point.

but IoT is one of the use cases it is designed for, isn't it? regardless of the naming, suggesting to use a desktop system for IoT is ridiculous.

the comparison to OpenWRT is warranted, if microsoft expects me to run this system on devices that i would otherwise run OpenWRT on.

You're "supposed" to acquire LTSC through non-official means, not using the evaluation ISO.

So the only way to use Windows, is to use a version that's designed for IoT, and only available through enterprise channels?

It's really selling itself...

See also: https://betawiki.net/wiki/Windows_8_build_8172

Explorer uses XAML Islands. Parts of it are WinUI, while the rest is still Win32.

C++

"Good enough" is not good enough.

There's a million and one ways to do it, here's just some of the ones I remember:

- https://www.mdsec.co.uk/2022/04/resolving-system-service-num...

- https://klezvirus.github.io/RedTeaming/AV_Evasion/NoSysWhisp...

- https://whiteknightlabs.com/2024/07/31/layeredsyscall-abusin...

Though I'm not sure which of these techniques, if any, would be most favored by a game DRM as I've never looked into it.

On modern enough x86 CPUs (Intel Broadwell, AMD Ryzen) you could also use ADX [1] which may be faster nowadays in situations where radix 2^51 representation traditionally had an edge (e.g. Curve25519).

[1] https://en.wikipedia.org/wiki/Intel_ADX

According to the standard `realloc(NULL, size)` should already behave like `malloc(size)`. You shouldn't need that special case unless you're working on a system with a very buggy/non-compliant libc.