Ah, Japan’s TRON project – every few years someone discovers it anew and it bubbles back up the surface, and deservedly so, as it’s an incredibly interesting operating system project that, like so many others, deserved a better fate.
There’s a version of computing history where the desktop OS that won wasn’t Windows. Not because the alternative was Unix-based or because Apple pulled off something different, but because an operating system designed at the University of Tokyo in 1984 was ambitious enough to try to replace the file system with a hypermedia document model, run on a custom Japanese CPU architecture, and encode 1.5 million characters, only to have a US trade report single it out as an unfair trade barrier in 1989.
That project was TRON (The Real-time Operating system Nucleus), a real, government-backed Japanese computing initiative whose desktop variant, BTRON, was named in a US trade barrier report and effectively killed before it could reach schools nationwide. Meanwhile, its embedded counterpart, ITRON, quietly became one of the most deployed operating systems in history.
TRON’s history has since attracted some genuinely wild conspiracy theories, including one claiming that Japan Airlines Flight 123 was deliberately crashed in order to target the TRON developers on board, despite there being no evidence that any TRON developers were even on the flight. But the strangest part of the story isn’t even a conspiracy theory: BTRON’s hypermedia desktop was decades ahead of what the market could support, and SoftBank founder Masayoshi Son may have helped sink it from the inside.
↫ Adam Conway at XDA
The most interesting part of TRON for me was the different ways it treated files and documents compared to other operating systems. Instead of focusing on applications and files as the core interaction points for users, it focused on the document. While most operating systems associate specific files with specific applications, TRON associated individual components of documents with individual handlers. If you want to edit a Word document today, you open Word and do all your editing work inside Word, whether you’re editing blocks of text or an image, or you open entirely different applications when Word’s capabilities for a certain component in a document are too limited. In TRON, you’d open a document, and only once you wanted to edit specific components did it “open” an “application” to perform the editing, without actually leaving the document in question.
Want to edit an image inside your document? In most operating systems, you’d have to open a separate image editor, load the relevant image file into it, make your edits, save the image file, and then paste said edited image file back into your document. There’s a considerable amount of overhead here that shouldn’t really exist; a computer is more than smart enough to open up just the editing controls from a different application if need be. In our current paradigm, applications often “solve” this by adding ever more features and controls and tools to cover every possible object or component you might have to deal with, but that just makes applications more complex, more bloated, and more difficult to use.
TRON’s approach has been tried in a variety of times and places, but it never caught on. My personal pet theory is that the application-first model is far better at wealth extraction and concentration than TRON’s model, and as such, that’s what we ended up with. If a user’s document and all of its constituent parts are tied to and wrapped up into a single application from a single vendor, it’s much easier to control said user and extract wealth from them than when that user can just pick and choose whatever handler they want to use for whatever object they happen to run into in a document, without having to open tons of different applications and move, copy, and paste stuff all the time.
In fact, this is also why consistency in user interface design is now all but dead; application developers and vendors use their own weird, non-standard, custom user interfaces for branding purposes. Sticking to a platform’s standards and conventions makes it harder to stand out and put your “brand” in people’s faces. But I digress.
Regardless, I’m not sure if all the stories about the US trying to bury TRON have any real value to them, as even the article itself notes (undoing its own clickbaity headline) that the project already seemed to be in dire straights even before it got a buried mention in some trade document. On top of that, ITRON, the embedded TRON variant, survived and thrives to this very day, powering untold numbers of devices. It seems to have done quite well for itself, supposed US government intervention or no.
This article by Steven J. Searle also takes a look at the workstation-focused variant of TRON.
What you’re describing sounds like it inspired Microsoft’s OLE and the Macintosh’s OpenDoc and all the other compound document frameworks that came later.
…the rise of the Internet either killed them or relegated them to very niche uses for the same reason that it killed off Mac OS Resource Forks as a concept… and it’s not wealth extraction.
It’s that they were a great idea in the era when exchanging documents outside a single company’s LAN or WAN was primarily done by some kind of flattening/rasterizing process like printing to paper or PDF, but they become a massive source of friction when you want to send the preferred editing form beyond the reach of your IT department.
Once the Internet exploded, the requirement that the recipient manually acquire not just MS Word (which we’ve become desensitized to requiring), but the handlers for any embedded subdocuments became prohibitive.
Heck, that’s why, before measures were agreed upon to ensure “browser is able to download the fonts on demand” wouldn’t become mass copyright infringement if implemented, websites limited their use of Internet Explorer’s support for requesting specific fonts to the set of fonts Microsoft was de facto forced to give away for free in perpetuity as the “Microsoft TrueType Core Fonts” downloadable bundle so websites could trust they’d always be available.
In short, if you want to push back against wealth extraction in a way that can actually compete in the arena of convenience that killed classical compound documents, focus on solving the dependency issue.
In this day and age, when you’re competing with no-install web apps, the answer would probably be following TiddlyWiki’s lead and implementing rich documents as HTML files that embed their own editing UI and override Ctrl+S to write out the changed document in a format that preserves the embedded self-editing application, and then offering an optional add-on like TiddlyFox which removes the need for “Save” to always be “Save As…”. (Yes, TiddlyWiki is an entire multi-page wiki, including editing application, in a single HTML file.)
(Likewise, I think Resource Forks in the Internet era could have worked… as long as there was a sufficiently advanced mechanism for knowing what file formats should have their resource forks discarded (eg. PNG, JPEG, MP3, etc.) vs. automatically AppleSingle-encoded when uploading or copying to a non-HFS+ filesystem and an MIT-licensed I/O library so non-mac platforms could use them too, similar to how SQLite is now used…. or just collaboration with other OSes to transparently support AppleSingle decoding.)
The problem with TiddlyWiki is its configuration through plugins and the fragile undo system.
I know because I’ve bundled it : https://github.com/wenuam/wm_app_doc_wiki_tiddly__Bob
Otherwise it’s a great way to organize notes, using the mermaid graph and vis-network modules.
Standardization is key, right? This is a non-problem for images and video. There’s some competition in the space, so manufacturers must follow standards. You won’t see a camera manufacturer coming around and “hey, jpeg is dead”. Or Adobe deciding that everyone must use PSD and they won’t support TIFFs anymore. It’s easy for a text editor handing a file with embedded images to offer built-in editors.
The same goes with video. You can export decision lists. I’ve not seen people having major problems to collaborate with people who use different products. For audio, my band uses Cubase in our garage but our producer prefers Logic. No problems as well. Import the assets and it’s good.
So exactly the problem is that, even with XML, Microsoft and other monopolies just won’t follow standards. A cousin of mine runs a small business and tried to migrate to LibreOffice and recipients kept complaining the documents didn’t open correctly. She has so collaborate with externals so she succumbed to the pressure. If Microsoft kept Word documents ISO-standard, any operating system could offer basic visualization features and call any sort of application to edit embedded images. You could have a TRON-like modern system that would allow you to choose your favorite embedded image editor and the system would open it in a plugin-like way.
Now that half of the world is rent-based SaaS, there’s absolutely no market incentive to making data portable. Our data live in online silos and interoperability is up to complicated APIs or manual import/convert/export. Wealth extraction, as you have mentioned.
I recall well Office 97/2000. Double clicking an image within Word would open a simple image editor. You could edit the source data for a chart from within Word as well, and it was quite cool to see the original sheet getting updated.
Heck, if you go back a couple of decades, even though it’s very clear that TRON is not UNIX, a common point is clear: in UNIX, you get text as the data exchange format of excellence, so you can just pipe away and be happy.
I’m pretty sure the US *never* intervene anywhere around the globe to favor their own technologies and market.
I remember the OpenDoc era; the promises being particularly pitched to the DTP crowd, that the embedded table could be a live spreadsheet from any number of spreadsheet vendors, the image could be an instance of the actual image editor, again from any number of competing vendors…
But in practice what it meant was that you needed to make multiple small purchases to get a functional DTP workspace, and (this was before PDF was really a thing) if you sent your file to a service bureaux to RIP to an imagesetter, they had to own all the same OpenDoc components you owned so they could open your file (just making sure your image and font file structure was correctly bundled on the SyQuest cartridge was bad enough).
Document-based computing is one of those ideas that happen over and over in tech, where people who invent an idea that might work well in a single usage paradigm, then assume it has a universal applicability. If your computing life is based on using dashboard UI paradigms, and doing slide decks… maybe it’s for you, but that’s only a small fraction of use cases.