Author: Al Williams

4504 Articles

A Brief History Of Unix Commands On Windows: CoreUtils (Again)

June 16, 2026 by 13 Comments

If you use Windows today and type ls, cat, grep, or awk in a terminal, there is a good chance something useful will happen. That was not always true. For most of the history of personal computing, Unix/Linux and Windows lived on opposite sides of a cultural border. Unix people had pipes, small composable tools, shell scripts, make, sed, awk, grep, tar, and the idea that everything was a file. Windows people had drive letters, backslashes, COMMAND.COM or cmd.exe, and an API that did not care much about what POSIX thought.

Yet there has always been a demand for Unix tools on Windows. Some of it came from programmers who wanted the same build scripts everywhere. Some came from administrators who missed grep and awk. Some came from companies trying to port big Unix applications to NT without rewriting them all. The result is a long, strange history of Unix-on-Windows layers, toolkits, compromises, and almost-but-not-quite compatibility.

Easy?

The simplest version of the problem sounds trivial. How hard can cat be? Open a file, copy bytes to standard output, done. Writing ls is a little more work, but Windows has directory APIs. Common commands like cp, mv, rm, mkdir are not very mysterious. Even pipes are not foreign to Windows. A lot of the everyday Unix command set can be ported as ordinary Win32 console programs with some path handling and enough patience.

But not all of Unix or Linux translates cleanly to Windows. The big issue is fork(). On Unix, a process can clone itself. The child gets a copy of the parent’s address space, open file descriptors, environment, signal state, and so on. Modern kernels make this efficient with copy-on-write memory, but the programming model is old and deeply baked into Unix. Shells use it constantly. Servers use it. Build systems use it. Scripting languages assume it exists, or at least that the surrounding environment behaves as though it does.

Windows process creation is different. Windows has CreateProcess(), which starts a new program. That is a perfectly reasonable model, but it is not fork() (more like fork()+exec()). If you are just launching notepad.exe, no problem. If you are trying to implement a POSIX shell that forks, redirects file descriptors, adjusts the environment, and then starts another program, the mismatch is extreme and you’ll have to do some strange things to fake things out.

One of the early commercial answers was the MKS Toolkit, originally from Mortice Kern Systems. MKS gave Windows users a pile of familiar commands, shells, and development tools. It was not just ls and friends; it included things like ksh, vi, grep, find, awk, make, and many of the utilities needed to move scripts and build procedures between Unix and Windows. The current PTC MKS documentation still describes it in exactly that spirit: Unix shells and hundreds of commands for interoperability with Windows.

MKS was attractive because it treated Windows as Windows. You were not necessarily pretending your machine was a Unix workstation. You were getting a Unix-flavored toolbox that could operate in a Windows environment. For many people, that was enough. You could write scripts, process text, drive builds, and avoid learning three different syntaxes for the same job.

Continue reading “A Brief History Of Unix Commands On Windows: CoreUtils (Again)” →

Picking A CRC

June 15, 2026 by 34 Comments

You send a file, but how do you know it arrived intact? In other words, how do you know that it didn’t get cut off, garbled, or changed somehow? Simplistically, you could just add up all the bytes in the file — a checksum — and send that along with the file. You compute the checksum when you know the file is good, and the receiver can compare the checksum to see if they match.

However, a simple addition doesn’t catch certain classes of errors, which is why there are better checksum algorithms that, for example, wrap the carry bit around or otherwise modify files with common errors so they produce different checksums. There are two problems with checksums. First, no matter how much you modify the algorithm, the chances that two files produce the same checksum are pretty high. Especially with common error patterns.

For example, assume a very simple algorithm that simply adds the bytes and discards any carry. If a file contains 0x80, 0x80, those numbers essentially cancel each other out. If you replace them with 0, 0, you’ll get the same checksum. To some degree, using anything other than a second copy of the entire file will have this problem — some corruption goes undetected — but you want to minimize the number of times that happens.

The other problem is that a checksum by itself doesn’t let you correct anything. You know the data is bad, but you don’t know why. If you think about it, the simplest checksum is a parity bit on a byte: odd parity is simply summing all the bits together. If the parity bit doesn’t match, you know the byte is bad, but you don’t know why. Any even number of errors goes undetected, but I am sure one-, three-, five-, or seven-bit errors will get caught.

People invent better error-checking codes by devising schemes that can promise they can detect a certain number of bit flips and, at least in some cases, correct them. One of these is the cyclic redundancy check (CRC). It is easy to think of the CRC as a “strong checksum,” but it actually works differently. What’s more, there isn’t just a single CRC algorithm. You have to select or design a particular algorithm based on your needs. Most people pick a “named” implementation like CCITT or Ethernet and assume it must be the best. It probably isn’t.

A CRC is a checksum in the broad sense: you feed it a message, and it gives you a small value that you append, store, or compare later. But unlike a simple additive checksum, a CRC is based on polynomial division over GF(2), which is a fancy way of saying “divide using XOR instead of carries.” That detail matters. It gives CRCs very strong guarantees against common classes of errors, provided you choose the right polynomial for the job. That’s the key. You must choose the right polynomial.

Continue reading “Picking A CRC” →

The Pacemaker Patch

June 13, 2026 by 36 Comments

A pacemaker is implanted to send signals that regulate a patient’s heartbeat, and to do that, you need power. That means they require battery changes, and when the device in question happens to be inside your chest, that means surgery. Sometimes as often as every five years. [Alex Music] writing in Spectrum notes that researchers have a new paper discussing a possible alternative: a tiny patch stuck to the outside of the chest that uses ultrasound to pace the heart rhythm.

Rats, pigs, and human heart cell samples have all responded to the system. You might wonder how ultrasound could make your heart beat, but the new pacemaker relies on gene therapy to sensitize your heart cells to the high-frequency waves. The therapy is delivered by a simple injection.

In addition to the chest patch, the patient would need a data and power module that they could keep in their pocket. The gene therapy doesn’t alter your DNA but introduces RNA to make heart cells produce a sound-sensitive protein in the cell’s ion channels. When stimulated, the ion channels admit calcium, which causes the heart to beat.

Pacemakers are nothing less than a modern technological marvel. Maybe if this catches on, cheap junked pacemakers will show up on the surplus market. They could be useful.

Custom Watch Is On The Case

June 13, 2026 by 11 Comments

We were excited to see [Z0hn]’s project about 3D printing a custom watch from scratch — both because it was an exciting idea, and because the pictures looked great. While we still liked the project, we quickly realized it wasn’t really printing a watch so much as it was printing a case that holds an off-the-shelf movement. But it still looked great.

Many homebrew watches are cool and fine to wear to your next hackerspace board meeting. But this watch wouldn’t raise an eyebrow out among the normal public. Conventional watches use press-fit backs, tiny screws, or make the back screw into the housing. None of those are great for 3D printing, so this watch uses a bayonet connector, which is easy to create, robust, and reliable.

The watch looks easy to modify, so if you don’t like, for example, the unusual crown placement, you can change it. The movement is a Miyota 8N24 and, of course, the crystal is off-the-shelf, too.

While not exactly a printed watch, it was still pretty cool, and there are lessons to be learned here if you want to pull off the same feat. Or just go full on hacker. You could, too, try your hand with an open source movement.

Homebrew Macropad Looks Good

June 12, 2026 by No comments

We are fans of macro pads and especially homebrew ones. The Apna Dost project by [np_vishwakarma] ticks most of our boxes. In addition to a few buttons, there’s an encoder, an OLED display, and it runs QMK firmware. Plus, it looks good, too.

We like that the system uses an RP2040. It is possible you have everything you need to put one of these together right now. We would wish for a few more keys, but it wouldn’t be hard to add them, either.

Continue reading “Homebrew Macropad Looks Good” →

The Air Position Indicator For The B-29

June 12, 2026 by 24 Comments

When you think of a computer, you probably don’t think of a tube full of motors and mechanics. However, as [Our Own Devices] shows, the Bendix AN5841 API Computer, an air position indicator computer, is exactly that. Using mechanical integrators and data from other analog systems on an airplane to provide key flight data to a pilot. You can see the video below.

These devices were made for military aircraft, including the B-29. It is odd that speed data can be derived from a pump that balances pressures using a fan. The video does a good job of explaining exactly how that works.

Continue reading “The Air Position Indicator For The B-29” →

A Peek Inside The Secret Lagercrantz Suitcase Radio

June 12, 2026 by 7 Comments

What counts as portable is somewhat a matter of opinion, especially over the years. [Helge Fykse] has a portable spy radio of Swedish origin. For its time, it was considered very portable, crammed into a good-sized suitcase.

You can see the large crystal that sets the transmit frequency and a key to send Morse code. The receiver has a VFO, so it was more agile. Based on the regenerative knob, it appears the receiver was of the regenerative type. The suitcase had its own battery, and with tubes, it could probably put out some kind of signal if connected to anything metal, like bedsprings, a clothesline, or anything. There was a lightbulb to let you see when you were transmitting maximum power.

Speaking of tubes, there were five inside, two for the transmitter and three for the receiver. The radio had storage for spare tubes, and the agent could maintain the radio in the field.

You not only get a peek inside the suitcase, but a look at the schematic. The radio is a model of simplicity, but we are certain it did its job.

We love looking at exotic spy gear, especially radios.

Continue reading “A Peek Inside The Secret Lagercrantz Suitcase Radio” →