6 ms·

> anything moderately large would need to be put into a special memory block that the OS could rearrange at will, and one would need to lock the block's handle

> anything moderately large would need to be put into a special memory block that the OS could rearrange at will, and one would need to lock the block's handle to keep it stable while accessing it Didn't 16-bit Windows and classic Mac OS do something similar? If you're doing multitasking on a system without an MMU then I think that kind of live heap defragmentation would have been practically required.

wmf 3y ago
Palm was started by ex-Apple people and borrowed a lot of ideas and mistakes from the Mac.
- deleted 3y ago
  [deleted]
- lproven 3y ago
  More saliently than that, Palm started out as a vendor of Newton apps, before it started making its own Newton-killer hardware. Palm's Graffiti started out as an alternate text input system for the Newton. It was an Apple software vendor long before it was an Apple rival, and its design is influenced by the Newton more proximally than the Mac.
- memsom 3y ago
  Well - it is even more than that. They basically used Apple style code resources to define PalmOS apps. You used to be able to compile Think Pascal code on a Mac, and some guy has worked out how to use that code resource to convert it in to a PalmOS app with just tweaking the code resources in the compiled MacOS code. It was quite mind bending to me as a 20-something PalmOS fanboy with a day job doing Delphi. This was in like, 1998/1999 or so. I even went as far as emulating MacOS just to play with it. I don;t know if his code still exists online, but the tool was called SARC (Swiss Army Resource Compiler) is anyone cares to search for it. I don't think Palm did a lot to change the exe format in the early days. And they used the same CodeWarrior 68K compiler that also targeted MacOS at the time.
xmm 3y ago
Classic MacOS did, but it's definitely not something needed for multitasking without an MMU. For instance AmigaOS didn't do this, but instead effectively had a single shared heap.
- alexey-salmin 3y ago
  How do you free the shared heap when an application quits?
  - vidarh 3y ago
    Very carefully. It's in fact one of the biggest issues with AmigaOS that made it incredibly hard to add proper MMU support. The OS is heavily message-passing based, and it's not at all always clear "from the outside" who the owner of a given structure passed via a message port (which is little more than a linked list) is, and so the OS doesn't even know which task (process/thread - the distinction was pretty meaningless due to the lack of memory protection) owns a given piece of memory. Later versions added some (optional) resource tracking to make it easier to ensure resources are freed, but if an application crashed or was buggy you'd frequently leak memory, and eventually have to reboot. It was not great, but usually less awful than it sounds with sufficiently defensive strategies. [I have at various points when e.g. doing some work on AROS way back, argued that it is is quite likely possible to largely untangle this; partially because for a lot of cases, the ownership changes are clear and rules that fit actual uses can be determined; partially because the set of extant AmigaOS apps is small enough you could "just" add some new calls that does ownership tracking, declare the old ones legacy, and map ownership changes for the rest one by one and either patch them, or, say, add a data file for the OS to use to apply heuristics; had the remaining userbase been larger maybe it'd have been worth it]
    - kazinator 3y ago
      That situation doesn't prevent an MMU and virtual memory. It prevents multiple address spaces. Multiple address spaces per process are not a requirement for virtual memory, as such. They are a requirement for getting some of the protection benefits of virtual memory. Not all the benefits. With a single address space for all applications, there can still be user/kernel protection: userland not being able to trash kernel data structures. (Of course with important system functions residing in various daemons, when those processes get trashed, it's as good as the system being trashed.)
kmeisthax 3y ago
Yes. The idea wasn't to get away with not having an MMU, though - it was to get away with shipping the Mac with an ungodly low amount of RAM for a machine with a GUI. I believe the original idea was to ship with like 64k or something? Obviously, with the state of mobile hardware back then relocatable blocks were also similarly necessary in order to save RAM. For anyone wondering, no, this isn't the thing that made classic Mac OS unfit for multitasking. The MMU is necessary to keep applications from writing other apps' heaps, not to do memory defragmentation. You can do some cool software-transparent defragmentation tricks with MMUs, but if you're deciding what the ABI looks like ahead of time, then you can just make everyone carry double-pointers to everything.
- NegativeLatency 3y ago
  I actually installed an aftermarket MMU in my Macintosh II, since it's required for A/UX. https://retrocomputing.stackexchange.com/questions/10931/what-was-the-design-of-the-macintosh-iis-mmu-replacement https://retrocomputing.stackexchange.com/questions/10931/wha... https://aux-penelope.com https://aux-penelope.com
- spc476 3y ago
  Well, there's also the fact that the MC68000 in the original Mac didn't have an MMU, and it was difficult to add an external MMU to a 68000 system [1]. You could use an MMU sanely starting with the MC68010, and it wasn't until I think the MC68030 that the CPU came with an integrated MMU. [1] Because exceptions on the 68000 didn't save enough information to restart the faulting instruction. You could get around this, but it involved using two 68000s as insane hack ...
  - JNRowe 3y ago
    Just to muddy the waters some more there was also an EC variant¹ of the 030 without the MMU. The EC variant was available right through to the 060, and I'd be curious to know how prevalent the line was. I suspect the EC versions far outnumbered the "full" chips, because they appeared in all kinds of industrial systems. I'm basing that entirely on working for a company that was still shipping products with MMU-less 68k and coldfire this century, not any real data. ¹ https://en.wikipedia.org/wiki/Motorola_68030#Variants https://en.wikipedia.org/wiki/Motorola_68030#Variants
MaulingMonkey 3y ago
> Didn't 16-bit Windows and classic Mac OS do something similar? I assume this is what `{Local,Global}{Lock,Unlock}` were for when combined with `{Local,Global}Alloc({L,G}MEM_MOVEABLE)` Similar idioms occasionally persist in modern code - e.g. when dealing with FFI in GCed languages (C#'s `fixed` statement pins memory in place.)
- asveikau 3y ago
  The lock/unlock metaphor is also used when sharing buffers with video or a/v apis in Windows. And the "safe array" type from COM/OLE.
  - saagarjha 3y ago
    And macOS too, with CVPixelBuffer.
pjmlp 3y ago
Windows 16 bit did, but it required a MMU anyway, at least since Windows 3, that was its big feature, 16 bit protected mode and a VM mode for running MS-DOS.
- skissane 3y ago
  > Windows 16 bit did, but it required a MMU anyway, at least since Windows 3 Windows 3.0 supported three modes of operation: real mode (8086 minimum), standard mode (286 minimum), 386 Enhanced mode (386 minimum). Real mode was pretty limited, and a lot of apps could not fit in its rather limited memory, but it was not completely useless. I believe real mode Windows apps could use EMS, although I’m not sure if many actually did In Windows 3.1, real mode was removed, and only standard and 386 Enhanced were supported. So, 3.1 was the first version to “require an MMU”, if by that you mean a 286 or higher
  - pjmlp 3y ago
    Yes you're right, but I never knew anyone that would get Windows 3, only to keep using it as Windows 2.

wmf 3y ago

Palm was started by ex-Apple people and borrowed a lot of ideas and mistakes from the Mac.

deleted 3y ago
[deleted]
lproven 3y ago
More saliently than that, Palm started out as a vendor of Newton apps, before it started making its own Newton-killer hardware. Palm's Graffiti started out as an alternate text input system for the Newton. It was an Apple software vendor long before it was an Apple rival, and its design is influenced by the Newton more proximally than the Mac.
memsom 3y ago
Well - it is even more than that. They basically used Apple style code resources to define PalmOS apps. You used to be able to compile Think Pascal code on a Mac, and some guy has worked out how to use that code resource to convert it in to a PalmOS app with just tweaking the code resources in the compiled MacOS code. It was quite mind bending to me as a 20-something PalmOS fanboy with a day job doing Delphi. This was in like, 1998/1999 or so. I even went as far as emulating MacOS just to play with it. I don;t know if his code still exists online, but the tool was called SARC (Swiss Army Resource Compiler) is anyone cares to search for it. I don't think Palm did a lot to change the exe format in the early days. And they used the same CodeWarrior 68K compiler that also targeted MacOS at the time.

xmm 3y ago

Classic MacOS did, but it's definitely not something needed for multitasking without an MMU. For instance AmigaOS didn't do this, but instead effectively had a single shared heap.

alexey-salmin 3y ago
How do you free the shared heap when an application quits?
- vidarh 3y ago
  Very carefully. It's in fact one of the biggest issues with AmigaOS that made it incredibly hard to add proper MMU support. The OS is heavily message-passing based, and it's not at all always clear "from the outside" who the owner of a given structure passed via a message port (which is little more than a linked list) is, and so the OS doesn't even know which task (process/thread - the distinction was pretty meaningless due to the lack of memory protection) owns a given piece of memory. Later versions added some (optional) resource tracking to make it easier to ensure resources are freed, but if an application crashed or was buggy you'd frequently leak memory, and eventually have to reboot. It was not great, but usually less awful than it sounds with sufficiently defensive strategies. [I have at various points when e.g. doing some work on AROS way back, argued that it is is quite likely possible to largely untangle this; partially because for a lot of cases, the ownership changes are clear and rules that fit actual uses can be determined; partially because the set of extant AmigaOS apps is small enough you could "just" add some new calls that does ownership tracking, declare the old ones legacy, and map ownership changes for the rest one by one and either patch them, or, say, add a data file for the OS to use to apply heuristics; had the remaining userbase been larger maybe it'd have been worth it]
  - kazinator 3y ago
    That situation doesn't prevent an MMU and virtual memory. It prevents multiple address spaces. Multiple address spaces per process are not a requirement for virtual memory, as such. They are a requirement for getting some of the protection benefits of virtual memory. Not all the benefits. With a single address space for all applications, there can still be user/kernel protection: userland not being able to trash kernel data structures. (Of course with important system functions residing in various daemons, when those processes get trashed, it's as good as the system being trashed.)

kmeisthax 3y ago

Yes. The idea wasn't to get away with not having an MMU, though - it was to get away with shipping the Mac with an ungodly low amount of RAM for a machine with a GUI. I believe the original idea was to ship with like 64k or something? Obviously, with the state of mobile hardware back then relocatable blocks were also similarly necessary in order to save RAM. For anyone wondering, no, this isn't the thing that made classic Mac OS unfit for multitasking. The MMU is necessary to keep applications from writing other apps' heaps, not to do memory defragmentation. You can do some cool software-transparent defragmentation tricks with MMUs, but if you're deciding what the ABI looks like ahead of time, then you can just make everyone carry double-pointers to everything.

NegativeLatency 3y ago
I actually installed an aftermarket MMU in my Macintosh II, since it's required for A/UX. https://retrocomputing.stackexchange.com/questions/10931/what-was-the-design-of-the-macintosh-iis-mmu-replacement https://retrocomputing.stackexchange.com/questions/10931/wha... https://aux-penelope.com https://aux-penelope.com
spc476 3y ago
Well, there's also the fact that the MC68000 in the original Mac didn't have an MMU, and it was difficult to add an external MMU to a 68000 system [1]. You could use an MMU sanely starting with the MC68010, and it wasn't until I think the MC68030 that the CPU came with an integrated MMU. [1] Because exceptions on the 68000 didn't save enough information to restart the faulting instruction. You could get around this, but it involved using two 68000s as insane hack ...
- JNRowe 3y ago
  Just to muddy the waters some more there was also an EC variant¹ of the 030 without the MMU. The EC variant was available right through to the 060, and I'd be curious to know how prevalent the line was. I suspect the EC versions far outnumbered the "full" chips, because they appeared in all kinds of industrial systems. I'm basing that entirely on working for a company that was still shipping products with MMU-less 68k and coldfire this century, not any real data. ¹ https://en.wikipedia.org/wiki/Motorola_68030#Variants https://en.wikipedia.org/wiki/Motorola_68030#Variants

MaulingMonkey 3y ago

> Didn't 16-bit Windows and classic Mac OS do something similar? I assume this is what `{Local,Global}{Lock,Unlock}` were for when combined with `{Local,Global}Alloc({L,G}MEM_MOVEABLE)` Similar idioms occasionally persist in modern code - e.g. when dealing with FFI in GCed languages (C#'s `fixed` statement pins memory in place.)

asveikau 3y ago
The lock/unlock metaphor is also used when sharing buffers with video or a/v apis in Windows. And the "safe array" type from COM/OLE.
- saagarjha 3y ago
  And macOS too, with CVPixelBuffer.

pjmlp 3y ago

Windows 16 bit did, but it required a MMU anyway, at least since Windows 3, that was its big feature, 16 bit protected mode and a VM mode for running MS-DOS.

skissane 3y ago
> Windows 16 bit did, but it required a MMU anyway, at least since Windows 3 Windows 3.0 supported three modes of operation: real mode (8086 minimum), standard mode (286 minimum), 386 Enhanced mode (386 minimum). Real mode was pretty limited, and a lot of apps could not fit in its rather limited memory, but it was not completely useless. I believe real mode Windows apps could use EMS, although I’m not sure if many actually did In Windows 3.1, real mode was removed, and only standard and 386 Enhanced were supported. So, 3.1 was the first version to “require an MMU”, if by that you mean a 286 or higher
- pjmlp 3y ago
  Yes you're right, but I never knew anyone that would get Windows 3, only to keep using it as Windows 2.