Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PumpkinOS, a Re-Implementation of PalmOS

github.com

Post reply on HN
Print view View original

61–70 of 141 posts

Re: PumpkinOS, a Re-Implementation of PalmOS

#61

Post by tomashubelbauer »

johnwalkr wrote: post #45
frellus wrote: post #37

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

This one's funny because on one hand you have young people finding their grandparents Game Boys in the attic but on the other you'll have kids of the same age recording YouTube videos about GB modding, because that scene is still huge, diverse and very lively.

Re: PumpkinOS, a Re-Implementation of PalmOS

#64

Post by skissane »

pjmlp wrote: post #60
jsheard wrote: post #5

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

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.

> 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

Re: PumpkinOS, a Re-Implementation of PalmOS

#65

Post by bayindirh »

JTyQZSnP3cQGa8B wrote: post #59
astrange wrote: post #55

Earlier quoted context omitted.

I read a lot of ebooks on mine.

We used to put ebooks on it to help us during university exams. I pretended it was a calculator. I know, I’m ashamed, but it was for a boring course on economics.

I was the opposite. I used it as a calculator, without adding any ebooks on top, but my professors were uneasy about it. Then I got a calculator to curb their anxiety.

Re: PumpkinOS, a Re-Implementation of PalmOS

#66

Post by Tor3 »

toast0 wrote: post #50
NegativeLatency wrote: post #35

Earlier quoted context omitted.

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.

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

Re: PumpkinOS, a Re-Implementation of PalmOS

#67

Post by p_l »

grishka wrote: post #29
verdagon wrote: post #4

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 accessi…

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

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.

Re: PumpkinOS, a Re-Implementation of PalmOS

#68

Post by pjmlp »

skissane wrote: post #64
pjmlp wrote: post #60

Earlier quoted context omitted.

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.

> 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 ac…

Yes you're right, but I never knew anyone that would get Windows 3, only to keep using it as Windows 2.

Re: PumpkinOS, a Re-Implementation of PalmOS

#69

Post by Someone »

verdagon wrote: post #4

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 accessi…

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

Re: PumpkinOS, a Re-Implementation of PalmOS

#70

Post by Someone »

kmeisthax wrote: post #19
jsheard wrote: post #5

Earlier 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…

> I believe the original idea was to ship with like 64k or something?

Yes. Both the 6809 based design and the first 68k one targeted 64k. See https://folklore.org/Five_Different_Macs.html

Post reply on HN