HN user
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:
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.
You're "supposed" to acquire LTSC through non-official means, not using the evaluation ISO.
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).
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.
It just uses GDI_CLASSIC for DWRITE_MEASURING_MODE [1] and DWRITE_RENDERING_MODE [2] in that case. No actual GDI in sight.
[1] https://learn.microsoft.com/en-us/windows/win32/api/dcommon/...
[2] https://learn.microsoft.com/en-us/windows/win32/api/dwrite/n...
The much dreaded Annex K functions are perhaps the worst possible example of an attempt at "fixing" anything safety related in C. A waste of ink.
Are there any benchmarks of Windows EH? The implementation is very different from DWARF/SJLJ EH and it would be interesting to see how it fares. I've seen some pretty exceptional claims for both sides of the argument (e.g. "[...] has no code impact for x64 native, ARM, or ARM64 platforms" [1]), but there's rarely if ever any data to back this up.
[1] https://github.com/Microsoft/DirectXTK/wiki/throwIfFailed
Is a single MOV instruction still fast when the 8 bytes begin on an odd address?
On x86, yes. There is no performance penalty for misaligned loads, except when the misaligned load also happens to straddle a cache line boundary, in which case it is slower, but only marginally so.
I think you should be able to get rid of most of the undocumented API usage with the newer CreateFileMapping2/MapViewOfFile3 APIs. Though that does require a higher minimum OS version and the crucial NtExtendSection function still has no documented equivalent as far as I can tell, so it's kind of a wash.
Also, you can link against ntdll.lib directly. Manually calling GetProcAddress for a few functions isn't a tragedy by any means, but in this case, why bother?
Great article nonetheless!
Be aware that if you actually want to do as the article prescribes, don't just copy and paste -- you shan't take anything at face value in C: https://news.ycombinator.com/item?id=31718292.
There is also Comic Code by the same author: https://tosche.net/fonts/comic-code. Feels like a more polished version of Comic Mono (but it is paid, too).
You don't need this exploit. You could use a media player that doesn't need MS codec packs, but assuming this is not an option:
1. Go to https://store.rg-adguard.net.
2. Paste in https://apps.microsoft.com/detail/9n4wgh0z6vhq.
3. Change ring to "Retail".
4. Download the file with an "appxbundle" extension.
5. Install it (might need to enable developer mode for this step; don't remember).
is this possible or is the backend selected e.g. based on the OS?
Selected in a reasonable order by default, but can be overridden.
There are three ways to do so:
- Set the SDL_HINT_GPU_DRIVER hint with SDL_SetHint() [1].
- Pass a non-NULL name to SDL_CreateGPUDevice() [2].
- Set the SDL_PROP_GPU_DEVICE_CREATE_NAME_STRING property when calling SDL_CreateGPUDeviceWithProperties() [3].
The name can be one of "D3D11", "D3D12", "Metal" or "Vulkan" (case-insensitive). Setting the driver name for NDA platforms would presumably work as well, but I don't see why you would do that.
The second method is just a convenient, albeit limited, wrapper for the third, so that the user does not have to create and destroy their own properties object.
The global hint takes precedence over the individual properties.
[1] https://wiki.libsdl.org/SDL3/SDL_HINT_GPU_DRIVER
[2] https://wiki.libsdl.org/SDL3/SDL_CreateGPUDevice
[3] https://wiki.libsdl.org/SDL3/SDL_CreateGPUDeviceWithProperti...
The current SDL GPU API does not intend to use this shader language. Instead, users are expected to provide shaders in the relevant format for each underlying graphics API [1], using whatever custom content pipeline they desire.
One of the developers made an interesting blog post motivating this decision [2] (although some of the finer details have changed since that was written).
There is also a "third party" solution [3] by another one of the developers that enables cross-platform use of SPIR-V or HLSL shaders using SPIRV-Cross and FXC/DXC, respectively (NB: It seems this currently wouldn't compile against SDL3 master).
[1] https://github.com/libsdl-org/SDL/blob/d1a2c57fb99f29c38f509...
Just to add one more data point, the .NET GC is also written in C++.
It's very common in games.
Integers are always an option, of course, but in this context it's hard to beat the convenience of just storing seconds in a floating point number.
Related: https://randomascii.wordpress.com/2012/02/13/dont-store-that...
This is a fair concern.
Does anyone know more about the security of the 8-round form and whether we should be concerned?
This is the latest cryptanalysis I could find (see Table 2 and 3 for an overview):
https://ieeexplore.ieee.org/document/10410840
We don't even have an attack against ChaCha8. While it is likely one will appear as cryptanalysis improves, it is far less likely such an attack will ever become practical.
But obviously, not everyone from within the cryptographic community would agree with JP Aumasson either. For example, DJB had this to say 1 year and 5 months before "Too Much Crypto" first appeared on the IACR ePrint archive: https://twitter.com/hashbreaker/status/1023969586696388613.
So in conclusion; somewhat inconclusive? Going by the results so far, ChaCha8 is probably fine.
The author of that talk, Eric Lengyel, also wrote the book "Foundations of Game Engine Development, Volume 1: Mathematics". Its 4th chapter focuses on the same topics.
The author of the post happens to be the person who implements your crypto, so you don't have to roll your own: https://github.com/FiloSottile.
(I personally also wouldn't use OpenSSL as an example of good cryptographic code)
From the linked GitHub repo:
As for the heap allocated objects, they will be allocated from unmanged(non-GC) memory, and will be allocated/freed exactly like in Rust.
I understand this decision, but it would also be interesting to see a version of this that hijacks the global allocator and the alloc types to use the GC instead (while still allowing you to opt-out and use unmanaged memory).
Good work nonetheless!
Yes and no.
My post specifically mentions UTF-16 and WTF-16, too. The term "Unicode string" exists and is well established: https://unicode.org/glossary/#unicode_string.
Windows Unicode strings happen to fit this definition, but of course, so would UTF-8 strings. Either way, in Windows's version of reality the definition is narrowed to mean "potentially ill-formed UTF-16LE encoded string", but that doesn't exactly roll off the tongue, so for better or for worse, "Unicode string" is the consistently and widely used Windows-specific nomenclature.
that release finally made UTF-8 the standard text encoding
This is a bit of a reach unfortunately. UTF-16 (most often broken WTF-16) is still the standard text encoding on NT. The manifest change only makes A-suffixed functions always do a "UTF-8 to UTF-16" conversion, instead of the unhelpful "local codepage to UTF-16" conversion. Sure, that's better, but:
- Microsoft has expressed no interest in switching the actual underlying encoding to UTF-8, they will likely never do so in NT.
- A-suffixed functions only exist for some Win32 API. Newer Win32 functions are defined only taking Unicode strings. All COM, WinRT and native (Rtl/Nt) APIs use Unicode strings as well. The UTF-8 API surface is actually quite small - one might have to step out of the UTF-8 comfort zone in practice.
- Performance is being left on the table. Transcoding still has to be done, it would be more beneficial to at least keep it local for optimization purposes. The most trivial, yet still important use case: constant string conversions can't be optimized across DLL boundaries.
- Unlike, say, DPI awareness mode, there is no official API to change this behavior at runtime. It has to be done through the manifest, a compiler implicitly embedding such a manifest into every executable it produces is not ideal.
TL;DR: It's an improvement, but just barely, so bumping the minimum version just for this "feature" is not worth it IMO. Just bite the bullet and convert to UTF-16 if you have to, it's conceptually simpler and likely faster, too.
It made the switch, sure, but overflow remains undefined.