> Why didn't they push this instead of the very limited MS-DOS?

Hardware requirements.

For a (quite long) while the plan was to keep DOS for microcomputers and Xenix for the serious stuff. DOS gained some extensions that made it very Xenix/UNIX-like (like subdirectories, pipes, "-" as command line switch char, device files in "\dev" instead of a global namespace, etc.).

I think for the time period, hobbyists can't be written off either. My dad got into Commodore and Atari in the late 70's/early 80's, and sparked my interest in software. Computing already wasn't cheap, but if the home consumer needed to pay for extra licensing fees, I could easily see adoption being far more limited to business. I think a lot of developers, myself included, got their start as hobbyists and never would have caught the "itch" to develop if for not this early exposure at home.

While MSDOS had subdirectories, pipes were not supported at the kernel level. It was simply a convenience of COMMAND.COM that simulated pipes by running each command sequentially. The command switch character was the slash (/) until the end, with the exception of a few non-standard third-party softwares insisting on the dash. Device names were always global namespace and \dev never existed in any form.

Did you copy-paste an hallucinating LLM?

No, it looks fair.

MS-DOS 1.x did not have subdirectories.

That came in with MS-DOS 2.x which is when the very rudimentary level of Xenix compatibility came in: device names such as `LPT1:` or `COM2:` could be prefixed as `/dev/lpt1` or `/dev/com2`. Pipes simulated in COMMAND.COM.

I don't recall DOS ever accepting command switches prefixed with `-` instead of `\` as standard, though.

The features were never turned on by default, so they are not popular knowledge (I used DOS since 2.x and never knew).

https://forum.winworldpc.com/discussion/comment/171783/#Comm... (devices in \dev, "-" as switch char, etc.).

> While MSDOS had subdirectories, pipes were not supported at the kernel level. It was simply a convenience of COMMAND.COM that simulated pipes by running each command sequentially.

You are confusing the lack of concurrency with lack of pipes -- the mere fact that COMMAND can do what you describe requires UNIX-like pipes and channels (e.g. stdin/out/err), and programs avoiding direct console I/O (way common for DOS programs...). Comm software such as Kermit did the same thing to simulate remote login (I used this one in the day, at least).

Hmm I remember switches always had to begin with “/“ in DOS

Yep, that must have been it. Porting it to BSD might have been more work and opened them up for a lawsuit.

How was Solaris an option then?

Good question but I don't know.

Apple did not create A/UX. It was created by UniSoft

https://en.wikipedia.org/wiki/UniSoft

https://virtuallyfun.com/2021/09/19/so-what-is-the-deal-with...

I'm guessing that Apple would have to pay a fee to both UniSoft and AT&T and maybe Sun was much larger and a partner with AT&T / Unix System Labs on SysV so maybe they could resell Solaris for cheaper.

Sun open sourced Solaris in 2008 for 2 years. Maybe AT&T / USL didn't care by then or maybe Sun's licensing agreement allowed them to do it. I don't know.

A/UX was also ridiculously insecure in its default configuration. It had a "guest" user, no password. I remember labs of Mac II or IIx systems at a local university, with public IP addresses, guest accounts, no passwords. A local BBS guy posted a message on how to get "free" internet access through the university's dialups. I think it was at least a month before things got locked down.

It was the time, only trustworthy people on the net so far. Told the story here about my mid-ninties job where I ran Quake servers on the lan before we had a firewall.

Yes, though contemporary OSes like SunOS were more secure than A/UX. Once you were on the network though, it was like swiss cheese (NIS / YP... unshadowed password files... etc.)

Interesting what-ifs. Perhaps offering the money they spent on Copeland to ATT could have bulk licensed it.