* 2 projects: dwrite and Win32k
* 2 devs, 6 months to rewrite 152KLOC C++ to 90KLOC Rust re dwrite
* Performance increases of 5-15% re dwrite
* Only about 10% of Win32k code is unsafe
* No perf regressions re Win32k
* Syscall in the Windows kernel now written in Rust
Only if the only thing one has read was Petzold's book.
Since MFC and COM, that outside of the kernel most code is C++, even MSVC libc is actually written in C++ with extern "C" declarations.
Additionally starting with Windows Vista, C++ code started to be allowed on the kernel (VC++ got /kernel flag), and nowadays there is a template library called WIL.
You're getting downvoted but i think it's a fair point that revisiting win32k in any language might come up with some opportunities for optimization along the way. Performance best practices have changed a lot since that component was written.
I suspect there reason the parent is being downvoted is that "So code optimized for 80486 machines in the 90's" isn't something we actually know. Do you really think Microsoft hasn't touched this code since the 90s? It comes across as sour grapes.
My understanding of what the presenter meant here was "this is gnarly code that's been around for a very long time." Not that it literally remains solely optimized for the 486.
I seem to recall hearing from MS affiliated people in my network that someone revisited GDI circa 2015? It also wouldn't shock me if there's more that can be done.
Also worth noting that various parts of MS have declared GDI as legacy at various points in time. Yet it remains a critically important component.
A rewrite of an old code base with today's hardware characteristics in mind should yield better performance, in Rust, C/C++ or any other system language.
In addition, I seem to recall that the Alliance For Open Media and its AV1 codec also derives from Mozilla sponsoring Xiph.org's Monty to come up with an unencumbered, next-gen media codec.
By the time of IE 5 came to be there was little left from David, hence why IE 6 was hardly having any updates, and most of the team went on to work on WPF.
Those memory bugs are costly after all. I think the best part of this presentation is they managed to improve performance while adding memory safety. Two people rebuilding a 90kloc c++ into rust in 6 months is also pretty impressive.
One the subject of porting code from one language to another (ignoring that the headline says "rewrite", which implies more than a dumb port).
Are there any tools to help map out the work that needs to be done? I found myself doing this by hand recently, doing graph search on a piece of paper. I needed to port one function, so I identified all the functions that function called, wrote them down, and then looked into the next layer of functions etc. I manually searched the potential call graphs by reading the code and wrote down all possible functions involved. I then crossed of functions that seemed obvious, such as a function to retrieve the value of a dictionary with a default value, such simple functions are trivial and need no special effort. In the end I had a list of functions that needed to be ported one-by-one and I began working from the bottom up.
I was wondering if there are any tools that could automate this process? It seems to be the beginning of a source-to-source compiler, but such a compiler could be kept simple by embracing that most of the work can be presented to a human to perform manually. The "compilers" only job is to structure the work and break it down into small chunks.
Lots of software tools for generating call graphs. I've used doxygen (free) for it in the past and LDRA (not free) at an early job. This won't generate the new code for you, but will be a lot easier than manually constructing a call graph.
> Rewrite the C standard library in Rust? I'm not sure I understand how that even makes sense. Are there problems this would solve?
The C standard library isn't necessarily a standard library of C code, it's more of a standard library for C code. There's plenty of languages these days where the standard library is built in other languages, somewhere between partially and fully; some portion of the C standard library can probably benefit greatly from the memory lifetime structures of Rust; although the constant need to interface with C code may reduce the effectiveness.
Many C standard libraries are actually re-written in C++ nowadays, e.g. Microsoft and clang's, so doing it in Rust is hardly any different, it would be safer than C++, minus the usual C gotchas that are anyway exposed on the public APIs and the implementations can't do much about it (like bad pointers or size).
Rust supports dynamic libraries with C ABI very well.
Technically, it also supports Rust ABI dynamic libraries, but their portability is quite fragile due to changes in the compiler. That's why Rust parts of the code are usually statically linked.
Highlights: