[flagged]
PumpkinOS, a Re-Implementation of PalmOS
41–50 of 141 posts
Re: PumpkinOS, a Re-Implementation of PalmOS
#42I remember investing in Palm thinking that they'd eventually be the ones to build something like the iphone. Sadly, they didn't and when apple did that was it for them.
Yeah, the GPL license cracked me up on this one. Can't imagine there's a danger of commercialization here..
GPL isn't about commercialization though, it allows commercialization. It's all about preventing closed-source forks.
Re: PumpkinOS, a Re-Implementation of PalmOS
#43This 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 accessi…
I loved Palm games! Those were the best mobile games, nothing modern compares to them at all.
Re: PumpkinOS, a Re-Implementation of PalmOS
#44Earlier quoted context omitted.
> 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.
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.
How do you free the shared heap when an application quits?
Re: PumpkinOS, a Re-Implementation of PalmOS
#45Nothing made me feel older than going to the Computer History Museum in Mountain View, CA and seeing a Palm Pilot in the display case. It should be illegal to show things which were an integral part of your life, a short 30'ish years ago, as if they were uncovered in the ruins of some pre-civilization. Not fair at all.
On Reddit a few months ago there was a post about someone finding their grandfather’s old gameboy.
Re: PumpkinOS, a Re-Implementation of PalmOS
#46I remember investing in Palm thinking that they'd eventually be the ones to build something like the iphone. Sadly, they didn't and when apple did that was it for them.
They did have the Treo line! Arguably, what ultimately brought Palm down was their early success and the huge library of existing shareware and freeware tools: They desperately needed to try something new (Palm OS was just showing its age as a single-threaded, in-RAM, non-virtual-memory-based OS), but couldn't, since it would have alienated long-time fans by stranding their existing software libraries. They could nev…
> They did have the Treo line!
Thank you for mentioning it. It makes me feel like I'm taking crazy pills when people talk about how Steve Jobs invented the smartphone. I had a series of Treos starting with the Treo 270: https://en.wikipedia.org/wiki/Treo_270
As somebody who carried a Palm for years, it was so amazing to suddenly have the internet in my pocket. It still is, really.
Re: PumpkinOS, a Re-Implementation of PalmOS
#47Earlier quoted context omitted.
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.
How do you free the shared heap when an application quits?
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]
Re: PumpkinOS, a Re-Implementation of PalmOS
#48Earlier quoted context omitted.
> 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.
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 cl…
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 ...
Re: PumpkinOS, a Re-Implementation of PalmOS
#49Earlier quoted context omitted.
How do you free the shared heap when an application quits?
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 meaningl…
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.)
Re: PumpkinOS, a Re-Implementation of PalmOS
#50This 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 accessi…
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.
> 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.