Remember Windows Recall, the Windows feature that would take a screenshot of your desktop every three seconds, stored them in a database, and then let you search through them at later dates? The feature has been hobbled by implementation problems, security issues, and privacy troubles, and has been released in preview and pulled since its original unveiling. Well, it’s back in testing now for users of the Release Preview Channel.

As you use your Copilot+ PC throughout the day working on documents or presentations, taking video calls, and context switching across activities, Recall will take regular snapshots and help you find things faster and easier. When you need to find or get back to something you’ve done previously, open Recall and authenticate with Windows Hello.

↫ Windows Insider blog

The “AI” magic (meaning, OCR and image recognition, but with sparkles) runs locally, on device, and supposedly, the collected screenshots and data extracted from them never leave your device – at least, for now. The tech industry has a long history of relegating its promises, so excuse me if I don’t have a ton of faith in this data remaining on a Windows PC for too long into the future.

Case in point, a related Windows Copilot feature: Copilot Vision. This is very similar to Windows Recall, but instead of taking automating screenshots every few seconds, you can invoke it manually so that Copilot will “read” the current contents of your desktop, applications, and so on, allowing you to ask questions, get help, and so on. The kicker, however, is that while the screenshots and resulting data from Recall supposedly remains on your machine, whatever Copilot Vision does is done on Microsoft’s servers. In other words, a feature very similar to Windows Recall is already sending your personal, private data to Microsoft.

I’m sorry, but I just don’t think Windows Recall will remain “on-device” for very long. The temptation to hoover that data up into the giant advertising machine is too great, and there’s no way in hell Microsoft will be able to resist it.

Yesterday we had SDL2 for the classic Mac OS, today we have modern SSL/TLS for the classic Mac OS.

This is a C89/C90 port of MbedTLS for Mac System 7/8/9. It works, and compiles under Metrowerks Codewarrior Pro 4.

This is a basic app that performs a GET request on whatever is in api.h, and prints the result out to the text box (with a lot of debug information, of course). The idea of this project was to build an ‘app’ of sorts for 640by480, my ‘instagram clone for vintage digital cameras’. The idea would be to login, post images, view images, and read comments. I would need HTTPS for that, so here we are: a port of MbedTLS for the classic mac.

↫ MacSSL GitHub page

It’s remarkable what tenacity can achieve.

Well, this you certainly don’t see every day.

This is a “rough draft” of SDL2 for MacOS 9, using CodeWarrior Pro 6 and 7. Enough was done to get it building in CW, and the start of a “macosclassic” video driver was created. It DOES seem to basically work, but much still needs to be done. Event handling is just enough to handling Command-Q, there is no audio, etc etc etc.

↫ A cast of thousands

The hardest part was a video driver for the classic Mac OS, which had to be created mostly from scratch using the QNX driver as a “skeleton” because it happened to be the smallest one. It works on both m68k and PowerPC as well as on SheepShaver and Basilisk II, and there’s already a few screenshots of it up and running at the link, too. Amazing work, and it opens the door for a whole bunch of especially games to be made available on classic Mac OS.

This month’s security updates for Windows 11 create a new empty folder on drive C. It is called “inetpub,” and it does not contain any extra folders or files. Its properties window shows 0 bytes in size and that it was created by the system itself. Neowin checked a bunch of Windows 11 PCs with the April 2025 security updates installed, and all of them had inetpub on drive C.

↫ Taras Buria at Neowin

So this folder, inetpub, is most likely coming from Microsoft’s Internet Information Services, the company’s web server. IIS is part of Windows, but inactive by default, and it seems some buggy update script somewhere forgot to remove the folder or created it by accident. Regardless, it seems you can remove it without any issue, so if you see it on your Windows’ root drive, just delete it any be on your merry way.

Still though, something about this seems odd, right? Internet Information Services as a core product hasn’t been updated since 2018 when version 10 came out, which doesn’t necessarily mean specific Windows updates might not have changed it since then, but it doesn’t exactly inspire confidence. The Internet Information Services’ website also hasn’t been updated in ages, and is broken in places, further adding to the feeling IIS seems to be mostly abandoned, only kept going as part of Windows updates because it’s, well, part of Windows.

I’m not trying to insinuate there’s anything nefarious or dangerous going on with this silly folder glitch or anything; I was just surprised to see such an outdated, seemingly abandoned web server suite still being a default part of Windows today.

With FreeDOS being, well, DOS, you’d think there wasn’t much point in putting out major releases and making big changes, and you’d mostly be right. However, being a DOS clone doesn’t mean there isn’t room for improvement within the confines of the various parts and tools that make up DOS, and that’s exactly where FreeDOS focuses its attention. FreeDOS 1.4 comes about three years after 1.3.

This version includes an updated FreeCOM, Install program, and HTML Help system. This also includes improvements to many of the utilities including FDISK, JEMM, 7Zip, FORMAT, FASM, MORE, RUNTIME, and more!

↫ FreeDOS website

If you’re using FreeDOS, you’re most likely doing so for a highly specialised task, and racing to upgrade isn’t exactly high on your list of priorities. Still, it’s great to see FreeDOS moving forward and improving where it can.

Remember when Qualcomm promised Linux would be a first-tier platform alongside Windows for its Snapdragon X Elite, almost a year ago now? Well, the Snapdragon X laptop have been out in the market for a while running Windows, but Linux support is still a complete crapshoot, despite the lofty promises by Qualcomm. Tuxedo, a European Linux OEM who promised to ship a Snapdragon X laptop running Linux, has posted an update on its progress, and it’s not looking good.

While Tuxedo did reach a major milestone last week by sending the laptop’s device tree to the LKML, that’s where the good news ends.

The next step is to support additional components of the ARM notebook within the device tree. This includes all USB functionalities, including USB4, external monitor connectivity via HDMI, and audio features, such as the headset jack. Additionally, driver testing is on the agenda. Unfortunately, a planned collaboration with Qualcomm, the manufacturer of the Snapdragon X Elite, did not materialize. However, we are in contact with the ARM specialists at Linaro and have sent test devices to them. We hope to receive valuable feedback from their developers and the community in the near future.

↫ Tuxedo’s website

This seems to indicate that Qualcomm isn’t as interested in Linux support after all, which may be because the Snapdragon X machines haven’t exactly taken over the laptop market as Microsoft and Qualcomm had hoped. The market for these things is probably not large enough for Qualcomm to justify investing in Linux support, especially when Windows on ARM is apparently not up to snuff yet either.

In case you are unaware of why device trees are such a big thing in ARM land, it’s because ARM devices do not have a nice ACPI table for operating systems to read system information from. Whereas x86 devices have their hardware components laid out in a nice ACPI table in UEFI, ARM devices do not, meaning that the Linux kernel needs to know specifically which device you’re using so it can load the correct device tree. On x86, this isn’t necessary, as the Linux kernel can just read the ACPI table, which works 99% of the time to get it to boot, even if specific components might not be supported (yet). On ARM, without a device tree, the Linux kernel doesn’t know what to do.

That’s one of the major reasons why it’s so hard for ARM to take off in the same way x86 once did. It’s just not designed to be infinitely intercompatible and interoperable as we’ve come to expect from the x86 world, and I don’t think anybody has any vested interest in changing that. I had hoped Microsoft might throw its weight around here, but it seems that’s not happening either.

The ARM desktop/laptop revolution seems mostly confined to Apple for now.

Software gets more complicated. All of this complexity is there for a reason. But what happened to specializing? When a house is being built, tons of people are involved: architects, civil engineers, plumbers, electricians, bricklayers, interior designers, roofers, surveyors, pavers, you name it. You don’t expect a single person, or even a whole single company, to be able to do all of those.

↫ Vitor M. de Sousa Pereira

I’ve always found that software development gets a ton of special treatment and leeway in quality expectations, and this has allowed the kind of stuff the linked article is writing about to become the norm. Corporations can demand so much from developers and programmers to the point where expecting quality is wholly unreasonable, because there’s basically no consequences for delivering a shit product. Bugs, crashes, security issues, lack of documentation, horrid localisation – it’s all par for the course in software, yet we would not tolerate any of that in almost any other type of product.

While I’m sure some of this can be attributed to developers themselves, most of it seems to stem from incompetent managers imposing impossible deadlines downwards and setting unrealistic expectations upwards – you know, kick down, lick up – creating a perfect storm of incompetence. We all know it, we all experience it every day, and we all hate it – but we’ve just accepted it. As consumers, as developers, as regulatory bodies.

It’s too late to fix this now. Software development will forever exist as a sort of no man’s land of quality expectations, free from regulations, warranties, and consumer protections, and imposing them now after the fact is never going to be accepted by the industry and won’t ever make it through any lawmaking process of any country, and we all suffer from it, both as users of software and as makers of it.

Apple’s Darwin operating system is the Unix-like core underpinning macOS, iOS, and all of Apple’s modern OS platforms. At its heart lies the XNU kernel – an acronym humorously standing for “X is Not Unix.” XNU is a unique hybrid kernel that combines a Mach microkernel core with components of BSD Unix. This design inherits the rich legacy of Mach (originating from 1980s microkernel research) and the robust stability and POSIX compliance of BSD. The result is a kernel architecture that balances modularity and performance by blending microkernel message-passing techniques with a monolithic Unix kernel structure. We’ll go through a chronological exploration of Darwin and XNU’s evolution – from Mach and BSD origins to the modern kernel features in macOS on Apple Silicon and iOS on iPhones. We’ll follow this with a deep dive into the architectural milestones, analyze XNU’s internal design (Mach-BSD interaction, IPC, scheduling, memory management, virtualization), and examine how the kernel and key user-space components have adapted to new devices and requirements over time.

↫ Tanuj Ravi Rao

Despite its popularity and open source kernel, it’s quite rare to see detailed deep-dives into the underpinnings of macOS. It always surprised me that nobody took whatever Apple threw across the fence every macOS release and ran with it – much further than “run existing open source desktops but worse” we never got when it comes to Darwin distributions (although this might change) – so perhaps having more approachable articles like these out and about get people interested.

Good news for Windows users, and for once there’s not a hint of sarcasm here: Microsoft has started rolling out Windows Hotpatch to the client versions of Windows. This feature, which comes from the server versions of Windows, allows the operating system to install patches to in-memory processes, removing the need for a number of restarts. Obviously, this is hugely beneficial for users, as they won’t have to deal with constant reboots whenever a new bunch of Windows updates are pushed.

There are some limitations and other things you should know. First, the way the system works is that every quarter, installations with Hotpatch enabled will receive a quarterly baseline update that requires a reboot, followed by two months of hotpatches which do not require a reboot. Hotpatches can only be security updates; new features and enhancements are rolled up into the quarterly baseline updates. In other words, while this will not completely eliminate reboots, it will cut the number of reboots per year down from twelve to just four, which is substantial, and very welcome in especially corporate environments.

The biggest limitation, however, is that Windows Hotpatch will only make it to one client version of Windows, Enterprise version 24H2, so users of the Home or Professional version are out of luck for now. On top of that, you’re going to need a Microsoft subscription, use Microsoft Intune, and an Intel/AMD-based system (Hotpatch will come to ARM later). I hope it’ll make its way to Windows 11 Home and Professional, too, because I’m fairly sure quite a few of you using Windows would love to set this up on your own machines.

This question was asked during my Boot Camp presentation last fall in Boston, and over the past 35 years dozens of times people have asked, how big is VMS? That translates into “how many lines of code are in VMS”? I thought it was time to at least make a stab at pursuing some insight into the answer. I wrote some command procedures to count the number of source lines in .B32, .B64, .C, .MAR, .M64, and .S files. Not counted are blank lines and lines beginning with the standard comment characters and miscellaneous directives for the particular language.

↫ Clair Grant

As always with the ‘lines of code’ metric, there’s some real arbitrariness going on, and in this case that means things like excluding networking, which to me seems like a core part of an operating system, but alas, choices need to be made. The final tally for lines of code, as per the definition used in the article, in the most recent version of OpenVMS, version 9.2-3, is almost 1.9 million. Do with that information as you please.

What’s really fascinating, though, are the deltas between the versions investigated in this article: V6.2 (May 1995, port to Alpha), V7.2 (February 1999, kernel threads, 64-bit APIs, Galaxy, and more), V8.2 (February 2005, port to Itanium), V9.2-3 (december 2024, port to x86). Going from one version to the next, roughly 400000 lines of code were added each time – the article doesn’t theorise about the consistency of this number, and I suspect it’s mostly just a fun coincidence, but it does jump out.

The AlphaStation 500 is a workstation from Digital, circa 1996. Mine is a 500 MHz model and has an Alpha 21164A processor (aka EV56). And the way it boots is weird.

On your common-or-garden PC, there has always been some kind of ROM chip. It holds a piece of firmware known as the BIOS. This ROM chip is available at a well-known location in the processor’s address space (remembering that any PC processor boots up in 16-bit, 8088 compatible mode, with a 1 MiB address space, just like an IBM PC 5150) and the processor just starts executing code in it after reset.

The Alpha (or at least this AlphaStation 500 – although I think they mostly worked like this) is different.

↫ Jonathan ‘theJPster’ Pallant

A great read, but a little bit over my head considering I’m anything but a programmer or developer. Still, even I managed to get the basic gist and learn quite a bit from this article, and especially the part about how the AlphaStation uses a little jumper to tell the SROM exactly which stream of boot code to send to the processor is fascinating. I’m not sure just how unusual the Alpha’s way of booting is, but I’d at least never heard of it.

There isn’t a lot to this story beyond the fact that in around 1990 I helped debug someone’s Lotus 1-2-3 set up via fax. But it’s a good reminder of how important the Zeroth Law of Debugging is (see below).

Without some sort of online connection with these folks, and with transatlantic phone calls being very, very expensive (I was in the UK, they were in the US) fax was the obvious answer.

↫ John Graham

Honestly, this would still be easier today than some of the bug reporting systems I’ve seen.

Right off the bat, there is not that much use for a Pixel Watch with Windows on it. The project, as the maker says, is for “shits and giggles” and more like an April Fool’s joke. However, it shows how capable modern smartwatches are, with the Pixel Watch 3 being powered by a processor with four ARM Cortex A53 cores, 2GB of DDR4X memory, and 32GB of storage.

Getting Windows to run on Gustave’s arm, as you can imagine, took some time and effort of inspecting a rooted boot image, modifying the stock UEFI to run custom UEFI, editing the ACPI table, and patching plenty of other files. The result of all that is a Pixel Watch 3 with Windows PE.

↫ Taras Buria at Neowin

More of this sort of nonsense, please. This is such a great idea, especially because it’s so utterly useless and pointless. However pointless it may be, though, it does show that Windows on ARM is remarkably flexible, as it’s been ported to a variety of ARM devices it should never be supposed to run on. With Microsoft’s renewed entry into the ARM world with Windows on ARM and Qualcomm, I would’ve hoped for more standardisation in the ARM space to bring it closer to the widely compatible world of x86.

That, sadly, has not yet happened, and I doubt it ever will – it seems like ARM is already too big of a fragmented mess to be consolidated for easy portability for operating systems. Instead, individual crazy awesome people have to manually port Windows to other ARM variants, and that, while cool projects, is kind of sad.

FreeDOS is a free and open‐source operating system designed to be compatible with MS‑DOS. Developed to keep the DOS experience alive even after Microsoft ended support for MS‑DOS, FreeDOS has grown into a complete environment that not only preserves classic DOS functionality but also introduces modern enhancements. Its simplicity and low resource requirements have made it a cherished resource for retro computing enthusiasts and a practical tool for embedded systems and legacy hardware.

↫ André Machado

A short but useful overview of what FreeDOS is. One of my favourite stories about FreeDOS will always be not just that HP offered it as an option on some of its laptops – supposedly because it couldn’t sell laptops without an operating system preinstalled – but also just how convoluted this preinstalled copy of FreeDOS was set up. They shipped several FreeDOS virtual machines on top of a minimal installation of Debian, in a complex web of operating systems and VMs.