6 ms·

This PumpkinOS project is pretty incredible. I can't imagine how much effort it would take to be compatible with all the system calls that the average Palm app

This PumpkinOS project is pretty incredible. I can't imagine how much effort it would take to be compatible with all the system calls that the average Palm app would expect. I remember Palm did some truly weird things with memory: 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. Stuff like that must have been challenging (and fun) to implement in PumpkinOS. This brings me back. I used to make little games for Palm OS, and I was so excited for the next version of the OS which would let one use the (then new) Palm OS Development Suite to make programs. It was also the last OS I've used where an app had a central event loop. Everything else today has UI frameworks that handle it for you. Things are easier now, but I still miss it.

jsheard 3y ago
> 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.
grishka 3y ago
> It was also the last OS I've used where an app had a central event loop. Windows is still like that if you use Win32 APIs directly. All GUI toolkits ever made are like that, but in most of the modern ones, this queue and loop are usually internal and you can only infer their existence by looking at the stack in a debugger or when something crashes.
- pjmlp 3y ago
  > Windows is still like that if you use Win32 APIs directly. Which is basically the only option for C and C++ developers, when using vanilla Visual Studio, unless they want to write libraries to be consumed by .NET instead, or use a third party framework. It is either raw Win32 or MFC, don't even bother with WinUI.
- p_l 3y ago
  Windows doesn't actually have a central event loop, which makes it pretty unique. macOS/iOS/etc have a central event loop in Cocoa - what more only initial thread is allowed to talk with windowserver! Xlib pretty much enforced single event loop per connection - XCB allowed more. In comparison, win32 applications can create an event loop ("message pump") per thread, and you can use GUI calls completely independently on them.
  - kjs3 3y ago
    I recall there was an Ada X11 server (Mitre?) that used tasks instead of a single event loop, although they may have been papering over an event loop underneath.
    - p_l 3y ago
      X11 server side is a bit different case - generally you control all message flows there in custom way. The windows message loop is essentially something you can create per thread, and "GUI" programs have one initialized for them (thus WinMain instead of main in C). But you need no special work to create more threads with more loops, in fact making every top-level window a separate thread is trivial (doing it for sub-windows like widgets might be slightly more complex though).
NegativeLatency 3y ago
One nice thing about modern hardware would be that you wouldn't exactly be memory constrained. You'd get to implement a complicated API with whatever large size chunk of memory you wanted, since 128 MB of ram or how ever much they came with is peanuts today.
- toast0 3y ago
  > since 128 MB of ram or how ever much they came with is peanuts today. The first Palm (Pilot 1000) had 128 kB. I think the biggest 68k Palm was the Palm Vx with 8MB. Towards the end of the (Intel) ARM Palms, they did have 128 MB models though.
  - Tor3 3y ago
    I think only the latest Treo had 128MB - the last PDA (Lifedrive) had 64MB, the TX 32MB. (One should remember though that there wasn't mass storage+RAM as we typically think of it - the memory of the Palm devices was storage and active memory in one. Battery-backup'ed until the very latest models. There wasn't a filesystem as such. So all this memory should be thought of as memory for applications, nor like storage in an Android device.)
    - Tor3 3y ago
      .. should not be thought of.. was what I meant to write. The memory is neither app memory nor storage, but both at once. The once-Windows based PDAs also used a combined memory setup, but there one section of the memory was for running apps, the rest for storage, i.e. different from PalmOS.
    - TeaBrain 3y ago
      Do you recall how the memory worked for the expanded storage on Palm OS devices that supported it? I had a Sony Clie TG-50, which supported Sony's proprietary pro duo memory cards, allowing me to expand the storage with a 2gb card, from the original 11mg of usable shared memory. I also recall that there was some sort of directory app, which allowed for the observing of files on either the device or the card. I'm curious how this would have worked.
jeanchen 3y ago
I loved Palm games! Those were the best mobile games, nothing modern compares to them at all.
Someone 3y ago
> I remember Palm did some truly weird things with memory: 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. Stuff like that must have been challenging (and fun) to implement in PumpkinOS. That’s extremely easy on modern hardware with gigabytes of RAM (compared to 2 megabytes on the pal pilot III): just use malloc, never move memory around, and make locking and unlocking such blocks no-ops. If there is an OS call to determine lock state, you’ll have to store that somewhere, but that isn’t difficult, either. It also isn’t hard to implement the way they did back then; it ‘just’ complicates using it.
deleted 3y ago
[deleted]

jsheard 3y ago

> 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.

grishka 3y ago

> It was also the last OS I've used where an app had a central event loop. Windows is still like that if you use Win32 APIs directly. All GUI toolkits ever made are like that, but in most of the modern ones, this queue and loop are usually internal and you can only infer their existence by looking at the stack in a debugger or when something crashes.

pjmlp 3y ago
> Windows is still like that if you use Win32 APIs directly. Which is basically the only option for C and C++ developers, when using vanilla Visual Studio, unless they want to write libraries to be consumed by .NET instead, or use a third party framework. It is either raw Win32 or MFC, don't even bother with WinUI.
p_l 3y ago
Windows doesn't actually have a central event loop, which makes it pretty unique. macOS/iOS/etc have a central event loop in Cocoa - what more only initial thread is allowed to talk with windowserver! Xlib pretty much enforced single event loop per connection - XCB allowed more. In comparison, win32 applications can create an event loop ("message pump") per thread, and you can use GUI calls completely independently on them.
- kjs3 3y ago
  I recall there was an Ada X11 server (Mitre?) that used tasks instead of a single event loop, although they may have been papering over an event loop underneath.
  - p_l 3y ago
    X11 server side is a bit different case - generally you control all message flows there in custom way. The windows message loop is essentially something you can create per thread, and "GUI" programs have one initialized for them (thus WinMain instead of main in C). But you need no special work to create more threads with more loops, in fact making every top-level window a separate thread is trivial (doing it for sub-windows like widgets might be slightly more complex though).

NegativeLatency 3y ago

One nice thing about modern hardware would be that you wouldn't exactly be memory constrained. You'd get to implement a complicated API with whatever large size chunk of memory you wanted, since 128 MB of ram or how ever much they came with is peanuts today.

toast0 3y ago
> since 128 MB of ram or how ever much they came with is peanuts today. The first Palm (Pilot 1000) had 128 kB. I think the biggest 68k Palm was the Palm Vx with 8MB. Towards the end of the (Intel) ARM Palms, they did have 128 MB models though.
- Tor3 3y ago
  I think only the latest Treo had 128MB - the last PDA (Lifedrive) had 64MB, the TX 32MB. (One should remember though that there wasn't mass storage+RAM as we typically think of it - the memory of the Palm devices was storage and active memory in one. Battery-backup'ed until the very latest models. There wasn't a filesystem as such. So all this memory should be thought of as memory for applications, nor like storage in an Android device.)
  - Tor3 3y ago
    .. should not be thought of.. was what I meant to write. The memory is neither app memory nor storage, but both at once. The once-Windows based PDAs also used a combined memory setup, but there one section of the memory was for running apps, the rest for storage, i.e. different from PalmOS.
  - TeaBrain 3y ago
    Do you recall how the memory worked for the expanded storage on Palm OS devices that supported it? I had a Sony Clie TG-50, which supported Sony's proprietary pro duo memory cards, allowing me to expand the storage with a 2gb card, from the original 11mg of usable shared memory. I also recall that there was some sort of directory app, which allowed for the observing of files on either the device or the card. I'm curious how this would have worked.

jeanchen 3y ago

I loved Palm games! Those were the best mobile games, nothing modern compares to them at all.

Someone 3y ago

> I remember Palm did some truly weird things with memory: 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. Stuff like that must have been challenging (and fun) to implement in PumpkinOS. That’s extremely easy on modern hardware with gigabytes of RAM (compared to 2 megabytes on the pal pilot III): just use malloc, never move memory around, and make locking and unlocking such blocks no-ops. If there is an OS call to determine lock state, you’ll have to store that somewhere, but that isn’t difficult, either. It also isn’t hard to implement the way they did back then; it ‘just’ complicates using it.

deleted 3y ago

[deleted]