51–60 of 141 posts
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.
Earlier quoted context omitted.
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.
Yeah, well people are misinformed. Unless there was something for the Newton that turned it into a phone, IBM was first to market in 1994 [1] The IBM Simon made calls, did data, had a paid 3rd party app, etc.
Besides Palm, Symbian (Mostly from Nokia, but some other companies made Symbian handsets), RIM's Blackberry, and Microsoft's Windows Mobile (with handsets from many OEMs) had established smartphones before Apple. Of course, the iPhone had much better sales, and changed the market in many ways, but the category was 12ish years old when Apple entered. Hardly inventing or first to market.
Earlier quoted context omitted.
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 kern…
Specifically in terms of the comment I replied to, you categorically can not automatically free memory when a task (process/thread) ends in AmigaOS without applications-specific knowledge without risking causing crashes, because some memory "handoffs" are intentional.
> With a single address space for all applications, there can still be user/kernel protection: userland not being able to trash kernel data structures.
Yes, you could if the OS was designed for it, and it was done at a point where most of the application developers were still around to fix the inevitable breakage.
The problem with doing this in AmigaOS without significant API changes or auditing/patching of old code is that there is no clear delineation of ownership for a lot of things.
This includes memory in theory "owned" by the OS, that a lot of applications have historically expected to be able to at least read, and often also write to.
You also e.g. can't just redefine the "system calls" for manipulating lists and message queues to protect everything because those are also documented as ways to manipulate user-level structures - you can define your own message ports and expect them to have a specific memory layout.
More widely, it includes every message sent to or received from the OS, where there's no general rule of who owns which piece of the message sent/received. E.g. a message can - and will often - include pointers to other structures where inclusion in the message may or may not imply an ownership change or "permission" to follow pointers and poke around in internals.
To address this would mean defining lifecycle rules for every extant message type, and figuring out which applications breaks those assumptions and figuring out how to deal with them. It's not a small problem.
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…
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 working on Intel MacOS, but they finally killed it with the 32-bit deprecation a year or two before Apple Silicon was released.
Apple could have worked in multitasking in classic MacOS if they really wanted to, but their management was totally dysfunctional in the 90's where there was no point seen in investing in boring old MacOS since there was always a revolution just around the corner in the form of Pink, Taligent, Copland etc, projects which due to the aforementioned management never went anywhere.
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.
I still have my original PalmPilot in a box in the attic. Its existence was a huge life lesson for me. I asked my boss to pay for it (he did) but he said: do you use anything to organize your life and projects right now? If you don't, I don't think a PalmPilot will help you. He was so right.
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 the other hand, there some special sense of nostalagia for what I was doing back on those days.
Earlier quoted context omitted.
> 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.
> Steve Jobs invented the smartphone Yeah, well people are misinformed. Unless there was something for the Newton that turned it into a phone, IBM was first to market in 1994 [1] The IBM Simon made calls, did data, had a paid 3rd party app, etc. Besides Palm, Symbian (Mostly from Nokia, but some other companies made Symbian handsets), RIM's Blackberry, and Microsoft's Windows Mobile (with handsets from many OEMs) had…
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.
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.
Earlier quoted context omitted.
I still have my original PalmPilot in a box in the attic. Its existence was a huge life lesson for me. I asked my boss to pay for it (he did) but he said: do you use anything to organize your life and projects right now? If you don't, I don't think a PalmPilot will help you. He was so right.
I read a lot of ebooks on mine.
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…
> 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.