There is a story in Writing Solid Code by Steve Maguire [1] where Apple asked Microsoft to fix hacks in its Mac apps that didn't conform to the developer docs in Inside Macintosh because such workarounds were required when the apps were first developed alongside the original Macintoshes. However, Microsoft's workarounds would be broken by a major System Software update under development at Apple, which naturally wanted to avoid having to permanently add back the implementation bugs and quirks that the workarounds either relied on or were meant to avoid.

As Maguire told it, removing one such workaround in Microsoft Excel was hotly debated by the Excel team because it was in a hot-path 68k assembly function and rewriting the code to remove it would add 12 CPU cycles to the function runtime. The debate was eventually resolved by one developer who ran Excel's "3-hour torture test" and counted how many times the function in question was called. The total: about 76,000 times, so 12 more cycles each time would be about 910,000 cycles total... which on the Macintosh 128k's ~7 MHz 68000 CPU would be about 0.15 seconds added to a 3-hour test run. With the slowdown from removing the workaround thus proven to be utterly trivial, it was indeed removed.

[1] https://openlibrary.org/books/OL1407270M/Writing_solid_code - page 136, heading "Don't Overestimate the Cost"

The fact that UWP XAML was its own new thing and not a extension of an existing Microsoft GUI app framework like WPF was not necessarily a "we hate managed code" thing, or even a "we hate those guys who invented managed code and want to screw them because we're Windows" thing. After all, .NET managed code had equal access to UWP through the .NET WinRT projection!

And to me at least (I didn't work on UI-facing stuff in Win8), it was absolutely conceivable that UWP could have just delivered Windows Phone 7 Silverlight's version of XAML to native code apps, with a thin adaptation layer to let even unmodified WP7 app binaries run on the desktop Windows .NET Framework with the WinRT projection and to allow slightly modified WP7 apps to look good in landscape mode on both Windows 8 and WP8. If we had done that instead of making UWP XAML its own thing, and if we had integrated the Windows Store with the Windows Phone Marketplace from the beginning so that Windows and Windows Phone apps could be sold as variants of each other through a single Store/Marketplace product entry on Windows 8 GA day, then I think we could have brought a lot of people forward who were already making good WP7 apps, and the Store wouldn't have been so empty.

Furthermore, IIRC much of the original UWP XAML implementation was done by the original people who built WPF and Silverlight the first time, and they would have known what they were doing in separating UWP XAML from Phone Silverlight. That they didn't go in the direction of extending Phone Silverlight was not necessarily shortsightedness on the part of provincial Windows people. Maybe they thought Phone Silverlight actually demonstrated fundamental limitations of WPF or Silverlight XAML or the Silverlight "coreCLR", or they wanted to make breaking changes as lessons learned from Phone Silverlight, which was put together about as hurriedly. (Windows Mobile 6 -> Windows Phone 7 first previews = 1.5 years; Windows 7 -> Windows 8 first previews = 1.5-2 years, tending toward 1.5 years if you account for the frantic re-planning after iPad came out in early 2010.)

It's important to remember the specific reasons why Windows RT 8 chose to not support third-party desktop apps. The most important aspect of "iPad compete" that we wanted on Windows for ARM was not "all app UXes look and work well on touchscreen tablets" but "you can't ship malware, not even by rebuilding your x86 malware from source." Thus, every 3rd party app on Windows RT would have to live in the AppContainer sandbox that UWP apps are in by default, and the requirement that you ship through the artist formerly known as the Windows Store would be a second line of defense against malicious apps. And with the forced-enabled Secure Boot, subverting the user-mode controls by secretly installing a bootkit would be hard even with physical access to the PC.

Even within the Microsoft world only, Windows Phone 7 had proven the success of this approach of locked-down apps only available through an app store that checked apps on submission and afterward for security. It was not unreasonable to think that similar lessons might also benefit users of "big" Windows, which is why Windows 10 and 11 have the opt-out "S mode" which defaults to the Windows RT restrictions.

I do wish though that Windows 8 had learned different lessons from WP7 (about which more in another point).

fair. but that struck me as strange even then. if anything, visual studio should have adopted the all-lowercase typography of the original metro-style design language from zune and windows phone 7, not AN ALL-UPPERCASE ONE.

Perhaps that was just another way that Windows 8 Metro-style apps' design and developer platform was like Windows Phone 7's Metro style, yet different in seemingly gratuitous ways. That is something I would attribute to internal Microsoft politics. Steven Sinofsky and Terry Myerson (leader of Windows Phone at that time) never really got along, and in the Microsoft philosophy of that era where engineering divisions were completely locked down from each other by default, that rivalry would have discouraged what little natural collaboration would have happened anyway.

I think the real mistake there was not so much that a particular projection of the Windows Runtime was stopped, but the more general idea that developers should be forced to consume what became known as the Universal Windows Platform or author custom WinRT components through only Microsoft-made WinRT projections.

In the name of winning over new or inexperienced Windows developers with "simpler, safer" projections, we in the Windows division almost completely failed for about 5 years to document or even explicitly say that WinRT was essentially just "COM: The Good Parts, Version 2012". (Martyn Lovell's Build talks on the origin of WinRT were a notable exception to this.) This discouraged people from using their existing COM skills to develop Metro-style/UWP apps or to gradually adopt features from UWP APIs that were accessible to them in their existing desktop apps. Other people have written that "WinRT=COM" thinking is actually a bad idea because it forces people to deal with COM and its more annoying ideas (separate IDL etc.); I disagree because we should have reached out to people who live in COM world to get a ready developer base.

That mistake was a key part of the still larger mistake you touched on of trying to make the UWP and desktop worlds 2 completely different developer platforms that happen to co-exist on the same desktop edition of the Windows OS. That was the key "we didn't listen to developers" mistake that set up UWP for its market failure. Another example: Even today, you can't adopt the battery-friendly UWP app lifecycle using Windows App SDK, which is supposed to be the UWP successor for desktop app developers. So much for WinAppSDK (or indeed UWP/Metro-style apps in Win8) enabling a true no-compromise user experience.

It took real tours-de-force like Kenny Kerr building C++/WinRT and blogging about it, Raymond Chen blogging about using WinRT APIs through the unprojected "ABI" interfaces, or the VideoLAN organization building a Win8/Win10 UWP version of VLC in C, to get the word out that the UWP world wasn't some alien thing with dark magic that only Microsoft wizards had full access to. And it doesn't help that the wizards really do have a few special powers that they jealously guard even now.

At the risk of getting my Microsoft history wrong, I'm fairly sure that Steven Sinofsky wasn't working on Windows or even MFC (i.e. what he did as one of you guys) in .NET's early days of 1999-2003. He was leading Office at that time. Office of that era was transitioning from the Windows XP look that still persists in Windows Forms to the early Ribbon, and was then (as now?) using very custom GUI code that didn't correspond to any specific higher-level Windows app framework.

Mac OS Office apps had just separated their codebase again from Windows apps after being unified in the mid-90s to get to feature parity (which annoyed Mac users who felt they now had non-native-feeling apps that were slow and bloated), and the "Office framework" was still quite distinct from any single-platform Windows app as a result of that.

So if Sinofsky did not understand why people went from USER/GDI to WinForms, that may just have been the fact that nobody working for him had felt the need to make that transition.

I think you're being a bit unfair to the Windows division during the Win8 lifecycle. Maybe that's just my rose-tinted glasses though. I know there are some HN/proggit commenters who like to harp on the supposed toxic rivalry between the Windows orgs and Microsoft developer tools orgs and how it has made Windows' developer platform much worse over the years, but I have always thought we had a better relationship than that, since my group's product was the main reason for yours for many years, and your group delivered so much for us in turn. Clearly your side had at least some reason to see things differently. On behalf of all of us, yes even up to stevesi, I'm sorry.

Now let me completely undermine my apology by nitpicking your comment :)

[continued in my replies to this comment]

For example, Windows classic desktop apps still have no equivalent to the UWP app lifecycle. Your UWP app's processes can be suspended and resumed without you writing code to force the suspension and request when to be resumed later. Instead, you are expected to appropriately handle event notifications for suspend, resume, and the app entering and leaving background state.

This system-managed UWP app lifecycle makes life harder for UWP app authors, but I think the net win for battery life is much better for the user experience, which is why mobile apps operate the same way. Yet the docs for the Windows App SDK, which is supposed to bring the best of the UWP to desktop apps, explicitly say that WinAppSDK apps control their lifecycle just like other desktop apps, and the only power friendliness in the WinAppSDK API is voluntary (aka no one will use it). [1, 2]

I'll probably write more soon in response to other parts of the original link's comment thread. Overall, I feel like UWP is being unfairly maligned here, and that while its introduction was unforgivably arrogant, Steven Sinofsky is also right that it was daring and necessary to fix the mistakes and outdated decisions of 16-bit Windows and Win32.

[1] https://learn.microsoft.com/windows/apps/windows-app-sdk/app...

[2] https://learn.microsoft.com/windows/apps/windows-app-sdk/app...

IMO Microsoft's best long-lived products have always been both finished solutions to your problems and platforms to help you develop more solutions, and Microsoft leadership has always recognized this. Examples: Windows. Office. Dynamics (their Salesforce competitor).

But even if a product doesn't meet that "why not both?" ideal, there is always going to be room for it at Microsoft, as long as it is not only a good or at least mediocre product by itself, but also works to sell you on the whole Microsoft ecosystem. Sometimes that is a bad thing (see all the Windows adware for Bing, Copilot, and M365). But that at least is where Microsoft remains consistent.

People who play this corrosive game either refuse to believe that they are at fault for not changing what they were doing at that time or speaking up about what they were observing then, or they know they're at fault and want to deceptively distract us from that fact. Either way, ask yourself this: "Aren't they sorry?" If they're not, just move on.

[1] Example: https://www.mozillafoundation.org/en/privacynotincluded/arti... (prev. HN discussion: https://news.ycombinator.com/item?id=37401563 )

At most, VS Code might say that it has disabled lexing, syntax coloring, etc. due to the file size. But I don't care about that for log files...

It still might be true that Visual Studio Code uses more memory for the same file than Sublime Text would. But for me, it's more important that the editor runs at all.

And I disagree with your implicit claim that the WP7 & WP8 Silverlight -> Win10 UWP transition had no migration path. There was >= 90% source code similarity, bolstered if you had already adopted the Win8.1/WP8.1 "universal" project templates. And Microsoft provided tooling to ease the transition. Sometimes it was literally just s/Microsoft.Phone/Windows.UI/g.

Games were a different matter, I'll admit. XNA as an app platform had no direct replacement that was binary compatible with Win10 desktop, but even then, not only was DirectX already available from WP8.0, but Microsoft invested in MonoGame as an XNA replacement precisely because they knew the end of XNA would hit hard. (In fact it was the Windows Phone division that had essentially kept XNA on life support in its final years so that WP7 games would not break.)

I'll give you the benefit of the doubt and assume you're thinking of the lack of device OS upgrades: from WP6.5 to WP7, from WP7 to WP8, and from older WP8 devices to W10M. So no forward compat, but absolutely yes to backward compat.

The announced plan was that Akihito would abdicate on April 30 and Naruhito would take the throne on May 1, so that Jan 1-Apr 30, 2019 would be Heisei 31 (平成31年) and May 1-Dec 31 would be Reiwa 1/Reiwa Gannen (令和元年).

The issue was with Windows Calculator's date calculation. If you ask it which day is 61 days after April 1, 2019, it correctly calculates June 1, 2019. The question, though, is what if you have your Windows settings set to show the Japanese era year - should it show "2019" in "June 1, 2019" as Heisei 31 or Reiwa 1?

If I remember right, the answer chosen was "it depends on what your computer's current clock time is!" In other words, if you ask Calculator while your PC's clock is set to April 2019 or earlier, it "wrongly" shows June 1, 2019 as in Heisei 31, but if your clock is set to May 2019 or later, June 1, 2019 is "correctly" shown as in Reiwa 1. This would be true even if the running Calculator and Windows code was already updated with the knowledge that the new era would be called "Reiwa." (Though the date when Reiwa would begin was specified by a law passed in 2017, Reiwa's name was only announced on April 1, 2019.)

(I forget whether this problem was solved in the calculator app itself or whether it inherited the solution from Windows' date and time formatting code.)

The justification was that the change of era would only be finalized when Akihito actually abdicated. In modern times, Akihito's abdication was the first time that the era changed without the reigning emperor dying. Calculator acting as if it knew before May 1, 2019 that Reiwa would begin on that day would thus be in bad taste, because it would be the moral equivalent of Calculator predicting or wishing for Akihito's death on April 30 - never mind that it was already well known that Akihito planned to abdicate on that day instead.

Comments URL: https://news.ycombinator.com/item?id=45973083

Points: 11

# Comments: 4

I say "read-write" or "writable" and "writability" for "mutable" and "mutability", and "read-only" and "read-only-ness" for "immutable" and "immutability". Typically, I make exceptions only when the language has multiple similar immutability-like concepts for which the precise terms are the only real option to avoid confusion.

Obviously the 2025 version will be out of date for the 2026 filing season, though public code means it can always be revived by anyone else.

(previous HN threads: https://news.ycombinator.com/item?id=44182356 https://news.ycombinator.com/item?id=44131901 )

Years ago I used to work on C++ code in a commercial editor called Source Insight [1]. At its default settings, it would do things like:

1. Show function and class names in HUGE fonts in declarations and definitions, so you always knew what was a declaration as opposed to a use

2. Show nested parentheses with the outermost parens being biggest and getting smaller as you got further in

3. Show comments in a proportional sans-serif font instead of a monospaced one so that you could tell where the comments were even if you have color blindness

Those features, along with having a C++ parser and code relationship visualizer much faster than the Visual Studio of the day without having to parse ahead of time (a la ctags), made Source Insight a near standard in my company. I still miss it on occasion.

[1] https://www.sourceinsight.com/feature-details/