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.
Ken Sakamura designed an OS family for the whole of Japanese society
He wanted all of it, silicon included
Ken Sakamura was a researcher at the University of Tokyo when he launched the TRON Project in 1984. It was an ambitious undertaking; he wanted a vertically integrated computing architecture that Japan could build its entire digital infrastructure on, from the microcontroller in a washing machine to the workstation on a desk to the telecom switch in a central office. The project had five sub-architectures: ITRON for embedded real-time systems, BTRON for personal computers, CTRON for mainframes and telecom switching, MTRON for cross-system coordination, and STRON, a hardware implementation of the real-time kernel.
The project designed its own CPU architecture, the TRON VLSI CPU, which Hitachi manufactured as the Gmicro/200 series. Hitachi actually produced and sold it, and it ended up powering some Japanese workstations and embedded systems throughout the late 1980s. Sakamura's team also drew up its own TRON keyboard layout, designed for efficient Japanese text input alongside programming symbols, and a real-time peripheral bus called micro-BTRON, based on IEEE 802.5 and intended as an alternative to MIDI for connecting "electronic stationery" peripherals, though that bus never shipped in a commercial product. The idea was that every layer, from silicon to user interface, would be designed together, with no compatibility debt to existing platforms.
The character encoding system, TRON Code, was arguably the most ambitious part. It supported multi-plane character switching via 0xFE escape codes, with 31 defined planes of 48,400 characters each, giving a theoretical capacity of 1,500,400 characters. By 1999, B-right/V R2 shipped with roughly 130,000 characters across 14 defined planes, covering JIS levels 1 and 2, Chinese GB 2312, Korean KS C 5601, Unicode's non-CJK range, and the Mojikyo collection of rare historical characters, and users could register new characters for free through the TRON Character Resource Center. To put that in perspective, Unicode 1.0 in 1991 defined 20,902 unified CJK ideographs, and TRON's CJK coverage exceeded Unicode's for well over a decade. A large part of that count came from Mojikyo, though, which separately encodes variant glyphs that Unicode unifies into single code points.
You can see the ambition from the very beginning, as the 1996 demo release includes a character-code viewer that lists its planes side by side: Japanese basic, Japanese supplementary, Chinese GB, Korean KSC, and 6-dot Braille. Braille is there as a first-class plane rather than an accessibility add-on bolted on later, and Unicode didn't encode Braille patterns at all until version 3.0 in 1999. For its time TRON Code was the best answer anyone had to a problem the rest of the industry was years from solving.
The project was backed by an actual organization: the TRON Association, established in 1986. Its members included Hitachi, Mitsubishi, Fujitsu, NEC, Matsushita, and Toshiba... basically every major Japanese electronics company of the era. On top of those domestic companies, foreign companies could join too, and several did. TRON was royalty-free and its specifications were open, which was a deliberate choice that would later allow ITRON to spread. The Japanese government, through MITI, supported the project as a national technology strategy, giving it the kind of institutional backing that most operating system projects could only dream of.
On top of all this, BTRON proposed something radical for desktops.
BTRON's desktop was decades ahead of where computing actually went
The file and the application were implementation details
BTRON's core idea was that the user-visible primitive on a desktop computer shouldn't be a file or the application, but the typed document part. In other words, a block of content with a stable identity and a declared type. Parts can contain other parts, and the same mechanisms that embed a figure in a report can also embed a report in a workspace, meaning that there was no special case for a top-level file.
This model could be found across the interface as well, and you can browse a container in 1B/V3 and see each entry carries its type in parentheses after the name. For example, a document called 中国・韓国料理ガイド（図形）, meaning "Chinese and Korean Cuisine Guide (Graphics)", describes this file as an image. In comparison, DOS would have given you an extension.
Parts were connected by typed links, stored in a system-managed link store rather than fragile string paths. Links survived renames, edits, and reorganizations, and applications weren't owners of files but handlers for part types. According to the BTRON3 specification, the first two halfwords of an application ID are the data type it applies to, and only the third distinguishes rival handlers for the same type. When a document contained writing, a table, and a figure, opening those parts made the system launch each one's registered handler to draw its own content inside the parent document's window. If no handler exists, or the handler fails to draw, the system strikes a diagonal line through the region where the content should have been.
BTRON also used a file system model called real-body/pseudo-body, which replaced the tree-structured directory hierarchy with an arbitrary directed graph. Files can exist in multiple locations without duplication, linked by the system rather than by symlinks or shortcuts, and the dictionary that powers Japanese text input is addressed the same way a cooking guide would be. Here, the TRON Application Databus format carries structured data between applications using a chunked segment structure with a common header, so a spreadsheet cell and a paragraph of text could be composed into the same document without the user ever having to think about file formats. Applications can skip data types they don't support, making interoperability a core aspect of the system.
Arguably, this is the same concept that tools like Roam, Logseq, and Obsidian have been rediscovering over the last decade. But BTRON proposed it as the fundamental OS abstraction in the mid-1980s, paired with a custom CPU and a real-time microkernel underneath. It's not that BTRON's implementation would feel smooth by modern standards, because the hardware it ran on was too slow for that, but the architecture was doing something conceptually different from anything that shipped commercially in the West at the time.
1B/V3 comes with a number of sample documents that show exactly this concept. One demonstration is a Microscript figure, which is a drawing canvas holding a green ball and a sloped surface, each a named object, with a text section dubbed SCRIPT in the same space. You can open the script and see "DEFINE 半径（ボール．W／2）", defining a radius as half the ball's width, then "SET 新Y ボール．Y+半径+速度Y／4" which advances the ball's position on each step. The script addresses the figure's contents as "ボール．X" and "斜面．W", meaning object and property, and the entire file is a single document rather than a program loading data files. Sure, a bouncing-ball simulation is a small thing to build, but the point is that it's a typed part inside the document instead of a dedicated application that owns it.
BTRON was made available in a small number of products in Japan: for example, the BrainPad TiPO PDA from Seiko Instruments had a version with a touchscreen and stylus. As well, B-right/V (also called Cho-Kanji) was available on commodity PC hardware through Personal Media Corporation, a company that still lists the software on its Japanese-language website today. This is 1B/V3, and I got the demo disk working in 86Box on an Apple Silicon Mac. All it needs, at minimum, is a mid-90s Pentium clone with 16MB of RAM and a Cirrus Logic video card.
Unfortunately, BTRON never got the distribution it needed, and by 1989 it had a much bigger problem than adoption.
The US government named TRON in a trade barrier report
Buried in Section 7
In April 1989, the Office of the US Trade Representative published its annual National Trade Estimate Report on Foreign Trade Barriers. Buried in Section 7, "Other Barriers," was a section about TRON. The report stated that the US had concerns about Japanese government market intervention to support the TRON OS and identified two specific markets where TRON was receiving government advantage.
The first advantage it was deemed to be benefiting from was in the industry of educational PCs. The Japanese Ministry of Education and MITI were developing a standard specification for computers being introduced into middle schools nationwide, and the specification was built around TRON. The second was NTT's next-generation digital communications network, which planned to adopt CTRON, the telecom variant. The report noted that while several US companies were members of the TRON Association, none were in a position to sell TRON-based products in either market.
The NTE report was an annual survey of foreign trade barriers, and it wasn't a sanctions list. The more aggressive Super 301 process, established by the 1988 Trade Act, was a separate mechanism that could escalate a dispute into investigation and negotiation, and TRON was never designated a Super 301 priority. The actual Japan designations that year were supercomputers, satellites, and forest products, as Carla Hills' May 25 statement confirms. No sanctions were ever applied to TRON, but it was clear that the US government had been spooked for some reason by the TRON project.
In fact, Ken Sakamura was surprised that it had been named at all. In an interview with Japan's Yomiuri Shimbun published in August 2026, he said: "TRON is open to the world, and American companies can use it freely. Why would it become a target of trade friction? I had no idea what was going on."
The TRON Association sent a written protest to the US government, and the US sent an inspection team to investigate as a result. By Sakamura's account, the matter was closed over a dinner where the USTR told him "On investigation, it turned out that BTRON is no harm. We are sorry for causing troubles to you if any." Unfortunately, by June 1989, the school adoption was dead.
Even though the legal reality was that TRON's naming in the survey was resolved, that mattered less than the reputational hit it took as a result. Japanese manufacturers interpreted the dispute as a signal that TRON had angered the US government, and staying associated with it could threaten their American business. Companies withdrew from TRON PC development left and right, and Yomiuri quotes an industry source describing the outcome bluntly: "TRON itself was never denied, but it became an OS with a blemish from America. We can't use it."
Funnily enough, the USTR's complaint had some validity to it. After all, the objection to TRON didn't come from it being closed off or exclusionary, but that the Japanese government was steering its procurement of two huge markets toward a domestic standard. This had the effect of excluding foreign vendors regardless of whether TRON's spec was open or not. However, what happened after, namely the reputational damage, is a lot harder to justify.
There's another side to this story, though, and it reframes things a little bit. In a book from Scott Callon in 1995, "Divided Sun: MITI and the Breakdown of Japanese High-Tech Industrial Policy," he argues that BTRON was already struggling with internal coordination problems and delayed hardware before the trade dispute, which made the controversy a convenient way to exit the market. An academic paper published in 2003, titled " Three Attempts at De-Wintelization," frames this dispute as just another event in a longer pattern of Japanese efforts to challenge the Wintel monopoly, each of which failed for a combination of political and structural reasons.
Even still, Matsushita Communication Industrial shipped the PanaCAL ET in 1990, which was a BTRON educational PC, but the momentum was well and truly gone at this stage. But there was another factor too, one that Sakamura himself would later describe as the real cause of the damage.
SoftBank's founder may have weaponized the report against BTRON
He published a book called 'The Tron Revolution' first
sakamura-son-accusation
There's a book from Japanese reporter Eiji Oshita, written in 1999 as a biography about Masayoshi Son. In the book, titled "Masayoshi Son: The Young Lion of Entrepreneurship," Oshita writes that Son had a direct incentive to sabotage the TRON project. Oshita states that Son was building a software distribution business around importing American PC software, and if TRON-based, Windows-incompatible PCs became the standard in Japanese schools (which was a captive market), then his business model would take a serious hit.
Oshita's biography further describes Son lobbying MITI officials, politicians, and business leaders to oppose TRON's adoption, arguing that TRON would isolate Japan from global computing standards. The TRON Association published an editorial in its own TRONWARE magazine in December 1999 titled "People who blocked the TRON project," which stated that "the person who destroyed BTRON using the USTR was not an American company, but a Japanese person."
Stranger still, the strongest corroboration of this allegation comes from Ken Sakamura himself. On the official TRON Project 30th Anniversary website, published sometime in 2014, Sakamura wrote a section called "An Unexpected Ending" that directly names Son. He describes how the Oshita biography details Son mobilizing every connection he had to oppose BTRON, and in Sakamura's own words: "I have to admit I was impressed by his thoroughness."
Son's SoftBank publishing division had published a book called "The Tron Revolution" in December 1988, four months before the USTR report that named TRON as a trade barrier.
All of this is from machine translations of Oshita's biography, the TRON project anniversary site, and other sources that appear to have never been published in English. It's important to know that the Yomiuri series approaches this claim far more apprehensively than Sakamura does: It says that "there was talk that Son opposed TRON," rather than outright accusing him of it. We don't know for sure if Son killed BTRON, but it's hard to dismiss Sakamura's own words as merely a rumor.
Sakamura goes further as well when he accuses Son, stating that Son used the US trade process as his way of sabotaging the project. He said that the person who destroyed BTRON did so "through what was essentially reputational damage leveraging the USTR," which isn't necessarily a claim that Son manufactured the NTE report, just that he exploited its existence. This particular detail, amongst many others, I couldn't find translated to English anywhere else, and it comes from someone who was essentially the father of the entire project.
To be fair to Sakamura as well, it actually lines up well with what happened, and explains several aspects of it. It certainly makes more sense than a claim that Son's lobbying and the US complaint were totally unrelated.
The embedded variant nobody noticed is in billions of devices
ITRON survived and became valuable infrastructure
While BTRON was dying, it was ITRON that was quietly spreading around the world. As an embedded real-time operating system, it didn't need a monitor, a keyboard, or a 1.5-million-character encoding space. All it needed was to be small, deterministic, and royalty-free, which it was. Remember the Java installer saying "3 billion devices run Java"? Yeah, we'll get to that in a second.
ITRON, and later T-Kernel, shipped in digital cameras, car engine control units, mobile phones, factory automation equipment, and home appliances. Casio's QV-10, the camera widely credited with sparking the digital camera revolution, ran on TRON, and Toyota even used it in engine control systems. On top of that, many first wave Japanese mobile phones ran on it too. In fact, this LinuxInsider article from 2003 calls ITRON "the most popular operating system in the world," and while nobody has published hard numbers since, the Yomiuri series reported that TRON-based operating systems still run in roughly 60% of the world's embedded devices.
TRON even got its own Java specification in the late 1990s, and it combined ITRON's real-time kernel with Sun's Java Runtime Environment. Commercial applications such as Aplix's JBlend came after, and Aplix says that JBlend shipped on more than 800 million devices. Not all 800 million of those were JTRON devices, since JBlend later became a portable Java platform that Aplix deployed across multiple operating systems, and there's no published breakdown of how many ran on ITRON. But it does mean that when that old Java installer proudly told you "3 billion devices run Java," some unknown number of those devices were almost certainly running Java alongside TRON.
A standardization effort has since cemented its longevity. In 2018, micro-T-Kernel 2.0 was adopted as IEEE standard 2050-2018, and in 2023, the IEEE recognized the TRON Real-time Operating System Family as an official Milestone, installing a plaque at the University of Tokyo. The TRON Forum, the successor to the original Association, still maintains the specifications and licenses the technology. Even more interesting is that, by Sakamura's account, Microsoft joined the TRON Project in 2003, through the efforts of its then-US vice president Furukawa. Microsoft really does seem to have a habit of supporting would-be competitors these days.
Unsurprisingly, the ambitious and politically targeted desktop variant failed. But it was the embedded variant nobody in the West paid attention to that managed to succeed to the point of becoming an important building block of day-to-day infrastructure. The same project produced what could well be the world's most-used operating system and an operating system that failed entirely, and it was the project that everyone was paying attention to that actually failed. You can still buy a BTRON implementation today if you know where to look, since Personal Media Corporation's website is still up and still selling Cho-Kanji, in Japanese only. The project's lasting mark on computing is invisible, though, running in the devices around you that you never think about as having an operating system at all.
Sakamura received the Takeda Prize jointly with Linus Torvalds and Richard Stallman, for spreading open architecture worldwide. After all, the same open approach that made TRON vulnerable in a trade dispute, the assumption that being open was protection enough, is what let ITRON spread without friction afterwards. Sakamura's apology, though, arrived after the damage had been done over dinner in 1989. The industry had already abandoned the project by that stage.
BTRON's hypermedia ideas are being rediscovered by a new generation of tools that don't know they're recreating a 40-year-old design. The character encoding is archived and the CPU is a museum piece. But the real-time kernel that nobody seemed to think of as an important piece of the puzzle still runs in places you'd never guess, and it's hard to think of a better legacy than that.
