Let’s set aside our sup project for a while.
Don’t get me wrong - it’s a perfectly fine project, and, were we simply rewriting “ping” for Windows in Rust, we could (almost) stop there.
We’re currently using the operating system’s facility to speak ICMP, which is great for a bunch of reasons: we can be sure that whatever flaws there are in the implentation, all “native” Windows programs suffer from it as well.
As a bonus, the binary size is reasonable, (looks like 175KiB for me at time of this writing - built with cargo build --release, of course).
But we didn’t come here to make sensible decisions for production-grade software. We came here to bind Win32 APIs and dig our way down the network stack, and we’re all out of APIs to bind.
It’s refactor time!
Our complete program is now about a hundred lines, counting blank lines (see the end of part 3 for a complete listing).
While this is pretty good for a zero-dependency project (save for pretty-hex), we can do better.
First off, concerns are mixed up. Second, a lot of low-level details are exposed, that really shouldn’t be. I don’t think main() really ought to be using transmute at all. We should build safe abstractions above all of this.
I interned with Microsoft as a Software Engineering Intern in the MSRC UK team in Cheltenham this past summer. I worked in the Safe Systems Programming Language (SSPL) group, which explores safe programming languages as a proactive measure against memory-safety related vulnerabilities.
This blog post describes the project that I have been working on under the mentorship of the SSPL team. Hopefully, this provides additional insight into the work Microsoft interns do! My goal was to build an open-sourced Rust library that will allow developers to both consume and produce in-process Component Object Model (COM) components in an idiomatic manner.
View all tags