<story><title>PumpkinOS, a Re-Implementation of PalmOS</title><url>https://github.com/migueletto/PumpkinOS</url></story><parent_chain><item><author>jsheard</author><text>&amp;gt; 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&amp;#x27;s handle to keep it stable while accessing it&lt;p&gt;Didn&amp;#x27;t 16-bit Windows and classic Mac OS do something similar? If you&amp;#x27;re doing multitasking on a system without an MMU then I think that kind of live heap defragmentation would have been practically required.</text></item><item><author>verdagon</author><text>This PumpkinOS project is pretty incredible. I can&amp;#x27;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&amp;#x27;s handle to keep it stable while accessing it. Stuff like that must have been challenging (and fun) to implement in PumpkinOS.&lt;p&gt;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&amp;#x27;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.</text></item></parent_chain><comment><author>kmeisthax</author><text>Yes. The idea wasn&amp;#x27;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?&lt;p&gt;Obviously, with the state of mobile hardware back then relocatable blocks were also similarly necessary in order to save RAM.&lt;p&gt;For anyone wondering, no, this isn&amp;#x27;t the thing that made classic Mac OS unfit for multitasking. The MMU is necessary to keep applications from writing other apps&amp;#x27; heaps, not to do memory defragmentation. You &lt;i&gt;can&lt;/i&gt; do some cool software-transparent defragmentation tricks with MMUs, but if you&amp;#x27;re deciding what the ABI looks like ahead of time, then you can just make everyone carry double-pointers to everything.</text></comment>
<story><title>PumpkinOS, a Re-Implementation of PalmOS</title><url>https://github.com/migueletto/PumpkinOS</url></story><parent_chain><item><author>jsheard</author><text>&amp;gt; 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&amp;#x27;s handle to keep it stable while accessing it&lt;p&gt;Didn&amp;#x27;t 16-bit Windows and classic Mac OS do something similar? If you&amp;#x27;re doing multitasking on a system without an MMU then I think that kind of live heap defragmentation would have been practically required.</text></item><item><author>verdagon</author><text>This PumpkinOS project is pretty incredible. I can&amp;#x27;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&amp;#x27;s handle to keep it stable while accessing it. Stuff like that must have been challenging (and fun) to implement in PumpkinOS.&lt;p&gt;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&amp;#x27;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.</text></item></parent_chain><comment><author>MaulingMonkey</author><text>&amp;gt; Didn&amp;#x27;t 16-bit Windows and classic Mac OS do something similar?&lt;p&gt;I assume this is what `{Local,Global}{Lock,Unlock}` were for when combined with `{Local,Global}Alloc({L,G}MEM_MOVEABLE)`&lt;p&gt;Similar idioms occasionally persist in modern code - e.g. when dealing with FFI in GCed languages (C#&amp;#x27;s `fixed` statement pins memory in place.)</text></comment>