Your Bluetooth is bad, August 2026 (Battery and Name)

 Your Bluetooth is bad, and you should feel bad

Alternate title: Your Bluetooth is OK, but it could be better

 Just two gripes this time!

Always include a name. 

I'm looking at you, Ruuvi. The Ruuvi sensors are interesting little devices. They started out back when the Eddystone protocol was an exciting new thing (fun fact: Copilot thinks there are still major Eddystone devices in the real world!), then made essentially the same sensors but with their own advertising format. And the Ruuvi company includes good documentation on their GitHub!

But ... why don't the tags advertise their names? Normally the way my app can tell one device from another is just from the name (and so far, without any overlaps) or for standard devices like Bike sensors, from the services exposed. Now I have to paw deep into every advertising packet just to see if an advert might be from a Ruuvi.

Use battery percentages, not voltages

Providing a battery voltage and not a percent, IMHO, is just weaseling your way out of a small bit of analysis. And it's an analysis that you, the maker, can do best.

There is no user out there who wants to know that the battery is at 2.45 volts. But everyone wants to know if the battery is running low. You can either do a conversion in your app, or you can just do the conversion on the device.

Not only that, but end users just expect a "ballpark" figure. This is confirmed by Microsoft, which expects devices to provide 11 steps (0..100% in 10% steps including the 0 and 100), and by the Bluetooth SIG which made the standardized battery levels.

API Rules for designers: use one encoding, not two

 

API Rules for designers: use one encoding, not two

 

"If you haven't tested your code, it's probably wrong"

 

Today's bad API example is from the Bluetooth Heart Rate system. Most of the protocol is fine: you get a notification every so often with updated heart rate information (e.g.,  heart rate in beats per minutes (BPM) plus optional stuff for overall energy and the "RR Interval" for fine-grained heart data).

 

Testing this protocol is extra expensive because the heart rate (BPM) can be sent in two ways. It might be a single byte, and it might be two bytes. There's a single bit in a flags structure to say which way it is. If the person's heart is 255 BPM or less, it's one byte. If it's 256 or more, it's two bytes. The app code (and device code) has to handle this.

 

For an app, the code is hard to test for two reasons. Most importantly, a human doesn't ever have a heart rate that high (according to Copilot, "255+ BPM is possible, but it’s always pathological"). The second is that even if I could find a person with a heart rate that high, I have no confidence that any specific consumer-grade device will ever produce this data. As just a person coding in their spare time, I can buy a couple of heart monitors. But imagine I still worked at Microsoft: what are the changes that a VP (that's the clearance it takes for approving purchases) would sign off on an unknown number of devices on the chance that one of them would produce this data?

 

In the end, I've got code in my new Bluetooth app (not on the Microsoft app store yet) to handle the special flag. But my confidence that it works isn't great.

 

The right API choice was to always send 2 bytes of data and not try to make something in the name of spurious efficiency.

 

For the nay-sayers: the awkward protocol doesn't support any interesting new scenarios, and doesn't have any appreciable amount of energy.

 

If they had kept the protocol as-is, developers would have the same abilities. The RR Interval data size would shrink from 9 entries to 8 -- but in typical use, there's only 3 or 4 entries. And if there's a case for needing more than 8 entries, the Bluetooth device could simply transmit more often.

 

Takeaway: Protocol designers should always include "how will a developer test their code" when considering complicated APIs.

 

IL2104 IL2026 TRIM and JSON with WinUI3 and newer C#

 JSON: why is C# TRIM so horrible for no reason 

Trim analysis warning IL2026: SerializeExtra.Demonstrate_Bug_Program.Demonstrate_Bug_Main(): Using member 'System.Text.Json.JsonSerializer.Serialize(!!0, JsonSerializerOptions)' which has 'RequiresUnreferencedCodeAttribute' can break functionality when trimming application code. JSON serialization and deserialization might require types that cannot be statically analyzed. Use the overload that takes a JsonTypeInfo or JsonSerializerContext, or make sure all of the required types are preserved.

In the old days, C# had a simple JSON story: always use the Newtonsoft JSON library, helpfully packaged up in NuGet, and never use anything else, ever. But then I tried making an app with WinUI3 and the more recent C# (like version 10?), and now it completely sucks, and it's ten times harder than it should be. And it's all Microsoft's fault

C# introduced a new concept: TRIM. This is a link time option. It's on by default for Release mode and off by default for Debug mode. What it does it go through your app and removes all of the "unneeded" code. The problem is that it means that the normal way Newtonsoft's JSON works doesn't work; it will just plain crash.

Note the horrific discovery mechanism for this, by the way: there you are, coding happily in a shiny new app, using shiny new features, and a switch you didn't set causes weird-ass warnings when you compile, and then your app crashes, but only when you're almost done and are now testing in Release mode.

The only solution is to switch to the System.Text.Json.JsonSerializer and Deserializer classes. But even these are completely broken with the new switch, and delightfully (sarcasm) the official Microsoft documentation guides you right into the absolute wrong way to use them.

Worse, the C# classes also guide you into the wrong way. Those shiny new templated classes? Those won't work at all.

Luckily, I've researched it so you can just jump right into the pit of success.

• When you make your SourceGenerationContext from JsonSerializerContext, always add a TypeInfoPropertyName option 
• When you call Serialize of Deserialize, you must use the non-templated versions. Pass in your object (or string, for deserialize), the typeof(yourclass) and your SourceGenerationContext.Default object. 
• Never new up a SourceGenerationContext object. When you do, it won't have the JsonSourceGenerationOptions that the Microsoft docs tell you to use
• Always specify a [JsonSourceGenerationOptions(WriteIndented = true)]. If you wanted a compressed serialization format, you'd have used Protocol Buffers, not JSON. When you use JSON, it's because your users want a human readable result, not some one-line nonsense.

See my complete project on Github for more details. The About file is particularly helpful. Look at the WeatherForecast_Fix1.cs file for full details. The bug is reported to Microsoft .NET team.

Weird EPUB bug: empty image files in the IRS i1040gi.epub file

This EPUB bug brought to you by the IRS and their i1040gi.epub file

Normally government EPUB files are pretty good about making usable EPUB files. But this year only, the IRS's "i1040gi.epub" file (the file with USA government tax information for filing out the very common 1040 tax form) has a subtly malformed epub file. The list of images (EPUB/img) has 28 GIF files which are all fine, and one JPG file (cover-instr-i1040.jpg) which is zero bytes long.

This file fails to load correctly which leads to a cascade of errors.

Solution is to catch the error and silently ignore it. (Technically, I first check for zero-byte files and ignore it, and also catch the exception and ignore it. Both branches were tested, of course)

Developing on ARM64: DEP0700 failures in Debug mode

Can you solve this error message? 

DEP0700: Registration of the app failed. [0x80073CF3] Windows cannot install package NAME because this package depends on a framework that could not be found. Provide the framework "Microsoft.VCLibs.140.00.Debug.UWPDesktop" published by "CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US", with neutral or ARM64 processor architecture and minimum version 14.0.33728.0, along with this package to install.

Background: building an existing UWP app on ARM machine

I have one of the ARM64 machines that Microsoft is big on, and of course I have a bunch of existing app (Store link). So what better thing to do than to enjoy a nice coffee in a fancy lodge here in the pacific northwest while updating the Bluetooth app to support a new device?

Except you can't deploy your debug-mode ARM64 app! It fails with the above error! 

What's do the might search engines say?

Search engines recommend the following three things:

<Dependencies>
<PackageDependency Name="Microsoft.VCLibs.140.00.UWPDesktop" MinVersion="14.0.24217.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />

</Dependencies>

Or this:

<RequiredBundles>$(RequiredBundles);Microsoft.VisualStudio.Component.UWP.VC.ARM64</RequiredBundles>

Or updating the user's .VSCODE profile. None of these work

Crappy solution found! Just run in x86 mode!

The crappy solution I eventually tried: just run in x86 mode instead of ARM64 mode. Sure, it's a waste of processor time and effort, and sure, it's a stunning indictment of Microsoft's absolute failure to actually support their own freaking devices, but it got me moving forward.

EPUB format thoughts

 How hard can EPUB files be?

"EPUB is just HTML"! Hah!

I've got a fun EPUB ebook reader in the store; it's got two nifty features that, IMHO, all ebook readers should have (it can do an offline search of Project Gutenberg, and it's got a two-screen mode, so you can see both a critical image and the text that talks about the image in one spot).

Over the years, I've had to work around a lot of EPUB failures. Today's failure is thanks to the newer EPUB books that Project Gutenberg publishes.

Notably, each book seems to include a (pointless) <pre/> tag. The problem with that tag is that HTML does not support self-closing (void) elements. The Mozilla pages are super clear about that.

So my HTML renderer (which is just a WebView element) takes the <pre/> tag and reads it HTML style, like a <pre> tag that isn't closed. The entire rest of the book, which is most of it, is then displayed with pre-formatted lines. Because pre-formatted lines don't wrap (that's the point of the <pre> tag, the rest of the reading experience is mostly ruined.

SIGH. 

WTF is “Exact time 256” : diving into Bluetooth SIG documents

 

WTF is “Exact time 256”    

The Bluetooth Special Interest Group (SIG) has a metric ton of Bluetooth LE device specs in a massively confusing pile. In this walkthrough I’ll show how I figured out the details of a fairly simple LE protocol. In particular, I’ll be creating something that needs to match the “Current Time Service”, services # 0x1805.

TL/DR: the good document is the “Gatt Specification Supplement”.

On the Bluetooth.com site, you want “Specifications” and under specification you’ll need a tab open for both the “Assigned numbers” and the “Specifications” directory.

In “Assigned numbers”, there’s two important documents. The first is “Assigned Numbers Document”. It’s a giant list of all of the GATT services by name and all of the characteristics. The second is “Gatt Specification Supplement”.

In the “Specifications” directory, find the listing for the "Current Time Service” and click the link to get the service page. It's got a bunch of the lest useful programming documents ever. The only document that’s interesting for most developers is the Current Time Service 1.1 PDF file. Click the link to read the long, complicated document.

Page 9 starts to be interesting: the Current Time Service supports three characteristics: the “Current Time” (page 10), “Local Time”, and “reference Time”. On page 10 it’s mentioned that we’ll be reading the Exact Time 256 field. This is the first bit of useful (and critical) information in the spec.

BTW, when they say “Unknown”, it’s not clear to me which “Unknown” value they mean. But in the Assigned Numbers document there are 8 time that “Unknown” is mentioned; all of the numeric values (6 of them) are zero. The others are weird strings for something having to do with telegrams. Or not, it’s a Bluetooth SIG spec, so nothing is clear.

At this point you might wonder what the actual bytes are. The Bluetooth SIG doesn’t care that you’re wondering. You might even try typing “Exact Time 256” into the main page search box on the main page, but you won’t get any hits. However, you can find it in the Assigned numbers where it has number 0x2A0C in the “Characteristics by name” and “Characteristics by UUID” section.

Note that in the “Specifications” it lists “Current Time” as the characteristic; that’s characteristic 0x2A2B.

And then finally, take a look at the GATT Specification Supplement, page 78, section 3.62, “Current Time”. It lists the bytes: there’s an Exact Time 256 and then a U8 “Adjust Reason” which says why the time changed. Even better, there's a decent overview of the Exact Time 256 fields!

And here the path through the forest of all Bluetooth knowledge ends. If only there was some way to know that the "supplement" is in fact the useful document, and not the pile of other docs.

History: writing fancy code on a plain compiler (Irix version)

 Writing fancy code on a plain compiler

This is a story of porting C++ code using all the latest features to a machine whose compiler was (ahem) definitely not supportive of advanced features :-/

Back in about 1997 and 1998 I was a software consultant and got hired by an old coworker at Avid to help them port their shiny new high-performance file-copying software to the Irix. IIRC, they had written it in “portable” C++ which I discovered was anything but ☹

Writing code with no strings attached

 Amongst the other delights of 1997 era SGI workstations: SGI was a leader in creating the C++ STL. But the SGI people really, really didn’t like the proposed STL string types, so they just … didn’t. One of the many, many steps on my journey to porting this code was to create enough of a string class to compile.

 Other issues were that vector<> wasn’t compatible either, so I had some lovely #ifdef’s in the code.

What's in a namespace? Nothing. 

 The compiler also didn’t handle namespaces; they were read in an ignored. For most code this was a minor inconvenience, but the people writing this “portable” C++ code were a different breed. They had many, many classes with the same name and similar but different functionality. My solution was to create enough of a C++ “parser” to re-write the code. Turns out that if you ignore enough of the rules, you can make a C++ parser with just Lex 😊

Exceptionally fine threading

 But the absolute worst part was that the “portable” C++ code used both multiple threads (typical for networking code) and exceptions (still a new thing). The SGI compiler (which was the only compiler – I did a thorough look to find anybody else with a compiler) could handle threads, and could handle exceptions, but created incorrect binaries when dealing with both. And it didn’t matter if you threw any exceptions; the generated code was wrong regardless.

 My simple solution was to note that every single exception was uniformly caught exactly one level higher, and that none of their code ever returned a value. So I just made the exception-throwing methods return a value, instead. Simple, quick to implement and IMHO made the code a little nicer looking. This solution was rejected.

 The alternative solution was to use processes instead of threads. A “thread spawn” became a “process spawn”. And not just a process spawn: a process spawn all of the processes sharing their C++ memory so the data structures should be shared (and mutually updated, meaning using cross-process mutexes).

 This was an unglodly heavyweight project. But the pay was very nice.

TL/DR

 Moral of the story: never outrun your compiler?

Your Bluetooth is bad, January 2023 edition

 Your Bluetooth protocol is bad, January 2023

I've finally gotten over a big hump in my Bluetooth Device Controller program -- I've been poking around with adding and fiddling with devices, and that means that the code has been getting much more "experimental". That's not a good thing for an app that I ship, and which has over 35 thousand downloads! I've been working hard to convert the experimental code into an app that people can use without too much frustration.

With that, it's on to the next installment of this series on crappy Bluetooth protocols, focused on the Govee line of air sensors. The version 1.10 app supports the Govee 5074; the next version (presumably 1.11) will support the 5075 and 5106. All of them suffer from the same three flaws, and the 5106 has a unique and fun new flaw.

Don't shut off communications too early. All of the Govee devices like to shut down their Bluetooth connections really fast -- after about 4 seconds, they shut down the connection even if you've been talking on it. Other devices will wait until the connection has no traffic before shutting down.

Just transmit your freaking data. If you provide data, just provide it: make a characteristic, and make it readable and notifiable. 

Don't fold multiple values into decimal values. This is harder to explain. The Govee Air Sensor, as an example, sends out temperature, humidity, and air quality data in a single advertisement. But instead of just filling in 3 two-byte integer values, they instead take the temperature and multiple by 1_000_000. Then then take the humidity and multiple by 1_000. Then they add the air quality. This is all written as a single 4-byte integer.

To decode this monstrosity, you have to read in the 4-byte unsigned integer (in big-endian mode, even though Bluetooth is mostly little-endian). Then do a weird combination of MOD and integer divide operations to split out the three numbers.

Use the right Manufacturer code. The Govee devices mostly use a made-up EC88 manufacturer code; this is an unassigned value that nobody should be using. But the 5106 Air Quality monitor, for no apparent reason, uses the Nokia Phone code (they are manufacturer #1).

FYI: Common Timeout connection parameters

Each Bluetooth LE device can provide a set of connection parameters. These are decoded (now) by the Bluetooth Device Controller; they are part of the "Connection Parameters" (2A04) characteristic of the "Common Configuration" service (1800). The timeout is the last two bytes in little-endian format. For example, if the last two bytes are "90 01" in hex, that's 0190(hex) which is 400 (decimal). The value is in 10s of milliseconds, so the 400 (decimal) means 4 seconds for a timeout.

Looking at my device library, common settings here are:

• 100 ms used by the SensorBug
• 175 ms used by the Sphero
• 4 sec used by the microbit, the govee, the kano coding wand, the viatom, the vion, and skoobot, smartibot and espruino
• 5 sec used by the gems activity tracker
• 6 sec used by the Mipow and the sense peanut
• 10 sec used by the inkbird, lionel, the pyle, the powerup, the various sensor tags, and the dotti

Review: God and Golem, Inc (Norbert Weiner) -- 1964, MIT

TL/DR: I'm glad to have read the book but can't recommend it. The interesting ideas are now widely accepted (computers can learn, and we can't rely on computers to make decisions).

Best Quotes

"A goal-seeking mechanism will not necessarily seek our goals" (page 63)

"This is only one of the many places where human impotence has hitherto shielded us from the full destructive impact of human folly" (page 64)

"A digital computer can accomplish in a day a body of work that would have the full efforts of a team of [human] computers for a year, ..." (page 71). A modern 2022 computer can do the work of 40,000 people for a year in about a second (a Core I5 can do 34969 million FLOPS).

"Written for the intellectually alert public"

The book cover flaps are, unusually, one long continuous text that summarizes the text. The final paragraph: "... written for the intellectually alert public, does not require of the reader that [they] have a highly technical background." I suspect that this is the editor code for "all the glamor of a calculus textbook, but without the equations."

I originally picked up this book second hand as part of my overall interest in everything in the history of my computing profession. This is the first time I've managed to get all the way through while also grasping what the heck Norbert is trying to say. It helped that I put in lots of annotations and had access to the internet.

Theme: Computers will be like humans

If you accept that the Star Trek character "Data" is a "sentient being", then you already agree with Weiner. The entire book is trying to get us people to understand that eventually computers will have all of the parameters of sentient life.

The book was written in the early 60's (the publication date of 1964 is misleading; the book is a rewritten amalgam of earlier lectures), which is before "Star Trek" and sentient robots for the general public, but it's written long after Isaac Asimov's Robot series (including the books with Daneel Olivaw).

Weiner's basic thesis is that "computers" need to be considered in three ways: can a computer learn, can a computer reproduce, and what functions should be handled by humans and which by computer?

Can computers learn (spoiler: yes)

The "can computers learn" is now well understood: yes, they can. Weiner has a highly intelligence-is-everything point of view: in his opinion, as soon as a game is theoretically understood, it ceases to be of any interest at all to anyone. The obvious counter-example -- that people still play tic-tac-toc -- is entirely unconsidered.

This section, BTW, is what propelled me to write notes in the book. Weiner will bring up a person's name on one page, mess about for 15 pages, and then bring back that name assuming that you remember it.

Can computers make a new computer? (spoiler: eventually, yes)

The section on whether computers can duplicate themselves can only be understood by people who understand the complex dead-end mechanism used in WW2 artillery fire control systems. This is something Weiner excelled at, and he has great enthusiasm for it. But a better example is the numerically controlled machine tools that were already available -- a computer can guide the tools needed to build more computers.

The section is also somewhat weird. Biologists love to use "can reproduce themselves" as part of the important distinction between living and non-living. But from a legal or religious perspective, it's bunk: people don't have more or fewer rights because of their ability to reproduce.

What's the right place of computers? (helper, not decider)

Weiner correctly foreshadows the problems of having computers be the ultimate decider of critical actions, while also missing most of the problems that we're bedeviled with currently.

He's got a lot to say about nuclear war (fifty years later, we thankfully have never had another nuclear war, although arguably several wars have been highly influenced by the nuclear capabilities of the sides). He's rightfully skeptical of automated launch systems -- the reality of most alerts is that they are false alarms.

So, he says that computers will be like humans? (answer: no)

On the one hand, he's got a lot to say about how computers can theoretically learn, mutate, and reproduce. But he doesn't carry this to the logical conclusion: that computers will eventually be sentient (which he doesn't bring up at all). Instead, he argues that we humans must block any attempt to have computer make decisions that affect us humans. He's firmly in the camp that computers are good helpers for the human intellect but are ill-suited to being in control.

And right now, I'd say he's right. We see computers making "unbiased" decisions on health care that turn out to be racist (*), or "unbiased" justice decisions that put one set of people into jail. And we see clearly during these days of the Ukraine war that computerized messaging can be a tool to amplify one position or another.

If it's not physics, it's crap

Holy cow, there's an entire chapter devoting to bashing the mathematical formulations of anything that isn't physics. He's got a lot to say about how (for example) mathematical economics can't possibly ever be useful because getting good data is hard. What he misses is that we can deal with the data being wonky. During the pandemic times, we all saw the strange way that death rates would fluctuate, only to be explained that this state or that state was behind in their processing, and would periodically catch up by providing one giant batch of data. Similarly, the reason that some states (like Florida) have a low death rate is that all visitor deaths are reported by the home state.

One problem some academics have is that they can see how their own field is impacted by whatever the new thing is, but they can't imagine how this will impact other fields. Famously, after WW2, the British government commissioned an academic to decide if these new "computers" would be useful. The academic could easily see how their own particular field would benefit (x-ray crystallography), but couldn't imagine that computers would be useful in any other field.

Wait -- what's all this religious stuff?

Weiner love to talk religion. He's not very good about being particularly coherent. FYI: the sin of simony isn't related to Black Masses.

Where's the golem?

The golem is the Golem of Warsaw. It's mentioned in passing on page 49. Considering that it's the overarching theme, you'd think it would be mentioned a bit more. It's also mentioned on page 95, the conclusion, where it's mentioned once in an attempt to explain why the book is called God and Golem, Inc.

What's with the ", Inc"?

The title is best parsed as "(God) and (Golem, Inc)". For years I've been assuming it was best read as "(God and Golem), Inc". He's comparing the for-profit creators of computing machinery ("Golem, Inc") with God. 

(*) I can hear the "well, actually" crowd now. "Well, actually, the computers are racists, they merely use racist data to implement racist policies that have disproportionate impact on different races in a way that dehumanizes people and creates additional stumbling blocks, but the computers themselves aren't racist". Well, actually, that attitude is bogus.

IBM 610 Auto-point: weird 1950's computer

IBM 610 Auto-Point computer (annotated)

Have you ever gone into your pantry, closed your eyes, randomly picked out the first dozen ingredients, and challenged yourself to make a dinner from whatever you grabbed? Well, it sure seems like that's how IBM designed the 610 computer.

The always-awesome bitsavers site has a couple of manuals for the IBM 610 auto-point (an old name for floating-point) computer, including a snazzy brochure and an operations guide. The breathless prose ("arithmetic and logical problems can be solved on the spot") hints of a world of promise, but a peek under the covers shows that this is, in fact, a bit of a monstrosity.

The keyboards

There are two keyboards, which seems like a lot. The one further on the left is called the "typewriter" and is a repurposed electric typewriter (which IBM also made, so they had them in stock). The typewriter is used to print out the results. As a special feature, you could type on the typewriter, and it would type onto the paper. There's no way to type on the typewriter and get it into the computer.

The specialized keyboard on the right is the "console". IBM loved their consoles. It's where you enter in your data, and it's also where you create your programs. The console is not to be confused with the control panel, which is another thing entirely.

The console has 43 keys. There are 11 number keys (0 to 9 and decimal point), plus 7 common math operations (+ - * / square-root convert [change sign] and a combined divide/multiply).  There are 2 blank keys, because why not. The rest of the keys are for controlling the machine, and entering in commands.

Programming the machine

You might be thinking, "what languages does this machine handle". The answer is: take a look at the keyboard. Whatever you can type there, the machine can do. Each possible machine opcode is a single keystroke. That might be nice if this was, say, a Sinclair ZX80 running BASIC. Instead, these are rather bizarre opcodes. Let's divide them up into groups.

I should point out that you can also program the computer via a program punch tape, which just duplicates the keyboard but weirdly, and you can program the computer via the control panel. And they can be mixed together, and the person at the keyboard can always override whatever commands you set up.

Input (control) selection keys (4): KB DTR PTR CP. Says which input device the computer should use for control: keyboard, data tape reader, program tape reader, and control panel. 

Output keys: TYP CR TAB DTP RO. The first three turn on the typewriter, either at the current position, after a carriage-return, or after a tab. DTP turns on the data tape punch. RO will  write the current register out to the selected output -- so to write a number to the typewriter at the current position, you have to do a TYP RO. But this won't work, because RO doesn't really do the auto-point conversion; first you have to do a SL15. The RO will undo the previous SL15, giving a truly weird side-effect.

Register edit keys: CLR CLR-RH COPY SL15 SR15 SL SR. The normal kinds of things like CLR to clear a register, CLR-RH to just clear the right-hand half of the register. SL15 and SR15 are just bizarre, but you have to use them to get output.

Control keys: REL INT  RSM ENT

REL  will drop out of the current operation, and reset the selected register. Interrupt will interrupt the current operation, but if you press it and a particular light goes on, you have to press RSM (resume) until the light goes off. ENT will "prepare the machine to enter data into a register"

Other keys: SEQ A DEL

The A key is used to select the A register. Otherwise, you'd have to select it by number, which is is register 2. DEL will help fix any data entry mistakes. SEQ is special, and deserves a section all to itself.

Lights, more light, other more lights.

The keyboard includes a set of lights that help you figure out what the computer is doing, and a set of "check" lights. 

But wait, there's more. The keyboard also includes a tiny, 2-inch (5 cm) cathode-ray tube (like an LCD screen, but uses more electricity). That screen lets you view the contents of the current register as tiny dots. 

Here's the pattern for "I'm entering the number 22.37".

The actual little numbers 0..9 aren't displayed; you just have to kind of squint and carefully measure where the little dots are. It's not (seemingly) calibrated, and each column can only display one dot. No, you can't display DOOM on this.

The main body of the computer also has lights, this time to tell you what the current program step and current registers are, plus whether the machine is off, on, or really on.

SEQ (Sequence)

Never have I ever read that description and understood it. But I'll try. A "hub" can't be described until "control panel" is described. A control panel is a set of bulk-removable wiring that can customize many kinds of very old IBM machines. Control panels predate computers, which is why they are a so very deeply different. 

If you have, say, a device that reads in punch cards and then prints the results, you might have a control panels with 80 wires, once from each card column that gets read going to one print position. Often they will be "straight", so that column 10 on a card will print into column 10 on the printer. But you can get fancy: you can print only some of the data, or duplicate some columns. And you can "suppress leading zeros" for some set of data, so that if the card is punched as "00020" you can print just the "20", which is often much easier to read. And it gets so, so, so much more complex.

A "hub" can now be described: it emits a pulse, so that you can have sequences of events. Yeah, sorry, not super clear. What can I say: IBM has hundreds of pages about hubs. 

The "machine functions" that the control panel opens up include things like "loops". That's right, writing a program with loops is impossible with just the keyboard; you have to wire it yourself.

 You might also want to program with fancy "if" statements. Those are available when you use the paper tape. The paper tape uses an 8-channel (8-bit) code. The top two bits say what "class" any particular instruction is in -- classes 0, 1, 2 and 3. You can specify which classes of instructions you want to run at any time. Yes, this means you a main body, a "if-else" statement, and a remaining "if" statement, and that's it. But good news: you can interleave the different statements together. 

But wait -- which class gets used? Answer, of course, as with everything about this machine, is that it depends, There's four switches on the manual keyboard, one for each class, and they can be set to "always", "never" and "depends on the programming panel". 

That auto-point isn't really floating point

IBM was really happy with their "auto-point" concept. If you've never used the previous technology -- which would be a "slide rule" -- those devices don't include the magnitude of the number at all. That is, you multiply "1.23" x "6.78" in the exact same way that you multiply "123" x "678" -- you just have to remember where the decimal point is.

With the "auto-point" concept, you get a bunch of registers, each of which can hold some numbers like "1.23" or "6,780". As you enter each number in, when you get to the decimal place, the number will automatically adjust in the machine so that the integer "left side" of the decimal point uses half of your register, and the fractional remainder goes into the right side of the register. 

On the one hand, this is convenient: you don't have to remember where the decimal point goes in your result of 83394. On the other hand, very large and very small numbers are absolutely impossible, and your precision will vary all over the place.

In summary: 

Every single part of the IBM 610 is harder to understand, and weirder, and pointless duplicated, with extra complications thrown in just to try to keep everything kind of working.

Learning Typescript, and why I'm not a fan

A work project I'm helping out with uses Typescript, I tried to use it for my extension, and now I just use JavaScript. It's all because TypeScript documentation is bad, the module system is silly, their conversion times are slow, and their target user is 100% not me.

I'm a little bit of a computer language enthusiast, and have been for years. My first intern project was to make a YACC grammar for a Fortran "wirelist" program for Teradyne (hi, Chuck!); I designed and built a technically-oriented terminal-based hypertext system for electric engineering; I created an incredibly simple search language for a game company (technical requirement: must be functional in less than one day, because otherwise we'd have to use my boss's approach, and he was wrong). 

I was enthused by having a reason to jump into Typescript for this project. I 100% love the concept of typescript: it's like JavaScript, but adds in types, so you make fewer mistakes. Who wouldn't like that? I'm not a fan of being all loosey-goosey with naming, and appreciate the little boost that Typescript add. The generated JavaScript code matches well with the original, making debugging easier.

And then in all went wrong. After a successful start, within a day I stopped working on the Typescript source and instead just edited the JavaScript file. 

The compile speeds take me out of the flow. My file is just a few hundred lines long; in JavaScript I can just reload. With TypeScript, you have an awkward pause. The pause is for no technical reason; my files are small, a reasonable program would be able to read it, parse it, and convert it in under a second. (my own current language project is a language converter; my own goal is <1second for a 1K line file)

The module documentation is much to terse. Specifically, if you already know how modules work, and know what you want, then you can understand the module documentation. Otherwise, it fails to provide basic information about what the settings do, and when to use them.

Modules simply emit errors. The goal of Typescript is that it generates working JavaScript. There are two settings for modules: ones that generate non-working JavaScript (the browser sees an import statement and complains that it doesn't know what requires means), and ones that spit out long lists of compiler errors about not finding some package that I'm not asking for (some configuration language).

If your customers are highly motived people then you can get away with badly documented features that generate errors. I'm not that highly motivated, and have an alternative.

Why do I even need modules? Typescript requires modules for two reasons: 

The -watch command that's needed to make compile times acceptable only work with the -build switch and that in turn only works with modules. It would have been nice if I would have just typed tsc file.ts --watch and be done with it. 

As soon as you have two files, you have to have modules. Otherwise, nothing works.

The language documentation is a barrier to understanding. The documentation for Typescript hardly presents an easy onboarding experience. There's pretty much nothing that I found that presents a high-level work flow, or explains their design choices. 

Mathematicians are the bane of computer documentation. I firmly believe that there's a mathematicians brain that some people have, such that they read in equations and very short, very succinct descriptions, and from that generate an entire field. It's actually an awesome ability, and it makes them write completely useless documentation for the rest of us. (Note: I have a degree in mathematics).

Typescript is full of the mathematicians approach: provide a tiny number of words, with no worked-out example, and starting from first principles (which no beginner know) instead of from what starting people need to read.

I wanted typescript to be a powerful new tool in my toolbox for designing programs. Instead, after multiple fruitless hours of trying to make Typescript work within my work-flow, I simply gave up and embraced JavaScript. And it makes me sad. 

 Everything wrong with the FINGER protocol 

For those of you who have never heard of it, Finger is one of the old "litle"¹ TCP services. As a user of a big multi-user machine, you can edit the ".plan" file in your directory; people can then run a command like finger person@example.com and it will retrieve your .plan file along with other information like where and when you last logged in. It was a super useful way to coordinate with teammates back in the days before cell phones had been created. 

 The protocol itself is pretty simple: the finger command sends a single line of data with the user name, and the server replies with a bunch of text and then closes the connection. So what could go wrong? In this minor screed, I list both things that should have been known at the time, and also things that we know about protocols today that weren’t known then. 

TL/DR: the spec is wrong, confusing, incorrectly implemented and potentially dangerous. But other than that, it works pretty well :-) 

The protocol spec is incorrect (/W). 

 Firstly, the finger spec, RFC  1288, is wrong. The "BNF" query notation, section 2.3, with query type #1, attempts to allow an optional /W before the user. The /W is the verbose switch (W stands for "whois") and servers can reply with more information when it's provided. (This is accessed by the finger -l person@example.com switch; -l stands for long). But that's not what the BNF actually says. What the BNF says is that the /W switch is required whenever a username is provided. What should be an optional switch into a mandatory one. 

Good news! Every actual finger client implements what the spec tried to say and not what it failed to say. Which is good, because a number of existing (as of February 2021) Finger servers implement the earlier RFC 742, which doesn’t allow the /W switch. 

The protocol BNF is clumsy. 

The protocol “BNF” in general is more formalistic than useful. There’s an old saying that every level of indirection makes code harder to follow; the corresponding saying for BNF is that simple and common definitions like CRLF should be spelled out each time they are used, not hidden behind a layer of naming indirection. The BNF also loves using short name; {C} is the name of the rule that eventually expands to CRLF, and {U} the rule for user names. 

Additionally, the BNF is split into two rules: one for direct user lookup, and one for an indirect network lookup (these are Q1 and Q2 in the BNF). But this makes the Q1 clumsy, as it has to handle both user lookups with no user, and user lookups with a user. A better split would be three query types: a NULL query (with or without a /W), a user query (also with or without a /W) and a network query. 

On-behalf-of is not good networking 

We can totes forgive the original spec from adding in the slightly weird “Q2” format. This format is used when we're asking server “A” to ask server “B” for information. It’s like the user can’t get the information they want directly; they have to go through a gatekeeper server. The other servers are called Remote User Information Program (RUIP). Back in the 1970s when the RFC was created, the internet was often provided to a single computer at a site; the site then used other protocols and network to connect to other computers at the site (hence the internet used to be described as a “network of networks” which were expected to use non-Internet protocols). 

But in modern times, the Q2 “on behalf of” experience isn’t needed. Indeed, none of the servers I found would handle it. 

Massive security issues 

 Finger servers often return the time and location of user logins. For example, FINGER might say that a particular user is currently logged in at a particular terminal in a particular room. This is handy when dealing with friendly teammates, but is totes wrong when dealing with stalkers and worse. Lots of people really don’t want other people to know where they are. 

Giant compat issues with modern servers 

You might be confused by this one – what could I possibly mean about modern Finger servers? Have there even been any modern Finger servers at all? Why would anyone build a new Finger server given that the Finger protocol is often blocked by firewalls and provides very few features needed by people. 

It turns out that just looking on GitHub shows a bunch of different Finger servers. These servers are mostly derived from the original RFC 742 Finger protocol. It’s almost the same as the RFC 1288 Finger, but doesn’t allow for the /W switch. Other servers attempt to handle the /W switch, but don’t do it correctly (finger.farm, for example, failed until recently).  

One more thing about the /W switch spec: case-insensitive

[Later edit]: the RFC set of specs has long declared that just strings in the BNF descriptions should always be assumed to be case-insensitive: "monday" is the same as "Monday" and "MONDAY" and "MoNDAy". The FINGER spec takes the opposite approach: the /W switch, AFAICT, is actually case-sensitive and should always be upper-case.

As a fun aside: the RFC editors are, in the instance, wrong. While I understand why they decided that BNF should be case-insensitive (it's part of our text-based heritage), it's also the case that the workaround they use (specify case-sensitive strings as hex characters) is demonstrably error-prone. I've personally filed about a half-dozen different bugs against Internet protocols for getting the HEX representation of strings wrong.

The best solution is to require each BNF description to say if they are case-sensitive or not.

Use these learning for your own protocols! 

Finger is part of the old tradition of text-based services that are almost designed for direct command-line manipulation. As such, it’s now mostly out of favor (when was the last time you read your email by directly talking to a POP server?). That said, there are still lessons from FINGER for today. 

• Simple, direct protocol descriptions are easier to debug than complex ones. 
• Be aware of bad actors. Don't let your APIs enable stalkers and thieves. 
• Make sure that the easy path for handling your protocol also allows servers an upgrade path. 

 

Note¹: Finger is one of the litte TCP services noted in RFC 848 along with echo, discard, systat, netstat, quotd chargen, finger and a couple of time-related services. 

 

Your bluetooth is bad (continued)

More example of how to make bad Bluetooth devices

What format is my number?

Bluetooth developers continue to create a bewildering variety of undocumented data formats. Indeed, it's a race between them and the bizarrely incompetent "Distributed Ledger" teams for the worse numerical formats.

• Nordic Thingy -- you can't just describe a value as a "uint_16"! Specifically, you can't do it because I don't know if you mean a big-endian or little-endian value (as it turns out, the Nordic Thingy is little-endian)
• Also Nordic Thingy -- describing a temperature as a signed value and an unsigned fraction only works if you tell me the denominator of the fraction. Some devices might reasonably make the "fraction" part be out-of-10 to get a degrees in a tenth of a degree (which is just fine for a weather station), or it might be out-of-100 or even out-of-256. 

Your Bluetooth is Bad, continued

Very silly Bluetooth protocols, continued

Bluetooth devices continue to astound me: there are clearly capable programmers who manage to completely misunderstand what they're doing. In this episode: the Elegoo Mini-Car kit.

The actual kit is pretty decent: it's got a lot of parts and polish for something so inexpensive (I think I paid about $30 for mine). Up on the Elegoo downloads site there's a 400+ megabyte (!) download with a bunch of well-written instructions and even a Windows 7 driver program.

Clearly the Elegoo people are doing well in terms of creating a complete package.

But then there's the Bluetooth. They obviously switched at some point from a purely serial connection to a BLE connection; this always causes weird issues. 

How should you interpret a command description like this: {RGB[R][G][B][N][T][M]} ?

A smart person would start to figure that it's a weird combination of text and hex, and would kind of wonder how the command RGB is separate from the obviously hex parameters. But no, that's not it. You're supposed to literally type in the "{" and the square brackets. The parameters are in text mode, and they really do have all of the [ and ]. A complete command looks like this:

{RGB[255][0][0][2][0][1]}

A smart person will also realize that because of the insane overhead of the command, it no longer fits into a 20-byte send; you have to split it into two sends!

Let's analyze. Each parameter when sent in binary would be one byte; in fact they will be between 3 and 5 bytes. The command code, instead of being a nice simple byte (there are only about 12 commands actually supported) is instead up to 5 bytes (the MOVES command).

Wait, it's worse. What happens with {BEEP[0]}? Answer: the beeper should stop beeping. What about {BEEP[00]} -- a 00 should be parsed as a zero, right? Wrong; zero is a special case. Only a 0 counts as a zero; 00 is not a zero. This is unlike some of the other commands.

The programmer has managed to make a language that's hard to parse, inconsistent, and wildly inefficient. 

Another grumpy post, this time about Application Insights

What is Application Insights, and why is it awful?

Hey, maybe for some people it's not a terrible time suck. Maybe for some people, it's providing value. How many ways has it sucked up my time so far? Let me count the ways:

1. When I made my Windows App, Microsoft not very helpfully added a reference to it in the project. I spent time to understand what it was (it is supposed to send up "telemetry" to some dashboard somewhere). I decided to keep it because I didn't want to offend the Awful Scary Microsoft Monsters.
2. When I got scary email saying that I'm about to spend hundreds of dollars a month to get some alleged insights because Microsoft decided that hosting a ton of data was expensive, and they didn't want to foot the bill forever. Luckily my actual usage is almost nothing (I think).
3. When my updated projects simply refused to compile. Except when they did compile. But they never compile when I'm making an app store
4. And just now, when I finally ripped off the bandage, and remove the Application Insights packages from my app.
5. Oh, and while I'm at it, I figured that I might as well look and see what awesome insights the Application Insights is giving me. I turns out that whatever data has been sent up is gone; when I go to my Azure Portal, there's a grand total of no data at all, or even a hint that any data has ever been sent up

Total wastage: too much.

Ethereum uses what base encoding?

Base 58 is about the dumbest thing ever

I've been learning Ethereum (because, you know, bitcoin). Being a networking kind of person, I'm looking at the networking protocols. Let's leave aside questionable choices like using Keccak-256 which can be argued are "forward looking" and not "completely unsupported by major languages".

No, lets look at encoding. Each Ethereum address is, of course, a big binary number. It's written out as hex (arguably silly, but whatever). It's then translated using, not base-64, but using base-58. As far as I can tell, this is something they just made up.

I'll ignore the lack of support in major languages.

Base-64 has the nice property that it's exactly 2^^6. This means that one byte transforms into one complete Base-64 value with 2 bits left over. Three bytes transforms neatly into four output bytes. A reader or writer can deal with small, finite-sized, easily handled values.

Base-58, on the other hand, is 5.858 bits. That's nothing useful. It means that any hand-crafted library is more likely to be wrong than to be right. The supposed benefit? So that a few characters that might be misinterpreted can be dropped.

Stupid Idea #692: The installed client has fewer features than the web client

So there I am, using my nice speedy Visual Studio program, happily editing and running code.  I want to use the new team planning features so I can pick my next task more rationally.  And what I discover is that it's horrible: the isn't really a way to "plan"; I can create a work item (but is that what I want to do?), and I can write a custom query to see my work items, but what I can't do is see some boxes on the screen and move them around.

Keep in mind that I use Trello for my hobby projects; it's awesome in its simplicity.  I can make new little card, and move them from column to column, and track what's going on.

So why is the expensive, heavy, full-featured Visual Studio so far behind the curve?  Why doesn't it have a nice graphical interface?  Where is the help for simple planning?

Answer: those are on the web, not in the full client.  In order to use them, I have to leave my nice productive environment, and go to a totally different web page.  And sign in.  with some credentials.  Which have to match the credentials I signed into Visual Studio with.  But there isn't a "go to the web" button.

Never force your customers to leave your product!  As soon as I have to type in a web address to go somewhere else, and sign in again, why wouldn't I just use Trello and skip the Microsoft solution entirely?

Issues with LIB files (a riff on Raymond Chen)

Today's The Old New Thing blog talks about a subject near and dear to my heart: why the Microsoft Linker needs some TLC when it comes to making lib files.

Let's back up.  What's a lib file, and why do they exist?  Well, a long time ago, computer programmers decided that the mechanics of converting what a programmer writes into what a computer understands should be done in two steps: a compiler turns the "source file" (what the programmer wrote) into a "object file" (a temporary file).  Then a linker turns the object file into a program.  It turns out that in general compiling is much slower than linking, and that most programs are composed of many source files, and that you don't have to re-compile a source file that hasn't changed.  So if your program consists of a hundred source files, and you change one, you only have to compile one, and then link them all together, and you get a program.

Now the twist come in: with bigger projects, it's handy to lump all of the object files together into a "lib" (library) file.  That way you don't have to tell the linker about all of your files; you just point it to the one lib file.

That's where the Microsoft Linker falls down, badly.  A common pattern for using lib files is to split the people using the lib file from the people who are making it.  As such, I want to pack my lib files with "everything" the user might want to use.  

But you can't.

As Raymond Chen points out in his (much better) blog , The Old New Thing, today (link: 

http://blogs.msdn.com/oldnewthing/archive/2008/12/29/9255240.aspx), it's eay to compile a file one way, put it into a library, and have a user compiling and linking another way to almost but not quite use your symbol.  It's very frustrating and requires a bit more fixing ability then we should expect end-programmers to have.

There are three things I'd like to see with the linker:

1. On failure, the linker should try a fuzzy match ("I didn't find 'xyz' but I did see 'xyxz@4')
2. The linker should keep track of how all of the files are being compiled ('the library was linked with /FOO but you are compiling with /NOTFOO)
3. A library should be "stuffable" with all of the different versions of a file -- I should be able to pop in the unicode and ansi, debug and release, statically linked and dynamically linked versions of all of my files. 

The goal, of course, is to let me as a library-creator make a library that other people can "just use" -- not "just use with a lot of swearing".

Shell Blog -- interesting blog ruined

So I've been poking at lots of interesting bits of Microsoft APIs, and was casting about for a new world to conquer. In the Shell blog I saw the 'Shell Namespace Extension: Created and Using the System Folder View Object'.

It's very interesting, it might solve some of my integration questions, and it's another couple hours out of my life that I would like back. What the entire (deleted) article didn't seem fit to mention is that when they say Microsoft Windows provides a default implementation of IShellView that what they really mean is most existing copies of Microsoft Windows do not provided any of these facilities

Because their code is (deleted) Vista only. Now, I don't object to Vista only code. But the Windows Explorer has only been around since what? Windows 95? Any code that talks about Shell Integration had better have a pretty good reason for not supporting their existing code base. And any code that does talk about integrating should mention any huge honking holes in the usability.

Microsoft: I want those hours back!

(Link to the Shell Revealed blog post: http://shellrevealed.com/blogs/shellblog/archive/2007/09/05/Shell-Namespace-Extension_3A00_-Adding-Custom-Command-Module-Items.aspx)