Microsoft C/C++ code keeps on giving:
https://msrc.microsoft.com/update-g...

Too sad, that Microsoft is too poor to afford good devs. As a lot of devs here are sure, that good devs surely can code safe and secure in C/C++, Microsoft probably just lacks the resources to get such devs to work for them.

/s

@12bitfloat: Is my wording too subtle?

@Oktokolo No all good :D

I don't even see bug details there. Also, Log4j proved that you can have remote code execution issues even in a managed language.

@Fast-Nop: This isn't about the ability to purposefully integrate an RCE - which basically is what happened in Log4j. Also i really hope, that Microsoft has a slightly greater budget assigned to the core of their OS than log4j...

@Oktokolo Remote code execution is what RPC is all about anyway, though intended in a controlled manner of course. Maybe that wasn't the best idea in the first place.

Also, no, MS doesn't afford their best devs for Windows because they have more profitable products. Since the customers think they're locked in under Windows anyway, there's no point wasting resources to give them quality.

@Fast-Nop: Yep, RPC definietely is a bad idea in the first place. But they had twenty years to harden the shit out of it. And they have 40k "engineers" (so probably 20k actual devs) - surely some of them still work on the core of their glorified browser launcher...

@Oktokolo I doubt that because they don't understand the code base anymore. That has become a case of "if it works, don't touch it". In particular because, as mentioned, that task would require the most experienced devs who are instead used in more profitable ways.

It's also a problem with the company culture that rewards implementing new shiny stuff a lot more than preventively fixing potential issues.

@Fast-Nop: Sadly, you are probably right.

@Fast-Nop realistically how hard could it be to understand windows source?

You start with a board listing all your core processes (for each build, home, enterprise, etc.). A short description of what each of those processes do.
A diagram of their life cycle.

A diagram of startup basics.

Then from there you identify problems, like quality of life issues, bugs, etc. And you start by locating them and fixing them one by one.

Requisition a big ass azure instance for your devs, and recompile either the entire thing, or just the parts that changed, and do that every single line that's changed can be recompiled as fast as if the codebase was hot reloadable.

If theres anything I learned, it's that competence is entirely trial and error, combine with standardizing practices (instead of NIH syndrome), and breaking down a problem till its actionable and understandable.

And that you can learn almost anything competently given a years time.

Yes even a monolithic os.

Theres no excuse for how god awful windows core OS is given the number of deva they have.

They could hire anyone, even a bum like me off the street, and in a years time, I guarantee you the documentation would be better, and I'd have enough of a grasp to be fixing shit.

The one thing that I learned from looking at *other peoples code* was self esteem.

I dont know how some people get hired at all, and here I am working at fucking IHOP on the grill.

@Wisecrack The sheer mass prevents that. Also, fixing bugs is not a priority. They axed their QA back in 2016 and now test in VMs only so that they only catch bugs that would hit everyone.

That's why they roll out the updates in waves and check which configs are problematic, then block the updates for these configs. If you ever have seen the message that this update isn't compatible with your computer, it means enough users have been bitten before you.

But they can't reproduce the bugs because they don't have their park of real HW PCs anymore. They rely on telemetry, but the point where the crash happened may not have anything to do with where the actual bug is.

See this nice summary here: https://borncity.com/win/2019/...

This is gonna sound insane, but you know what I would do?

First requisition that massive azure instance, like before, to make single line recompiles quick.

And then write a utility to do testing by

1. Attaching to the VM to monitor for stop conditions

2. For each recompile, removing the previous old insertion, and inserting a NEW exception or fucking PRINT statement on the next previous line.

3. Walk the source file tree, testing every line that can be isolated like this.

Yep, that's what I would do. Automate newb-tier hand-testing. Find the location where it stops in this fashion, log it for investigation, and then start investigating the line(s), or source file in question.

Doesnt fix bugs that arise from interacting processes though. Might insert logging for everything, and do randomized dumps of data, use that to initialize vm instances with dozens, or hundreds of configurations, and run some sort of intersect() to automate the process of elimination to winnow it down.