The Old New Thing

The first thought that came to my mind was if Raymond Chen's blogs on MSDN got deleted. Now , that would have been a tragedy! The blog is still up fyi. Tons of technology trivia and snippets there. Growing up, JoelOnSoftware[1] and Raymond Chen's blog[2] were two great companions for me while surfing the net. Knowing HN, I am pretty sure a lot of you would have grown up with these blogs :-) [1]https://www.joelonsoftware.com/ [2]https://devblogs.microsoft.com/oldnewthing/ Old MSDN link : https://blogs.msdn.microsoft.com/oldnewthing

> Every other release fails to compile on FreeBSD. But in later message you also state: > Our toolchain is actually GPL-free It's obviously the conflict of the goals, where you, the way I understand it, can't complain that the GPL-based tools "don't always (in every release) perfectly (i.e. without any adjustments) work" on the platforms whose goal is to avoid the GPL. You should be lucky that they indeed fix the issues when somebody submits the patches. But the other communities can't expect from the GPL contributors to do the very work for which the said non-GPL communities exist. Or, in the words of my favourite Microsoft (i.e. non-GPL) developer: https://blogs.msdn.microsoft.com/oldnewthing/20110118-00 "Don’t just stand around saying somebody should do something: Be someone"

Raymond Chen's excellent blog The Old New Thing has spent much time cataloging the weird permutation of English that has grown up among people at Microsoft, which he calls "Microspeak": https://blogs.msdn.microsoft.com/oldnewthing/tag/microspeak I'm guessing "turned down" is an emergent example of a new dialect, "Googlespeak."

Great insights! Your comment also made me wonder what actually happened to ELKS. Last I checked (many years ago, apparently), it seemed abandoned. But development has started again in 2014, and still seems ongoing: https://github.com/jbruchon/elks Should play with it some time, maybe in an 8086 emulator. EDIT: By the way: I forgot to mention this in my other comment: > The core of it is a smart linker/loader which allows code and data segments to be loaded, patched together on the fly, and dropped on demand. All data is relocatable, allowing it to be rearranged or swapped out. Early Windows on early XTs did that, too! With all sorts of crazy hacks to make it happen [1]. I don't know how it compared to what GEOS did, though. [1] https://blogs.msdn.microsoft.com/oldnewthing/20110316-00/?p=11203 and many other articles on that site can send you down a deep rabbit hole.

This [1] article by Raymond Chen is one of my favorite on exceptions. I admit there is an elegance to exceptions, but when I'm trying to write reliable code, I find reasoning about exceptions significantly increases my cognitive load. Error handling is a place where a little more verbosity is okay because it keeps my focus on the local context rather than having to consider the entire call stack. I basically agree with the TL;DR of the article: "My point is that exceptions are too hard and I'm not smart enough to handle them". [1] https://blogs.msdn.microsoft.com/oldnewthing/20050114-00/?p=36693

It might be worth mentioning that MS Windows has very similar (though somewhat distinctive) function WaitOnAddress https://docs.microsoft.com/en-us/windows/desktop/api/synchapi/nf-synch… , introduced in Server 2012 and Windows 8. See for details https://blogs.msdn.microsoft.com/oldnewthing/20170601-00/?p=96265

There's a fabulous article from Raymond Chen about EXE headers in general: https://blogs.msdn.microsoft.com/oldnewthing/20060130-00/?p=32483 >A Win32 executable file begins with a so-called "MZ" header, followed by a so-called "PE" header. If the "PE" header cannot be found, then the loader attempts to load the program as a Win16 executable file, which consists of an "MZ" header followed by an "NE" header. >If neither a "PE" nor an "NE" header can be found after the "MZ" header, then the loader attempts to load the program as an MS-DOS relocatable executable. If not even an "MZ" header can be found, then the loader attempt to load the program as an MS-DOS non-relocatable executable (aka "COM format" since this is the format of CP/M .COM files).

As others have recommended, wear a pair of Nikes and just do it. For some inspiration, here is a good technical writing blog (a Microsoft dev analyzing various algorithms, apparently as part of his phd preparation): https://blogs.msdn.microsoft.com/devdev/ Another with funny anecdotes from the Windows world https://blogs.msdn.microsoft.com/oldnewthing/ I also like Peter Norvig's blog http://www.norvig.com/

Nah, it's a valid optimization as long as ereport() returns. The compiler doesn't need to follow the order of operations as long as the observed behavior is the same as if the operations were performed in the order in the code. Since the compiler doesn't have any responsibility if division by zero happens, it's fine to do the division before. This is an interesting read: https://blogs.msdn.microsoft.com/oldnewthing/20140627-00/?p=633

One of my favorite posts was [1], specifically this bit: > Note: I actually don't know who ordered first. I just made up that part of the story to make it funnier. (Note that I make up parts of other stories, too. I'm not a historian. I'm a storyteller.) It really made me rethink the value everyone places in the accuracy (or lack thereof) of storytelling. [1] https://blogs.msdn.microsoft.com/oldnewthing/20130205-00/?p=5343

Good point, here. As is often said, when the documentation says "undefined behavior", it means the compiler can do whatever it wants, including "work just fine"; and sometimes it'll cause time travel[0]. Hence the "nasal demons" lore. Often, it'll cause optimizations to be applied that would have otherwise been avoided resulting in a bug that appears to occur somewhere else and a programmer to look at the result of execution and ... if it actually continues executing ... swear a lot. These are especially fun because the problem frequently won't appear in debug builds. [0] https://blogs.msdn.microsoft.com/oldnewthing/20140627-00/?p=633/ - worth a read for some entertainment - basically what happens when the compiler assumes "undefined behavior" can't happen and optimizes accordingly.

Inferences from https://blogs.msdn.microsoft.com/oldnewthing/20081020-00/?p=20523 . I also know that 32bit programs could load 16bit modules without issue. In fact that was one of the things that MS was harping on people to not do; was stop using 16bit modules in their 32bit applications (which would have otherwise run fine on 64bit systems). I'm pretty sure it worked because 32bit system DLLS all got a 32 appended to them so the linker and loader would know which version they were going to and ensure that call was routed appropriately. Edit: It's also worth noting that 32bit and 16bit instructions are different because of register size operands. So to speak you're absolutely right... a 16bit read/write COULD do that... but it's a feature, not a bug.

https://blogs.msdn.microsoft.com/oldnewthing/20050902-00/?p=34333 rather implies it updates at the "tick" frequency, not actually every milisecond. Someone should do the followup test to see how frequently it actually changes.

I used to work on Windows and would pretty often edit source files that were written over 20 years ago, sometimes by the guy four levels above me in the chain of command, back when he was an individual contributor. I actually preferred the C and older C++ components, with no exceptions and manual memory and error handling, to the "modern" C++ components. I recommend Raymond Chen's blog, The Old New Thing, for some cool stories about how and why ancient Windows/Office components were written a certain way, and what the effects down the line have been. Among other things. https://blogs.msdn.microsoft.com/oldnewthing/ What you're saying is probably more true in the web dev world.

Yeah, but you'd expect the golden master .iso of a major Windows release to be examined in greater detail and not sloppily add bloat like that. It's in great contrast to earlier releases like Windows 95 where blinking dots were removed from the task bar to save a few kilobytes of demand paged memory. https://blogs.msdn.microsoft.com/oldnewthing/20031010-00/?p=42203

I love the Boeing management anecdote being referenced in comparison to Bill Gates nudging you off'f an email he receives![0] Great nugget to pull out if you have a manager with a penchant for stating the obvious! [0] - https://blogs.msdn.microsoft.com/oldnewthing/20100705-00/?p=13503

Raymond Chen's posts are excellent https://blogs.msdn.microsoft.com/oldnewthing/

> Especially since Terminal.app is far more modern than CMD.EXE? To be fair, a lot of Terminal.app dates back to ancient Mac OS too. The menu bars, for example, are all still Carbon. There is still a full classic Mac OS main loop running alongside the Cocoa main loop in every macOS application. Apple's done a good job hiding it, but it's still there. Anyway, cmd.exe is a bit of a special case. What you're really seeing is conhost.exe, which is kept the way it is because it's part of CSRSS, which occupies a similar place as PID 1 does, and Microsoft doesn't want to bring new UI into it for fear of increasing its dependencies [1]. [1]: https://blogs.msdn.microsoft.com/oldnewthing/20071231-00/?p=23983

Agree, NT has many excellent ideas. But re-implementing it today seems silly. Are you going to have messages with take two integers only, then stick two 16-bit fields into second one? Look at these articles, do you think anyone should be implementing API like this in 21st century: https://blogs.msdn.microsoft.com/oldnewthing/20070710-00/?p=26083 https://blogs.msdn.microsoft.com/oldnewthing/20120913-00/?p=6613 I am all for variety. Hurd, L4 -- these are fundamentally different from Unix and very interesting. ReactOS? well if you enjoy debugging windows kernel drivers without source code...

My favorite: https://blogs.msdn.microsoft.com/oldnewthing/20130327-00/?p=4833 People had written guides advocating for turning off certain 3D effects, which itself would turn off hardware acceleration and slow down rendering.

That's not even the full Win32/16 style. That first line should be: static LRESULT WINAPI MCIWndProc16(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam) And even then MS couldn't decide whether to use message (MSG struct), Msg (SendMessage), uMsg (WindowProc) for the second variable name. Sometimes they would use hwnd as well. I remember it all being very, very confusing when I was learning to program because it was inconsistent in so many ways. In a semi-related note, Raymond Chen's blog (1) is great for diving into the history of the Windows API and its many quirks and gotchas. [1] https://blogs.msdn.microsoft.com/oldnewthing/

I love this one, about DirectX not trusting drivers responses to capabilities requests: https://blogs.msdn.microsoft.com/oldnewthing/20040211-00/?p=40663

This is a great idea. The problem is convincing management to keep you employed. :) Whenever I see another 100mb update for trivial software, I'm reminded of Raymond Chen's blog on this topic - https://blogs.msdn.microsoft.com/oldnewthing/20061101-03/?p=29153

As relevant today as when it was written: https://blogs.msdn.microsoft.com/oldnewthing/20030728-00/?p=43043 People will blindly follow a tutorial online that tells them how to activate this option, and continue to contact Philips for support. I've worked on products that have these unsupported/advanced modes, and customer queries on them are constant and time-consuming, even to simply dismiss (and, of course, those customers then go on to leave bad reviews, et cetera).

I try to live by a few simple rules regarding code vs comments. Here are ten of them. Some of these are already in other comments, in a different form. 1. Code should show not tell. That means the comments I write are typically at the beginning of a class or function rather than scattered throughout on separate lines. 2. Code shows how, comments instruct why. A good comment includes the reasoning behind the algorithms and tradeoff choices chosen by the coder. 3. Good comments include an example of usage 4. Good comments are compatible with an automated documentation framework, such as Javadoc, Doxygen, Rustdoc, and Pydoc 5. Good comments do not include a modification history. Version control and changelogs can handle that. 6. Kill your darlings - Good code follows the KISS principle, and is easily understood, as well as easily maintained 7. Good code is SOLID - This is part of Kill Your Darlings, in a way. To be easily maintained, in many cases, you need to follow SOLID. Here's a good article on SOLID: https://scotch.io/bar-talk/s-o-l-i-d-the-first-five-principles-of-obje… 8. Good code is short - I don't have a firm line count, because it's different based on domain, language, etc. I do try to keep each method/function to no more than a quarter of a screen of code at a reasonable resolution, so that's maybe around 15 lines. With modern optimizing compilers and VMs this will not be a large performance hit, if it's a hit at all, assuming you are…

I enjoy Yossi Kreinin's blog [1] and The Old New Thing [2]. I don't read programming language books, which I usually find to have little good industry knowledge and to be too detail oriented and easily out of date. Although K&R (the one about C) is a great book that's exactly the right size and the examples from the Gang of Four book are actually very on point. Most often I learn code by reading code. OpenSceneGraph is an example of an open source project that has modern ish C++ but no deliberately abstract misdirection. Open source usually does not have super clean code but it's a good way to sample the variety of structures you can find in a project. Of course the classics (sqlite and the Linux kernel) are much too C-like for where I'm getting at but they are still full of lessons for how to organize modules and APIs, how many arguments to pass and where, where to park I/O code, that sort of thing. I posted it here for the benefit of HN readers who may have the same question but I'll write you an email too so you can share what you want to improve and such. There aren't many C++ programmers left in the HN-reading, not just punching a clock demographic, and I kind of miss talking to people who get that. Like the prototypical game dev in the article I go to one conference a year, and it's not about C++. [1]: https://yosefk.com/blog/ [2]: https://blogs.msdn.microsoft.com/oldnewthing/

I agree with you, but it's important to acknowledge the strength of the argument against exceptions. I think Raymond Chen put forth some of the best arguments, claiming they were human error prone: https://blogs.msdn.microsoft.com/oldnewthing/20050114-00/?p=36693 https://blogs.msdn.microsoft.com/oldnewthing/20040422-00/?p=39683/ While forceful, I don't accept the conclusion of Raymond's argument. I feel it may be true for programmers primarily trained and experienced in C, but is not true in general. As such, the argument reduces to "programmers who are not familiar with exceptions sometimes make mistakes when using them." One could say the same thing about pointers, dynamic typing, lambdas, macros, comprehensions, pass-by-reference, etc. Today, most programmers are familiar and comfortable with exceptions, having almost certainly been taught to use them in college and almost certainly using them on a daily basis for their entire professional career. They'll also have been taught to use a language-specific toolbox such as RAII or try/catch/finally to deal with any potential problems. Once you get in the habit, it's not hard to scan through a program line-by-line asking yourself "what would happen if an exception were thrown at this point?" and to take appropriate precautions. In fact, I'd wager that for anyone who's spent years working in any language with exceptions this quickly becomes second nature. It's also an easy way to add value during peer code review. In my…

There's actually a very good reason to implement a delay in switching submenus. Recent versions of Apple's human interface guidelines don't make any mention of it, because those decisions are baked into the toolkit and not under control of application designers, but the earlier editions of Apple's guidelines went into some detail about why and how pop-up submenus were delayed. 1995 edition of Macintosh Human Interface Guidelines: http://interface.free.fr/Archives/Apple_HIGuidelines.pdf >pp. 79: Hierarchical menus are menus that include a menu item from which a submenu descends. You can offer additional menu item choices without taking up more space in the menu bar by including a submenu in a main menu. When the user drags the pointer through a menu and rests it on a hierarchical menu item, a submenu appears after a brief delay. To indicate that a submenu exists, use a triangle facing right, as shown in Figure 4-36. The original 1987 version of the Apple Human Interface Guidelines can be checked out from the Internet Archive, and should be required reading for serious user interface designers, the same way that serious art students should contemplate the Mona Lisa, and serious music students should listen to Mozart. Even though it's quite dated, it's a piece of classic historic literature that explicitly explains the important details of the design and the rationale behind the it, in a way that modern UI guidelines just gloss over because so much is taken for granted and…

why would a compiler do that? The theory is that constraint propagation enables optimizations that aren't possible otherwise. In particular, it lets the compiler avoid emitting code for conditions it judges are impossible to occur. This usually doesn't help much with C, but can be useful with C++, and many of the optimization decisions are driven by C++ performance. To satisfy the Rust community's desire to spread FUD throughout the C community? I'm a big fan of C, and consider it my primary language. I have barely used Rust and am not part of the Rust community. A more logical thought process here is that signed operations aren't uniform across architectures and are sometimes emulated, leading to UB for certain edge cases, like overflow. Personally, I would love if this was the vision for C that compiler writers held. But it is not, and has not been for at least a decade. Its more practical to believe that a future C standard will fix this loophole rather than think compilers will exploit this and punish their own community. Unfortunately there is no chance that this will happen. That ship has sailed. Compilers are taking ever greater advantage of undefined behavior for purposes of optimization. Overflowing a signed integer is undefined behavior, therefor real-world compilers can and do strip out checks that they determine would require undefined behavior to be occur. I realize this is hard to believe, but try this article as an intro:…

I follow https://blogs.msdn.microsoft.com/oldnewthing/