Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Only passingly related, some fun rust stack-allocation insanity by my 17yo son:by jacknews
- Very impressive for a 17yo!by anitil
- 17? You should be very proud. This is good work for anyone, but especially at his age!by jjice
- This is great. I'm learning Rust myself and your son's article contributed to my knowledge.
I'm also very impressed by part 2. I have my own lisp but I haven't managed to implement a compiler or code generation yet. Really enjoyed reading about the hashmap too. The textbook solution to collisions is probing and comparison. It never occurred to me that I could just resize the underlying array until the collisions disappear altogether.
- Related to the above, two important concepts to know w.r.t a stack are "Red Zone" and "Guard Pages".
Raymond Chen again;
Why do we even need to define a red zone? Can’t I just use my stack for anything? - https://devblogs.microsoft.com/oldnewthing/20190111-00/?p=10...
A closer look at the stack guard page - https://devblogs.microsoft.com/oldnewthing/20220203-00/?p=10...
by rramadass - I wonder how Linux manages without explicit _chkstk? In my experience, it feels like MAP_GROWSDOWN regions have way more than 1 guard page below its start — I can poke like a megabyte lower than its start, and the kernel will grow the memory region into there just fine.by Joker_vD
- Recommended related reading: https://nullprogram.com/blog/2024/02/05/by eska
- So what if several functions that use less than 4KB each call each other before using the stack variables in a way that the first access skips over one page?by stkdump
- A function call causes the return address to be pushed onto the stack, thus accessing the stack below the adjusted stack pointer address.
On compiler generated x86 code, the base pointer register will quickly follow when entering the target function.
by st_goliath - One thing that scares me a little is whether there are younger developers, say, 25-40, who can and want to pick up the mantle of Windows internals gurus.
I mean, Chen has decades of winternals in his head. Microsoft has been gutting their staff for years now. When the Petzold/Chen generation hang up their spurs, does Microsoft still have a critical mass of people who understand Windows from the metal up?
by kjellsbells - Obviously it's Copilot /sby mrheosuper
- One trend to watch is AI cheat devices. Instead of running detectable software they have a fully separate device that uses AI for object detection and aimbotting. If cheaters move to using those, then the argument for kernel mode anticheat weakens. And that is the cornerstone keeping gamers on windows.by im3w1l
- Why do you think that is not already happening within Microsoft?by charcircuit
- > who can
Probably enough to keep Windows going, at least.
> and want to
Not if the pay or location is uncompetitive.
by dataflow - I was a dev on the Visual Studio and Windows teams in the 90s. I’m retired but mentor CS students at two local universities.
I haven’t had a student in two years that was even remotely interested in ring-0, internals, or really understanding a debugger.
I’m not being critical; they are just focused on higher level abstractions.
by LatencyKills - As someone within that age group who moved back to Windows for development and entertainment, I find systems programming on Windows more fun and engaging than on competition OSs.
Oddly enough the open-source nature of the latter kind of takes away some of the thrill. Eerything is just... there, whereas with Windows there's always quite a bit of digging and investigation involved. Or maybe this is Stockholm syndrome; I dunno.
- Why do you think Windows is currently such a mess?
Microsoft new blood has been educated on Macs and ChromeOS, even if they do games it is most likely consoles.
On WinUI community calls you usually would get puzzled faces when the Q&A touched when would WinUI be able to do "insert basic Win32/Forms/WPF" feature.
Management apparently doesn't care they actually understand Windows, or get the required trainings to meet the quality of their predecessors.
That is how you get Webview2 all over the place.
by pjmlp - > One thing that scares me a little is whether there are younger developers, say, 25-40, who can and want to pick up the mantle of Windows internals gurus.
A similar "brain drain" has occurred in macOS (formerly known as OS-X) over the years, as evident in man page documentation for "newer" daemons shipped. An easy way to verify this is to run:
And compare the man pages for the daemons running with the man page for `launchd`.ps -A | awk '{ print $4 }' | grep 'libexec/.*[a-z]d$'While this exercise is illuminating, it is also depressing IMHO.
by AdieuToLogic - One of those functions that isn't really implementable in standard C, requiring either compiler support, or being written in straight Assembly for stack registers manipulation, one of those "micro runtime" features for C.
From UNIX 7th edition all the way up to C99, when VLAs where introduced, only to be made optional in C11, and the C23 update still doesn't support automatic VLAs, only for function parameters, thus the point stands.
by pjmlp - Nobody should use alloca. If you must allocate a buffer on the stack, use a VLA, which is standardized, has proper scope-bound lifetimes, and a type that remembers the exact size. Yes, I know MSVC does not upport it. Don't use this compiler. (where credit is due: MSVC had stack probing a lot ealier than GCC and clang, and clang was very late).
With gcc, you get stack probing with -fstack-clash-protection, which is similar to _chkstk but GCC inlines the stack probes.
VLA got a bad name because of stack clash attacks, but without stack clash protection these attacks can appear also without VLAs (and the first such attacks actually exploited fixed-size arrays), and if you activate this protection there is IMHO not much reason to avoid VLAs.
If you need a small variably-sized buffers, VLAs are almost always superior to any alternative. alloca is worse in every way (see above), a regular array with worst-case bound increases stack use relative to a VLA and does not encode the correct dynamic size which makes bounds checking weaker, and moving the buffer to the heap is slower and complicates the code.
If you can not properly account for the sizes of the things you put on your stack and worry about VLAs exceeding the limit (but again, regular arrays with worst-case size increase stack usage compared to VLAs), on GCC you can use -Wvla-larger-than to make sure the size of each VLA stays bounded.
by uecker - On the contrary, nobody should use VLA, rather use alloca, if small enough. VLA is very new, compiler horror, poorly supported and on the chopping block. alloca is supported for decades alreadyby rurban
- Developers should know that built-in stack is something like arena, aka dynamic region. And alloca() or VLA is using built-in stack as arena. If neither alloca() nor VLA is available, then additional arena can do the trick. Portable programs should have such fallback. Requires additional management for cleaning on exit, but that's it. I have seen malloc fallback in portable programs, but arena can be better.by OCTAGRAM