[academi]

Could someone add support to automatically test this on an emulator?

Or, better yet, put in checks that prohibit future code from including those bad char seqs?

This is bigger than the cool pics of nostalgic hardware.

It reminds me of other compatibility problems over the years like:

1. Microsoft choosing the opposite slash and a different way of doing CLI options via slash vs dash.

2. Windows, Apple, and Linux not agreeing on a good filesystem and method of network access and supporting it together. Incompatibilities have wasted a great deal of time, and it’s unreasonable to think that every IT department will make changes to allow everything to work smoothly.

3. Microsoft Office, Lync, Skype for Business, Remote Desktop, etc. not including 1:1 functionality in the macOS versions of their products. This is evil since the user can’t do things that others can. Similarly, Microsoft changed menus and where things are located between versions. Should a wooden chair be the Mac version of a couch because they’re both butt-compatible? Should marmite be the next version of strawberry jam because they both spread on toast and are tasty?

4. Programming language tools and libraries that favor one OS over another or one well-used database over another.

While supporting compatibility can be a timesuck, here we have fish shell spending the time supporting a minority, which is great.

But large companies, leaders of small well-used projects, and everything in-between are self-sabotaging the future of all life on our planet by wasting others’ time because they want to do their own thing or want to make people not like some other company’s product.

Incompatibility and not working together isn’t healthy competition, beneficial capitalism, or good business. It’s going to kill us.

[arghwhat]

1. That's a symbol conflict, dating back to TOPS-10 that used forward slash for option separators[1]. \ was picked instead as it was shift-free as well, and directly opposite / on IBM Model F keyboards[2].

2. All those platforms have supported mutually compatible formats for as long as that has been relevant (that is, after some standardization on network hardware). That local variants stems from different OS's having different features that need support. E.g., Windows' complex ACLs vs. POSIX permissions (support for ACLs on UNIX-like platforms came later).

3. Office for Mac was a product developed by an entirely different team, having no relation to the regular office products. It's natural it was not identical. However, the solution here is not to force Microsoft to make 1:1 products for all platforms. It's to let alternatives grow: No one needs nor wants Microsoft Remote Desktop for Linux. We have FreeRDP, Remmina, and others. Don't monopolize computing.

4. You can either try to hide an OS and inevitably favor one over another (thereby significantly crippling the others), or you can expose everything (which usually leads to complaints about how much work it is for the developer).

---

1. http://www.os2museum.com/wp/why-does-windows-really-use-back...

2. https://en.wikipedia.org/wiki/Model_F_keyboard#/media/File:I...

[academi]

1. It could have and still could be fixed. WSL commands and syntax are not yet integrated as an optional standard command shell. It’s separate and not equal.

2. Mutually compatible doesn’t solve all of the time wasted having to reformat as FAT32 or NTFS or to configure and support multiple filesystems like CIFS and NFS.

3. MS calls it Office. It’s neither the same team nor the same product. The macOS versions of the product are crippled with less configurability and fewer expected features. MacOS Remote Desktop provided by Microsoft is not equivalent to RDPing from Windows 10. And why shouldn’t you have the same product available for Linux? How do you know what those users want?

4. Another option would be to collaborate.

My point is not that anyone specifically dropped the ball, but that incompatibility and some kinds of changes waste time and resources.

Healthy competition is doing the best you can do, not tripping your opponent or excluding them from the race.

[laumars]

1. You can use UNIX style slashes in NT and it works fine. It’s just the default is to represent them using \ because CP/M and DOS originally used / as flag prefixes back before their respective file systems supported hierarchical directories.

To be honest your point is a little like moaning that Windows 10 doesn’t use GRUB or that FreeBSD doesn’t use systemd. Sometimes those differences are the differentiators, ie part of the OS design, and thus why you’d pick one OS over another OS.

2. CIFS and NFS is a protocol not a file system. Also see answer to point 1.

3. Product names are just another form of metadata. If you want 1st party Microsoft support then naturally you’d use a Microsoft operating system. Also see my reply to point 1.

4. You’re not asking for collaboration though. You’re asking for uniformity. Collaboration is different solutions that agree on supporting the same standards. Uniformity is when the same solutions are pushed on every platform. The later is a monopoly and that is very the antipathy of what Linux stands for.

[skissane]

> 1. It could have and still could be fixed

Microsoft actually tried to fix it in DOS 2.0 with SWITCHCHAR. In CONFIG.SYS, you could specify SWITCHCHAR=/ or SWITCHCHAR=-, and then there was an API (INT 21,37) programs could call to find out which to use.

However, they pulled this feature from the 2.0 documentation, and then mostly removed it in 3.0 (some vestiges remained, but it was non-functional). I think the big problem they faced was that while programs shipped with DOS would respect the SWITCHCHAR setting, third-party programs wouldn't (at least until new versions using that API were released). I think they found out that it was too late and all too hard due to the backward compatibility constraints with the already (even by then) vast base of existing DOS software.