How about this - every time a problem like this is found, the affected component is rewritten in Rust.

Kinda like how a bug should ideally be fixed by reproducing the issue with a unit test first - the test ensures that particular problem won't come back.

AFAIK that's possible for C - a project can be rewritten in Rust one function at a time - but I acknowledge it may not be possible or practical for C++ or other languages.

Thing is, there's going to be tons of old C in Windows that is perfectly safe. That code doesn't need to be changed - and with this model, it wouldn't be. What needs to be changed is components like SMB which has been the source of a few high profile vulnerabilities before.

When Rust calls into C code it completely loses almost all of its safety guarantees. Having a codebase which is half C and half Rust sounds worse to read and reason about than all either.

Additionally, most Windows code is C++ with Windows specific language extensions (COM, Structured Exception Handling, and others).

I think most C++ code should be rewritten in Rust library by library, but most software is not properly constructed as a series of libraries. And asking a business to rewrite working code in a brand new language instead of fixing a buffer overflow is a difficult ask.

Microsoft is already had an internal Rust summit,

https://twitter.com/ryan_levick/status/1225837057186000896?s...

and are doing other experiences as well,

https://www.infoq.com/news/2019/11/microsoft-exploring-rust-...

https://msrc-blog.microsoft.com/2019/11/07/using-rust-in-win...

Kenny Kerr, the original author of C++/Winrt, which replaced C++/CX, has now turned into Rust.

https://kennykerr.ca/2020/02/22/rust-winrt-coming-soon/

They are also motivated to actually make C safer, with Checked C project, something that ISO C doesn't seem to care that much.

https://www.microsoft.com/en-us/research/project/checked-c/

As per MSRC advisory, new code should be a mix of .NET, Rust or Core Guidelines compliant C++, depending on the use case.

There's also Project Verona [0], a research project inspired by Rust, Cyclone and Pony.

[0]: https://github.com/microsoft/verona

> When Rust calls into C code it completely loses almost all of its safety guarantees.

Not really, it means that if there is a memory safety bug it must be either in an unsafe block or foreign C code (which also must be called in an unsafe block). While technically any C code could completely invalidate Rust's memory model, in practice that is almost always a C bug which you can debug more easily if much less of your codebase is in C (or equivalently, unsafe Rust).

> Having a codebase which is half C and half Rust sounds worse to read and reason about than all either.

I think that really depends how it's structured. You would probably want to avoid something like Rust calling C calling Rust calling C (calling Rust calling ... etc), but if the codebase is already separated into modules or even separate libraries you could rewrite a library or module while maintaining the same C API (and that Rust or C module can be read independently from the rest of the codebase).

COM is not windows specific, and it doesn’t require any language extensions. You can implement and consume these objects with GCC on ARM Linux just fine: https://github.com/Const-me/ComLightInterop

What I need is a seamless interop between C++ and Rust structures. The closest is maybe what the WebAssembly can do.

That way functions written in both languages can be mixed.

I'm not suggesting re writing everything. I'm suggesting that it's irresponsible to start a new project in an unsafe language when an equally efficient safe language is available.

This isn't a new project. Also tooling is a thing & in bigger companies you have to deal with inertia (retraining people is hard). I think at some point the bullet has to be bitten. I also think there's some value in figuring out how to write C/C++ -> Rust translators to automate some of this process. That's the only way we can get ahead of the curve.

It's possible to migrate C to Rust function by function, not sure if anyone has figured out something similar for C++ yet though:

https://github.com/carols10cents/rust-out-your-c-talk

There is also https://github.com/immunant/c2rust

Rust is not equal to C++, not even language wise and certainly not from a tool / pipeline / libraries / knowledge side.

When you have legacy code, with millions line of code you just don't swap for something else for the sake of it might be better.

Adding a new language in a medium / large company is not an easy task.

I think Rust is a good contender for C++ "replacement" on the long term but it's a really difficult task and you need proper planning.

> for the sake of it might be better.

There are a billion Windows computers on the planet. Each time we have a buffer overrun which gives attackers access or lets them exfiltrate user data, real people are at risk. At risk of ID theft, of money theft, of scammers, of crypolockers, of extortion and blackmail, of company collapse and job loss, of stolen business secrets, of fines, and of wasted time. Each time we have an urgent patch, tens of thousands of IT people around the world have to hurry to patch/bodge/remediate/mitigate/educate systems with little warning and little testing, dragged away from whatever else they were doing.

Microsoft have proven they can't do this competently in C++. Are we not long past the "might be better to have tools which check" speculation, and far into "definitely definitely definitely is better" by now?

If not by now, what will it take to convince you?

(I'm not saying "Definitely Rust", but something - Microsoft make implementations of C++, T-SQL, C#, F#, JS/TypeScript, VB.Net, and employ many top Haskell people at Microsoft Research, and various other languages, they aren't inexperienced at languages).

it's a really difficult task and you need proper planning.

Then they should hire good developers and plan properly? They are one of the richest companies on the planet who make some of the most popular programming languages and tools on the planet. They're not a poor-me charity case.

Microsoft is fully aware it is reached the tipping point.

https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-s...

https://msrc-blog.microsoft.com/2019/11/07/using-rust-in-win...

Worth pointing out that MS has made extensive investments into making their C++ code bases safe and secure in the last ~twenty years, yet they still regularly have these problems. If Microsoft cannot handle the problem, few organizations would have the resources to.

Also see the recent slew of security issues on OpenBSD, which is developed by what many consider some of the most skilled and careful C programmers.

Because one issue doesn't mean hurry we need to switch language. Especially not on the OS side where unsafe will be used and has not yet to be proven that is safer than C/C++ with various tools.

If you think that's possible why no-one is actually doing it?

There are mainstream efforts to do the legwork to allow Linux kernel modules to be written in Rust and a fair few core system libraries (the most obvious example being librsvg) and applications have undergone Rust rewrites. And of course there's Redox OS which a full OS entirely written in Rust, and it only contains a few hundred lines of unsafe code (which, given how Rust works is the only really key code that needs to be audited for memory safety).

The reason that more things aren't yet written in Rust is because these things take time, and there is lots of inertia to switching languages for established projects (one big roadblock to such rewrites is that maintainers need to be familiar enough with Rust).

> yet to be proven that is safer than C/C++ with various tools.

What "various tools"? Buffer overruns were old-hat decades ago. Impossible in Pascal in 1970, impossible in ALGOL-60 years before that. If the C/C++ tools to protect against buffer overruns in 2020 are worse than the technology of sixty years ago, how much longer do you suggest we wait?

> Because one issue

This isn't the first buffer overrun issue. This isn't the first buffer overrun issue in 2020. PHP has had a buffer overflow which could leak data or crash. IBM DB2 has had a buffer overflow which could allow an attacker to gain privileges. macOS and all iPad/WatchOS and iTunes for Windows have had buffer overruns leading to arbitrary code execution. Samsung Galaxy S10 has. QEMU has. pppd has. SQUID has. CA Nimsoft has arbitrary code execution buffer overflow. PHP Multibyte string handling has. Emerson OpenEnterprise SCADA, libmysofa, OpenJPG, mRuby, libMing, Cisco Unified Contact Center, Honor smartphones, QEMU iSCSI handling, Intel Graphics Drivers, Adobe Reader arbitrary code execution (Again!)

just look https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer

and that's only the CVE disclosed ones.

> If you think that's possible why no-one is actually doing it?

It's cheaper and more profitable not to bother.

I don't agree with you that C++ is superior to Rust

> Microsoft already tried to migrate bits of userspace to C# in 2008 with windows vista, and that didn't exactly go well..

If there was an actual support from WinDev they would have managed to pull it off, instead they sabotaged the effort and went on redoing those C# classes as COM objects in Vista until we got UWP instead.

These kind of reboots do require a change of developer's generation to pull it off.

And now we got this fragments ecosystem of classic bare metal "Win32" apps, WinForms, WPF, UWP, and obviously a handful of 3rd party GUI libraries so vendors can completely redesign their UI so it is a special snowflake.

C# in 2008 was too early. It was still slow and resource hungry since .NET wasn't that optimized, but also PCs were a lot slower. They sold Vista machines with 1GB of RAM back then. half of that was eaten by the system without opening any actual program you wanted to use.

Using rust shouldn't significantly increase resource usage, and nobody is suggesting you go ahead and design yet another UI framework for it. I'm still perfectly fine with win32 apps today.

> And now we got this fragments ecosystem of classic bare metal "Win32" apps, WinForms, WPF, UWP, and obviously a handful of 3rd party GUI libraries so vendors can completely redesign their UI so it is a special snowflake.

What do you know, Microsoft really did embrace Linux, including its design mentality.

Actually, it was more like a return to Microsoft roots.

https://en.wikipedia.org/wiki/Xenix

That was the thing, if WinDev was serious, they would have contributed to the .NET runtime improvements, like the SIMD support, AOT compilation or value type improvements in C# 7.x that came from Midori experience.

Instead they made sure COM would save the day.

I believe 10's of millions might be quite an underestimate.