I worked on Windows back in 2014, probably the most surprising thing joining there out of college was looking through the bug database. Every issue that gets complained about online -- and many more -- are in there, and have been for a long time, marked WONTFIX due to a potential compatibility break, lack of priority, or some other policy reason.
I don't know if anyone even owned Notepad or any other older inbox apps like the command prompt, but the issues were pretty well understood and WONTFIXed. Single undo, unicode support, unix LF support, etc, etc.
For Notepad a frustrated engineer had produced a change-set to fix all of them, and it had sat there attached to the bug for some time. It would surface on internal mail threads from time to time as a joke or a bitter reflection on bureaucracy, and if I recall a VP once chimed in to say they had looked at it, and sadly none of it could be committed due to backwards compatibility issues.
Of course the compat issues were real (you could view reports on which obscure apps hooked into this or that internal code of cmd.exe or Notepad and would break), but I always though they served as a nice justification for whichever investments were being made at the time: certainly not Notepad.
It's nice to see the wind change on that, even if it took a decade or two.
> For Notepad a frustrated engineer had produced a change-set to fix all of them
Hey, that was me (JeffMill). I was a dev lead for the Windows shell team at the time, and I got frustrated with notepad not getting any attention, so I spent a weekend and made the changes you describe and more, and had one of my reports code review it. I checked the changes in, and that week, some of the members of test team (remember those?) had a cow and my lead pulled out all of the changes.
I'm still at MSFT, now as an architect, so it turned out not to be a career limiting move, but I certainly should have discussed my plans more broadly rather than just "cowboying" those changes in.
Small world, I worked with you on the Windows Update team. Hope you are doing well. Good to see you here on the HN forum. I also remember the notepad incident!
Why not releasing it as NewNotepad or something? This way it keeps the old one working but provides a newer alternative. Like Paint and 3DPaint or whatever it is called.
I would be have been pretty sad to hear that so much enthusiasm to improve the product resulted in problems regarding your career. That's promotion material, in my book. Glad it worked out.
First thing I do on any windows machine is replace notepad with notepad2 [0], there are installs of it that hides original notepad and uses notepad2 in all the "Edit" context menus etc.
I have an app that has run on every version of Windows from 2000 through Windows 10. It now doesn't work in Windows 11 because they didn't reimplement the IDeskBand interface for the taskbar that my app uses to show remaining battery time.
My app is even part of their compatibility test suite (they asked me for permission and a license).
I understand the need to move forward and that BW compatibility can be hinder that, but it's really frustrating for me to 1) respond to thousands of people asking why it doesn't work after they upgrade, and 2) lose income because there's nothing I can do to make it work the same in Windows 11.
>I have an app that has run on every version of Windows from 2000 through Windows 10
Well, it had a good run. Should such compatibility forever hold Windows back from making breaking changes to those APIs though? 20 years is an eternity in computing...
Tell your users to vote with their money and stay on Windows 10. If enough people do so and get enough of a "Windows 11 breaks all your software" sentiment going, MS may start to reconsider.
It's not in Windows 11. That seems to be even more evidence that 11 was quite rushed for some reason. They rewrote the taskbar but didn't finish reimplementing much of the existing functionality.
Years ago I reported a bug in a VB function, something to do with date calculations. I spent quite a while on the phone with them, feeling like I was banging my head against a wall. They readily admitted that the output of their function was wrong, yet steadfastly maintained that they would not fix it because other programs might depend on that incorrect output.
If the answer to any bug report is that the buggy behavior is now the baseline standard, what's the point in reporting any bugs?
This all can be worked around given enough will. Excel files do have a format version number in them somewhere, right? I'm sure they do. So support the old behavior for older files, and the new one for the newer ones. All files created with the new version of Excel won't be affected by that bug, but the older ones, that might rely on it, won't break either.
I suspect it's a mindset change. Not heeding demand and staying stuck in the past was how Windows became a punchline, although I'm sure enterprise customers loved it. At some point it did begin to change -- I suspect it hasn't changed enough for HN readers.
For instance, Unix LF support was added to Notepad back in 2018 (at last!) with a few registry switches for compatibility.[1]
I'm not entirely clear whether the "current" API set called "WinRT" is the continuation of "Windows RT". It sounds plausible but it could just be Microsoft being terrible at naming.
Patching other people's binaries, turning off features if the app making the request is "problematic-app", re-introducing bugs, fixing should-be-impossible-to-happen calls from programs that were written by hand, it's all there!
> one useful shim is known as HeapPadAllocation; it is applied to programs that have heap buffer overrun bugs. The shim intercepts calls to the HeapAllocate function and adds a specified amount to the requested size. That way, when the program overruns a buffer, it merely corrupts the padding rather than corrupting the next heap block.
It was different when your typical application came on ten floppy disks. Not being able to use it on the next version of Windows might hinder the adoption of Windows.
Going to have to buy this book now. Enjoyed this extract. I wonder what font was used? whatthefont thinks it might be Adobe Jenson Display, and I don't currently have any PDF tools to inspect the document. The 'y' looks so pretty, with it's rightward curve.
> Wait what, external software calls into notepad?
External software calls into everything. Welcome to Windows development.
It's extremely difficult to implement even "obvious" changes like a dark-mode Notepad when it could potentially break customers who have been depending on specific behavior for decades.
This is why they've had to write shim-specific code for certain vendors. The desire to move forward versus the awful prospect of having to keep those shims in place.
Surprisingly I actually deal with a fairly hefty integration that does some horrible win32 shit I don’t understand after opening notepad to integrate it into their app. There’s so much of that out there it’s unreal.
I imagine then at least 80% of Excel's bug tracker must have WONTFIX as a designation, cause I tell you, the same fucking bugs seem to come with every release.
I've always liked Apple's approach more. There are public APIs that are mostly guaranteed to work across system versions. Then there are private ones. You can reverse engineer them. You can use them in your apps. They might even do what you wanted. But you're on your own with them, as Apple rightfully considers itself free to break anything that isn't part of the public SDK.
Microsoft, on the other hand, sees that some app calls an undocumented internal function, or has a bug that causes it to misuse an API call that just happens to still work correctly, or even worse, hooks into a system library or something, and considers that now to be a part of the public SDK that is to be maintained and made compatible with everything that might use it, forever.
I worked on macOS for many years. Apple's policy is more like Microsoft's than you describe. It was commonplace to have to revert changes that broke a "must-not-break" application that was dependent on undocumented APIs or behavior, and the source of certain projects is littered with app-specific workarounds.
I've never understood this desire to run everything 100% natively all the time AND keep your system up to date. Just put a Windows 95/98/2000/XP VM into Windows 11, integrate its window manager with the host desktop, and be done with it forever. Start it transparently for apps that need it. IIRC Apple did a similar thing when transitioning from classic Mac OS to OS X, and it worked pretty well.
I did a bit of cross-platform development in C++, and I'm glad to report that Linux is an API clusterfuck in regard to anything going beyond system calls. None of the desktop-related stuff is part of the system and there's always more than one way to do something, and you have to support all of them because else someone would complain that your thing doesn't work on their particular configuration.
I don't know if anyone even owned Notepad or any other older inbox apps like the command prompt, but the issues were pretty well understood and WONTFIXed. Single undo, unicode support, unix LF support, etc, etc.
For Notepad a frustrated engineer had produced a change-set to fix all of them, and it had sat there attached to the bug for some time. It would surface on internal mail threads from time to time as a joke or a bitter reflection on bureaucracy, and if I recall a VP once chimed in to say they had looked at it, and sadly none of it could be committed due to backwards compatibility issues.
Of course the compat issues were real (you could view reports on which obscure apps hooked into this or that internal code of cmd.exe or Notepad and would break), but I always though they served as a nice justification for whichever investments were being made at the time: certainly not Notepad.
It's nice to see the wind change on that, even if it took a decade or two.