8.0 and 8.1 do require an '040, cutting off any MacⅡ or 1xx-series PowerBook. It's especially important to have access to OS 8.1 for HFS+ filesystem support!
you'll find various games and demos preinstalled, thanks to an old MacWorld Demo CD from 1997. Namely, Oregon Trail, Duke Nukem 3D, Civilization II, Alley 19 Bowling, Damage Incorporated, and Dungeons & Dragons.
Oh this is not just looks, which would already be nice, but it actually runs stuff.
It’s hard to explain the excitement that those CDs packed to newer generations. The internet was 14.4 or 33.6kbps. My HD had 250MB.
That meant that 650MB was just colossal. Thousands of exquisite icons, games, productivity, utilities, etc. It was vast.
Besides, the drivers were 2X or 4X, so it really took you a while to browse the whole thing.
Every reading noise would correspond to another portion of the screen being partially painted, something to look forward to.
I swear I'm into computers because stuff took forever. Listening to that floppy drive, listening to that hard drive, watching that loading bar fill, swapping out the disk, anticipation and excitement growing ever greater. The result maybe wasn't that important, but the PROMISE of the result...that was special.
Same thing hit again later with Napster and building up collections of albums. I didn't even care about the music, but those loading bars hit a primal spot of "acquire," "forbidden fruit," and "anticipatory glee."
MacFormat, a UK based magazine with a CD full of shareware and demos, would unexplainingly appear every month at a magazine shop in my hometown of Puebla, Mexico, at around ‘94-98.
Without a doubt I would have a different career should I have not have access to this information.
I wasn't born in Mexico, but I had a similar experience. There was a fancy magazine shop/bookstore/coffeeshop that sold MacWorld, MacFormat, MacUser, MacAddict, etc. And they were expensive. Everything seems so when you're 10, of course, but I imagine it truly was, if you account for currency exchange, shipping, etc. It sure consumed every christmas, birthday present and dime I could get my hands on at the time.
I learned so much from those magazines: tips and tricks, reviews of products I could never afford, industry analysis. Being featured on a Q&A session was ecstatic.
A few years ago I had coffee and a Cuban cigar at that store when I visited my parents. I heard it went out of business recently.
The graphical user interface still looks gorgeous! And it brings me a slight shudder that the look and feel might be more consistent that what we have today, even on the Mac.
QuickTime looks felt bizarre even to us Windows users. Even though we had no expectations of consistent or pretty UIs, every time I had to use QuickTime (a typical use case: watching movie trailers) I marveled at the grotesque bizarreness of its UI.
Modern windows has no expectations of consistency, but Windows in the 9x era would have a pretty consistent feel. Sure, there were two file pickers, and yes some people made their own, but other than media players and games meant for full screen, almost everything used system widgets and kept system colors etc.
You're right, I misspoke. I meant indeed that media players had quirky UIs in general... I was thinking of WinAMP for example. But even then, QuickTime looks felt both bizarre and unwieldy to me.
The unique Apple CD Audio Player application pre-dated Mac OS 8 by quite a few years. It may have been one of the first widespread Apple experimentations with a colorful and somewhat different interface than original Mac updated only slightly for System 7.
> Can I connect to the Internet? No. For what it's worth, the web was quite different 30 years ago - and you wouldn't be able to open even Google. However, Internet Explorer and Netscape are installed [...]
If IE and Netscape are available I'd assume this would be alright, unless it's some Electron thingy going on... how's that so?
Classilla requires a PowerPC and CarbonLib, and this machine is an emulated 68040. The best browser you can get is probably iCab, but even then it won't display many modern pages. Think of how many sites require TLS 1.2 to do anything at all.
Think of how many sites require TLS 1.2 to do anything at all.
...and then think of how there's no theoretical reason why TLS 1.2, 1.3 or any crypto, really, won't work on such a processor; the practical reason is that no one has really spent the effort to create/port such an implementation.
Certainly they can be installed on the VM, doesn't mean that the VM has network drivers installed.
Separately, very old browsers only talk HTTP 1.0 (No Host: header support, so they can't connect to non-dedicated servers) and no modern ciphersuites. (Can't connect to HSTS servers that disallow insecure ciphers)
HTTP 1.1 was released before Mac OS 8 so I'd be surprised if the installed browsers didn't have header support (shared hosting was already common when I used to support Mac OS 8 systems and those users certainly never had a problem).
TLS would be a bigger issue at the protocol layer and with the web moving to HTTPS everywhere, you'd expect a great deal of sites not to load.
On the rendering side, HTML 5, CSS 3 etc weren't around. In fact I don't even think HTML 4 was around (or if it was, it would have been extremely new so still unlikely to be well supported -- remember how long it took browsers to pass the ACID tests?). Back then it was still common to use framesets and tables for formatting.
Ironically, you'd probably get a better experience elinks or lynx.
There was a project floating around recently that rendered the website as an image using a modern browser backend, transmitted it back to any old browser (was demonstrated using IE5, I think), and also mapped mouse clicks to the appropriate locations in the document so the page remained more or less interactive. The UI looked like an extra navigation bar.
Can't remember the name, though (and it's also hard to search for).
If you're doing a MITM attack, Google's behavior doesn't matter; you can handle all the http requests and send them to Google (or whoever) as https and fix up all the internal links etc. If the user's browser is willing to go to google.com with http, it's probably ancient (no preloaded HSTS lists).
If you're actually on an ancient browser, Google's behavior does matter --- if they send you to https and don't work with ancient SSL/TLS stacks, then you can't use their products. For anything with a login, that seems reasonable, but for search, it seems pretty useful to allow HTTP for ancient browsers, because it's very hard to use the web without search.
Projects like these remind me that there are people in this world live in a different intellectual plane than us. For them, time probably moves slowly and the average person's intellect must surely amuse them. Because how is it possible for this to be made by one human?
This is really just a repackaging of work thats already been done. It uses the BasiliskII emulator which was compiled to Javascript with Emscripten by someone else a few years ago.
Still pretty cool but not some crazy technological feat.
Author here. You're 100% right, I do consider Basilisk and the Emscripten compiler to be the "real" work here. I added that in a Credits file in the repo, the app, and even _in_ the virtual machine - because I think that's important to know.
We need to go deeper! Soon we'll have a machine learning algorithm conjure Mac OS by calculating the next frame to display, taking into account user input, based on watching thousands of hours of normal Mac OS usage
Weirdly I don't think there's a machine learning algorithm that can actually do this. pix2pix loses cohesiveness quickly, and GANs require mostly aligned input to make any sense of reality. BigGAN is the closest, yet even that doesn't seem to work very well for continuity.
Also I believe 7.6 updated error reporting to native PPC codes so that a lot of the time an application could just crash on its own without crashing the whole system. Not always, but yeah even without protected memory.
That's brilliant. Gave me the funny thought that GPT-3 could solve one problem we used to argue about back in the day. What's the right order for loading extensions? I don't remember the details, but I do remember my old office would discuss it endlessly. The black magic and superstitions to keep the system going as long as possible before the inevitable crash. Maybe, 25+ years later, there could be a definitive answer.
I seem to remember a Cassidy & Greene program that would do all sorts of statistics to your extensions. I mainly used it to do a binary search to figure out which extension is causing the shareware app of the day to crash.
Conflict Catcher! By Jeff Robbin, who later wrote SoundJam MP, which was then bought by Apple and turned into iTunes, and he stayed at Apple for many years (may still be there even(
This was one of the only games I actually played in the Macs they had at elementary school (we spent most of our recess time on Napster...playing 12 different songs simultaneously in the same room, and nobody cared). I spent so long looking for this game, but I couldn't even figure it what to search for, because I didn't remember the title.
Alas, it doesn't have Excel on it. I want to test my theory that Excel 5 in an old mac emulator would be more snappy for basic input tasks than Excel 16 native on a MBP.
I have a theory that modern Excel forces the display to redraw too much. It's the only thing I can think of that would cause my 2018 MBP CPU to peg at 100% while (jankily) resizing the window on my external monitor unless I play games with the OS resolution settings to disable retina upscaling.
That seems like a bug right? The drawing code might be highly optimized for equal height rows but resizing cells is quite common, I’m surprised they just punt on it.
IIRC redraw doesn't happen until the sort finishes, but I use Excel as little as I can get away with, so I don't have a recent memory to rely on. That said, at a guess, reordering rows of equal height (and otherwise with no non-default properties) is probably mostly just rearranging pointers - why bother keeping row index associations intact, when the only trait of any row is the values in its cells? - while reordering rows of varying height might involve a lot of copying, or otherwise significantly more complex shenanigans, to make sure data and row properties stay properly associated.
I'm not even talking about varying heights of cells, just resizing the window. It. jumps. and. jerks. and. crawls. and. chugs. Even if it's a fresh blank sheet. And the problem gets noticeably and rapidly worse the bigger the window is, so if I want to fullscreen a sheet on a big monitor...oof. It's like the application completely reconstructs the whole visual canvas from scratch any time you do anything, whether it makes sense or not.
This doesn't happen with any other application.
Hiding the ribbon makes a _huge_ difference. That's hilarious and awful.
I feel like old stuff always feels way slower than I remembered when I revisit it years later. I couldn't believe how slow of an iPhone I lived with when I booted my old one up recently.
Plus, most of modern Excel's apparent slowness comes from the animated text input and the animations between cells in the spreadsheet. I think that the text animations could be safely removed, but animations that give users a sense of relativity on the 2D plane when they make movements are very useful for UX.
As someone who regularly uses old Mac emulators on modern hardware, most programs are hundreds of times faster (despite emulation overhead). As someone who regularly uses an actual old PowerBook 2400 from 1997 for fun, I can say that Photoshop 4 is by far snappier on that than the latest Photoshop CS on my MacBook Pro...
This is depressing, but hardly surprising. The dedication to "just ship it" has really built up. The market pressure to build efficient software approaches zero.
All software will approach "human speed," whether it's adding two integers or getting near instant predictions from a GAN. All available resources will be used until it's "good enough. Just ship it," and efficiencies will multiple as in any natural selection: defensive measures like "confusing code," and "unrelated system fails when this one is changed" allowing mostly harmless dumb code to survive and propagate.
Some intrepid learner comes to study the code one day. "Huh, I guess this is how you're supposed to do it. Seems kinda weird but I'm sure it was written this way for a reason. It's been like this for a decade!" And so they copy the procedure into their greenfield project.
Efficient code will always be sacrificed to the god of "Just Ship It" as long as the overall performance is "Good enough." And why not?
Only if you really have to use modern software (which, admittedly, we all have to from time to time). Vim, my terminal, grep and GCC are faster than ever!
To really enjoy computers the trick is to run old software on modern hardware.
I'd like to file a bug report: running Photoshop and using my wacom tablet, the lines are somewhat twitchy. On the other hand, it's responsive as hell: how nice to upgrade to a Quadra running inside Electron inside Mojave inside a pretty gnarly iMac Pro :)
I wish my old Performa 575 booted that fast or ran Photoshop 3 that well. I am old enough that I started with Photoshop 3 on such a machine, so this really was a trip for me. How utterly cool.
Now if I could run Photoshop 3 natively on THIS box… hoo boy would that be responsive.
I was a Macromedia fanboy. Photoshop is still a second class citizen in my mind to Fireworks. Even though Adobe felt different and nuked their best editor I still run it.
In the mid 2000s I spent years converting bitmap mockups into html table designs using Fireworks (using the slice->export workflow). My managers were perpetually in awe of how much faster I churned out the work when compared with the Photoshop wizards we had in the house.
Yes, I know, it’s silly to snark on Electron app sizes by this point. You want to see some real bloat? Let’s compare the included Adobe Photoshop 3 and Adobe Photoshop 2020:
Past that, the big one is “disk” in Contents/Resources/app/src/ — which I will be completely honest, I don’t know what that is exactly. Is it a disk image? If so, does it have to be set to a reasonably large size at build time so you don’t run out of space in the emulator?
Ah, yeah, I think I assumed correctly. In the emulator, the “macintosh.js” hard drive is 650 MB, so you must have to explicitly give it a big giant size to begin with, as it can’t dynamically increase the volume size on the fly.
Hi, author here! This is silly, but I'm allocating the entire size of the _virtual_ disk on your actual hard drive. There's probably a smarter way to do this, but that's how it is right now. PRs would be lovely!
Sadly I’m not terribly knowledgable if this is easily implementable or not but theoretically you don’t need to allocate all the disk space, just the parts you’ve written to.
Some of that bloat is legitimate, or at least dictated by consumer expectations.
Consider graphics resources: modern screens typically 9 to 16 times as many pixels per square inch. Even though Macintosh computers have always been known for their graphical interfaces and use in publishing, user interface elements did not always exploit increased colour depth in the early 1990's. A graphics resource in a modern application can use an additional 4 to 32 times more memory just for colour. Software also tends to incorporate more graphical elements these days, thus adding more bulk. We shouldn't be surprised by Photoshop being 310 times larger. Since people tend to notice the visual quality of software, whether it enhances the software or is pure cosmetics, it is not necessarily a bad thing.
Other aspects of software will also influence its growth. Modern software tends to support more languages and regional variations in how data (numbers, time, etc.) are represented. This virtually always produces a noticeably larger program. More features means more code and associated data, while optimization tends to focus upon speed at the expense of size. Again, programs will be larger. When it improves accessibility and functionality, this "bloat" is a good thing.
I am not saying that bloat is always a good thing and I appreciate how much developers of the past could do so much with so little. My favourite example are early versions of Clarisworks, where a stripped down installation could fit on a single floppy disk while offering a word processor, spreadsheet, database, paint program, vector illustration, and telecommunications software. It also addressed the needs of most home and home office users, even considered in the current context. That being said, most people would consider the presentation stark by modern standards and anyone who takes the time to actually learn how to use their software would find the features skimpy.
Oh I know and accept that, it’s just always a little funny to see that much of a difference in size.
I use Photoshop every day, and I know that features added since version 3 that I use take up size:
* Layer styles
* Adjustment layers
* Smart objects
* Camera RAW
* Machine learning selection tools
* Generator for assets
So they have added real, valuable features for me. And I don’t particularly care about application size. Just funny to think you couldn’t even fit Photoshop on a CD at this point.
I am pretty much the opposite in that I do care, but I did the math one day and decided that the growth of software is consistent with general expectations. So instead of griping about bloat, I now think that it is better to respect how much developers accomplished with so little.
Developer here! I'm so excited to see that people like this toy. I'm happy to answer any questions, if you have any.
But first, some important credits: Emulator: Basilisk II, a 68k Macintosh emulator, by Christian Bauer et al, modified and compiled with Emscripten by James Friend. Installed software from vintage computing archives: WinWorldPC, Macintosh Garden, and Macintosh Repository.
how easy is this to get running in an actual browser, rather than Electron*? I want to host some Hypercard stacks (some of which need Quicktime support, hence colour Mac emulation).
James Friend is the one who got the C compiled with Emscripten, and as long as you're able to serve an entire disk image from a server (and don't crumble under the bandwidth), a browser is good enough.
Electron is only here to ensure that state is saved (save a game, quit the app, start the app, your save game is still there) and to make the mounting of disk images and transfer of files from your local machine super easy.
That's indeed probably a bad idea if the author wants the repository to last, embedding unlicensed content is always a risk. Morally I'd argue that it's absurd that such old software isn't in the public domain yet, but legally it's pretty clear that this can't be redistributed freely, although I doubt that Apple is likely to enforce it.
This running MacWord+MacExcel in 1997 would have prevented the dystopia from coming true. (Of course, the dystopia is necessary to even conceive of doing this!)
Now put down the keyboard, raise your arms slowly and back away from the NodeJS interpreter. ;)
It's crazy to me that somehow "Alley 19 Bowling" has been lingering around in my brain for 20+ years. All of a sudden I feel like I played it yesterday.
164 comments
[ 10.3 ms ] story [ 215 ms ] threadThat meant that 650MB was just colossal. Thousands of exquisite icons, games, productivity, utilities, etc. It was vast.
Besides, the drivers were 2X or 4X, so it really took you a while to browse the whole thing. Every reading noise would correspond to another portion of the screen being partially painted, something to look forward to.
Same thing hit again later with Napster and building up collections of albums. I didn't even care about the music, but those loading bars hit a primal spot of "acquire," "forbidden fruit," and "anticipatory glee."
Without a doubt I would have a different career should I have not have access to this information.
This is what I do today https://method.ac
I learned so much from those magazines: tips and tricks, reviews of products I could never afford, industry analysis. Being featured on a Q&A session was ecstatic.
A few years ago I had coffee and a Cuban cigar at that store when I visited my parents. I heard it went out of business recently.
https://guidebookgallery.org/screenshots/macos80
…compared to the brushed metal and bizarre volume control in QuickTime in Mac OS 9.
https://guidebookgallery.org/screenshots/macos90
A: Even a Mac Plus runs Glider.
> Can I connect to the Internet? No. For what it's worth, the web was quite different 30 years ago - and you wouldn't be able to open even Google. However, Internet Explorer and Netscape are installed [...]
If IE and Netscape are available I'd assume this would be alright, unless it's some Electron thingy going on... how's that so?
[1]. https://www.floodgap.com/software/classilla/
[2]. https://en.wikipedia.org/wiki/Classilla
...and then think of how there's no theoretical reason why TLS 1.2, 1.3 or any crypto, really, won't work on such a processor; the practical reason is that no one has really spent the effort to create/port such an implementation.
The emulator this is based on (Basilisk II) does support networking, FWIW.
Separately, very old browsers only talk HTTP 1.0 (No Host: header support, so they can't connect to non-dedicated servers) and no modern ciphersuites. (Can't connect to HSTS servers that disallow insecure ciphers)
TLS would be a bigger issue at the protocol layer and with the web moving to HTTPS everywhere, you'd expect a great deal of sites not to load.
On the rendering side, HTML 5, CSS 3 etc weren't around. In fact I don't even think HTML 4 was around (or if it was, it would have been extremely new so still unlikely to be well supported -- remember how long it took browsers to pass the ACID tests?). Back then it was still common to use framesets and tables for formatting.
Ironically, you'd probably get a better experience elinks or lynx.
Can't remember the name, though (and it's also hard to search for).
edit: browser history to the rescue, it's https://github.com/ttalvitie/browservice
If you're actually on an ancient browser, Google's behavior does matter --- if they send you to https and don't work with ancient SSL/TLS stacks, then you can't use their products. For anything with a login, that seems reasonable, but for search, it seems pretty useful to allow HTTP for ancient browsers, because it's very hard to use the web without search.
Google worked, but any further link failed, as expected.
Still pretty cool but not some crazy technological feat.
https://github.com/felixrieseberg/macintosh.js/blob/master/C...
If you want to mildly astonished of project(s) in a similar vein, look at all the stuff Fabrice Bellard have made! It's really quite impressive.
</pointless historical nitpick>
(I only ever used one real 68k Mac, and that was something donated to my school’s art department).
Imagine that being a selling point in an Apple product today...
Crystal Quest and it's sequel, Crystal Crazy
https://www.macintoshrepository.org/5955-crystal-crazy
If you're looking for games or other software for this check out the always excellent Macintosh Garden. https://macintoshgarden.org/
[1]. https://winworldpc.com/product/microsoft-excel/5x
Sorting large datasets with varying cell heights will bog down your system. Force uniform cell height and sorting can easily be twenty times quicker.
This doesn't happen with any other application.
Hiding the ribbon makes a _huge_ difference. That's hilarious and awful.
Plus, most of modern Excel's apparent slowness comes from the animated text input and the animations between cells in the spreadsheet. I think that the text animations could be safely removed, but animations that give users a sense of relativity on the 2D plane when they make movements are very useful for UX.
All software will approach "human speed," whether it's adding two integers or getting near instant predictions from a GAN. All available resources will be used until it's "good enough. Just ship it," and efficiencies will multiple as in any natural selection: defensive measures like "confusing code," and "unrelated system fails when this one is changed" allowing mostly harmless dumb code to survive and propagate.
Some intrepid learner comes to study the code one day. "Huh, I guess this is how you're supposed to do it. Seems kinda weird but I'm sure it was written this way for a reason. It's been like this for a decade!" And so they copy the procedure into their greenfield project.
Efficient code will always be sacrificed to the god of "Just Ship It" as long as the overall performance is "Good enough." And why not?
Every year it seems to get worse.
Only if you really have to use modern software (which, admittedly, we all have to from time to time). Vim, my terminal, grep and GCC are faster than ever!
To really enjoy computers the trick is to run old software on modern hardware.
https://www.macintoshrepository.org/195-microsoft-excel-1-03...
I wish my old Performa 575 booted that fast or ran Photoshop 3 that well. I am old enough that I started with Photoshop 3 on such a machine, so this really was a trip for me. How utterly cool.
Now if I could run Photoshop 3 natively on THIS box… hoo boy would that be responsive.
Really miss Fireworks.
Size of this .app on my Mac: 866 MB
Yes, I know, it’s silly to snark on Electron app sizes by this point. You want to see some real bloat? Let’s compare the included Adobe Photoshop 3 and Adobe Photoshop 2020:
Photoshop 3.0.5: 8.9 MB
Photoshop 21.2.1: 2.76 GB
Now that is some bloat.
Electron Framework takes up 174 MB.
Past that, the big one is “disk” in Contents/Resources/app/src/ — which I will be completely honest, I don’t know what that is exactly. Is it a disk image? If so, does it have to be set to a reasonably large size at build time so you don’t run out of space in the emulator?
Sadly I’m not terribly knowledgable if this is easily implementable or not but theoretically you don’t need to allocate all the disk space, just the parts you’ve written to.
Consider graphics resources: modern screens typically 9 to 16 times as many pixels per square inch. Even though Macintosh computers have always been known for their graphical interfaces and use in publishing, user interface elements did not always exploit increased colour depth in the early 1990's. A graphics resource in a modern application can use an additional 4 to 32 times more memory just for colour. Software also tends to incorporate more graphical elements these days, thus adding more bulk. We shouldn't be surprised by Photoshop being 310 times larger. Since people tend to notice the visual quality of software, whether it enhances the software or is pure cosmetics, it is not necessarily a bad thing.
Other aspects of software will also influence its growth. Modern software tends to support more languages and regional variations in how data (numbers, time, etc.) are represented. This virtually always produces a noticeably larger program. More features means more code and associated data, while optimization tends to focus upon speed at the expense of size. Again, programs will be larger. When it improves accessibility and functionality, this "bloat" is a good thing.
I am not saying that bloat is always a good thing and I appreciate how much developers of the past could do so much with so little. My favourite example are early versions of Clarisworks, where a stripped down installation could fit on a single floppy disk while offering a word processor, spreadsheet, database, paint program, vector illustration, and telecommunications software. It also addressed the needs of most home and home office users, even considered in the current context. That being said, most people would consider the presentation stark by modern standards and anyone who takes the time to actually learn how to use their software would find the features skimpy.
I use Photoshop every day, and I know that features added since version 3 that I use take up size:
* Layer styles
* Adjustment layers
* Smart objects
* Camera RAW
* Machine learning selection tools
* Generator for assets
So they have added real, valuable features for me. And I don’t particularly care about application size. Just funny to think you couldn’t even fit Photoshop on a CD at this point.
> Now that is some bloat.
Yeah, but you're roughly 310 times more productive now.
But first, some important credits: Emulator: Basilisk II, a 68k Macintosh emulator, by Christian Bauer et al, modified and compiled with Emscripten by James Friend. Installed software from vintage computing archives: WinWorldPC, Macintosh Garden, and Macintosh Repository.
Electron is only here to ensure that state is saved (save a game, quit the app, start the app, your save game is still there) and to make the mounting of disk images and transfer of files from your local machine super easy.
https://github.com/felixrieseberg/macintosh.js/blob/master/s...
Now put down the keyboard, raise your arms slowly and back away from the NodeJS interpreter. ;)
somepeepz15@gmail.com
coincidently today firefox 79 was released, which brings back support for SharedArrayBuffer, which is a key part of the browser port of this emulator