4 ms·

I am amazed that 1980's software works on binary API compatibility rather than relying on API quirks like timing, memory alignment quirks, memory layout from s

I am amazed that 1980's software works on binary API compatibility rather than relying on API quirks like timing, memory alignment quirks, memory layout from specific allocator behaviour, etc. It only takes one unintentional reliance on an implementation detail to make an application not run on another OS implementation...

wmf 6mo ago
There were plenty of apps that relied on implementation quirks.
- CharlesW 6mo ago
  Out of curiosity, what app are you thinking of? Of all of types of software used with classic Mac OS (INITs, CDEVs, FKEYs, Desk Accessories, Drivers, etc.), apps would be the least likely to rely on implemention quirks.
  - wk_end 6mo ago
    Macintosh Common Lisp - at least the versions floating around Mac Garden and such - seems to refuse to run on anything besides accurate emulators and real hardware.
- eschaton 6mo ago
  They mostly relied on OS/Toolbox implementation quirks though, not hardware implementation quirks, because applications that relied on the latter wouldn’t run on the Macintosh XL and that mattered to certain market segments. (Like some people using spreadsheets, who were willing to trade CPU speed for screen size.) Similarly anything that tried to use floppy copy protection tricks wouldn’t work due to the different system design, so that wasn’t common among applications. So even things that wrote directly to the framebuffer would ask the OS for the address and bounds rather than hardcode them, copy protection would be implemented using license keys (crypto/hashes, not dongles) rather than weird track layouts on floppies, etc. It led to good enough forward compatibility that the substantial architectural changes in the Macintosh II were possible, and things just improved from there.
  - icodestuff 6mo ago
    Eh, there were plenty of games that were coded for a particular clock speed, and then once the SE came out, had an update that included a software version of a turbo button, let you select which of two speeds to run at. They run FAST on an SE/30 or Mac II and unusably fast on anything newer.
    - eschaton 6mo ago
      I didn’t encounter too many of those back in the day, I think because there was the VBL task mechanism for synchronizing with screen refresh that made it easy to avoid using instruction loops for timing. Much more common in my experience was the assumption that the framebuffer was 1-bit, but such games would still run on my IIci if I switched to black & white—they’d just use the upper left 3/4 of the screen since they still paid proper attention to the bytes-per-row in its GrafPort. Could be that by the time I was using a Mac II though that all the games that didn’t meet that minimum bar had already been weeded out.
      - flomo 6mo ago
        Yeah, there were a bunch of floppy games which only ran on an original Mac or maybe a Plus. No go with even my Mac SE.
- hyperrail 6mo ago
  Indeed, even ones from companies as big as Microsoft! There is a story in Writing Solid Code by Steve Maguire [1] where Apple asked Microsoft to fix hacks in its Mac apps that didn't conform to the developer docs in Inside Macintosh because such workarounds were required when the apps were first developed alongside the original Macintoshes. However, Microsoft's workarounds would be broken by a major System Software update under development at Apple, which naturally wanted to avoid having to permanently add back the implementation bugs and quirks that the workarounds either relied on or were meant to avoid. As Maguire told it, removing one such workaround in Microsoft Excel was hotly debated by the Excel team because it was in a hot-path 68k assembly function and rewriting the code to remove it would add 12 CPU cycles to the function runtime. The debate was eventually resolved by one developer who ran Excel's "3-hour torture test" and counted how many times the function in question was called. The total: about 76,000 times, so 12 more cycles each time would be about 910,000 cycles total... which on the Macintosh 128k's ~7 MHz 68000 CPU would be about 0.15 seconds added to a 3-hour test run. With the slowdown from removing the workaround thus proven to be utterly trivial, it was indeed removed. [1] https://openlibrary.org/books/OL1407270M/Writing_solid_code https://openlibrary.org/books/OL1407270M/Writing_solid_code - page 136, heading "Don't Overestimate the Cost"
Lerc 6mo ago
The Mac classic was about as pure as you could get from an architectural point of view. A 1 bit framebuffer and a CPU gets you most of what the machine can do. Most of the quirk abuse of 8-bit machines came from features that were provided with limitations. Sprites, but only 8 of them, colours but only 2 in any 8x8 cell. Multicolour but only in one of two palettes and you'll hate both. Almost all of the hacks were to get around the limitations of the features. I don't know if the decision apple made was specifically with future machines in mind. It certainly would have been a headache to make new machines 5 generations down the track if the first one had player missile graphics.
- philistine 6mo ago
  They absolutely knew that they were making a platform that needed as much hardware independence as possible. The 512k was already in development before they even finished the original, and they had the experience of the Apple II, which for all of Wozniak’s legendary work, was a dead-end because it relied too heavily on hardware hacks.
  - jjuran 6mo ago
    A Mac 512K of sorts was already built before the Macintosh introduction at the 1984 shareholders meeting — the demo wouldn't run in 128K of RAM.

wmf 6mo ago

There were plenty of apps that relied on implementation quirks.

CharlesW 6mo ago
Out of curiosity, what app are you thinking of? Of all of types of software used with classic Mac OS (INITs, CDEVs, FKEYs, Desk Accessories, Drivers, etc.), apps would be the least likely to rely on implemention quirks.
- wk_end 6mo ago
  Macintosh Common Lisp - at least the versions floating around Mac Garden and such - seems to refuse to run on anything besides accurate emulators and real hardware.
eschaton 6mo ago
They mostly relied on OS/Toolbox implementation quirks though, not hardware implementation quirks, because applications that relied on the latter wouldn’t run on the Macintosh XL and that mattered to certain market segments. (Like some people using spreadsheets, who were willing to trade CPU speed for screen size.) Similarly anything that tried to use floppy copy protection tricks wouldn’t work due to the different system design, so that wasn’t common among applications. So even things that wrote directly to the framebuffer would ask the OS for the address and bounds rather than hardcode them, copy protection would be implemented using license keys (crypto/hashes, not dongles) rather than weird track layouts on floppies, etc. It led to good enough forward compatibility that the substantial architectural changes in the Macintosh II were possible, and things just improved from there.
- icodestuff 6mo ago
  Eh, there were plenty of games that were coded for a particular clock speed, and then once the SE came out, had an update that included a software version of a turbo button, let you select which of two speeds to run at. They run FAST on an SE/30 or Mac II and unusably fast on anything newer.
  - eschaton 6mo ago
    I didn’t encounter too many of those back in the day, I think because there was the VBL task mechanism for synchronizing with screen refresh that made it easy to avoid using instruction loops for timing. Much more common in my experience was the assumption that the framebuffer was 1-bit, but such games would still run on my IIci if I switched to black & white—they’d just use the upper left 3/4 of the screen since they still paid proper attention to the bytes-per-row in its GrafPort. Could be that by the time I was using a Mac II though that all the games that didn’t meet that minimum bar had already been weeded out.
    - flomo 6mo ago
      Yeah, there were a bunch of floppy games which only ran on an original Mac or maybe a Plus. No go with even my Mac SE.
hyperrail 6mo ago
Indeed, even ones from companies as big as Microsoft! There is a story in Writing Solid Code by Steve Maguire [1] where Apple asked Microsoft to fix hacks in its Mac apps that didn't conform to the developer docs in Inside Macintosh because such workarounds were required when the apps were first developed alongside the original Macintoshes. However, Microsoft's workarounds would be broken by a major System Software update under development at Apple, which naturally wanted to avoid having to permanently add back the implementation bugs and quirks that the workarounds either relied on or were meant to avoid. As Maguire told it, removing one such workaround in Microsoft Excel was hotly debated by the Excel team because it was in a hot-path 68k assembly function and rewriting the code to remove it would add 12 CPU cycles to the function runtime. The debate was eventually resolved by one developer who ran Excel's "3-hour torture test" and counted how many times the function in question was called. The total: about 76,000 times, so 12 more cycles each time would be about 910,000 cycles total... which on the Macintosh 128k's ~7 MHz 68000 CPU would be about 0.15 seconds added to a 3-hour test run. With the slowdown from removing the workaround thus proven to be utterly trivial, it was indeed removed. [1] https://openlibrary.org/books/OL1407270M/Writing_solid_code https://openlibrary.org/books/OL1407270M/Writing_solid_code - page 136, heading "Don't Overestimate the Cost"

Lerc 6mo ago

The Mac classic was about as pure as you could get from an architectural point of view. A 1 bit framebuffer and a CPU gets you most of what the machine can do. Most of the quirk abuse of 8-bit machines came from features that were provided with limitations. Sprites, but only 8 of them, colours but only 2 in any 8x8 cell. Multicolour but only in one of two palettes and you'll hate both. Almost all of the hacks were to get around the limitations of the features. I don't know if the decision apple made was specifically with future machines in mind. It certainly would have been a headache to make new machines 5 generations down the track if the first one had player missile graphics.

philistine 6mo ago
They absolutely knew that they were making a platform that needed as much hardware independence as possible. The 512k was already in development before they even finished the original, and they had the experience of the Apple II, which for all of Wozniak’s legendary work, was a dead-end because it relied too heavily on hardware hacks.
- jjuran 6mo ago
  A Mac 512K of sorts was already built before the Macintosh introduction at the 1984 shareholders meeting — the demo wouldn't run in 128K of RAM.