5 ms·

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 arguabl

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.

rvba 2y ago
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 2y ago
  > 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/ https://github.com/skissane/MOSI/ – but I doubt that ever saw much use.

rvba 2y ago

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 2y ago
> 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/ https://github.com/skissane/MOSI/ – but I doubt that ever saw much use.