[skissane]

I didn't watch the video but I skim read the YouTube transcript.

The video doesn't propose any single explanation, just a series of events all of which arguably set back Japan's indigenous software industry. A few of the incidents it mentions include (my summary below is more based on my own knowledge of the topic, than what the video specifically mentions):

Fujitsu and Hitachi cloned IBM mainframes. So did lots of other companies. At the time they started doing it, IBM was (intentionally) releasing their software into the public domain. However, in 1969, IBM announced they'd start copyrighting their software. Initially they still released the core OS (primarily MVS) into the public domain, and only copyrighted add-ons. However, as the 1970s progressed, more and more new functionality went into the copyrighted add-ons, while the public domain core received only limited enhancements. Finally, in the early 1980s, they put the whole OS under copyright. This left Fujitsu and Hitachi in a difficult position. They were used to getting their mainframe OS from IBM for free, and suddenly they couldn't legally do that any more. Legal choices for them would have included: (1) fork IBM's operating system and create new enhancements themselves (either clone IBM's copyrighted enhancements by clean-room engineering, or design their own incompatible enhancements), (2) negotiate with IBM for a license (unclear if IBM would agree, and may have cost $$$), (3) license an alternative operating system (e.g. UNIX), (4) build their own OS from scratch. But none of those options appealed to them (or maybe they tried some and it wasn't working out), so they decide to go with option (5): illegally copy IBM's copyrighted mainframe operating systems. They used the fact that IBM still shipped the source code for much of its copyrighted software to customers, and somehow got customers to (illegally) hand that source code over. They made rather trivial changes to the source code to try to hide the copying–for example, Fujitsu renamed a lot of IBM routines whose name started with the letter I, to start with the letter J instead. They searched and replaced IBM copyright notices with their own. They even bribed IBM employees to give them IBM confidential material (the IBM employees accepted the bribes as part of an FBI sting operation). And IBM found out, and sued both Fujitsu and Hitachi, and the settlement of the suit required Fujitsu and Hitachi to pay IBM hundreds of millions of dollars, and also banned Fujitsu and Hitachi from continuing to sell the software outside Japan (IBM agreed to let them continue selling it in Japan, in exchange for them paying licensing fees.)

Other stuff I know about this topic (not in the video): In the 1980s and early 1990s, Fujitsu mainframes were quite popular in Australia, but due to this settlement, by the end of the 1990s, basically all of Fujitsu's Australian mainframe customers had either migrated to IBM mainframes, or else to non-mainframe platforms. There are still Fujitsu and Hitachi mainframes running in Japan today, but they are deeply legacy, basically stuck in the 1990s – they didn't follow IBM's transition to 64-bit in 2001. Fujitsu and Hitachi weren't the only mainframe vendors faced with this problem, but other vendors sought to solve it within the confines of the law. In the US, Amdahl had the same issue, but it decided to focus on their Unix variant UTS instead of MVS. (Amdahl did have an internal project to build a clone of IBM's MVS, apparently based on legal clean-room reverse engineering, called Aspen, but it got caught in development hell, and Amdahl cancelled it before they ever officially shipped it, although possibly a few customers got beta test versions.) Germany's Nixdorf had a fork of IBM's DOS/VS operating system (for low-end mainframes), which they got by acquiring the American company TCSC; they ported the Unix clone Coherent to run on top of it, before killing it off in the late 1980s when Nixdorf decided to give up on mainframes and focus purely on Unix instead. Other mainframe vendors didn't have this problem because their operating systems were not based on IBM's – for example, the other Japanese mainframe vendor, NEC, their mainframes run a fork of GE/Honeywell/Bull's GCOS operating system (ACOS), which NEC legally licensed.

Another incident the video discusses is the TRON project, which was a Japanese indigenous standard for operating system APIs, endorsed by the Japanese government, conceptually similar to POSIX. It included both variants aimed at general purpose computing (BTRON) and embedded systems (ITRON). However, this frightened the US software industry, which convinced the US government to declare TRON a "trade barrier". And that mostly killed TRON as an operating system. TRON didn't die completely, it still sees some use in embedded systems even today (the video mentions the Nintendo Switch Joy-Con controllers run it), but it never achieved the original vision of becoming Japan's standard operating system. Instead, Microsoft Windows did.

And then there were also macroeconomic issues (Japan's real estate crisis in the 1990s), and cultural issues – it mentions how the Japanese government encouraged Japanese industry to focus on copying successful Western technologies, even improving them incrementally in the process, as opposed to coming up with fundamentally novel technologies of their own. That approach served Japan very well for industries such as cars, but doesn't work so well for the software industry.

[zzo38computer]

I had tried to figure out some of the details of TRON but some are difficult to find due to being Japanese and/or some files seems to be missing.

(I think ITRON is still in use, but BTRON and CTRON are not as common these days, as far as I know.)

There is also FOSS implementation of BTRON called B-Free but it is seems to be incomplete, and as far as I can tell is abandoned. (There is also year 2053 problem, which could be mitigated by using 64-bit timestamps, and some other problems.)

(I had also had idea of my own operating system design, which also uses TRON character code, as well as other things. This can also be made operating system standard which multiple implementations could be made up, I would hope.)

[skissane]

The ITRON specs can be downloaded from the TRON website: https://www.tron.org/specifications/

Most of them are available in English, although a few of the more peripheral specs are Japanese-only.

At least some of the BTRON and CTRON specs were published in English - http://tronweb.super-nova.co.jp/tronspecs.html - but don’t appear to be available online.

CTRON appears to have been based on OSI-I see references to FTAM and MOTIS (the X.400 mail transport protocol)-and also advertised support for ISDN as a key feature-which would make it very dated by today’s standards

I can’t find any references to actual specs for MTRON. I am wondering if it was ever actually specified, or if it was just vapourware

> (I had also had idea of my own operating system design, which also uses TRON character code,

You don’t need a whole operating system for that. It could just be a library which supported converting TRON code to other character sets, displaying text in TRON code, etc.

[zzo38computer]

> The ITRON specs can be downloaded from the TRON website

I had seen that, but many things (including many of the older stuff) seems to be missing.

However, some stuff I had found elsewhere (not from TRON website), and I had been able to partially figure out from the Japanese documentation and had been able to write a program that can partially parse the TRON Application Databus format. However, many things I could not figure out very well.

I had also found what seems to be some document of TRON instruction set (I have some interest in the instruction sets of some older computers, not only TRON), but is Japanese and also seems that some files are missing, anyways. So, I don't know its working anyways. (I also found some English documentation but it does not actually explain much, although there is a few minor explanation of them.)

> CTRON appears to have been based on OSI-I see references to FTAM and MOTIS (the X.400 mail transport protocol)

However, I think X.400 uses ASN.1, and ASN.1 does not have a TRON string data type (I had once also wanted to use this in something else (unrelated to X.400 mail and CTRON), so I used the octet string type instead).

> I can’t find any references to actual specs for MTRON. I am wondering if it was ever actually specified, or if it was just vapourware

That was my guess as well, but I don't know either.

> You don’t need a whole operating system for that. It could just be a library which supported converting TRON code to other character sets, displaying text in TRON code, etc.

You are right, I do not need a whole operating system for that (see below). But, the operating system design is helpful for many other things. The use of TRON character code is only one of its features; it also has many other features, many of which are difference from POSIX and other systems (although some things are similar to other systems). (I had written elsewhere about my ideas of operating system designs, too.)

I had done some of the other stuff relating to TRON code in Linux too (although it is incomplete). I have written some programs that can display text, I had made fonts with TRON character set (although not all planes are implemented), and some programs that can convert some character codes (including e.g. EUC-JP, EUC-CN, EUC-KR). I had also been able to write partial English documentation from what I could figure out (which I documented on Just Solve The File Format Problem Wiki), although much of it is difficult.

(One of the problems I have is the way the GT fonts are coded; they are several TrueType fonts, that use an improper Unicode mapping that does not seem to have anything to do with the actual Unicode characters that those numbers are supposed to correspond to (except font 1, which does correspond correctly to Unicode), and the mapping of improper Unicode into TRON code is given in a large PDF file, and the mapping seems to not have any sort of reasonable order, and that I could not figure out how to handle automatically. If I could figure out how to handle it properly then I could implement a file that can use them with the TRON code directly; someone who is Japanese and is able to compare the characters to figure out how to make up your own bitmap fonts with the GT character set, could do that too, I suppose.)

[skissane]

The main selling point of the TRON character code, from what I understand, is CJKV speakers who disagree with Han unification.

But it sounds like you don’t know Japanese. Do you know another CJKV language? If not, what makes the TRON character code attractive to you?

Personally TRON interests me simply because it is an OS API which looks rather different from POSIX, and I’m interested in learning about other ways of doing things - just maybe some of those other ways of doing things contain some good ideas. But the TRON character code doesn’t really, since as a non-CJKV speaker, the debate about Han unification has no practical relevance, but rejecting that is the main selling point of the TRON encoding.

[zzo38computer]

> But it sounds like you don’t know Japanese.

Actually, I do know a little bit, but not very well. (I still don't like Han unification though. Also, that is not the only problem with Unicode (and some other character sets) anyways. Furthermore, I also think that one character set will not be suitable for all purposes anyways (and that it is not possible to make it so), so I also have interest to allow additional character sets to be available for use.)

> Personally TRON interests me simply because it is an OS API which looks rather different from POSIX, and I’m interested in learning about other ways of doing things - just maybe some of those other ways of doing things contain some good ideas.

I am also interested in it for this reason, too. (I also have interest to learn of some old Japanese computer systems, too.) (As you could see, I did mention stuff other than TRON character code, too)

[skissane]

> Furthermore, I also think that one character set will not be suitable for all purposes anyways (and that it is not possible to make it so), so I also have interest to allow additional character sets to be available for use.)

There are a number of libraries in existence for converting between character sets. ICU is one of the most famous but it is Unicode-centric (it supports many character sets but wants to use Unicode as a lowest common denominator.) But older libraries such as iconv or recode lack ICU’s Unicode-centricity, so might be more appealing to you. Have you thought about doing something like contributing TRON support to recode?

https://github.com/rrthomas/recode - I always called it “GNU recode”, but https://www.gnu.org/software/recode/ says it isn’t a GNU package, even though for a long time the GNU website hosted it. (I think maybe it is “ex-GNU”: the GNU project maintainer retired, and the new maintainer who took over wasn’t willing to abide by the GNU project’s policies.)

[rvba]

It makes sense to have one stanfard across the world. This way good software can come from multiple countries.

But... killing TRON probably helped a lot. Look at consoles - somehow nintendo can come with good software made by good, creative programmers.

Maybe the soft was killed by trade barriers.. and more trivial things - such as software developer being a poorly paid dead end job in Japan?

[skissane]

> It makes sense to have one stanfard across the world. This way good software can come from multiple countries.

TRON was not the only attempt to define a standardised operating system API in the 1980s. As well as TRON and POSIX, another was IEEE Std 855-1990 (Microprocessor Operating System Interface or MOSI for short). But POSIX was the only one which really succeeded.

MOSI is pretty obscure, but my impression of what happened there – in the early 1980s, 8-bit platforms were widely popular, but very incompatible with each other (e.g. software written for Apple II could not run on Commodore 64 even though they both had 6502 CPUs). So the proposal for a common OS API was made, and an IEEE standards committee started standardising it. But by the time the standard was finished, those 8-bit platforms were declining, and IEEE was left with a standard focused on the needs of a declining market, and so very few ever used it. [0] (MOSI itself isn't inherently 8-bit – like POSIX it is a source-level standard rather than a binary-level standard, so could be used on 16-bit or 32-bit systems – but its feature set was a lowest common denominator of what 8-bit systems supported, so not very attractive for machines that have the memory to do much more.)

In 1988, the Japanese education ministry decided to make BTRON the standard operating system for Japanese schools. From what I understand, this move frightened Microsoft (among others), who feared that it would prevent DOS/Windows from being used in Japanese schools, or else force Microsoft to add a BTRON compatibility subsystem to their operating systems. So Microsoft lobbied the US government to pressure the Japanese government, and that pressure resulted in the Japanese education ministry dropping the requirement for BTRON, which in turn largely killed BTRON off. It didn't completely die; a variant of BTRON (Cho-Kanji) continues to be developed into this century, but it is a niche product whose primary value proposition is far more comprehensive support for obscure Kanji characters than mainstream Unicode-based operating systems (maybe useful if you do research into historical Japanese texts). Another factor in killing the Japanese education ministry's requirement for BTRON, was domestic opposition from NEC – at the time, NEC PC-98 machines running DOS were the de facto standard in the Japanese education system, and BTRON threatened NEC's dominance of that market. It could well have been a combination of both external pressure from the US government and internal pressure from NEC that killed it.

Related is Ada Programming Support Environment (APSE) and Common APSE Interface Set (CAIS). Part of the US DOD project which resulted in Ada, whose requirements demanded not only a standard programming language, but also a standard development environment, with APIs for integrating with compilers, editors, version control, build tools, etc. CAIS is standardised in MIL STD-1838A. So it is like POSIX/MOSI/BTRON, a cross-operating system API, albeit one focused on the needs of software development rather than general purpose computing–implementations of CAIS existed for Unix, OpenVMS and MVS, so development tools written against the CAIS API could run on all three operating systems. And the US government poured untold amounts of money into it, but I'm not sure if anyone ever used it. Probably some military projects did.

And APSE/CAIS in turn inspired PCTE (Portable Common Tool Environment), which was basically the EU's answer to APSE/CAIS. And just like APSE/CAIS, it consumed large quantities of EU research funding, before eventually being forgotten without ever seeing much if any real world use. It is standardised as ISO/IEC 13719–which apparently nobody uses, but ISO keeps on renewing because withdrawing a standard consumes bureaucratic resources, and PCTE is so obscure nobody even wants to expend the effort on withdrawing it.

[0] There was an implementation of MOSI for CP/M-80 and Pascal-MT+ – you can find it at https://github.com/skissane/MOSI/ – but I doubt that ever saw much use.

[formerly_proven]

Siemens did real mainframes and their mainframe OS BS2000 is still around, it's just part of Fujitsu, Nixdorf appears in that story as well because that's how the Siemens mainframe division ended up at FSC (Siemens acquires Nixdorf, folds its mainframe division into that, then splits it up into the ATM business and sells the rest to Fujitsu).

[skissane]

Nixdorf shut down their mainframe business in 1989, and sold the remnants to Comparex (which started out as a Siemens-BASF joint venture, but Siemens withdrew around the same time as Comparex acquired Nixdorf's mainframe business). So when Siemens and Nixdorf merged in 1990, Siemens did not acquire Nixdorf's mainframe business, only Nixdorf's other product lines (Unix systems, ATMs, etc). But Siemens still had their own mainframe business. Comparex already sold IBM-compatible mainframes, so they didn't continue Nixdorf's mainframes as an independent hardware line, they were primarily buying the support contracts and the customer base.

Siemens mainframes and Nixdorf mainframes had significant differences:

Siemens BS2000 mainframes were derived from RCA Spectra 70. Their ISA was mostly IBM-compatible in user mode (problem state), but significantly different in kernel mode (supervisor state), and their operating system was completely incompatible–the BS2000 operating system was derived from RCA TSOS. RCA sold their mainframe business to Sperry, who then merged with Burroughs to form Unisys. The RCA Spectra mainframes became Unisys' Series 90 mainframe line, and RCA TSOS was renamed to Unisys VS/9. But by the 1980s or early 1990s, the RCA-derived Unisys mainframe line was dead. Whereas, their Sperry and Burroughs heritage mainframe lines (Unisys OS 2200 and Unisys MCP) survive today, although now they are software emulators running on x86-64 servers instead of physical hardware. RCA Spectra/TSOS only survives today in the BS2000 branch, save that Siemens ended up selling it to Fujitsu.

By contrast, the Nixdorf mainframes were more straight IBM clones, and so aimed for instruction set compatibility both at the user application and operating system level, and could run IBM operating systems. They were mainly used with the low-end IBM DOS/360-derived operating systems rather than the high-end MVS operating system family. Nixdorf faced the same problem that Fujitsu and Hitachi did, of IBM closing their operating systems, but they solved it by buying the American software company TCSC, who maintained their own fork of the IBM mainframe DOS, called Edos, which Nixdorf then renamed NIDOS (Nixdorf DOS). TCSC had started Edos when IBM decided to make new DOS versions available only for S/370, not for older S/360 machines, hence Edos was originally a backport of those newer S/370-only DOS versions to the older S/360 machines. When Nixdorf bought TCSC, they renamed it NCSC. NIDOS ended up offering features that IBM DOS/VSE never had, like a Unix compatibility subsystem (PWS/VSE-AF, derived from Coherent) – much latter, MVS (now z/OS) and VM/CMS (now z/VM) ended up getting one, but DOS/VSE (later z/VSE and now VSE^n since IBM offloaded it to 21CSW) never has.

Siemens also once had a lower-end mainframe line, which ran an operating system optimised for smaller machines, BS1000. BS1000 was discontinued long ago, and there is little information about it online. There was a BS1000 compatibility subsystem for BS2000, called SIM-BS1000 [0], but I'd be surprised if anyone is still using it today.

And Siemens also had BS3000 mainframes – like Nixdorf mainframes, these were fully IBM compatible, and designed to be able to run IBM's operating systems – they ran the Siemens BS3000 operating system, which was a rebadging of Fujitsu MSP – Fujitsu stolen version of IBM MVS. Siemens had to enter into a settlement with IBM as a result, although I'm led to believe the terms were relatively lenient on Siemens, who did their best to portray themselves as innocent victims of Fujitsu's dishonesty. But that was the end of BS3000. I think the remnants of the Siemens BS3000 line ended up with Comparex too. Comparex finally shut down their IBM-compatible mainframe business in 2000; they survived as an IT services business until 2019, when they were acquired by SoftwareOne.

And then in 1999 Siemens transferred their mainframe business to the Fujitsu-Siemens joint venture, and in 2009 Fujitsu bought out Siemens, and hence Fujitsu ended up with Siemens mainframe business.

And so today Fujitsu has three totally incompatible mainframe lines – their own Fujitsu MSP mainframes (previously sold internationally but now only surviving in Japan), the ex-Siemens BS2000 (primarily surviving in Germany, although a little bit in the UK and a few other European countries), and the VME mainframes they got by buying ICL in 2002 (I believe the UK government is the sole remaining user, they really want to migrate off them but it is just too hard.) Both BS2000 and VME now run under x86-64, while I believe the Japanese line still has proprietary physical hardware.

[0] https://link.springer.com/chapter/10.1007/978-3-642-67415-0_...