Alright. ALRIGHT. I know, we’re all excited, but let’s think about what we’re doing again.

So we’ve managed to look at real network traffic and parse it completely. We’ve also taken some ICMP packets, parsed them, and then serialized them right back and we got the exact same result.

So I know what you’re thinking - let’s just move our way down the stack again - stuff that ICMP packet in an IP packet, then in an Ethernet frame, and then serialize the whole thing.

Because I started accepting donations via GitHub Sponsors, and because donating at the “Silver” tier or above gives you advance access to articles and your name in the credits, I need to interface with the GitHub API the same way I do the Patreon API.

Because I’d rather rely on third-party identity providers than provide my own sign up / log in / password forgotten / 2FA flow, user identifiers on my website are simply {provider}:{provider_specific_user_id}:

So! Rust futures! Easy peasy lemon squeezy. Until it’s not. So let’s do the easy thing, and then instead of waiting for the hard thing to sneak up on us, we’ll go for it intentionally.

Cool Bear's hot tip

That’s all-around solid life advice.

Choo choo here comes the easy part 🚂💨

We make a new project:

$ cargo new waytoodeep Created binary (application) `waytoodeep` package

In the day 8 problem, our input is a height map:

30373 25512 65332 33549 35390

This is a 5x5 grid, and every number denotes the height of a tree. For part 1, we must find out how many trees are visible from the outside of the grid.

If we consider the first row, from the left: only the 3 is visible: it obscures the 0. From the right, 3 and 7 are visible.

So, how does ping.exe actually send a ping? It seems unrealistic that ping.exe itself implements all the protocols involved in sending a ping. So it must be calling some sort of library. Also, since it ends up talking to the outside world via a NIC (network interface controller), the kernel is probably involved at some point.

In reading files the hard way - part 2, we learned about dynamic libraries (like libc), and the Linux kernel, and how syscalls allowed us to ask the Linux kernel to do our bidding. For this series, we’re going to have to look at the Windows equivalents.

Since I write a lot of articles about Rust, I tend to get a lot of questions about specific crates: “Amos, what do you think of oauth2-simd? Is it better than openid-sse4? I think the latter has a lot of boilerplate.”

And most of the time, I’m not sure what to responds. There’s a lot of crates out there. I could probably review one crate a day until I retire!

In our last article, we managed to load and execute a PIE (position-independent executable) compiled from the following code:

; in `samples/hello-pie.asm` global _start section .text _start: mov rdi, 1 ; stdout fd lea rsi, [rel msg] mov rdx, 9 ; 8 chars + newline mov rax, 1 ; write syscall , , "hi there", 10

There are news!

Here are all the changes I’m implementing, summarized as a table:

In Part 11, we spent some time clarifying mechanisms we had previously glossed over: how variables and functions from other ELF objects were accessed at runtime.

We saw that doing so “proper” required the cooperation of the compiler, the assembler, the linker, and the dynamic loader. We also learned that the mechanism for functions was actually quite complicated! And sorta clever!

Hey everyone!

This article is brought to you by a shameless nerd snipe, courtesy of Pascal.

In case you’ve blocked Twitter for your own good, this reads:

There should be a post explaining and comparing smolstr and smartstring (and maybe others, like smallstr)

Well, I took the bait.

But, since this is me writing, I get to set the rules:

• There will be no “maybe others” - we’ll review just the first two