121–130 of 141 posts
My heart thumped faster when I read this headline. Please make it work on Android so I can 'replace' my daily driver and go back to a better time!
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.
Earlier quoted context omitted.
> 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 o…
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 original idea was 64K and a 6809 instead of the 68000. Quickly became clear that wasn't going to live up to expectations.
Earlier quoted context omitted.
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,…
Whether the Motorola MMU for the 68010 (the 68451) was sane or not is a matter of some debate. The 68451 was definitely slow and limited (segments, not pages); in the end, most vendors rolled their own MMU out of static RAM and PALs.
Earlier quoted context omitted.
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,…
Just to muddy the waters some more there was also an EC variant¹ of the 030 without the MMU. The EC variant was available right through to the 060, and I'd be curious to know how prevalent the line was. I suspect the EC versions far outnumbered the "full" chips, because they appeared in all kinds of industrial systems. I'm basing that entirely on working for a company that was still shipping products with MMU-less 68…
There were huge numbers of embedded 68k family chips shipped, although I've never seen the actual numbers. Folks went from 68000 to 68ec020 to 68ec060 as a (sorta) easy upgrade path. They're still made if you count the 68sec000, and the 68300 line is the spiritual successor.
Earlier quoted context omitted.
Mac OS, Win16, PalmOS all have shared heaps too. This is precisely why you need defragmentation (after an application quits, the heap is a fragmented mess, full of holes) and therefore some system so that the other applications keep "movable handles" to heap blocks instead of raw pointers (which would become invalid after the heap undergoes one round of defragmentatino). If an OS does not do this you are basically in…
> Mac OS, Win16, PalmOS all have shared heaps too Mac OS didn’t. It had a system heap and a heap for the running application. Once it supported running multiple applications simultaneously, each of them had its own heap ( https://www.folklore.org/Switcher.html : “One fundamental decision was whether or not to load all of the applications into a single heap, which would make optimal use of memory by minimizing fragmen…
Earlier quoted context omitted.
But the (horrifying) maths checks out: say he got the Gameboy at the age of 12 when it launched in 1989, had a first child at twenty in 1997, that child has a child of its own also at the age of twenty in 2017, grandchild aged six or seven now excited to find granddad's Gameboy. Twenty is merely youngish for a first child, not the stuff of shotgun-wedding backblocks.
When I was 17 I had a job at Software Etc (a forerunner of Gamestop), and person checking out asked if I had any kids. I was kind of bewildered and said "I think I'm a little young for that" and she sort of shakes her finger in front of me, "oh no you're not honey" I've been thinking about that ever since, marking various dates in my life where I could take this theoretical kid out for a beer, etc. If my child's chil…
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…
Earlier quoted context omitted.
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…
> 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…
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 5.1a and Excel 4.0 (the macos versions) to run on UNIX, with native [Motif?] look and feel and good performance without source code.
they later made a library called 'Latitude' so macos App developers could easily port their apps to Unix, which was how the Adobe Apps - Photoshop / Illustrator etc. got made available for Unix. .. and Latitude also apparently implemented a lot of QuickDraw.
"At the heart of Latitude is our own Portable Toolbox Implementation Layer. This layer is completely platform independent. It presents the Mac Toolbox API to the application, answers these calls through a trap table mechanism, and relies on other toolbox calls within the layer whenever possible. When a native system facility is needed, such as the display of a window or control, or some graphical rendering, this layer calls out to one of Latitude's platform dependent modules through an internal, well defined API. The toolbox layer doesn't know what kind of system lies underneath, only that calling this function will display a window or that function will draw a line, etc.
.. Because we've mapped native system facilities to Mac calls, the running application is an equal citizen on the desktop. The application's windows, menus, and control items are native system objects. Cutting and pasting between apps is facilitated by the native system's clipboard mechanism. Fonts come from the system font server -- including the default system font, which means the dialogs come up in something other than Chicago! Application windows are native windows -- not some rendering of a window inside of another. The performance hit is minimal. Latitude is merely mapping the Mac calls to the native system. There is very little processing going on in between. "
[0] http://preserve.mactech.com/articles/mactech/Vol.13/13.06/Ju...