Larry Osterman, a longtime Microsoft engineer, writes about Windows internals, DOS history, and software engineering stories.
HN commenters cite it for firsthand explanations of Windows and DOS history, threading models, and his 'one in a million is next Tuesday' essay.
Wow. Thanks for the detailed response. I will try to answer point by point.
#2 that tight coupling can ever be good comes as a shock to the learner
#3 any breakage is an opportunity learn from and about failure — also when it's broken and you know that is better than if it's broken and you don't know
Regarding regression testing: writing tests is a design activity so if it is "driven" by whatever happened to break last, that sounds like treating the symptom not the underlying cause. That is why I have never been a fan of "bug-driven development" nor of large-scale regression testing.
#20 "who draws the lines" is an incredibly important political question. So who makes the declaration that the so-called black box can not or is not to be opened? This was my point. I understand what a black box means in software testing parlance.
#31 check out this great article then: https://blogs.msdn.microsoft.com/larryosterman/2004/03/30/one-in-a-million-is-next-tuesday/
#51 testing is runnable documentation and sufficiently advanced monitoring, particularly ubiquitous StatsD usage, is indistinguishable in practice from testing, see https://www.youtube.com/watch?v=uSo8i1N18oc
#66 I truly do not understand the objection you are making here. If an event goes unobserved and is without impact it is the same as if the event never occurred.
#83 no bugs always cluster at the interfaces between components
#84 Uh oh. I need to check my math and will respond further in another comment once I…
How is it possible I didn't know that? Thank you. Does anyone know the history of it? I did a little research:
* I found someone asking the same question as me in 2005 (!) [1]
* Per someone on Stack Overflow: "/ can be used as a path separator at the API level, but you aren't calling the API directly. You're using cmd.exe, and cmd.exe parses the / as a command line option" [2]
* Later in the same Stack Overflow discussion someone performs a series of tests on Vista, with some inconsistent results. [2]
* Here's a history by veteran Microsoft developer Larry Osterman, which takes us back to the developers of MS-DOS and also mentions other undocumented ways MS-DOS can/could be made Unix friendly. [3]
-----
[1] https://bytes.com/topic/python/answers/23123-when-did-windows-start-accepting-forward-slash-path-separator
[2] https://stackoverflow.com/questions/10523708/why-does-the-cmd-exe-shell-on-windows-fail-with-paths-using-a-forward-slash
[3] https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/why-is-the-dos-path-character/
"The ADA? What on earth could the ADA have to do with a PC making a beep? Well it turns out that at some point in the intervening 25 years, the Win32 Beep() was used for assistive technologies – in particular the sounds made when you enable the assistive technologies like StickyKeys were generated using the Beep() API. There are about 6 different assistive technology (AT) sounds built into windows, their implementation is plumbed fairly deep inside the win32k.sys driver.
But why does that matter? Well it turns out that many enterprises (both governments and corporations) have requirements that prevent them from purchasing equipment that lacks accessible technologies and that meant that you couldn’t sell computers that didn’t have beep hardware to those enterprises."
Source: https://blogs.msdn.microsoft.com/larryosterman/2010/01/04/whats-up-with-the-beep-driver-in-windows-7/ (search for ADA)
I actually really like many of the blogs at Microsoft. It's a bit of a mixed bag, but there's some gems in there.
Raymond Chen's blog[1] in particular was good enough to get me to buy his book (which definitely did not disappoint).
Other ones I subscribe to are the Microsoft Edge Dev Blog[2] , Mark Russinovich[3] and Games for Windows and the DirectX SDK[4]
And there's a few that have unfortunately not been updated for a long time, such as Larry Osterman[5], or have come to an end, such as Rico Mariani[6]
[1] https://blogs.msdn.microsoft.com/oldnewthing/
[2] https://blogs.windows.com/msedgedev/
[3] https://blogs.technet.microsoft.com/markrussinovich/
[4] https://blogs.msdn.microsoft.com/chuckw/
[5] https://blogs.msdn.microsoft.com/larryosterman/
[6] https://blogs.msdn.microsoft.com/ricom/
> E.g. in Windows, when specifying color value using COLORREF they use the BGR format 0x00bbggrr.
Wait a little bit... isn't Windows little-endian [1]? Following the link in that sentence:
> typedef DWORD COLORREF;
> The low-order byte contains a value for the relative intensity of red; the second byte contains a value for green; and the third byte contains a value for blue.
Given that Windows is and has always been little-endian, the byte order of a COLORREF is red first, then green, then blue, that is, the order is RGB. So the reason for BGR can't be Windows' COLORREF.
[1] "A decision was made VERY long ago that Windows would not be ported to a big-endian processor." https://blogs.msdn.microsoft.com/larryosterman/2005/06/07/the-endian-of-windows/
> a Microsoft employee discovered a way to make virtualization work with their ongoing Windows 3.x design instead of having to go with OS/2.
That's sort of right. Larry Osterman goes into more detail here, but the gist is that Microsoft figured out how to run (mostly) unchanged Win16 apps in protected mode. This was released to market in 1990 and immediately turned into the best solution to get at more than 640K RAM.... which had been a latent and mostly unresolved issue for over five years. (So lots of pent-up demand.)
https://blogs.msdn.microsoft.com/larryosterman/2005/02/02/farewell-to-one-of-the-great-ones/
(V86 Virtualization happened with Windows/386... another good product, but not nearly as compelling as Windows 3.0 was.)