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

131–140 of 141 posts

Re: PumpkinOS, a Re-Implementation of PalmOS

#131

Post by miki123211 »

Someone wrote: post #112
kalleboo wrote: post #54

Earlier quoted context omitted.

> For anyone wondering, no, this isn't the thing that made classic Mac OS unfit for multitasking Yeah, the way to port classic MacOS apps to native OS X apps was called Carbon, and it was basically 80% of the classic MacOS toolbox just ported to OS X, Handles and QuickDraw and all. Classic MacOS apps written to CarbonLib would "just run" natively in OS X (and the same binary in Classic MacOS). Carbon even kept workin…

> Apple could have worked in multitasking in classic MacOS if they really wanted to They did, and they couldn’t. Most users had some code running that patched system calls locally or globally or that peeked into various system data structures, and all applications assumed the system used cooperative multitasking. Going from there to a system with preemptive multitasking would mean breaking a lot of code, or a Hercule…

Microsoft actually sort of did that with Windows 9x.

There was a lot of Windows 3.1 and DOS software and drivers that they wanted to remain compatible, and those relied on DOS quirks. So, they had a copy (copies) of DOS always resident in RAM, mostly unused. All DOS syscalls (interrupts) were hooked so that they would call Windows instead. If a program added its own hooks, Windows would detect that and switch to 16-bit mode for the relevant operation. When the custom hook completed, it would call the next hook in the chain, which was the one that went back to Windows. Of course, this relied on Windows understanding DOS's internal data structures and keeping them in sync with what Windows was doing. A similar technique was used for drivers, if Windows found a driver it didn't understand, it would let that driver run in 16-bit mode.

Raymond Chen (of Microsoft fame) explains this much better than I ever could https://devblogs.microsoft.com/oldnewthing/20071224-00/?p=24...

Re: PumpkinOS, a Re-Implementation of PalmOS

#132

Post by p_l »

kjs3 wrote: post #123
p_l wrote: post #67

Earlier quoted context omitted.

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

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.

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

Re: PumpkinOS, a Re-Implementation of PalmOS

#133

Post by TeaBrain »

Tor3 wrote: post #66
toast0 wrote: post #50

Earlier quoted context omitted.

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

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.

Re: PumpkinOS, a Re-Implementation of PalmOS

#135

Post by [deleted] »

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…

[deleted]

Re: PumpkinOS, a Re-Implementation of PalmOS

#136

Post by Tor3 »

TeaBrain wrote: post #133
Tor3 wrote: post #66

Earlier quoted context omitted.

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

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

I should check this - I still have some SD cards which I used with my T3 (I had two Tungsten T3 PDAs actually). But I think they were simply FAT-accessed, i.e. different from the internal storage. I'm unable to verify that at the moment. It's correct that there was an entry in the system menu or some such to look at the card. Again I can't check this - battery is out on both my T3 devices, and charging got more and more tricky over the years (the Palm socket was a very weak point)

Re: PumpkinOS, a Re-Implementation of PalmOS

#137

Post by NegativeLatency »

sillywalk wrote: post #130
kalleboo wrote: post #54

Earlier quoted context omitted.

> For anyone wondering, no, this isn't the thing that made classic Mac OS unfit for multitasking Yeah, the way to port classic MacOS apps to native OS X apps was called Carbon, and it was basically 80% of the classic MacOS toolbox just ported to OS X, Handles and QuickDraw and all. Classic MacOS apps written to CarbonLib would "just run" natively in OS X (and the same binary in Classic MacOS). Carbon even kept workin…

> classic MacOS toolbox just ported to OS X There was a company that re-implemented the macos toolbox on various Unixes. I hope somebody on HN worked there and can fill in more details. Tldr; from [0] The company was orignally Quorum Software Systems, Inc. which transformed into -> Latitude Group in 1994, and which got bought by Metrowerks in 1996-7?. The original product was called Equal, and allowed Microsoft Word…

neat

Re: PumpkinOS, a Re-Implementation of PalmOS

#138

Post by kalleboo »

sillywalk wrote: post #130
kalleboo wrote: post #54

Earlier quoted context omitted.

> For anyone wondering, no, this isn't the thing that made classic Mac OS unfit for multitasking Yeah, the way to port classic MacOS apps to native OS X apps was called Carbon, and it was basically 80% of the classic MacOS toolbox just ported to OS X, Handles and QuickDraw and all. Classic MacOS apps written to CarbonLib would "just run" natively in OS X (and the same binary in Classic MacOS). Carbon even kept workin…

> classic MacOS toolbox just ported to OS X There was a company that re-implemented the macos toolbox on various Unixes. I hope somebody on HN worked there and can fill in more details. Tldr; from [0] The company was orignally Quorum Software Systems, Inc. which transformed into -> Latitude Group in 1994, and which got bought by Metrowerks in 1996-7?. The original product was called Equal, and allowed Microsoft Word…

That's amazing!

Re: PumpkinOS, a Re-Implementation of PalmOS

#139

Post by saagarjha »

asveikau wrote: post #24
MaulingMonkey wrote: post #23

Earlier quoted context omitted.

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

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.

And macOS too, with CVPixelBuffer.

Re: PumpkinOS, a Re-Implementation of PalmOS

#140

Post by yencabulator »

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.

What made me feel extra old was being momentarily confused about how a Palm OS device had a display that wasn't green monochrome.
Post reply on HN