2024 mid-year link clearance

Raymond Chen

Hey, look at this, we’re just about halfway through the year.

And the obligatory self-serving plug: It appears that the Windows Dev Docs team created a short link that takes you to a playlist of many of my One Dev Question videos: https://aka.ms/ODQ-RaymondChen.

10 comments

Leave a comment

  • Joshua Hudson 0

    So that switch OS on sleep monstrosity. I understood why it used that journal replay method. That’s how it protects against trashing NTFS.

    The OS is asleep not shut down. If you rearrange any on disk structures bad things. But if you journal the writes and replay them as normal filesystem writes when windows resumes from sleep, it’s all good.

    In other news, that .efi application is actually smart. You’ve heard of no deps right? This is the ultimate no deps.

    That display calendar thingy, I expected a video driver not smm.

    • Toni Ylisirniö 0

      Even if the Windows was fully shut down, I believe in 2009 Linux NTFS drivers write support was still experimental and dodgy, and could trash the journaling or worse. You were well advised to only treat NTFS partitions as read only from Linux side. So, no matter the status of the Windows OS, it still makes sense to do this delayed write back of the data on Windows side to make sure nothing breaks the NTFS filesystem.

    • alan robinson 0

      The thing that’s crazy about all this is they made it into an OS when it could have been a simple win32 app (replacing explorer perhaps), as the startup times are almost identical for the linux based “instant on” OS as real windows 7. If they had just made a shell alternative then the boot times would be unchanged (or possibility faster since exlporer.exe is fairly heavy) and switching into it from an already booted win7 would have been much, much faster.

  • Christopher Lee 0

    WordPad was once published in the Microsoft Store at product ID 9NBLGGH4V89G (probably as a packaging proof of concept). It lacks file type associations, but perhaps that is preferable so you have to make a conscious decision to run it.

  • alan robinson 0

    There’s a long history of updating the wordpad sample MFC code to make “interesting” variants. I’ve even done it myself, thought I don’t think I ever published it online. Since the OS does most of the work the resulting apps are super light weight, loading instantly and taking nearly zero space. These days I use metapad ( 94k installed!) for that purpose, though in all honesty it’s raw C not MFC so it’s actually not from the same source code lineage, though I imagine it’s inspired from the same “wrap as little code as possible around a rich text control” philosophy.

  • Jan Ringoš 0

    Darek Mihocka, in his dive deep into ARM64EC recalls Windows RT and writes:

    “We already know that Windows RT had no foreign binary support, provided only a limited set of native ARM built-in apps, and required third-party developers to port their applications to ARM if they wanted to run on Windows RT at all. When not enough developers bought in on this (as happened with RT) the OS ended up being of little value to paying consumers and eventually died.”

    This is not true.

    Windows RT died because Microsoft, for the whole lifetime of Windows RT, actively prevented developers from porting their apps to that environment. Hundreds of developers were willing and eager to port their apps to ARMv7 Windows, but you blocked loading Win32 (non-Metro) EXEs/DLLs by requiring them to be signed by a certificate you didn’t give anyone but the Office team. Then you kept patching and closing all and every loophole people found and used to have their favorite apps running.

    This truly grinds my gears because those devices were so slick and cool.

    • LB 0

      I think the intention was for developers to publish their apps through the Microsoft Store, which back then only allowed publishing UWP apps, and I’ve heard other developers absolutely hated UWP, but it was possible and some apps and games did get ported that way. You’re right though, the refusal to accept Win32 apps on Windows RT probably significantly contributed to its demise, since that would have been a trivial porting process for many apps and games compared to making a few small modernizations to the code for the UWP app model. Plus I think back then UWP only worked with C++/CX and C#, so it used to be that porting to UWP meant having to learn a bit of new C++ syntax, or an entirely new language. The UWP porting process is much easier nowadays since it can be done with pure standard C++ thanks to C++/WinRT, but it’s too late I suppose.

      • alan robinson 0

        How many Win32 apps are written in pure C, at least since the start of the last millennia? Or am I misunderstanding you? Probably…

        • LB 0

          Well there is a C ABI for UWP stuff too now, I just don’t have any experience with it, but you could check out what SDL does if you’re curious. If you’re targeting Windows though then C++ is always an option and has good interoperability with C, and you can still keep the majority of your codebase as ordinary C in either case. Many Win32 APIs also work fine in UWP.

  • M . 0

    You have no idea how happy it makes me to know that you watch Red Letter Media and that you’re a trekkie :’)

Feedback usabilla icon