[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.