-
Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.
Snow Leopard and Classic Mac OS
- Thread starter napabar
- Start date
Snow Leopard is the first MacOS with a fully 64-bit-capable kernel. It defaults to 32-bit mode on most machines or on any Mac with 32-bit kexts loaded. So you're right, a network stack doesn't need to be 64-bit, but loading it would force a 32-bit kernel and a 4GB app RAM limit. Apple is trying to wean users and especially developers away from 32-bit code. At the WWDC they kept repeating "Don't be the last guy to load 32-bit libraries! Those libraries will go away someday soon."
AppleTalk isn't relevant to the user base except nuts like us who keep old Macs, and there aren't enough of us to make it worth maintaining. These are the same screams as were heard when floppies went away, and serial ports, and SCSI ports. The only time I remember Apple has backed down over user protests was dropping FireWire from the MacBook. Apple responds a lot more quickly to Steve than to its users.
There are articles about Snow Leopard, 64-bitness, which parts are new, etc. in every Mac magazine, on Apple's web site, and many blogs. I commend them to your attention. Bitching to me doesn't do any good. I don't think Steve reads this board.
I knew that statement would make it into this thread at some point, as it is so often use as a weapon against others when something changes and many Mac users voice concerns about the change. But I for one don't buy into that "is the same as the floppy" argument.
Floppies are hardware. Serial and SCSI ports are also hardware. AppleTalk is software. That's a big difference. Yet another difference is that one could effectively argue that floppy drives perhaps were in some way holding back computing technology from taking a big leap forward. But can one honestly say that keeping the "software" AppleTalk protocol alive in Snow Leapord would in any significant way hold back OS X development? My personal feeling is "no." I feel that way because many decisions made at Apple under Jobs are not necessarily rooted in what you and I deem "logic" as they are rooted in what goes on inside the brain of a very talented billionaire CEO in Cupertino. But that "talent" doesn't always mean Steve does everything for the benefit of his existing customer base.
First of all, Apple pretty much is Steve. I say this because, when Apple does something, it's not like Mr. Jobs knows nothing about it or that he had no hand in it. Even during his recovery period and absence from Apple, he very much played at role at Apple and keep the communication with Apple execs and engineers and designers flowing. To deny this is to admit ignorance of the past and the role Mr. Jobs has played in it.
Second, as I previously mentioned in this thread (which apparently few cared very think deeply about), the OS X Beta had some unMaclike UI "features" in it which were conceived by OpenStep engineers, who by the way worked for and were closely directed by Mr. Steve Jobs himself. (Remember that Steve created NeXT after his departure from Apple in the mid-1980's and NeXTStep was the OS for Steve's new hardware there. NeXTStep later became OpenStep, ultimately purchased by Apple for a cool $400 million.) The OpenStep column-style Finder (which is one of the Finder views we still have today) and the functionless Apple logo in the middle of the menu bar were two things in the OS X Beta that caused Mac users to cry out to Apple for change. And guess what, the same engineers (again, under the close direction of the iCEO) who put the OpenStep Finder and functionless Apple logo into OS X, put back a more traditional MacOS Finder and somewhat functional Apple menu into OS X 10.0. This is a historical fact.
So to me, if one wishes to contend that AppleTalk was somehow holding back OS X development, then one should then also be inclined to contend that the legacy "Apple menu" has held back OS X from its full potential -- which would indirectly say that Steve was foolish to bowing to pressure from users in his having restored that functionality in OS 10.0. Oh my!
Steve makes more good design decisions than any other CEO I know of on the planet today. And I am so thankful that he had a hand giving birth to the computing platform we all have come to love so dearly. But that doesn't mean Steve is always right, nor does it mean that we ought to reverence and worship him so deeply that we lose our own sense of reason.
I am realistic in understanding that it is highly unlikely any manner of crying to Apple today is going to restore AppleTalk or AFP 2.x compatibility along the lines of what happened in the transition from OS X Beta to OS X 10.0. (That doesn't mean you should avoid trying though.) Even so, I side with Mac128 and others in feeling that AppleTalk is not a technology that is in any serious way holding back OS X 64-bit development. Truly, "it wasn't hurting anybody." And it is very sad to see it now gone from OS 10.6. And while some of us can avoid that axe by simply not upgrading our OS, at some point we will be forced to upgrade to 10.6 or higher as we will want to purchase a new Mac some day that will only run OS 10.6 or higher. And while we could use an old Mac (like the G4 Cube I am using now to type this post), not all people will enjoy doing that -- it's not a seamless experience and it requires physical desk and power outlet space too. Indeed, I would consider an OS 10.6 compatible emulator solution to AppleTalk to be more seamless and convenient than being forced to have a G4 Mac taking up space in my already tiny office. That is why I look forward to reading more here about what is possible in OS 10.6 via SheepShaver or Mini vMac.
As to SSD in a Cube, we've been chatting about this for quite some time over at CubeOwner:
http://www.cubeowner.com/forums/index.php?showtopic=12717&st=0
It's easy to miss in a thread that seems to wander around a bit, but did you see this post? Napbar has successfully used ZTerm & XModem protocols to send Mac binary files directly from OS X to a classic Mac running MacTerminal. This is based on the method I have been using with a Keysapn serial adapter to transfer data from a MacBook/Tiger running Sheepshaver and Clarisworks/MacTerminal 1.1 to a 128K Mac using MacTerminal 1.1. Of course this method is a bit slower than AppleTalk, but considering the average file size on a 128K through SE, that's not a huge problem.
In thinking about what Mini vMac will have to do to support vintage Mac hardware, I realized the one simple thing that will allow us to transfer files from Snow Leopard to a Mac Plus, IIx and up, is the ability to use Zip drives and floppy disks, respectively. Clearly there is no way to use AFP without one or two intermediary Macs. But the sneaker method would work quite well if one small thing were possible: Disk Copy.
Since the ZIP and 1.44MB floppy disks can be formatted HFS or HFS+ using the same rotational speed and media, it should be a simple task to duplicate an HFS disk image to the media bit-by-bit. This is even easier than Apple's Disk Copy which could write an MFS disk image to a 400K or 800K disk regardless of whether the Finder could read the disk, but only on a SuperDrive capable of variable speed control.
Anyone see a reason why an OS X Disk Copy utility couldn't be written under Snow Leopard to copy an HFS disk image created in Mini vMac to a standard USB floppy disk or ZIP drive?
Should be doable. I just tried restore a floppy image using 10.6 and it's disk copy to a USB floppy disk. No luck.
What is weird, is that 10.6 will format a DD disk (800k) as HFS+! The USB floppy drives are PC drives...they don't read Mac DD disks. So basically, Mac OS 10.6 is formatting the disk using the PC speed for DD, but with HFS+! I put it in my 6500 with OS 9, and it mounted just fine! Crazy!
It's formatting as 720K you mean?
All right, Mac128, I got my Keyspan serial adapter today! I have some good news! I was able to send files from my iMac with 10.6 and ZTerm to my LC using MacTerminal 2.2. I was also able to pull files from my iDisk and iPhone, as well as send files from MacTerminal to the same places respectively. In ever case, the resource fork came through!
This is good news!
I wonder how different AFP 2.x is in regards to AFP 3.x, and if perhaps a simple protocol "converter" program could be written to sit between the two.
Hey guys, I have some partial good news. I updated to 10.6.2 last night. One of the fixes listed was "compatibility with third-party AFP servers". I fired up my 6500 with OS 9.2.2 and was able to connect to it from Snow Leopard with full read/write access! I can confirm this work with 7.6.1 and ShareWay IP as well. On the downside, neither OS 9.2.2 or 7.6.1 were able to connect to Snow Leopard as a client. At least it's something.
We got very lucky in this case. It's rare that Apple will throw us a bone. Good to hear ShareWay works too. What's the oldest OS you can load ShareWay on?
Similar threads
