Get started with Rust in Windows programming

Microsoft signals that it might support Mozilla’s memory-safe alternative to C and C++

Could Microsoft switch from its use of C, C++, and C# to other languages? A recent blog post from the Microsoft Security Response Center (MSRC) suggested that it might well be looking at alternatives, with the aim of reducing the risks to its code. As Gavin Thomas, the principal security engineering manager at MSRC, noted that one of the main causes of the bugs in Microsoft code reported to the MSRC is memory corruption, bugs that let memory be overwritten or access what should be protected memory.

Keeping memory safe

Memory safety has been a significant issue for a long time, but the statistical work done by MSRC shows the issue is not going away. You’ve got lots of tools to help write secure code, from Microsoft’s own Secure Development Lifecycle, to using newer memory-safe languages like C#. But those approaches have their trade-offs: The code they produce is slower and works at a higher level than C++.

That’s not a problem for customer-facing code. There’s no perceptual difference between a C++-develoepd user experience and one built in C#. But a system level, the code used to build operating systems and device drivers, there’s a big difference. Processor cycles matter when you’re working at a systems level, and as Thomas points out in his blog post, unprotected languages like C++ and C are really the only tools that historically work at that level.

It’s clear that the memory-safe approaches used by higher-level languages don’t work at a system level. Many of the problems that plagued Microsoft’s abortive Longhorn project were caused by trying to build an entire OS on the .NET platform. So how can we bring memory safety to the foundations of system development?

To continue reading this article register now

How to choose a low-code development platform