Modern GUIs are often not great. Back in the days™, it was mostly pre-installed crapware and printer utilities that used idiosyncratic controls and their very own colors and window decorations because, well, just because. Somewhere along the road, common buttons, checkboxes, title bars, and window controls went out of fashion, and when everything became a web-app or was styled like one, things took a turn for the (even) worse. Nowadays, you cannot even tell if a window is active by looking at its title bar, let alone drag or resize it easily.

Yes, this is…

• the rambling of a grumpy nerd,
• a platitude,
• covered in tons of opionated articles already,
• and true. :)

Recently, I especially enjoyed reading this post about the downfall of native GUIs and these thoughts on the shortcomings of “invisible” design.

I’m currently working on a long-overdue Coppenheimer update – the last one was nearly two years ago, and its recent popularity gave me a little nudge. As I’m not a wasm, emscripten, or C++ guy, progress is slow (i. e. getting it to compile again after the vAmigaWeb merge and making sure everything still works), but I’ve got to the point where I’m thinking about new features. That’s where these blog posts struck a nerve: One thing I certainly won’t change are the GUI elements!

Originally I chose AmigaOS 2/3-inspired buttons for some authentic retro feeling, and because I wanted to try out the border-image CSS feature (I love what modern browsers can do out-of-the-box with plain HTML and CSS).

But looking back at it now, having oldschool buttons and checkboxes with classic fake-3D borders makes for a nice user experience as well. As in: The interface communicates clearly what is clickable and where, you don’t need to hover with your mouse pointer over possible controls, guess the meaning of minimalist icons, or guess-click (I hope). It was also a huge help when making the GUI: I just crammed in all the buttons I needed and balanced them a little with spacing and alignment – done! It’s a mess and not very logical, but you quickly find your way around if you try.

Or maybe I just like the look, and it amuses me how its approachability is a breath of fresh air in 2026? Although it’s 35 years old now?

Probably that, yes. :)

PS: I did notice one thing I might change: I applied the “disabled” state inconsistenly – with the authentic ghosting pattern for checkboxes, and an opacity change for the pause/step buttons. Tsk, tsk…

Small addendum to my previous post: To put their signature on the “3-Demon” release in 1988, The Bitstoppers didn’t only put a README, an intro, and some deeply nested directories onto the disk – they also included a custom, Bitstoppers-branded mouse pointer as well! Funny that I missed that, because I myself extracted and manually categorized that mouse pointer, among thousands of others, and wrote a little web app that lets me link to it, complete with an OpenGraph-compatible preview image:

But that’s what shower thoughts are for, I guess. To make up for the slip-up, here’s a recording of Bitstoppers’ fabulously oldschool cracktro. Year!

The other day on pouët, the question came up when people started naming Amiga executable files with an “.exe” suffix, which isn’t really necessary under AmigaOS. Interesting question! I started scanning the disk images I collected for the Amiga Pointer Archive. At least in the TOSEC disk images, .exe files occur as early as 1987, and maybe earlier overall.

While the file names scrolled by, I noticed something funny: Endless directory structures that seemed to repeat themselves. Take “3-Demon” from 1988, contained in 3-Demon v1.0 (1988)(Mimetics)[h TBS].adf – an early 3D editor, apparently:

This specific disk was spread by The Bitstoppers — they put a README file in front of it, added a little intro…

…and also left their name on the disk as a directory name. When you list the disk contents with AmigaDOS, you get:

1> dir df1:
     c (dir)
     objects (dir)
     devs (dir)
     s (dir)
     fonts (dir)
     libs (dir)
      ** THE BITSTOPPERS **  (dir)
     »> BST <«                     !ReadMe!
  .info                            3-Demon
  3-Demon.info                     BST
  Disk.info                        Example 1.3demon

However, when you try to list all files recursively with dir df1: all, the system crashes:

Neat! Keep those lamers from listing your directories, hehe!

But is this a clever file system trick, maybe with a directory containing itself, causing the dir command to exhaust all memory or overflow internal buffers? Kind of like a ZIP bomb – an Amiga directory bomb?

At least for this disk, it’s not. If we analyze the ADF image in a file system analyzer like vAmigaDOS, we can follow the directory tree. Amiga OFS file contents are split up in 512-byte blocks, with references to their neighbors, parents, and children. Starting from the root block at 880, we get:

[880] 3-Demon: /> block 880

                   Block : 880
                    Type : ROOT
              Header Key : 0
                Checksum : 0x19ca146d
                    Name : 3-Demon
                 Created : 18-Mar-88 11:53:49
                Modified : 18-Mar-88 11:53:49
           Bitmap blocks : 1012
  Bitmap extension block : 0
              Hash table :  7 ->  883 (.info)
                            8 ->  925 (c)
                           10 ->  887 (3-Demon)
                           13 ->  886 (Example 1.3demon)
                           17 ->  894 (objects)
                           22 ->  926 (devs)
                           24 ->  899 (s)
                           28 ->  960 (!ReadMe!)
                           39 ->  924 (fonts)
                           40 ->  952 (   »> BST <«   )
                           44 ->  932 (BST)
                           46 ->  954 (libs)
                           47 ->  958 ( ** THE BITSTOPPERS ** )
                           54 ->  882 (Disk.info)

[880] 3-Demon: /> block 958

                   Block : 958
                    Type : USERDIR
              Header Key : 958
                Checksum : 0xe48554e4
                    Name :  ** THE BITSTOPPERS **
                 Comment :
                 Created : 16-Feb-87 18:45:36
                  Parent : 880
                    Next : 0
              Hash table : 47 ->  961 ( ** THE BITSTOPPERS ** )

[880] 3-Demon: /> block 961

                   Block : 961
                    Type : USERDIR
              Header Key : 961
                Checksum : 0xe4855475
                    Name :  ** THE BITSTOPPERS **
                 Comment :
                 Created : 16-Feb-87 18:45:37
                  Parent : 958
                    Next : 0
              Hash table : 47 ->  962 ( ** THE BITSTOPPERS ** )


[...many more blocks omitted...]


[880] 3-Demon: /> block 1009

                   Block : 1009
                    Type : USERDIR
              Header Key : 1009
                Checksum : 0xe48555e3
                    Name :  ** THE BITSTOPPERS ** 
                 Comment : 
                 Created : 16-Feb-87 18:45:47
                  Parent : 1008
                    Next : 0
              Hash table : 

So it’s turtles directories all the way down – just more than dir can handle. Listing all the directories in vAmigaDOS doesn’t crash your browser or gives the “unresponsive JavaScript” warning, it just outputs a very long list:

Still, the question remains: Is it possible to create an evil directory structure? One that contains itself, or maybe a parent and a child that point to each other?

Surprisingly, yes! We can get dir to crash without wasting 512 bytes for each dummy directory, saving precious disk space! It just takes some adjustments in a hex editor…

- create a blank ADF disk image

- makedir evil

- makedir evil/evil

    block 880 (0x370) = root block
    block 881 (0x371) = disk bitmap
    block 882 (0x372) = directory "evil"     (path: "evil")
    block 883 (0x373) = sub-directory "evil" (path: "evil/evil")

- find the top-level "evil" disk block

    882 * 512 bytes = offset 451584 = 0x6e400


0006e400: 0000 0002 0000 0372 0000 0000 0000 0000  .......r........
0006e410: 0000 0000 8f9a 2d16 0000 0000 0000 0000  ......-.........

                    checksum: need to adjust that by 1

0006e420: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0006e430: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0006e440: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0006e450: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0006e460: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0006e470: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0006e480: 0000 0000 0000 0000 0000 0373 0000 0000  ...........s....

                                   hashtable with child reference
                                   to "evil" sub-directory; let it
                                   point to ourselves = 0372

0006e490: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0006e4a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0006e4b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0006e4c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0006e4d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0006e4e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0006e4f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0006e500: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0006e510: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0006e520: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0006e530: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0006e540: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0006e550: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0006e560: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0006e570: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0006e580: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0006e590: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0006e5a0: 0000 0000 0000 44b1 0000 0575 0000 0802  ......D....u....
0006e5b0: 0465 7669 6c00 0000 0000 0000 0000 0000  .evil...........
0006e5c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0006e5d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0006e5e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0006e5f0: 0000 0000 0000 0370 0000 0000 0000 0002  .......p........

…and voilà!

Here’s the resulting disk. Let’s see what other utilities we can crash with it…

I had a hunch that vAmigaDOS would be cleverer than that, and I was right. It notices something is fishy right away. Boooring! :)

That’s Finnish for “Valentines’s Day cheese”. Also, it’s not really “Valentine’s Day” in Finland – ystävänpäivä is more like friends’ day.

Here’s a piece from Finland’s public broadcasting company, Yle, looking at Valentine’s Day rituals around the world. To the Finns, it’s all very romantic, and thus weird. :)

But why cheese? Because it was my inspiration for Yle’s Valentine’s Day Pixel Festival organized by Dan Farrimond a. k. a. illarterate. My thought process went like this:

• Valentine’s Day, what do I draw…
• Hearts, roses, smooching – it’s all a bit cheesy
• Hah!

Yle’s V-day-around-the-world article ends with a teaser for their own Teletext event, featuring these two lovely pieces:

Humppa! If that isn’t my cheese! :)

Take a bite of all the other entries as well. There’s even a raccoon not made by RaccoonViolet!

PS: Any resemblance with the I choo- choo- choose you intro I made a year ago is purely coincidental…

Yuck, what’ this? A ready-made rice-dish sauce with… peaches?

But there’s another “yuck”, something that caught my eye about the “Süß-Sauer” (sweet sour) jar.

Let’s just skip for a moment that by German orthography rules, there is no reason to capitalize the second adjective (Sauer)…

There’s no way this is a regular sharp S – with the straight line going out at the top, it looks more like a capital sharp S! It’s suspiciously wide, too.

If you’re unfamiliar with the aesthetic and historic cosmos surrounding ß and its relatively new uppercase counterpart, I warmly recommend studying Luc(as) de Groot’s excellent write-up. I also rambled a bit about the topic when I designed an 8×8-pixel specimen for Topaz-8.

Granted, the difference can be hard to make out – some fonts don’t care too much about the contrast between the lowercase and uppercase variants. With Georgia, for example, smuggling an uppercase ß between lowercase letters doesn’t look very suspicous. Times New Roman does a better job at that, making the odd capitalization stand out more:

Let’s find out what’s happening with the labels in question. Unleashing the power of modern image-based font recognition, the font in question seems to be Bastia by Jen Wagner. Does this font not have a sharp S? That would be very weird. Does it have an uppercase sharp S, and does it look like the one I spotted at the supermarket?

Of course it has an ß character, and a capital version as well. It actually has a very special sharp S design, alluding to the historic origins of the letter as a ligature of ſ and s, back when the printing press was new. After all, this typeface is marketed as a “retro serif”…

So this is not an overcompensation at all – “Our labels are like a headline, should we use that newfangled uppercase ß we see more and more often?” – but rather a case of typographic fumbling. I bet the conversation went like this:

• That typeface looks neat on our packaging, let’s use it!
• Wait a minute, that ß is too extraordinary for my taste… Now what?
• Let’s screw the typeface designer’s choices and just use the uppercase one!
• Perfect! It’s wrong and looks weird, but who gives a shit!
• Not me, that’s for sure! (packaging designers do a high-five)

So, um, congratulations, Sonnen Bassermann design agency, for this… capital crime in packaging typography! :)