Blog

Software update round-up

It’s high time to give some love to a few of my older and less-maintained software projects, and bring them up to date with a few much-needed and requested features!

DiskImager

DiskImager is a tool that I’ve used “internally” for a few years now to read and write raw disk images. I’ve simply never found the time to polish it up and make it production-ready, until now. This is a small standalone tool that will dump the contents of any drive connected to your PC to a file on another (larger) drive. It can also write a disk image file to a physical disk. Furthermore, when selecting a disk image to write to a physical disk, you can choose from several types of image formats (besides raw images) including VDI, VMDK, VHD, and E01.

FileSystemAnalyzer

The FileSystemAnalyzer tool has gotten a huge number of bug fixes, as well as these enhancements:

  • Improved compatibility with FAT, exFAT, NTFS, ext4, and UDF filesystems in various states of corruption.
  • Improved previews and metadata for more file types.
  • The main file tree view now has columns with file size and date, similar to Windows Explorer. These columns are clickable to sort the file list by ascending or descending order of the column type.
  • Directories can now be saved from the file tree view (recursively), in addition to individual files.

Outlook PST viewer

The PST viewer tool has been updated to be more compatible with a wider range of PST files from different versions of Outlook, and to be more forgiving of corrupted PST files. There is also a new option to save individual messages as .MSG files.

In praise of Windows Forms

Many of my personal projects such as DiskDigger, DiskImager, and so on are written using Windows Forms, on top of the Microsoft .NET framework. This is because these projects of mine were originally created many years ago during the heyday of Windows Forms, and I made somewhat of a gamble that WinForms would be a sustainable choice in the long term.

Fast forward to today, and it seems like mentioning Windows Forms in polite company evokes a chuckle or two. WinForms is now considered by many to be a quaint relic of a bygone era, which has been largely superseded by new and superior frameworks.

That being said, my old personal projects are still used by a good number of people, and even though I’ve added plenty of new features over the years, I haven’t changed a thing about the fact that they still use WinForms.  And even when I need to create a new GUI app for some random purpose today, I find myself reaching for a blank WinForms project.

So why do I still use WinForms in my personal projects, and why have I not abandoned it in favor of something newer like UWP, or something more cross-platform like Qt?

Because it bloody works. You might have noticed that support for Windows Forms in the most recent versions of .NET is as robust as ever, and in no danger of being dropped. This is because WinForms is an extremely solid foundation for building GUI apps. All of the components are intuitive, make sense, and feel native to the platform, because they are. If you don’t need any of the fanciness provided by XAML such as animating components at every opportunity, rotating buttons by 12 degrees, or making your app run on Xbox One, then WinForms is for you!

Because it’s an absolute pleasure to use. Creating a new Windows Forms project in Visual Studio takes four clicks at the most, and you’re up and running. Designing your app’s window is as simple as dragging and dropping components from a toolbox and adjusting their properties to your liking. Creating an event handler for a component is as simple as double-clicking it. There’s virtually no boilerplate code to worry about — just focus on the code that responds to a button click, ListView selection, etc.

Because it’s compatible and lean. Compatible in the sense of running across various versions of Windows, that is. If you target the right version of the .NET framework, your WinForms app will run perfectly well on Windows XP as well as the latest build of Windows 10. As for leanness, a “hello world” graphical app is on the order of a few kilobytes, and even a hugely complex app would be hard-pressed to exceed a few megabytes of bytecode.

Compatibility (or lack thereof) with other operating systems is, of course, the major unfortunate drawback. This is where my original gamble from years ago didn’t pay off as much.  Since .NET was touted as a “cross-platform” framework, I thought naively that components like WinForms would eventually be ported over to Linux and macOS in an official way by Microsoft. This never happened, and the only real “porting” was done by the excellent Mono project, whose port of WinForms is great but not perfect, and really only works in Linux and not macOS.

Nevertheless, despite the blemish of the lack of actual cross-platform support, WinForms remains a truly solid choice for desktop GUI development on Windows. Don’t be surprised if we keep seeing WinForms used by hobbyists and enterprises well into the future, and don’t hesitate to give WinForms a second look yourself. It might not be the shiniest new thing, but it has persisted this long for a reason.

Minimalist programming, Android edition

Suppose you open Android Studio and create a new project from a template, say, a blank Activity with a button. Then build the project, and look at the APK file that is produced. You’ll notice that the APK is over 3 MB in size.  These days we don’t bat an eye at these kinds of numbers, and indeed this size is pretty modest in the grand scheme of today’s software ecosystem. However, objectively speaking, 3 MB is a lot!  Let’s take a deep dive into what these 3 MB actually consist of, and see how much we can reduce that size while maintaining the same functionality.

The app I’ve built for this exercise is slightly more complex than “hello world”; it’s an app that could actually be minimally useful: a simple tip calculator.

It’s literally a single input field (an EditText component) where the user enters a number, followed by a few lines of text that tell the user different percentages of that number — 15%, 18%, and 20%, which are the most common tipping percentages in the U.S.

Once again, with the default project settings generated by Android Studio, this app comes out to about 3.2 MB when it’s built. Let’s examine the generated APK file and see what’s taking up all that space:

Right away we can see that the heaviest dependency by far is the AndroidX library, followed by the Kotlin standard library and the Material library (under the com.google package).  In fact the code that actually belongs to our package (com.dmitrybrant.tipcalc) is a mere 76 KB, dwarfed by the library dependencies that it’s referencing.

To be fair it’s possible to reduce the size of the APK by a good amount by using the minifyEnabled directive, which is not enabled by default. In fact it would probably optimize away most of the “kotlin” dependency and much of the “androidx” dependency.  However, even with minifyEnabled our APK size would still be on the order of megabytes. For the purpose of this exercise I left minifyEnabled off, so that we can see exactly which packages are contributing to the code sizes in our APK.

In any case, let’s start whittling away at this extra weight, and see how lean we can get.

The Kotlin tax

As we can see, merely using Kotlin in our app causes the Kotlin standard library to get bundled into the APK. If we don’t want this library to get bundled, we must no longer use Kotlin. (Although I’ll repeat that if we use minifyEnabled, then Kotlin would pretty much be optimized away, so this is more of an observation than a “tax.”)

After converting the code to plain Java and rebuilding the app, our APK is now 2.7 MB:

That’s a little better! But now can we remove the bulkiest dependency, namely the androidx library?

The AndroidX tax

AndroidX is a fabulous library that ensures your app will run consistently on a huge range of different devices (but not all of them!) and different versions of the Android OS. It makes perfect sense that AndroidX is used by default for new projects, and I’m not saying that you should reject it when building your next app. Buuuut… could we actually get away with not using it? How would our app look and run without it?  And would our app still run on the same range of devices?

Getting rid of AndroidX means that our app will rely solely on the SDK libraries that are part of the operating system on the user’s device itself.  To get rid of AndroidX in our project, we need to do the following:

  • Our Activity can no longer inherit from AppCompatActivity, and will now simply inherit from the standard Activity class from the SDK.
  • We can no longer use fancy things like ConstraintLayout, and will be limited to using basic components like LinearLayout.
  • Our theme definitions can no longer inherit from predefined Material themes. We will need to apply any color and style overrides ourselves.

After these modifications are all done, here’s what our APK looks like:

That’s right, you’re not dreaming, the app is now 88 KB. That’s kilobytes!  Now we’re getting somewhere. And if we look closely at those numbers, we see that the bulk of the size is now taken up by the resources that are bundled in the app. What are those resources, you ask?

Launcher icons

By default Android Studio generates a launcher icon for our app that takes several forms: a mipmap resource, which is a series of PNG files at different scales, which will be chosen by the launcher to match the pixel density and resolution of the device, and also a vector resource that will be used instead of the mipmap on newer devices (Android 8 and higher).

This is all very useful stuff if you need your launcher icon to appear pixel-perfect across all devices. But since our goal is minimalism, we can dispense with all of these things, and instead use just a single PNG file as our launcher icon. I created a 32×32 icon and saved it as a 4-bit PNG file, making it take up a total of 236 bytes.  It doesn’t look perfect, but it gets the point across:

So, after getting rid of all that extraneous baggage, how are we looking now?

We’ve arrived at 10.5 KB!  This is more like it.  It may be possible to squeeze it down even further, but that would necessitate doing even more hacky and inconvenient things, such as removing all XML resources and creating layouts programmatically in our code. While I’m going for minimalism, I do still want the app to be straightforward to develop further, so I’m happy to make this a good stopping point.

This is definitely closer to the size that I would “expect” a tip calculator app for a mobile device to be.  Speaking of mobile devices, which devices will this app be able to run on?

Compatibility

By default Android Studio sets our minimum SDK to 21, making our app compatible with Lollipop and above. There are plenty of good reasons to set your minimum SDK to 21, but now that we’ve removed our dependency on AndroidX, as well as our dependency on vector graphics, there’s nothing stopping us from reducing our minimum SDK even lower.  How much lower? How about… 1? That’s right, we can set our minimum SDK version to 1.  This would make our app compatible with literally every Android device ever made.

I don’t own any devices that actually run Android 1.0, but here is my Tip Calculator app running on the oldest device I own, a Samsung Galaxy Ace from 2011, running Android 2.3 (API 9):

And here is the same app running on my current personal phone in 2021, a Google Pixel 3 XL running Android 11 (API 30):

Takeaways

Aside from being an interesting random exercise, there’s a point I hope to convey here:

As time goes by, software seems to be getting more and more bloated. I believe this might be because developers aren’t always cognizant of the cost of the dependencies they’re using in their projects, whether it’s third-party libraries that provide some kind of convenience over standard functionality, or even the standard libraries of their chosen programming environment that the developer has gotten used to relying upon.

As with anything in life, there should be a balance here — a balance between convenience offered by libraries that might add bloat, and lower-level optimization and active reduction of bloat.  However, it feels like this balance is currently not in a healthy place.  The overwhelming emphasis seems to be on convenience and abstraction ad infinitum, and virtually no emphasis on stepping back and taking account of the costs that these conveniences incur.

Android is far from the worst offender in the world of bloat, and even though a 3 MB binary may be totally acceptable, it doesn’t have to be that way.  Even though bulky standard libraries should be used in the majority of cases, they don’t need to be used all the time, and there may even be cases where the app would benefit from not using them.  If only developers would maintain a better sense of how their dependencies are impacting the size of their apps, or indeed what dependencies they’re even using in the first place, we can begin to restore the balance of bloat in our lives.

Homeowner’s log, February 2021

Our steam heating has had some sporadic issues now and then, and I think I’ve finally got it solved once and for all. It’s all about the steam traps! If you have a two-pipe steam heating system, it’s very important to replace the steam traps every few years. Or rather, replace the internal component of the steam traps, which is the cage unit.

Failed or failing steam traps can cause all kinds of issues in your heating system, including radiators not warming up quickly, all kinds of noises around the radiators, and water hammering in the return pipes due to steam leaking into them.

And this time, I made a video about it!

Just for my own recollection in the future: most of the steam traps are Barnes & Jones #3045, and a couple are #122. Both of these types are compatible with the #1721 cage unit. However, one of the radiators has a #134 trap which requires a #1929 cage unit. In the future, if these parts become scarce enough, it looks like Tunstall has new replacement units that might be compatible.

Random thoughts 1

  • If your app has a “splash screen,” it’s a tacit admission that the app doesn’t load as fast as it should. If you build a splash screen into your app on purpose, you’re in the wrong field.
  • Programming languages are tools; they are a means to an end. There are very many programming languages. Don’t fixate on just one. It’s not particularly useful to become a great expert in any single language. It’s better to be adaptable and pick up a language for an application for which it will be useful. Unless you’re an actual hobbyist of language design, there’s really no reason to “master” a programming language for its own sake. What you should master are theoretical computer science concepts, and an instinct for where these concepts fit in real-world applications. Once you do that, it becomes easy enough to express those concepts using the language that best fits your task.
  • I would say I’m almost a libertarian, but not quite. Libertarianism seems to be predicated on the idea that individual people know what’s best for themselves. As I get older, I see that this is actually a very, very unsafe assumption. A good example is vaccinations: vaccinations have to be instituted and mandated at the federal level, lest the general public be swayed against them by less credible scientists like Marjorie Taylor Greene. Another example is education, especially education of science (viz. evolution). It’s probably better for school curricula to be composed at the federal level, instead of being voted upon by local communities of parents and teachers who grew up on the same nonsense that they teach.
  • When I reject the existence of a god, I’m not just rejecting the god, I’m rejecting the entire logical framework within which this god is constructed. So, as long as you continue to make arguments that are confined to that framework, you’re not adding anything new to the discussion. The fact that so many people in the world are religious says nothing about whether such a being actually exists; instead, it says something about human psychology.  It says something about these ancient psychological devices that we evolved during our prehistory as frightened primates struggling to survive and understand the world around us. It’s so trivially easy to reverse-engineer religion, and see exactly which buttons it pushes on the psyche, which emotions it appeals to, and what various uses it has for its practitioners, whether it’s for good or for evil.
  • The definition of “conservative” seems to be changing. Conservative used to mean wanting to go back to the old days, where “old” days could be fifty years in the past. But today you can be called a conservative for wanting to go back ten years, when ideas that were considered liberal at the time would be considered far-right today. It’s a bit of a problem when our moral universe changes within a human lifetime, and an even bigger problem when our moral universe changes with each new social media app.