3 ms·

I assure you that Microsoft knew for years that there were thousands if not tens of thousands of memory related bugs lurking in Windows. But their policy was "d

I assure you that Microsoft knew for years that there were thousands if not tens of thousands of memory related bugs lurking in Windows. But their policy was "don't fix" (and "don't look") unless a remotely exploitable vulnerability was making headlines. Because every minute a developer spends finding and fixing bugs is a minute he can't spend on adding new features customers will pay for. Luckily one of the perks of A.I. is that it makes large scale code migrations feasible in a timely manner.

davidjade 2mo ago
And I can assure you that there were a number of MS research developed tools for finding memory bugs that have been used for decades at MS. There was never a don’t look / don’t fix policy while I was there. Quite the contrary.
- hn_submit 2mo ago
  Was there ever a time, apart from the short monthlong stint in 2001 after Blaster, when Microsoft developers worked on fixing memory related bugs? Automated tools (before the advent of A.I.) can only get you so far. The bugs being found by A.I. today could've been found by eyeballs if companies thought it worthwhile.
  - davidjade 2mo ago
    When these tools were set up, on every code change you had to run these tools and deal with the output of anything it thought was a memory bug - part of the dev cycle before you could commit your code. Did you have to scan the code looking for memory bug yourself with your eyeballs too? Yes, at every code check in you went through a paired peer code review before checking code in no matter your dev level. So two sets of eyeballs would look at every change. So yes, we had to look for bugs in multiple ways no matter the type of bug on every single code change. Then the testers would run all these tools and look at the output too (I was there when each org still had SDE Testers). Did bugs still get missed? Of course, just like today even with today's new tools.

davidjade 2mo ago

And I can assure you that there were a number of MS research developed tools for finding memory bugs that have been used for decades at MS. There was never a don’t look / don’t fix policy while I was there. Quite the contrary.

hn_submit 2mo ago
Was there ever a time, apart from the short monthlong stint in 2001 after Blaster, when Microsoft developers worked on fixing memory related bugs? Automated tools (before the advent of A.I.) can only get you so far. The bugs being found by A.I. today could've been found by eyeballs if companies thought it worthwhile.
- davidjade 2mo ago
  When these tools were set up, on every code change you had to run these tools and deal with the output of anything it thought was a memory bug - part of the dev cycle before you could commit your code. Did you have to scan the code looking for memory bug yourself with your eyeballs too? Yes, at every code check in you went through a paired peer code review before checking code in no matter your dev level. So two sets of eyeballs would look at every change. So yes, we had to look for bugs in multiple ways no matter the type of bug on every single code change. Then the testers would run all these tools and look at the output too (I was there when each org still had SDE Testers). Did bugs still get missed? Of course, just like today even with today's new tools.