10 ms·

> A/UX was very impressive for its time — 1988, before Windows 3.0. It could run both Unix apps and classic MacOS ones, and put a friendly face on Unix, which w

> A/UX was very impressive for its time — 1988, before Windows 3.0. It could run both Unix apps and classic MacOS ones, and put a friendly face on Unix, which was pretty ugly in the late 1980s and early 1990s. I realize I really don't know much about A/UX at all. I didn't even know it could run classic MacOS apps. Does anyone have a link to more about the OS? I always assumed it was just a clone of System V, but if it could run classic MacOS apps, that meant it was more than just that.

protomyth 8y ago
It was more than a System V licensee, but it only ran on the 68K line of Macs, so it really didn't have a chance and was dead before Copeland.
ghaff 8y ago
The Wikipedia article [1] is reasonably thorough. It was a licensed System V with some BSD features (and Apple UI, etc.) added. (Most of the Unixes of that era mixed System V and BSD together to various degrees.) According to the linked article, it ran a few MacOS apps but not many. I actually have an A/UX coffee mug on my shelf complete with a phone number to call for more information (no URL or email :-)) [1] https://en.wikipedia.org/wiki/A/UX https://en.wikipedia.org/wiki/A/UX
classichasclass 8y ago
It can run some. The Finder is basically System 7.0, with all that implies. Some CDEVs and INITs will work in it, and some others will not only not work but (from personal experience) make it impossible to bring up the Mac side. Some Mac apps will balk at what's missing from the OS or are used to playing fast and loose in ways A/UX will prohibit. That said, it is remarkable how the two sides work together. It's not a perfect union because X apps still have to come up in a dedicated X server which runs on the Mac side, so even graphical apps don't come together seamlessly. But even within its limitations it presents a compelling illusion of a unified whole and Commando is a great way to discover command line options.
- Taniwha 8y ago
  most of the really bad issues were things that were broken in OS7 running VM too - mostly it was people messing with the upper 8 bits of pointers directly rathyer than using the standard handle APIs, but expecting to be able to write directly to hardware devices or 'knowing' about undocumented stuff inside the ROMs was also an issue
salgernon 8y ago
There's an emulator that was written to run just a/ux: https://github.com/pruten/shoebill https://github.com/pruten/shoebill You need to track down roms and install media.
Taniwha 8y ago
I worked on the original port (did about half the kernel stuff) - it was our standard SystemV with berkeley sockets, and wrote some of Apple specific stuff (kernel event manager, appletalk etc) - one thing I was particularly proud of was on the fly loadable unix device drivers, somewhat ahead of their time - feel free to ask me questions The Mac compatibility stuff (done at Apple) essentially ran in a single unix thread - really a VM for the mac OS7 world - it ran in user mode (mac OS apps usually ran in kernel mode) and emulated exceptions
- jamesfmilne 8y ago
  Hi Taniwha I’m working on a new Ethernet card for the Mac SE/30, and I’d love to be able to get if working with A/UX 3. https://www.mactothefuture.org/ https://www.mactothefuture.org/ If you had any pointers on how one could write an Ethernet driver for A/UX I’d be very appreciative! :-)
  - Taniwha 8y ago
    oooh .... sadly I haven't had access to kernel source for maybe 30 years, it's been a long time essentially you need to write a BSD style networking driver (of the era, so likely 4.1) along with interrupts/etc I think without source it's going to be really difficult - on the other hand you can use autoconfig to load it into an old kernel, hook up the interrupts and set it running
    - jamesfmilne 8y ago
      Cheers. I'll see what I can dig out of the fossil record about autoconfig ;-)
      - Taniwha 8y ago
        autoconfig is essentially a front end like the linux module loading tools, it makes some fake COFF files containing the kernel symbol table and some glue code and links them against the driver(s) you want to load, then it loads the code into kernel space, patches the block/char major tables and calls a driver's init routine Sadly it's not as functional as we would like, I actually wrote it for UniSoft as a way we could sell drivers without building kernels every time, someone at Apple saw it and not only demanded we include it in A/UX but also demanded that they own it .... so I wrote another one for Apple, it worked differently and was barely functional - Apple could have had the original better one for free if they'd dropped the demand that they owned it

protomyth 8y ago

It was more than a System V licensee, but it only ran on the 68K line of Macs, so it really didn't have a chance and was dead before Copeland.

ghaff 8y ago

The Wikipedia article [1] is reasonably thorough. It was a licensed System V with some BSD features (and Apple UI, etc.) added. (Most of the Unixes of that era mixed System V and BSD together to various degrees.) According to the linked article, it ran a few MacOS apps but not many. I actually have an A/UX coffee mug on my shelf complete with a phone number to call for more information (no URL or email :-)) [1] https://en.wikipedia.org/wiki/A/UX https://en.wikipedia.org/wiki/A/UX

classichasclass 8y ago

It can run some. The Finder is basically System 7.0, with all that implies. Some CDEVs and INITs will work in it, and some others will not only not work but (from personal experience) make it impossible to bring up the Mac side. Some Mac apps will balk at what's missing from the OS or are used to playing fast and loose in ways A/UX will prohibit. That said, it is remarkable how the two sides work together. It's not a perfect union because X apps still have to come up in a dedicated X server which runs on the Mac side, so even graphical apps don't come together seamlessly. But even within its limitations it presents a compelling illusion of a unified whole and Commando is a great way to discover command line options.

Taniwha 8y ago
most of the really bad issues were things that were broken in OS7 running VM too - mostly it was people messing with the upper 8 bits of pointers directly rathyer than using the standard handle APIs, but expecting to be able to write directly to hardware devices or 'knowing' about undocumented stuff inside the ROMs was also an issue

salgernon 8y ago

There's an emulator that was written to run just a/ux: https://github.com/pruten/shoebill https://github.com/pruten/shoebill You need to track down roms and install media.

Taniwha 8y ago

I worked on the original port (did about half the kernel stuff) - it was our standard SystemV with berkeley sockets, and wrote some of Apple specific stuff (kernel event manager, appletalk etc) - one thing I was particularly proud of was on the fly loadable unix device drivers, somewhat ahead of their time - feel free to ask me questions The Mac compatibility stuff (done at Apple) essentially ran in a single unix thread - really a VM for the mac OS7 world - it ran in user mode (mac OS apps usually ran in kernel mode) and emulated exceptions

jamesfmilne 8y ago
Hi Taniwha I’m working on a new Ethernet card for the Mac SE/30, and I’d love to be able to get if working with A/UX 3. https://www.mactothefuture.org/ https://www.mactothefuture.org/ If you had any pointers on how one could write an Ethernet driver for A/UX I’d be very appreciative! :-)
- Taniwha 8y ago
  oooh .... sadly I haven't had access to kernel source for maybe 30 years, it's been a long time essentially you need to write a BSD style networking driver (of the era, so likely 4.1) along with interrupts/etc I think without source it's going to be really difficult - on the other hand you can use autoconfig to load it into an old kernel, hook up the interrupts and set it running
  - jamesfmilne 8y ago
    Cheers. I'll see what I can dig out of the fossil record about autoconfig ;-)
    - Taniwha 8y ago
      autoconfig is essentially a front end like the linux module loading tools, it makes some fake COFF files containing the kernel symbol table and some glue code and links them against the driver(s) you want to load, then it loads the code into kernel space, patches the block/char major tables and calls a driver's init routine Sadly it's not as functional as we would like, I actually wrote it for UniSoft as a way we could sell drivers without building kernels every time, someone at Apple saw it and not only demanded we include it in A/UX but also demanded that they own it .... so I wrote another one for Apple, it worked differently and was barely functional - Apple could have had the original better one for free if they'd dropped the demand that they owned it