I encountered the Sony MMCD when I fell down a rabbit hole *checks literal notes* around five years ago while researching Microsoft Encarta MindMaze[0] and its related file formats.
It turns out the data associated with MindMaze (& other encyclopedia data) changed storage format over subsequent releases of Encarta and these changes provide some interesting historical insights--including that if MS had had its way we'd all be writing web pages in RTF rather than HTML[1]. :D
You may ask, "What connection does this have to the Sony MMCD?".
Well, one of the storage formats used with early Encarta data is `.mvb` which is a format used by Microsoft Multimedia Viewer[2] (also known by multiple other names--none of which are any easier to web search :D ).
And, it turns out, "Multimedia Viewer could compile titles for Tandy Video Information System and other Modular Windows systems, as well as Sony Multimedia CD-ROM Player, a portable MS-DOS-based CD-ROM XA reader released in 1992."[2][3]
According to my research the tool "...includes software tools that simulate the look and feel of the Sony player titles on a PC" which is interesting in the context of the emulator for the Discman mentioned in the original post.
Anyway, that's the very short version of the rabbit hole--maybe in another five years I'll get around to writing up the rest...
Oh, sure, rpath/runpath shenanigans will work in some situations but then you'll be tempted to make such shenanigans work in all situations and then the madness will get you...
To save everyone a click here are the first two bullet points from Exhibit A:
* If an executable has `RPATH` (a.k.a. `DT_RPATH`) set but a shared library that is a (direct or indirect(?)) dependency of that executable has `RUNPATH` (a.k.a. `DT_RUNPATH`) set then the executable's `RPATH` is ignored!
* This means a shared library dependency can "force" loading of an incompatible [(for the executable)] dependency version in certain situations. [...]
Further nuances regarding LD_LIBRARY_PATH can be found in Exhibit B but I can feel the madness clawing at me again so will stop here. :)
I vaguely wondered if FreeHand would make an appearance in this thread. :)
Two features that come to mind as IIRC being unique (as compared to Illustrator) were multi-page documents and multiple page size multi-page documents. Ideal for the complete standard set of company branded print documents: business card, "With Compliments" slip, and letterhead. :D
Adobe's acquisition of Macromedia and subsequent killing of (the IMO superior) FreeHand contributed directly to my subsequent decision to avoid closed source application software--especially for creative tools--even if alternatives were "technically inferior".
(And, indeed, "creative tool killed/hampered for business reasons" is a story which has been repeated elsewhere multiple times in the quarter century[0] since.)
While Inkscape is still missing features compared to FreeHand it is however also still here many years later and is what I've used ever since when I need 2D vector design software. (Although I've also been keeping an eye on Graphite: https://graphite.rs)
> I've been thinking about bluetooth and a standard protocol and generic app.
A long time ago I developed a project called "Handbag[0] for Android"[1] based around a similar concept--it targeted the short-lived "Android Open Accessory Protocol" initially over USB & later also over network/WiFi.
(My project notes from the time mentioned a long-term goal of also supporting Bluetooth but that never eventuated...)
Handbag made use of a "generic" Android app for UI display/interaction and an Arduino library that communicated with the app over a binary protocol.
The app would display various UI widgets such as labels/progress bars to display feedback from the accessory and text inputs/buttons to accept input forwarded to the accessory.
While the project did not take the world by storm, I was reminded when digging up these links that at least one person called the concept genius[2]. :)
----
[0] Because it let you "accessorize your Android phone or tablet". :D
"Cregit" tool might be of interest to you, it generates token-based (rather than line-based) git "blame" annotation views: https://github.com/cregit/cregit
I learned of Cregit recently--just submitted it to HN after seeing multiple recent HN comments discussing issues related to line-based "blame" annotation granularity:
