3 ms·

Classic Mac was like this (as were other systems) - the toolbox started in rom, but the OS would patch out it's jump table (effectively) as needed to add new fu

Classic Mac was like this (as were other systems) - the toolbox started in rom, but the OS would patch out it's jump table (effectively) as needed to add new functionality or fix bugs - but since the interface and data structures were basically what was defined in 1984 for much of it, it was really easy to insert yourself as a third party up and down the system. It was a lot of fun - and completely fell apart because of memory safety issues.

retrac 3y ago
Even more so with the Mac's predecessor, the Lisa. Lisa didn't really have the concept of "applications" or "user programs". The "document" was a central feature, a core OS concept. Programs provided the OS with handlers for new document objects, which might be interactive. No programs ever started or exited from the user's perspective; it was always the same document interface, with slightly different document properties, depending on the document. In the background it was transparently loading and running the different handlers as OS tasks. No concept of "saving a file" either; the document state was implicitly always preserved when you closed it. It was mostly programmed in object-oriented Pascal. One of the first big uses of an OO language. And it was terribly big and slow, requiring a fatally expensive amount of RAM at the time. A lot of those abstractions were stripped out for Macintosh in a bid to slim things down extensively, and they have not really been tried elsewhere since.
- esjeon 3y ago
  > The "document" was a central feature, a core OS concept. Isn't this largely the same in the modern desktop? File explorers do call handlers for each files. But it's also true that the recent trends among apps half-killed the concept of file explorer - they use built-in search functions these days. It's good in its own ways, but often it's necessary to go through filesystem when working with multiple apps, which can be awkward in terms of data management. Also, many apps automatically save states on close. A problem is that the behavior is far from being standardized, and there are tons of different ways how apps handle their states. This usually gets really painful, as one must learn each app through trial-and-error.
hakfoo 3y ago
The PC could go there somewhat too; you have the interrupt vector table at the bottom of memory, nominally in control of the BIOS. If you invent a new disc controller, for example, you can change the vector for Interrupt 0x19 to point to your code, and if you realize from the body of the request that the call was intended for another device, you pass it on to the original code. There were two problems: * The standard BIOS features were somewhat limited and narrow. * They added enough overhead that you might want to ignore them and start fiddling with registers directly. This was especially true for video control (BIOS Interrupt 0x10). Nobody was going to follow through on the proper way of stuffing the framebuffer when it was memory mapped and you could just dump stuff straight into it. So on the one hand, it meant a BIOS-level compatibility wasn't enough, and it also forced hardware rictus (I could imagine, for example, a video standard which communicated with I/O ports to open up more addressable memory, but there's no way it would support anything but the most well-behaved software).

retrac 3y ago

Even more so with the Mac's predecessor, the Lisa. Lisa didn't really have the concept of "applications" or "user programs". The "document" was a central feature, a core OS concept. Programs provided the OS with handlers for new document objects, which might be interactive. No programs ever started or exited from the user's perspective; it was always the same document interface, with slightly different document properties, depending on the document. In the background it was transparently loading and running the different handlers as OS tasks. No concept of "saving a file" either; the document state was implicitly always preserved when you closed it. It was mostly programmed in object-oriented Pascal. One of the first big uses of an OO language. And it was terribly big and slow, requiring a fatally expensive amount of RAM at the time. A lot of those abstractions were stripped out for Macintosh in a bid to slim things down extensively, and they have not really been tried elsewhere since.

esjeon 3y ago
> The "document" was a central feature, a core OS concept. Isn't this largely the same in the modern desktop? File explorers do call handlers for each files. But it's also true that the recent trends among apps half-killed the concept of file explorer - they use built-in search functions these days. It's good in its own ways, but often it's necessary to go through filesystem when working with multiple apps, which can be awkward in terms of data management. Also, many apps automatically save states on close. A problem is that the behavior is far from being standardized, and there are tons of different ways how apps handle their states. This usually gets really painful, as one must learn each app through trial-and-error.

hakfoo 3y ago

The PC could go there somewhat too; you have the interrupt vector table at the bottom of memory, nominally in control of the BIOS. If you invent a new disc controller, for example, you can change the vector for Interrupt 0x19 to point to your code, and if you realize from the body of the request that the call was intended for another device, you pass it on to the original code. There were two problems: * The standard BIOS features were somewhat limited and narrow. * They added enough overhead that you might want to ignore them and start fiddling with registers directly. This was especially true for video control (BIOS Interrupt 0x10). Nobody was going to follow through on the proper way of stuffing the framebuffer when it was memory mapped and you could just dump stuff straight into it. So on the one hand, it meant a BIOS-level compatibility wasn't enough, and it also forced hardware rictus (I could imagine, for example, a video standard which communicated with I/O ports to open up more addressable memory, but there's no way it would support anything but the most well-behaved software).