Microsoft is Busy Rewriting Core Windows Code in Memory-safe Rust (theregister.com) 150
Microsoft is rewriting core Windows libraries in the Rust programming language, and the more memory-safe code is already reaching developers. From a report: David "dwizzle" Weston, director of OS security for Windows, announced the arrival of Rust in the operating system's kernel at BlueHat IL 2023 in Tel Aviv, Israel, last month. "You will actually have Windows booting with Rust in the kernel in probably the next several weeks or months, which is really cool," he said. "The basic goal here was to convert some of these internal C++ data types into their Rust equivalents."
Microsoft showed interest in Rust several years ago as a way to catch and squash memory safety bugs before the code lands in the hands of users; these kinds of bugs were at the heart of about 70 percent of the CVE-listed security vulnerabilities patched by the Windows maker in its own products since 2006. The Rust toolchain strives to prevent code from being built and shipped that is exploitable, which in an ideal world reduces opportunities for miscreants to attack weaknesses in software. Simply put, Rust is focused on memory safety and similar protections, which cuts down on the number of bad bugs in the resulting code. Rivals like Google have already publicly declared their affinity for Rust.
Microsoft showed interest in Rust several years ago as a way to catch and squash memory safety bugs before the code lands in the hands of users; these kinds of bugs were at the heart of about 70 percent of the CVE-listed security vulnerabilities patched by the Windows maker in its own products since 2006. The Rust toolchain strives to prevent code from being built and shipped that is exploitable, which in an ideal world reduces opportunities for miscreants to attack weaknesses in software. Simply put, Rust is focused on memory safety and similar protections, which cuts down on the number of bad bugs in the resulting code. Rivals like Google have already publicly declared their affinity for Rust.
Just ask Bing (Score:5, Funny)
Re: Windows is done anyway. (Score:4, Insightful)
Really? Where did they move to, Mac and Linux?
No, the majority of the working world still gets things done with Windows, for better or worse.
Well, there you go (Score:2, Insightful)
If a company with $2T market cap can't afford to hire enough "non-idiots" to competently write C/C++ code, then you probably can't, either.
Re: (Score:3, Insightful)
hey Rust fanbois are cheap
Re: Well, there you go (Score:3)
Re: (Score:3, Insightful)
Experienced developers still make mistakes. So, do what you can to reduce the number/amount of mistakes that can be made. Not saying that Rust cures all mistakes, but takes the most egregious ones out of play.
Re: (Score:2)
+1 Agree. Even the most skilled of developers will make mistakes, and there are limits to what static analysis and code reviews can catch. Putting up guardrails is a good thing.
Re: (Score:2)
I ship a helmet to every user, just in case.
Re: Well, there you go (Score:4, Insightful)
It's a classic No True Scotsman fallacy that they're falling into.
https://en.m.wikipedia.org/wik... [wikipedia.org]
Bjarne Stroustrup himself seems to believe in it as well. Basically the C++ die-hards argue that any good programmer can produce bug free code. Yet not a single one of them could ever point to such a person, which is because that person doesn't actually exist.
Re: (Score:2)
Re: Well, there you go (Score:5, Insightful)
Substitute "memory safety problems" with "memory safety problems that we know of" and you have your answer. The Linux kernel itself has had its share of memory errors that were in the source code for everyone to see, and yet nobody did for over a decade.
https://arstechnica.com/inform... [arstechnica.com]
https://en.wikipedia.org/wiki/... [wikipedia.org]
https://www.bankinfosecurity.c... [bankinfosecurity.com]
https://www.bleepingcomputer.c... [bleepingcomputer.com]
Keep in mind, this is only a few of them. There was one particular vulnerability that was in the kernel a whopping 20 years, I can't recall the CVE though. That last link in particular is three different memory bugs that were 15 years old at the time of discovery.
And of course, this is *only* one project, which is open source, and used on a majority of the computers that connect to the internet. Sure, it's not C++, but C developers aren't the ones going around saying that there's nothing wrong with their language. C is only trying to be a portable assembly, not an endless heap of abstractions that sees drastic changes every 5 years to the point that every C++ developer has their own style that doesn't make sense to any other C++ developer.
All the while, NIST, Microsoft, Google, Fuckerbook, and basically every other big tech company has realized that, as much as he doesn't want to hear it, Stroustrup's "call to action" to save C++ from Rust is ultimately pointless because he's trying to argue that all of the existing C++ code shouldn't just be tossed out, but the only realistic way to pull off his "call to action" is to do exactly that anyways. That's why these companies are exclusively moving to Rust for all greenfield work, and even rewriting old problematic code in Rust, which is exactly what Microsoft is doing here.
Despite that, people like The Evil Atheist just use the "NIST and all of the big tech companies don't know what they're talking about and have shitty engineers anyways" excuse every time this topic comes up. And people like him are one to talk because they definitely have no leg to stand on compared to the ones they criticize.
Re: Well, there you go (Score:2)
Re: (Score:2)
If that person does exist, there certainly aren't enough of them to write a text editor, much less an entire operating system and all its accoutrements.
C++ is two (or more) languages (Score:2)
You can write C with classes and still do pointer arithmetic.
You can also write RAII code and use safe array methods and write pretty safe code. Certainly the main examples purported by Rust are easily done in C++.
C++ is ugly, but I have never understood how Rust can be better than safe C++. And I have yet to see a good article.
That said, can we please have a NoPointerArithmetic compiler warning?!
I never want to see
"The answer is: " + 42
compile cleanly!
Re: (Score:2)
C++ is ugly, but I have never understood how Rust can be better than safe C++.
The difference is that in C++, you have to get out of your way to make safe code. In Rust, you have to get out of your way to make unsafe code.
That wouldn't matter to perfect beings who never make mistakes and have no deadlines, but developers are not those creatures.
Re: C++ is two (or more) languages (Score:2)
Rust isn't any safer than C++. All those statements made in that regard are all pretty baseless.
The only advantage it has is that it is a new, smaller and simpler language.
Re: Well, there you go (Score:3, Insightful)
Thinking c/c++ is "perfectly fine" in the hands of the best programmers is an opinion only poor, low skill programmers can have. It's ironic, if unsurprising.
Rust is real, and the best c/c++ people I work with are huge proponents of it, as they should be. Get used to this, unless you truly have nothing to lose from missing the inevitable boat. There's a reason it's in Linux and Windows now. This is not Xbox vs playstation. The adults in the room know why we need what it brings to the table. This is not a dr
Re: (Score:2)
All true, but the problem with C++ may lie more in legacy code bases than the modern language itself. The next couple of releases of the C++ standard are bringing a lot of what Rust has for reference safety and ownership to C++.
Re: Well, there you go (Score:4, Interesting)
I am and have been a c++ for 25 years on performance critical software used by hundreds of millions of people. I'm actually not a Rust programmer (at least not required professionally at this point in time, I've certainly educated myself and used it, otherwise I wouldn't have an informed opinion about it) But it's inevitable I will be a Rust programmer in the future, because anybody that has actual stakes in time and money wrt to programming realizes it would be stupid not to use it in the areas of any reasonably large codebase that would benefit from the myriad of advantages it has over c++
with an opinion like yours, I sincerely doubt any level of authority you have on the subject
Re: (Score:2)
A lot of APIs involve passing in a pointer to a memory block, and hacking revolves around malforming it to cause unexpected behavior.
Is your API gonna require a Rust-approved block?
"Sure, here it is, not malformed at all!"
Re: (Score:3, Insightful)
The problem is not the cost. The problem is broken management that only cares about the bottom line and wants to do things cheaper than possible, hence accumulating technological debt. This move will probably not fix anything but introduce a few new and stupid problems.
Re:Well, there you go (Score:5, Informative)
It never had anything to do with cost or doing things cheaply.
Microsoft puts an extremely high value on backwards compatibility, and decades old code will usually still run on modern Windows versions. That level of compatibility often means mistakes made decades ago are often kept around far longer than anyone would otherwise like.
They're well known for going out of their way to include hacks so that popular old programs still work after Windows bugs have been fixed. It would be far cheaper to just fix the Windows bugs and let everyone else deal with the fallout, but that's not how they want to operate.
Re: (Score:3)
Microsoft puts an extremely high value on backwards compatibility, and decades old code will usually still run on modern Windows versions
That just isn't true anymore. Especially being that there are no longer going to be anymore 32bit Windows releases
Re:Well, there you go (Score:5, Informative)
64 bit versions of Windows are compatible with 32 bit software. It's only 16 bit Windows code that no longer runs.
That means your baseline of support is Windows NT 3.1, which was released in 1993.
Re: (Score:3)
There is also a ton of 32 bit software that was packaged with a 16 bit installer.
Re: (Score:2)
Yeah those installers will break, but if you can separate the software from the installer, you can still use it.
There isn't anything Microsoft can do about this. If you're running an x86 CPU into 64 bit mode, you can't create a 16 bit process. The compatibility only goes back one level. Best you can do is run a 32 bit OS in a Virtual Machine, and run a 16 bit process inside that.
Re: (Score:2)
Well, that's not really true, it is: https://github.com/leecher1337... [github.com]
Re: (Score:2)
I'm sure that comes down to 16 bit code just not being very common anymore. It was very common back when the RISC ports of Windows were around.
Re: (Score:2)
It's still true to this day. A lot of 32-bit software from ~20 years ago will run quite happily in Windows 10. There will always be outliers, but backwards compatibility is still impressive in Windows.
Obviously if it's a game that requires an ancient 3rd party API (*looks at 3DFX*) or has a 16-bit installer (*sigh*) then it's not going to work, but there are plenty of examples online of people running pretty ancient software on Windows without hacks or community-made patches.
Re: (Score:2)
Re: (Score:2)
They did include XP Mode in Windows 7, letting your run Windows XP in a VM. It was mostly there to ease the transition from 32 bit Windows to 64 bit. But people generally want their programs running together, not sandboxed in a VM.
Re: (Score:2)
Of course there are. But there aren't many clear cutpoints where you can say "anything before this point isn't supported anymore". Cutting off DOS support is one. Cutting off Win16 is another. Once you get into Win32 though, it's all connected and constantly evolving. Win64 is just Win32 with larger data types. There's not a huge burden to supporting both. The Win32 implementation now is just stub code that calls into the Win64 implementation.
They tried creating things like WinRT and Universal Windows Platf
Re:Well, there you go (Score:5, Informative)
Exactly. Remember the blatant, utterly dishonorable lie that Win10 would be the last Windows? Obviously it was only used to manipulate people into moving and then, as soon as they had the numbers they did not care anymore and announced the next version. I think there was not even any kind of apology ever for their despicable conduct.
MS lives off selling defective products so they can sell you the next, slightly less bad (in some aspects) product after that. They are a really bad historical accident that has done and keeps doing massive economic damage.
Re: (Score:2)
You know, backwards compatibility _can_ be done right (see the Unix API) or can be done massively wrong (see the Windows API). And I would like to point out that the Unix API is quite a bit older. Hence it has to do a lot with the MS API being done cheaply and incompetently initially and with ignorance of what already existed. And then they did it over, keeping the old bad stuff and added some new bad stuff that is broken in a different way. And then MS did this several times again.
Hence this is all about m
Re: Well, there you go (Score:5, Insightful)
Tell that to the team that completely broke the ATL Wizard in VS2017. You couldnâ(TM)t do basic things like adding properties and methods. They clearly didnâ(TM)t know what they were doing or had tried to even test the most basic and common use-cases.
Thatâ(TM)s why re-writing things in Rust just for the sake of re-writing it in Rust is stupid. All new code has bugs, and furthermore, the people who wrote the original code have probably long gone either retired or fired for being too expensive so todayâ(TM)s devs are going to be doing a lot of guessing.
Re: (Score:2)
Microsoft puts an extremely high value on backwards compatibility, and decades old code will usually still run on modern Windows versions.
They do not value backward or forward compatibility even within MS Office. Couldn't even go '972000/xp without getting document corruption. Thankfully StarOffice was around.
Re:Well, there you go (Score:5, Interesting)
If a company with $2T market cap can't afford to hire enough "non-idiots" to competently write C/C++ code, then you probably can't, either.
Microsoft has some of the best people in the world working for them. This brings snickers here at Slashdot, but they've truly got some world-class folks.
The problem isn't so much competence as sheer volume. How many lines of code is Windows up to now? Office? It was Sisyphean task to keep even older version of Microsoft OS's debugged. It's only gotten more difficult as software becomes more complex. Throw in the pressure of deadlines, and even experienced, quality programmers are going to make mistakes.
Re: (Score:3)
Re: (Score:2)
And lack of QA. :(
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
If a company with $2T market cap can't afford to hire enough "non-idiots" to competently write C/C++ code, then you probably can't, either.
There's no such thing as a non-idiot. Not a single person in history has ever written a complex piece of code perfectly securely. And if they have, maybe we should kill these non-human alien imposters.
Re: (Score:2)
In high rise construction, even (especially) non-idiots use harnesses to keep from falling to their deaths. Only an idiot programmer would want to use antiquated, unsafe tools, when perfectly good, safer, modern tools exist.
Re: (Score:2)
Yeah, excepting brake failures, blowouts, coolant leaks, animals in the road, children chasing balls, etc.
The seatbelts are there because shit happens. Shit happens, aka Murphy's Law, is the law of the universe. Rust can help.
What could go wrong? (Score:3)
The coders who know the millions of lines of undocumented/un-commented backward-compatible tangled messes of code have long since moved on.
My guess is that the risk of changing anything that "ain't" broken will outweigh the benefits of Rust.
Re:What could go wrong? (Score:4, Insightful)
Indeed. The real problem MS has is not shoddy implementation. They have that too and with their broken engineering culture, they will doubtlessly introduce many new and exciting problems in this rewrite. Mut memory safety does not fix stupid. It may look to some people like it would, because lot of problems get lumped together under "memory safety" while other problems are usually grouped in smaller groups. This gives the wrong impression that fixing memory safety would make code fundamentally better. It does not. Incompetent coders will just make other mistakes and Rust cannot prevent that at all. Also, in some places you cannot have memory safety because it costs far too much performance. An OS has a lot of such places.
No, the real problem Microsoft has is shoddy design and architecture which accumulates technological debt. No implementation technique will fix that because it cannot, This is due to MS management there not actually caring about technology. All they care about is profits. What they would have to do is the same as Apple, throw it all away and rebuild the look & feel on an actually solid base. My guess is there is not enough pressure to do that despite the billions the substandard MS crap costs users all the time.
Re: (Score:2)
Windows is a victim of its own success. Fixing bad implementation and bugs in many cases means having to carry along known issues and papering them over wherever possible. Any profound fixes are going to break backwards compatibility, so they have one of two choices, either keep the bringing forward the screwy and potentially dangerous bits of the API, trying to bolt on security fixes where possible, or sandbox the ghosts of Christmas past. That's basically what they've done with IE, creating a sandbox vers
Re: (Score:3)
I have given this some thought over the years (esp during the transition from 32bit to 64bit) and I believe I have a solution:
Start with a clean-sheet OS, 64bit, no backward compatibility with all the legacy code. Call it WindowsNew (or something) and run it along-side the existing Win10/11/whathaveyou, but let everyone know, WindowsNew is the only path forward. Let all the old code die off, yes it'll take years, like WinXP/7, but it will eventually die off. In the meantime, code from fresh.
Yeah it'll never
Re:What could go wrong? (Score:4, Insightful)
A good craftsman never blames his tools. I started out on two large (~5+million lines) C++ projects. If you know what you are doing, C++ can be used effectively (Ha-Ha Mr. Meyers). Didn't seem too hard back in the day. Good habits go a long way, and I had some awesome mentors. Likewise any programming language can be used to write hideous code (I haven't had reason to use Rust. Guess I need to find an excuse).
Certain people have a way of clearly thinking about a problem and then turn out clean code. Just a few of these people working together can accomplish a lot.
Re:What could go wrong? (Score:5, Interesting)
Certain people have a way of clearly thinking about a problem and then turn out clean code. Just a few of these people working together can accomplish a lot.
I agree. I talked about this with a lot of students back when I was supervising a lot of thesis work during my PhD. It seems there really were only two cases when they had to use existing code: 1. Utter mess (90%) and 2. Clean code that you could use easily and that explained things. I fall in the 2nd class and I had several students tell me how clean and readable and usable my Perl (!) code was. You know, Perl, the "write only language". It is likely because I have pretty bad memory and write every piece of code with all assumptions and decisions documented and the cleanest interface I can do, so that I can read and understand it a year later. Apparently that makes it easy to use for other people as well.
So, yes. Expecting a tool like a programming language to fix your mess is foolish. A programming language can stand in your way to some degree, especially when it offers features that are not nearly as good as advertised or does not let you do some things. But that is it. If you know what you are doing, you can write clean, maintainable and efficient (within the limits of the execution model) code in almost anything, be it C, C++, Perl, Python, Rust, Haskell, Erlang or even Java. You can also create the most awful unmaintainable mess in all languages. It really comes down to coder skill, experience and, yes, mindset. Most of what the Rust proponents like to promise is hence simply a lie, because these are things that a _language_ cannot fix. Shoddy thinking will be shoddy thinking in any language. Bad or missing documentation will be bad in any language. Broken logic will be broken in any language. In the OWASP Top10, for example, memory-safety places wayy down the list and even then shared with other issues. Other things are far more important, especially as memory safety issues are easy to find and easy to fix. Other issues are often neither.
Re: What could go wrong? (Score:3)
Re: (Score:2)
Perl can be beautiful, but it needs some skill to achieve that. Nothing wrong with that. This is not finger-painting were everybody can participate.
Re: (Score:3)
Re: (Score:2)
hahaha, you thought that this announcement was about making Windows better.
Ah, no. I thought that was the narrative being pushed. And it is. It is obviously not what MS is trying to do as making Windows better would mean tossing the whole horrible mess and starting over. I am pretty sure quite a few people at MS know that.
Someone leaked the first line... (Score:5, Funny)
unsafe {
Re: (Score:2)
The following 3 paragraphs pretty much says it all:
All the code we’ve discussed so far has had Rust’s memory safety guarantees enforced at compile time. However, Rust has a second language hidden inside it that doesn’t enforce these memory safety guarantees: it’s called unsafe Rust and works just like regular Rust, but gives us extra superpowers.
Unsafe Rust exists because, by nature, static analysis is conservative. When the compiler tries to determine whether or not code upholds the guarantees, it’s better for it to reject some valid programs than to accept some invalid programs. Although the code might be okay, if the Rust compiler doesn’t have enough information to be confident, it will reject the code. In these cases, you can use unsafe code to tell the compiler, “Trust me, I know what I’m doing.” Be warned, however, that you use unsafe Rust at your own risk: if you use unsafe code incorrectly, problems can occur due to memory unsafety, such as null pointer dereferencing.
Another reason Rust has an unsafe alter ego is that the underlying computer hardware is inherently unsafe. If Rust didn’t let you do unsafe operations, you couldn’t do certain tasks. Rust needs to allow you to do low-level systems programming, such as directly interacting with the operating system or even writing your own operating system. Working with low-level systems programming is one of the goals of the language. Let’s explore what we can do with unsafe Rust and how to do it.
I like how they use the terms/sentences: "second language hidden inside", "it’s called unsafe Rust", "superpowers", “Trust me, I know what I’m doing.”, "use unsafe Rust at your own risk", "problems can occur due
Re: (Score:2)
}
Old fart (Score:3)
Wondering if I'm going to be like the old farts who thought FORTRAN was for ever.
Re: (Score:3)
Re:Old fart (Score:5, Informative)
Yes it certainly is. It's still big in HPC which means physics more or less. Creeps in in some other bits via BLAS and LAPACK, though they're usually neatly wrapped. Nowhere near as big as it used to be relatively speaking.
As someone with limited Win32 API experience (Score:5, Funny)
So now instead of a HANDLE for everything, we'll get a win32::Handle<win32::Result<win32::Option<win32::FnMut() -> u64>, _>>. I'll be honest, I really don't know which one I prefer.
Re:As someone with limited Win32 API experience (Score:4, Interesting)
Re: (Score:2)
I truly miss Windows WaitForMultipleObjects. "select" and "poll" don't even come close.
Unless you need to wait for more than 64 objects, in which case WatForMultipleObjects screws you over.
Re: (Score:2)
Re: (Score:2)
Re: As someone with limited Win32 API experience (Score:2)
The windows-rs crate abstracts it to just being a pointer with a .is_valid() method. In the standard library it's just *mut c_void.
How often is memory safety the issue though? (Score:2)
The big Windows exploits I remember have been more about stupid decision making - having and SQL listener running by default; having a blank admin password; rewriting the TCP stack without apparently considering the old exploits the previous BSD stack had squashed over time, etc. etc.
Re: (Score:3)
The answer is right in the summary:
Sure, this won't fix the rest of the stupidity in Microsoft's products, but if they can fix a majority of it by rewriting certain modules in another language, that's better than just letting the old code remain in the wild and...rust.
Re:How often is memory safety the issue though? (Score:5, Insightful)
You forgot an important one: "Hide file extensions for known file types" as a default.
On new machines, I'd always get pissed off because extensions were part of my "muscle memory", so I'd have a few MyFile.txt.txt. files, and then I'd go "dammit!" and un-check that. The real problem was all the people that didn't think about and opened Temptation.txt.exe.
It was like they socially engineered a huge chunk of their own users with that.
Re: How often is memory safety the issue though? (Score:2)
IMO it's the single dumbest "feature" Windows added.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Alternative reading... (Score:2, Insightful)
That "about 70 percent of the CVE-listed security vulnerabilities patched by the Windows maker" were "memory safety bugs" is NOT a problem with C++ (or any other language)... it's a problem with the programmers and the source code.
If they don't "fix" the programmers bad habits, changing the language will not resolve the underlying problem, only add more issues.
It's like automatic vs manual transmission (Score:2)
p>If they don't "fix" the programmers bad habits, changing the language will not resolve the underlying problem, only add more issues.
Honestly, having worked in C and Java, I don't miss memory management....similarly to how I don't miss driving a stick shift. Automatic works great for me. I am not a shittier driver just because I've forgotten how to use a clutch. It's a very specialized skill...just like memory management. Just because you make mistakes in memory management doesn't mean you're a garbage programmer. I see little overlap between memory management and designing good software. Lots of people write great stuff in Java,
Re: (Score:3)
Yeah, we've been trying this for 50 years.
It doesn't work.
Microsoft's hiring standards are amongst the toughest in the industry with corresponding highest salaries and even they couldn't "fix" the bad programmer habits.
C++ smart pointers partially solved this issue. But 1) You have to use them and 2) references can actually create the same problems, in very tricky and non-obvious ways.
Re: Alternative reading... (Score:2)
Re: (Score:3)
C++ has tons of nasty memory safety bugs.
The worst one is that you must never create pointers to objects in a vector. Otherwise your pointer points to garbage data once the vector resizes.
Re: (Score:2)
If I called myself a programmer I'd be... well, not lying, but certainly overstating the case by orders of magnitude. I've done some low end stuff professionally.
Enough that I feel comfortable asking: "If this problem is so well known, why hasn't it been fixed?" and "If this problem has been around so long, why isn't there a code checking tool that will flag it?". Maybe a third, "If we know it hasn't been fixed and the code checker exists, why aren't they using it or accepting its corrections?"
It just se
Re: Alternative reading... (Score:2)
I think the biggest problem with C++ is its semantics (which are very broad and complex) seem to do the least optimal or most unsafe thing by default. You'd swear the language was designed to make it easy to win underhanded coding contests.
Re: (Score:3)
Re: (Score:2)
That is not quite correct. Having something like a std::vector<int*> is perfectly fine. That vector resizing will not change any of the pointer values or cause re-allocations, What you are probably referring to is something like std::vector<std::auto_ptr<int> >. Because of how auto_ptr works, resizing the vector will result in basically all your original items becoming de-allocated.
Re:Alternative reading... (Score:4, Insightful)
You are working with the people you have not with ideal programmers that you don't have. That's almost like saying "there's no reason for safety belts, just have better drivers that don't crash". Besides, if there are tools that eliminate 70% of your problems, why not use them?
Re: (Score:2)
it's a problem with the programmers and the source code.
Nope. Programmers are people. You can take the best C++ programmers in the world and throw them into situations where they work for a large company with a huge code base and they won't make anything any better. Linux is no better. Nor are audited highly secure open source libraries. The list of CVEs show one thing and one thing only: Perfect programmers don't exist.
If they don't "fix" the programmers bad habits, changing the language will not resolve the underlying problem
Changing languages definitely fix the problems that a specific language causes. You're assuming that the underlying problem is that everyone is
Re: (Score:2)
Quote: " You're assuming that the underlying problem is that everyone is an idiot and purposefully writing unsafe code rather than the actual reality"
Nope, YOU are the one assuming THAT.
We're talking about WINDOWS OS, and I'm not assuming anything, I'm quite CONFIDENT with my statement. You can only see how many bits of outdated code is present just by moving around system config, core apps, and DLLs.
So, yeah, I KNOW the source code is a hell of "hack-and-slash" which is BAD HABIT of WINDOWS programmers.
Re: Alternative reading... (Score:2)
I know you don't know any top tier programmers because you seem to believe top tier programmers are not capable of making mistakes that are easily caught in langues that have good static analysis. (Or static analysis was used in your c/c++ environment and therefore I hope you were against that because ... Good programmers shouldn't need it right?)
Re: (Score:3)
Blaming programmers for being careless, is like blaming factory workers in the early 1900s for carelessness when they lost hands or arms in the dangerous factory machinery. You could blame those factory workers for their "bad habits" but that doesn't give them their arm back. Today's factories require a lot more safety mechanisms to be built into their equipment, and as a result, a lot fewer people are hurt.
Code is no different. Why would we want to keep using antiquated, dangerous tools to build code that
It's an OS kernel. (Score:2)
You dont have memory safety in the core as it has to be able to access any system memory in order to work so I dont see how Rust will help. Sounds like a case of the new shiny shiny has won out over common sense with some gen z devs there.
Re: (Score:3)
Ring 0 is always going to have to have unfettered access to the system, and it's also where you want to gain the most efficiency. A lot of that is going to be written in assembly and C/C++, and that's probably never going to change. But, providing you don't have a fundamentally broken driver model (ha ha), other parts of the kernel and the core libraries probably could benefit from a memory safe language. But how you do that with that a kernel with some fairly significant legacy architecture choices is hard
Re: (Score:2)
Because they'd wind up making the same mistakes over again. A huge reason the code is so nasty in the first place is because they've been catching and fixing bugs, and many of those fixes result in the code being weird and non-obvious. If you throw that out and start over from scratch, you lose all those fixes, and the same mistakes creep back in. Not all of them, of cours
Re: (Score:3)
Re: (Score:2)
Re:You can't put lipstick on a pig! (Score:5, Insightful)
Are you kidding? Microsoft has been putting lipstick on the Windows pig since Windows 95 (with the exception of Windows 2000, which I consider probably the best OS they ever released).
Re:You can't put lipstick on a pig! (Score:5, Funny)
Microsoft has been putting lipstick on the Windows pig since Windows 95
Spoken from true ignorance. The windows kernel has seen some pretty significant re-writes over the past 3 decades. They aren't putting lipstick on pigs, they are making whole new hogs to play dressup with.
Re: (Score:2)
Sure you can.
However I would suggest you start with small pigs (but not so small that mom feels particularly protective of them) and work your way up to full grown male feral pigs who are more likely to take offense and more capable of stopping you from doing so.
Re: (Score:2)
Since the code is closed source, we don't really have any way to know wether the code has been so tried and test as to be close to bug-free, or if there are large numbers of bugs that just haven't been found yet.
Re: (Score:3)
Given that it's closed and for-profit, you can almost guarantee that there is a risk-assessment process and real preventative effort only goes in the obvious areas.
After all, the market seems to be quite tolerant of frequent exploits in the wild followed by eventual acknowledgement and later patches of issues that escape capture by QA. And if occasionally a big one gets out? OK, NOW throw the resources at it for a rushed patch. Still more profitable.
Re: Windows is done anyway. (Score:3)
Sorry are we talking about the OS with 74% share of the desktop maket? Are you saying the working world isn't using desktops?
Re: (Score:3)
Yes you keep saying that. However saying it does not make it true. Windows still runs the business world. Sadly Excel mostly.
Re: (Score:2)