Skip to main content
Home▸ Forums▸ 68kMLA▸ Snow Leopard and Classic Mac OS
Thread

Snow Leopard and Classic Mac OS

68kMLA Networking 96 posts Aug 29, 2009 to Nov 11, 2009
Hey guys, I have some bad news. I just upgraded to Snow Leopard today, and the Classic Mac OS can no longer connect or share to it. I'm using a fully updated Mac OS 9 Mac, and I get an incompatible AFP error message. And yes, I'm using IP, not Appletalk.

Looks like the last vestige of AppleShare and Pre-OS X has been eliminated.

It was inevitable.

A sad day indeed. :'(

I don't really get this (which is no big surprise)... aren't filesharing protocols essentially standards? Isn't this a bit like breaking ftp or http?

Someone please explain...

Pretty sure I recall reading that Apple ditched Appletalk in 10.6. I might be mistaken though.

Darn, I was just getting ready to set up a network with my SE/30, Orange iMac, and Macbook...

Guess I'll have to stick to the old floppies and zip disks then. :(

Pretty sure I recall reading that Apple ditched Appletalk in 10.6. I might be mistaken though.

As I stated, I was connecting via AppleShare with IP, not AppleTalk.

AppleTalk was still around in 10.4 and 10.5, but just for printers. 10.5 worked just fine with Classic Macs and AppleShare over TCP/IP. 10.6 it's broken.

aren't filesharing protocols essentially standards? Isn't this a bit like breaking ftp or http?
The difference is that ftp and http are international standards and not tied to any one vendor. The AppleTalk protocols are all, funnily enough, defined by Apple.

Yes but have you tried these steps to success?
And further reading on the TCPquantum hack as used in my steps.

Tried it, but it doesn't work. I can add the line to the Pref file, and save it just fine with File Sharing off. After I try and fail to connect with the OS 9 Mac, the line is no longer in the pref file.

It looks like your hack was more of a 10.4 solution. 10.6 is very different.

It appears that the client will have to have AFP 3.0 or higher, which means Mac OS X. OS 9 introduced AFP 2.2, and it's not cutting it anymore.

The difference is that ftp and http are international standards and not tied to any one vendor. The AppleTalk protocols are all, funnily enough, defined by Apple.
Well, I get that part... just wondering if there's actually a pragmatic reason for breaking it (like they need the ports for something else) or if it's just a matter of forcing hardware upgrades.

The difference is that ftp and http are international standards and not tied to any one vendor. The AppleTalk protocols are all, funnily enough, defined by Apple.
Well, I get that part... just wondering if there's actually a pragmatic reason for breaking it (like they need the ports for something else) or if it's just a matter of forcing hardware upgrades.

AFP (AppleShare) has evolved many times over the years, where FTP has been a "Gold" standard for decades. AFP originally shared using AppleTalk, then a mixture of AppleTalk and IP, and finally just IP. Even there, when Mac OS X came out, they continued to evolve it to version 3.0. Apparently, that version (3.0) is required now to share files. Mac OS 9 only went up to AFP 2.2.

I think the main reason for this is less to test for Apple. In reality, most people who care about this stuff are Classic Apple nerds like us. :)

I don't think Apple's trying to force Mac OS 9 users to upgrade. If you're still using Mac OS 9, Apple has long since given up on trying to upgrade you. :)

What about this method? It requires an intermediary, so I guess now, the intermediary has to be an 10.5.x or less?

What about this method? It requires an intermediary, so I guess now, the intermediary has to be an 10.5.x or less?
Hey, I wrote that article! LOL!

That was more related to getting really old Macs talking to Leopard, but now all Classic Macs are shut off!

Snow Leopard can share using FTP, which means you could share back to a Mac Plus easily with Fetch.

One cool thing about sharing with FTP is that it "Shares a Share" unlike AppleShare. In other words, all mounted drives, including network drives, are available to the FTP client. That is really cool. Imagine a Mac Plus pulling directly from an iDisk or other share it couldn't natively get to.

The downside of FTP is it's not disk/GUI based sharing. You can't mount and run apps off of it like AppleShare.

The downside of FTP...
Right now, I can use my G4 Cube running Tiger and my SE/30 running System 7.5.5 to talk to each other over Ethernet (via the TCPquantum hack), and I can simply drag one of my SE/30's hard disk partitions over to the Cube's hard drive to make a full backup of it. It's relative fast and easy, and all the System files copy over just fine. I never was able to accomplish that with FTP.

In a pinch, Snow Leopard still supports 1.44 megabyte USB floppy drives. Just thought I'd mention it.

No reason as to why it wouldn't - USB floppy drives use the standard USB Mass Storage drivers.

In a pinch, Snow Leopard still supports 1.44 megabyte USB floppy drives. Just thought I'd mention it.
Is it that OS X .6 specifically supports 1.44MB floppy disk drives, or that it supports USB removable FAT volumes, of any size? I would think the USB drive itself would be responsible for the MFM encoding scheme, leaving it to send/receive the FAT file formatting via USB. As long as OS X understands FAT and allows 1.44MB volumes to be read and written, I can't imagine any Mac OS would ever omit the USB floppy disk – and I don't see FAT being eliminated anytime soon. This goes for any USB device. It's like asking how much longer will Apple support HFS, which can no longer be used as a startup disk?

Unfortunately, Apple dumped MFS with OS 8, and never fully revived it. Even MFSLives runs only on Tiger. I really wish someone would update MFSLives for Leopard as well as enabling read & write capabilities. Then if someone would only develop that USB GCR floppy drive!

Is it that OS X .6 specifically supports 1.44MB floppy disk drives
In the sense of appearing on the desktop with a floppy disk icon, yes.

Leo Laporte, The Tech Guy, stated on this past weekend's episode that OSX code named "Snow Leopard" is the watershed for PowerPC-based Macs. It is the only version that you'll need an Intel Mac to run. This also includes dropping AppleTalk, as it is old and outdated.

73s de Phreakout. 8-)

Leo Laporte, The Tech Guy, stated on this past weekend's episode that OSX code named "Snow Leopard" is the watershed for PowerPC-based Macs. It is the only version that you'll need an Intel Mac to run. This also includes dropping AppleTalk, as it is old and outdated.
73s de Phreakout. 8-)
This isn't about file sharing with AppleTalk. It's about file sharing with AppleShare over IP. AppleTalk hasn't been used for file sharing since 10.3, and even then it was only for discovery purposes. The AppleTalk that was dropped from 10.6 was only used for printing to an AppleTalk printer.

The downside of FTP is it's not disk/GUI based sharing. You can't mount and run apps off of it like AppleShare.
I'm presently connecting to a 10.5-running PPC server from my 10.6-running Intel laptop via FTP. (Go -> Connect to Server -> Typed in "ftp://MacServer.local") It mounted the root of the server as a new network share "/" on my desktop. I can browse it exactly the same as an AFP-connected share. (Although it is much slower.)

And I just launched AppleWorks 6 over the FTP connection. (Yup, AppleWorks 6, a PPC-only app.) When I double-clicked the icon, I got a warning "The application "AppleWorks 6" is on an FTP server. Are you sure you want to open "AppleWorks 6"? Applications may not run or may run very slowly when opened from an FTP server."

Update: AppleWorks refused to load. I did successfully load TextEdit, RealPlayer, and Sound Studio though. (TextEdit the 10.5-shipped Universal binary, RealPlayer 10, a Universal binary, and Sound Studio, a PPC-only app.)

If FTP was so great, we would have all ditched other connection methods for it long ago. But the fact is, FTP stinks. And like I said, it does not allow me to drag an entire disk partition from my SE/30 to my Intel Mac and make an easy backup like Appletalk over Ethernet allows.

The downside of FTP is it's not disk/GUI based sharing. You can't mount and run apps off of it like AppleShare.
I'm presently connecting to a 10.5-running PPC server from my 10.6-running Intel laptop via FTP. (Go -> Connect to Server -> Typed in "ftp://MacServer.local") It mounted the root of the server as a new network share "/" on my desktop. I can browse it exactly the same as an AFP-connected share. (Although it is much slower.)

And I just launched AppleWorks 6 over the FTP connection. (Yup, AppleWorks 6, a PPC-only app.) When I double-clicked the icon, I got a warning "The application "AppleWorks 6" is on an FTP server. Are you sure you want to open "AppleWorks 6"? Applications may not run or may run very slowly when opened from an FTP server."

Update: AppleWorks refused to load. I did successfully load TextEdit, RealPlayer, and Sound Studio though. (TextEdit the 10.5-shipped Universal binary, RealPlayer 10, a Universal binary, and Sound Studio, a PPC-only app.)
I was referring to Classic Macs not being able to run apps off an FTP share. :)

Mounting a FTP share as a disk is something that came along in 10.4 or 10.5 (can't remember). A Mac Plus can't do that! It has to use a client, and pull the files down to it's on drive first.

I was referring to Classic Macs not being able to run apps off an FTP share.
Which reminds me. I need to check Sheepshaver's compatibility before I upgrade to Snow Leopard to ensure I can stilltransfer directly from OS X to my 128K.

Using MacTerminal, while slow is actually pretty easy. What surprises me is that Apple never updated MacTerminal to represent the files graphically. For all practical purposes it works like any terminal software, or FTP – files are represented by a directory list. Odd considering that Apple could have really set themselves apart from the crowd. Auto connection would have been helpful too, so one doesn't have to manually choose send and receive (though I understand why that was the case with a 400K disk-based system.

I was referring to Classic Macs not being able to run apps off an FTP share.
Which reminds me. I need to check Sheepshaver's compatibility before I upgrade to Snow Leopard to ensure I can stilltransfer directly from OS X to my 128K.

Using MacTerminal, while slow is actually pretty easy. What surprises me is that Apple never updated MacTerminal to represent the files graphically. For all practical purposes it works like any terminal software, or FTP – files are represented by a directory list. Odd considering that Apple could have really set themselves apart from the crowd. Auto connection would have been helpful too, so one doesn't have to manually choose send and receive (though I understand why that was the case with a 400K disk-based system.
That reminds me, Mac 128, why don't use just use Zterm on your modern Mac, and MacTerminal on the 128?

I was referring to Classic Macs not being able to run apps off an FTP share. :)
Mounting a FTP share as a disk is something that came along in 10.4 or 10.5 (can't remember). A Mac Plus can't do that! It has to use a client, and pull the files down to it's on drive first.
FTP was never designed to do that. It is "file transfer protocol", it is not a file sharing protocol. Most file sharing protocols are designed for LANs, not WANs. Also, Classic OS has it's own share of pain through use of resource forks which make no sense to the rest of the planet.

Isn't FTP broken? Most contemporary sites require that the client uses SFTP or FTP over SSL. Not easy on a classic or vintage Mac.

That reminds me, Mac 128, why don't use just use Zterm on your modern Mac, and MacTerminal on the 128?
MacTerminal 1.1 was the GUI Mac-Like plug-n-play interface. It correctly handles the resource forks on the file so that it does not need to be compressed to be transferred (a bit of a hassle on anything less than System 6). So, you basically find the file you want to send and send it. It shows up on the other Mac exactly the way it appeared under the Classic Finder using ClarisWorks, which uses the MacTerminal 1.1 protocol. I could never get Zterm to work as smoothly and the files never made the transition intact. With MacTerminal, you just double click them and they work. I even wrote to the ZTerm people at one point asking them to add the MacTerminal 1.1 protocol, but it never happened, AFAIK. ClarisWorks was the last communications package I'm aware of which supports the MacTerminal 1.1 protocol.

Isn't FTP broken?
(a) clear text passwords

( B) unencrypted communications

© client acts as server during transfers

That reminds me, Mac 128, why don't use just use Zterm on your modern Mac, and MacTerminal on the 128?
MacTerminal 1.1 was the GUI Mac-Like plug-n-play interface. It correctly handles the resource forks on the file so that it does not need to be compressed to be transferred (a bit of a hassle on anything less than System 6). So, you basically find the file you want to send and send it. It shows up on the other Mac exactly the way it appeared under the Classic Finder using ClarisWorks, which uses the MacTerminal 1.1 protocol. I could never get Zterm to work as smoothly and the files never made the transition intact. With MacTerminal, you just double click them and they work. I even wrote to the ZTerm people at one point asking them to add the MacTerminal 1.1 protocol, but it never happened, AFAIK. ClarisWorks was the last communications package I'm aware of which supports the MacTerminal 1.1 protocol.
Mac128,

This article from Apple states that MacTerminal supports xmodem. So does ZTerm. Did you try send a file xmodem to xmodem?

http://docs.info.apple.com/article.html?artnum=1166&coll=ap

Isn't FTP broken? Most contemporary sites require that the client uses SFTP or FTP over SSL. Not easy on a classic or vintage Mac.
You'd be surprised how much regular FTP is still used by companies.

Mac OS 10.6 shares with standard FTP. I am able to access it with a System 6 Mac and Fetch 2.0. Going through the Root and the Volumes folder, I was also able to access my iDisk. :)

You'd be surprised how much regular FTP is still used by companies.
Another word might be "horrified".

If you are using a guest account and downloading freely available information then no problem, eg just as secure as an HTTP download.

This article from Apple states that MacTerminal supports xmodem. So does ZTerm. Did you try send a file xmodem to xmodem?
Yup. In fact to use MacTerminal 1.1, the protocol is set to XModem. The same is set under ClarisWorks. For whatever reason this did not work in ZTerm. While it may be XModem protocol, it is not MacTerminal 1.1 compatible, meaning it doesn't keep the resource forks intact in a way MacTerminal Xmodem understands them. This doesn't really surprise me as MacTerminal 2.2 is the highest version which can be used on a 128K, so the vintage version of XModem protocol it uses could be different than the a more modern and standardized version used in ZTerm. Also, MacTerminal 1.1 was a Mac-only legacy transfer protocol which was eliminated with ClarisWorks. I have to imagine that Apple modified the XTerm implementation to allow for encoding and decoding of the resource fork, and likely packet size, none of which would have been necessary on the original CP/M format, or PC driven variants which ZTerm claims to largely support. I just don't see anybody continuing a MacTerminal 1.1 legacy standard which was likely mostly usurped by more efficient ones in the late 80s.

On the other hand, I may not have had the settings adjusted exactly right on ZTerm, so it is worth obtaining the latest version and checking it out.

However, one thing Sheepshaver provides for that I do not believe Leopard does is the ability to use MFSLives to read from MFS disk images under the Finder (as Tiger allows). There is a certain amount of corruption that can occur when an HFS only FInder manipulates an originally MFS written file. Of course anything less than OS 8 on Sheepshaver will read an MFS file allowing that file to be loaded by SheepShaver. This also means all original disk images and Classic SEAs, and other archives, etc. can be kept and run in a "native" environment.

This article from Apple states that MacTerminal supports xmodem. So does ZTerm. Did you try send a file xmodem to xmodem?
Yup. In fact to use MacTerminal 1.1, the protocol is set to XModem. The same is set under ClarisWorks. For whatever reason this did not work in ZTerm. While it may be XModem protocol, it is not MacTerminal 1.1 compatible, meaning it doesn't keep the resource forks intact in a way MacTerminal Xmodem understands them. This doesn't really surprise me as MacTerminal 2.2 is the highest version which can be used on a 128K, so the vintage version of XModem protocol it uses could be different than the a more modern and standardized version used in ZTerm. Also, MacTerminal 1.1 was a Mac-only legacy transfer protocol which was eliminated with ClarisWorks. I have to imagine that Apple modified the XTerm implementation to allow for encoding and decoding of the resource fork, and likely packet size, none of which would have been necessary on the original CP/M format, or PC driven variants which ZTerm claims to largely support. I just don't see anybody continuing a MacTerminal 1.1 legacy standard which was likely mostly usurped by more efficient ones in the late 80s.

On the other hand, I may not have had the settings adjusted exactly right on ZTerm, so it is worth obtaining the latest version and checking it out.
Hmmm. I've just been messing around with ZTerm. I ran it on my LC and PowerMac 6500, and used a printer cable to connect. I was able to send files and apps over, and they retained their resource fork. It would be my expectation that a Mac specific app like this would cover those bases. I have MacTerminal 1.1, but it won't run on my LC, even under System 6. I still think there is a way to make this work. You mind emailing me MacTerminal 2.2 to give it a whirl?

I'm also going to send Dave Alverson an email. His last entry on his ZTerm page was a year ago, where he mentioned he was working on a UB for ZTerm. That would be cool, as I didn't install Rosetta with 10.6, and don't plan to.

There are also some other Terminal programs out there, like MacWise I might give a whirl.

This is a bit off topic

but...

Shouldn't this topic be in either software or General 68kmla news and stuff?

This is a bit off topicbut...

Shouldn't this topic be in either software or General 68kmla news and stuff?
Nope. Without Mac OS 9 connecting to Snow Leopard, there is no way to bridge a Mac 512k, Plus SE, etc....to a modern Mac using AppleShare.

This is a bit off topicbut...

Shouldn't this topic be in either software or General 68kmla news and stuff?
Nope. Without Mac OS 9 connecting to Snow Leopard, there is no way to bridge a Mac 512k, Plus SE, etc....to a modern Mac using AppleShare.
But doesn't that mean every Machine?

Its not like only the compacts had AppleTalk?

Some here have mentioned that many companies still use FTP, and that you can still use FTP to "access" old Macs from new. Terminal programs have also been mentioned for "access." I myself am well aware of that, but "limited access" is not the same as the robust file transfers one can perform via AppleTalk. I challenge you to drag and drop your SE/30's hard disk partitions (in my case, some being more than 1GB in size) to your OS 10.6 Intel Mac and do a full backup over Ethernet via FTP or Terminal programs! I've done a complete backup of my SE/30 this way, including System 6.x and 7.x and OS 8.1 system folders, with all files, filenames, custom icons, etc. intact after the transfer, with no special compression or encoding required. That is the big difference. Yes, FTP and terminal apps still provide access. But such "limited access" does not excite me.

Some here have mentioned that many companies still use FTP, and that you can still use FTP to "access" old Macs from new. Terminal programs have also been mentioned for "access." I myself am well aware of that, but "limited access" is not the same as the robust file transfers one can perform via AppleTalk. I challenge you to drag and drop your SE/30's hard disk partitions (in my case, some being more than 1GB in size) to your OS 10.6 Intel Mac and do a full backup over Ethernet via FTP or Terminal programs! I've done a complete backup of my SE/30 this way, including System 6.x and 7.x and OS 8.1 system folders, with all files, filenames, custom icons, etc. intact after the transfer, with no special compression or encoding required. That is the big difference. Yes, FTP and terminal apps still provide access. But such "limited access" does not excite me.
Dude, you've already made that point earlier in this post. No one is arguing with you. We're just discussing alternatives.

This is a bit off topicbut...

Shouldn't this topic be in either software or General 68kmla news and stuff?
Nope. Without Mac OS 9 connecting to Snow Leopard, there is no way to bridge a Mac 512k, Plus SE, etc....to a modern Mac using AppleShare.
But doesn't that mean every Machine?

Its not like only the compacts had AppleTalk?
Re-read my post. The compacts would get to 10.5 through an OS 9 machine as a bridge. Now they cannot. This is a Compact Mac problem. It qualifies.

bbbbut

don't all of the Machines built in that time period apply as well?

Am I missing something?

bbbbutdon't all of the Machines built in that time period apply as well?

Am I missing something?
I'm missing your point. What is it? Why do you care?

bbbbutdon't all of the Machines built in that time period apply as well?

Am I missing something?
I'm missing your point. What is it? Why do you care?
Well it would mean that this is in the wrong sub-forum! You know what er just forget it...

:?:

No one is arguing with you. We're just discussing alternatives.
Indeed. But your reply indicates you have misinterpreted my intentions. My repeated posts in this thread were aimed at emphasizing my own personal sorrow over Apple's foolish decision to kill of AppleTalk in OS 10.6. Additionally, I in some small way hoped to stimulate further discussion on "real alternatives" to what I in the past had accomplished with a Tiger Mac and an SE/30 via AppleTalk -- namely, the convenient means of speedy drag-and-drop file transfer for a large number of files. But so far, I have not seen any genuine "alternatives" presented here to the functionality that the AppleTalk protocol provided. FTP and Terminal apps are not complete alternatives to the functionality that AppleTalk gave us.

The removal of AppleTalk (especially for printing) from OS X is quite simply a blunder by Apple. Steve Jobs isn't killing AppleTalk so the Mac OS can move forward, as if "maintenance" or "compatibility updating" for the AppleTalk protocol had in any way delayed the release dates of any version of OS X. Jobs did it merely to slash-and-burn the past. Indeed, such also explains why it has taken the man took this long to OK a tablet design. Jobs hated every technological idea related to John Sculley and you will recall how short a time it took him to end axe the Newton (which still bests the iPhone/iPodTouch in some respects). Steve Jobs may be a genius about aesthetically pleasing industrial designs that sell, but he is also a man of extreme pettiness. I therefore am not among my Mac lovers who fear the day Steve Jobs is no longer at the helm in Cupertino. Indeed, it may be of some benefit to see him go. And I say this without ignoring the benefits he has brought to Apple, including the tremendous value he has directly and indirectly brought to the AAPL shares I own.

As to truly off-topic chit chat of whether this thread belongs in the compact Mac forum or not, that is a decision for ~tl alone to decide. As for me, I personally do not think it out of place as it pertains to old compact Macs more than newer Macs. Further, of all the forums on 68kMLA I prefer the Compact Mac forum. It excites me to get the oldest Macs to do things they were never intended to do, which includes networking compact Macs with even the newest Intel Macs running Tiger, Leopard and Snow Leopard.

No one is arguing with you. We're just discussing alternatives.
Indeed. But your reply indicates you have misinterpreted my intentions. My repeated posts in this thread were aimed at emphasizing my own personal sorrow over Apple's foolish decision to kill of AppleTalk in OS 10.6. Additionally, I in some small way hoped to stimulate further discussion on "real alternatives" to what I in the past had accomplished with a Tiger Mac and an SE/30 via AppleTalk -- namely, the convenient means of speedy drag-and-drop file transfer for a large number of files. But so far, I have not seen any genuine "alternatives" presented here to the functionality that the AppleTalk protocol provided. FTP and Terminal apps are not complete alternatives to the functionality that AppleTalk gave us.

The removal of AppleTalk (especially for printing) from OS X is quite simply a blunder by Apple. Steve Jobs isn't killing AppleTalk so the Mac OS can move forward, as if "maintenance" or "compatibility updating" for the AppleTalk protocol had in any way delayed the release dates of any version of OS X. Jobs did it merely to slash-and-burn the past. Indeed, such also explains why it has taken the man took this long to OK a tablet design. Jobs hated every technological idea related to John Sculley and you will recall how short a time it took him to end axe the Newton (which still bests the iPhone/iPodTouch in some respects). Steve Jobs may be a genius about aesthetically pleasing industrial designs that sell, but he is also a man of extreme pettiness. I therefore am not among my Mac lovers who fear the day Steve Jobs is no longer at the helm in Cupertino. Indeed, it may be of some benefit to see him go. And I say this without ignoring the benefits he has brought to Apple, including the tremendous value he has directly and indirectly brought to the AAPL shares I own.

As to truly off-topic chit chat of whether this thread belongs in the compact Mac forum or not, that is a decision for ~tl alone to decide. As for me, I personally do not think it out of place as it pertains to old compact Macs more than newer Macs. Further, of all the forums on 68kMLA I prefer the Compact Mac forum. It excites me to get the oldest Macs to do things they were never intended to do, which includes networking compact Macs with even the newest Intel Macs running Tiger, Leopard and Snow Leopard.
Would it be cool if 10.6 had an AppleShare 1.x server and could share to a Mac 512k? You bet it would! Should it at least share back to Classic Macs capable of AppleShare/IP like 10.5 did? Yes. Am I slamming my fists on the table about it? No. Tech moves on and part of that makes the challenge for us to work around it.

I seriously doubt Steve Jobs is PERSONALLY killing off old AFP versions. He really isn't that technical. He's not sitting around the table saying, "Johnny, I want you to kill AFP 1.x in Panther. Phil, kill off AppleTalk for file sharing in Tiger. Bertrand, kill off AFP 2.2 in Snow Leopard." Steve's got bigger fish to fry. These decisions are being made my Apple's software engineers based on real world use vs. testing time. I've said before, only old Apple nerds like us give a damn. Apple sells millions of Macs every year now. How many people play with classics Macs? Honestly?

The Sculley era is filled with many crippled Macs and a geuine inabilty to move forward with new ideas. My God, man, did we really need to run 7.5.5 on a Mac Plus? That's 11 years of support! For what? It ran horrible on 8 MHZ Macs.

Steve's hatred of all things Sculley has been overrated by many. If he hated all things Sculley, why didn't he axe Quicktime? Quicktime was a great technology, and it stayed and evolved to be the backbone of Apple's media services. The reason the Newton was killed is because it WASN"T SELLING WELL. Shocker, I know.

Steve also didn't like Amleio, but our Finder icon is still from his era too. :)

Tech moves on and part of that makes the challenge for us to work around it.
"Work around it" has been the inspiration for my posts in this thread. I am curious to hear what robust networking solutions there are beyond FTP and Terminal apps for OS 10.6 to 68k-Mac communication via Ethernet.

Having a number of classic Macs myself I've never had much need to run emulators, although I've launched vMac about a dozen times or so in the past. Is there an emulator that I can run on Snow Leopard that will allow use of the AppleTalk protocol to communicate with my SE/30, such that I can perform all the networking tasks I was able to do previously (such as dragging and dropping entire disk partitions from the SE/30 to make a backup on the modern Mac)?

I see from Googling that Snow Leopard will also not print to an Appletalk printer. X.5, by contrast, will even print to a localtalk printer (with an Appletalk Router on the network).

There are, of course, workarounds like print servers, but for most people, this kind of tinkering is beyond reach.

IT types may rejoice at the demise of Appletalk, but it is bad for the ordinary user. Appletalk was an excellent protocol for the ordinary user.

Some here have mentioned that many companies still use FTP, and that you can still use FTP to "access" old Macs from new. Terminal programs have also been mentioned for "access." I myself am well aware of that, but "limited access" is not the same as the robust file transfers one can perform via AppleTalk. ... I in some small way hoped to stimulate further discussion on "real alternatives" to what I in the past had accomplished with a Tiger Mac and an SE/30 via AppleTalk -- namely, the convenient means of speedy drag-and-drop file transfer for a large number of files. But so far, I have not seen any genuine "alternatives" presented here to the functionality that the AppleTalk protocol provided. FTP and Terminal apps are not complete alternatives to the functionality that AppleTalk gave us. It excites me to get the oldest Macs to do things they were never intended to do, which includes networking compact Macs with even the newest Intel Macs running Tiger, Leopard and Snow Leopard. ... Yes, FTP and terminal apps still provide access. But such "limited access" does not excite me.
First, accessing any files in a method that approaches anything close to the ease of AppleTalk on 128K or 64K ROM MFS system excites the hell out of me! Until I get MacServe 1.0 running on my 128K, MacTerminal will continue to be extremely exciting for me.

Second, I agree, it's really the compact Macs, the 68000 chips that are the most challenged when dealing with AppleTalk issues associated with OS X, and to a lesser degree the 24-bit IIx challenged Macs, of which the SE/30 is one. Any Mac that can run OS 7.6.1 or OS 8 does not necessarily face these issues in the same way and would have a somewhat different discussion.

As for solutions, I still vote for the easiest, which means an intermediary. All 10.6 has done is forced a 10.3 intermediary between 10.6 and the earliest Macs. So a 512K would need to go to an OS 8.1-9.2, to a 10.3, to a 10.6. I have two PowerBooks which would serve this function easily and quietly.

But like you I want to go directly from one into the other.

Is there an emulator that I can run on Snow Leopard that will allow use of the AppleTalk protocol to communicate with my SE/30, such that I can perform all the networking tasks I was able to do previously (such as dragging and dropping entire disk partitions from the SE/30 to make a backup on the modern Mac)?
Yes, Sheepshaver will do that. I can just as easily run AppleTalk out of that environment and share with older partitions. You may not be able to open the connection from the SE/30, but it should work bi-directionally once initiated from the OS X Mac. Of course, 10.6 has broken a number of things, so that is something that will have to be tested and fixed. I'll start looking at SheepShaver to see what can be done with it on 10.6. Of course, any emulator which wants to grab the serial driver for itself, might be able to manipulate the USB/Serial adapter I use with MacTerminal to drive real AppleTalk over the port.

I've asked Paul Pratt to look into this specifically for Mini vMac due to the fact that OS X continues to leave the real Macs further and further behind and no one else seems to be interested in maintaining Apple's Classic environment on the Intel platform.

Steve also didn't like Amleio, but our Finder icon is still from his era too. :)
Actually the Finder icon is from the Spindler era, first being used with the release of System 7.5 in 1994.

This article from Apple states that MacTerminal supports xmodem. So does ZTerm. Did you try send a file xmodem to xmodem?
Yup. In fact to use MacTerminal 1.1, the protocol is set to XModem. The same is set under ClarisWorks. For whatever reason this did not work in ZTerm. While it may be XModem protocol, it is not MacTerminal 1.1 compatible, meaning it doesn't keep the resource forks intact in a way MacTerminal Xmodem understands them. This doesn't really surprise me as MacTerminal 2.2 is the highest version which can be used on a 128K, so the vintage version of XModem protocol it uses could be different than the a more modern and standardized version used in ZTerm. Also, MacTerminal 1.1 was a Mac-only legacy transfer protocol which was eliminated with ClarisWorks. I have to imagine that Apple modified the XTerm implementation to allow for encoding and decoding of the resource fork, and likely packet size, none of which would have been necessary on the original CP/M format, or PC driven variants which ZTerm claims to largely support. I just don't see anybody continuing a MacTerminal 1.1 legacy standard which was likely mostly usurped by more efficient ones in the late 80s.

On the other hand, I may not have had the settings adjusted exactly right on ZTerm, so it is worth obtaining the latest version and checking it out.
OK, I got MacTerminal 2.2 and ZTerm to work. The correct combination was to set MacTerminal to use MacBinary under the File Transfer options, and send the file from ZTerm as Xmodem. Once I did that, the resource fork remained and everything was fine! There may be other configs that work, but the few i tried resulted in the file coming over and loosing the resource fork.

I'm going to get a Keyspan USB to serial adapter, and give this a whirl from Snow Leopard and ZTerm to my LC running MacTerminal 2.2. If this works, then it should work on a Mac 128k, since you mentioned 2.2 would work on it.

OK, I got MacTerminal 2.2 and ZTerm to work. The correct combination was to set MacTerminal to use MacBinary under the File Transfer options, and send the file from ZTerm as Xmodem. ... I'm going to get a Keyspan USB to serial adapter, and give this a whirl from Snow Leopard and ZTerm to my LC running MacTerminal 2.2. If this works, then it should work on a Mac 128k, since you mentioned 2.2 would work on it.
Apple is unclear about whether a 128K will officially support MacTerminal 2.2. Only that version 2.0 & 2.1 are incompatible with System 4.1. v. 2.2 is compatible and to use v. 4.0 or earlier. However, the 128K will not support System 4.0 and up. So I know that the 128K will support up to v. 2.1. EDIT: This Apple TIL seems to indicate that the 128K will support v. 2.2, but NOT v. 2.3. Guess I'd have to test it to be certain.

Nevertheless, I take it "MacBinary" is available in both v. 1.1 and 2.2 and otherwise the settings are the same. If so, v. 1.1 should work with XTerm as well. One question comes to mind as you are using a significantly more modern LC, running System 6 or 7? And what version of XTerm? What System on your 512K (I presume you were going from the LC to your 512K) – and v.2.2 on both?

I wonder if the 68K version of XTerm on your LC behaves the same as XTerm under Snow Leopard? The reason I wonder is that I'm certain I had MacTerminal set to MacBinary when I first tried to connect with XTerm from TIger using "Xmodem" protocol, though I may not have had that exact combination when I was testing. Perhaps there is an additional setting necessary in the OS X version, not required in the 68K version.

AFP under Snow Leopard

Also, I notice on my "Sharing" pane in System Prefs under Snow Leopard that the "File Sharing" service settings has an "Options" button that allows "Share files and folders using AFP" which was disabled by default. I presume you checked this and it still killed connecting to a legacy system?

I notice on my "Sharing" pane in System Prefs under Snow Leopard that the "File Sharing" service settings has an "Options" button that allows "Share files and folders using AFP" which was disabled by default. I presume you checked this and it still killed connecting to a legacy system?
I don't have 10.6 myself, but I read that AFP support for protocol versions prior to 3.0 was killed, but that AFP itself has not. So I interpret that as saying if we could find a way to get our old Macs to talk AFP3, then all would be well again.

OK, I got MacTerminal 2.2 and ZTerm to work. The correct combination was to set MacTerminal to use MacBinary under the File Transfer options, and send the file from ZTerm as Xmodem. ... I'm going to get a Keyspan USB to serial adapter, and give this a whirl from Snow Leopard and ZTerm to my LC running MacTerminal 2.2. If this works, then it should work on a Mac 128k, since you mentioned 2.2 would work on it.
Apple is unclear about whether a 128K will officially support MacTerminal 2.2. Only that version 2.0 & 2.1 are incompatible with System 4.1. v. 2.2 is compatible and to use v. 4.0 or earlier. However, the 128K will not support System 4.0 and up. So I know that the 128K will support up to v. 2.1.

Nevertheless, I take it "MacBinary" is available in both v. 1.1 and 2.2 and otherwise the settings are the same. If so, v. 1.1 should work with XTerm as well. One question comes to mind as you are using a significantly more modern LC, running System 6 or 7? And what version of XTerm? What System on your 512K (I presume you were going from the LC to your 512K) – and v.2.2 on both?

I wonder if the 68K version of XTerm on your LC behaves the same as XTerm under Snow Leopard? The reason I wonder is that I'm certain I had MacTerminal set to MacBinary when I first tried to connect with XTerm from TIger using "Xmodem" protocol, though I may not have had that exact combination when I was testing. Perhaps there is an additional setting necessary in the OS X version, not required in the 68K version.

AFP under Snow Leopard

Also, I notice on my "Sharing" pane in System Prefs under Snow Leopard that the "File Sharing" service settings has an "Options" button that allows "Share files and folders using AFP" which was disabled by default. I presume you checked this and it still killed connecting to a legacy system?
I had assumed you had used MacTerminal 2.2 on your Mac 128k before. Is this not the case?

MacTerminal 1.1 crashes on my LC running system 6, so I had to fire it up in Mini vMac. It does not have a MacBinary option. There are more options in 2.2, including MacBinary. That was the ticket.

My setup is as follows. LC running System 6 with MacTerminal 2.2. I set MacTerminal to connect to "Another Computer" instead of "Modem", set baud rate to 19200, The protocol to "MacBinary", turned on "Local Echo" and tuned Handshake to "XOn/XOff"

I connected the LC using standard Apple Din-8 printer/serial cable to my PowerMac 6500.

On the 6500, I am running ZTerm 1.1B7 (PowerPC Classic Mac OS version). This is the same version as the Mac OS X version. The developer decided not to have a unified Carbon version for technical reasons.

The ZTerm settings are also 19200, Local Echo, and XOn/XOff. I send and receive using XModem.

I did some more tests tonight. I was able to send and receive files from my LC and MacTerminal to network shares on my 6500 using ZTerm. Resource fork included. Freakin' sweet! Mac 128k to iDisk, here we come!

I had assumed you had used MacTerminal 2.2 on your Mac 128k before. Is this not the case? ...
Duh, it's in French! LOL

[1.1] does not have a MacBinary option. There are more options in 2.2, including MacBinary. That was the ticket.
According to Apple it should work, so French or not, I'll be trying it out as soon as I can. I think v.2.2 has more automation as well. I need to find some old MacTerminal books and dig into it more since this is likely to be the only method available on a stock 128K or 512K for some time (indeed any 68000).

It's great that I can bypass Sheepshaver. It is unfortunate that MFS Lives is not compatible with Leopard since that would mean one could simply open a 400K MFS disk image and load a file directly into XTerm, keeping everything native. I guess for now all MFS disk images will have to be copied onto HFS disk images and loaded from there. It's just sometimes those files introduce corruption, especially the System files.

Napbar, make sure you use the MFS 800K disk hack with your 128K. It really saves time giving you over 400K more disk space to copy files onto. Theoretically you can have over 1.6MB of storage using it, that's like a hard drive for a 128K.

I had assumed you had used MacTerminal 2.2 on your Mac 128k before. Is this not the case? ...
Duh, it's in French! LOL

[1.1] does not have a MacBinary option. There are more options in 2.2, including MacBinary. That was the ticket.
According to Apple it should work, so French or not, I'll be trying it out as soon as I can. I think v.2.2 has more automation as well. I need to find some old MacTerminal books and dig into it more since this is likely to be the only method available on a stock 128K or 512K for some time (indeed any 68000).

It's great that I can bypass Sheepshaver. It is unfortunate that MFS Lives is not compatible with Leopard since that would mean one could simply open a 400K MFS disk image and load a file directly into XTerm, keeping everything native. I guess for now all MFS disk images will have to be copied onto HFS disk images and loaded from there. It's just sometimes those files introduce corruption, especially the System files.

Napbar, make sure you use the MFS 800K disk hack with your 128K. It really saves time giving you over 400K more disk space to copy files onto. Theoretically you can have over 1.6MB of storage using it, that's like a hard drive for a 128K.
Hey, I figured it out! :) It's not that hard! Just look at the English 1.1 version. Almost identical (expect for the transfer option, but most of that is in English on 2.2)

Yes, this will be the only direct connection option for a Mac 128K, 512K/512Ke. A Mac Plus can do TCP/IP and Ethernet, so Fetch works just fine and Snow Leopard shares over FTP.

Speaking of MFS not working, it gets worse! I just found out that Snow Leopard treats old HFS disks as read only, and the Disk Image Utility will no longer create HFS disks!! Only HFS+!!! Yikes!! HFS has been MFS'ed!!!! LOL!!!!

I don't have a 128K or 512k yet. I'm doing preliminary experiments before I commit to purchasing a fully serviced 128K and or 512K. $$$$$! But I'll try the 800k trick if I get hold of those special 800k drives!

I just found out that Snow Leopard treats old HFS disks as read only, and the Disk Image Utility will no longer create HFS disks!!
Oh you have got to be KIDDING ME! Seriously? So Snow Leopard can no longer create an HFS disk for use with an older Mac? What the hell is wrong with them? I mean imagine ... you need to prep a disk for use with an older Power PC. I mean this is really taking the forced upgrade thing way too far. What is the harm in allowing HFS? It's simply a file structure. I have hope that if MFS could be implemented under Tiger that someone will add HFS to Snow Leopard, which (as I've pointed out) is still currently far more useful and relevant.

Thank GOD for Mini vMac. At least HFS & MFS disk images can still be manipulated. But here's a real problem. You won't be able to put files directly into an HFS disk image for use within Mini vMac. It will have to be manipulated directly within the application. But when did HFS+ become available? I think it was OS 8.1, which I don't think any 68000 will boot. This means HFS & HFS+ files will have to be manipulated in Sheepshaver or Basilisk II. What a fricking nightmare. I do believe Paul Pratt has enabled a way for files to be imported and exported to and from Mini vMac directly into OS X, so that may become a larger component of the system now. Brother ...

EDIT: I just checked, Paul's file importer doesn't import a stand-alone file with the resource fork intact. He recommends using an archive for that reason. Unfortunately, I don't think there is a good way to create an archive under OS X which can be opened under System 7.5.5 or less. Fortunately Paul is currently working on a Macintosh II emulator. Theoretically that emulator could use a IIfx ROM like the SE/30 & IIx which would allow for the use of HFS+ under 8.1. So the Mac II emulator becomes the most important Mini vMac emulator in order to maintain the original 68000 emulators. Of course Basilisk II and SheepShaver are alternatives which need to be further explored under Snow Leopard. I've already determined that some aspects of SheepShaver have been crippled by SL, like serial port access. Unfortunately neither has been touched since 2006.

But I'll try the 800k trick if I get hold of those special 800k drives!
Actually, not a very "special" drive. Fortunately, the UniDisk used that drive since 1985 and Apple switched to the same drive mechanism both internally and externally by September 86. So it is the most widely available 800K drive. The disabled header models were used only briefly in the Mac Plus and original 800K external drive.

(a) time only goes in one direction

( B) there is no money in it

You aren't obviously "thinking different" enough.
Oh you have got to be KIDDING ME! Seriously? What the hell is wrong with them? I mean this is really taking the forced upgrade thing way too far. What a fricking nightmare. Brother ...
All excellent sentiments I enjoyed reading because I for one share them. It's not about time (it probably took longer to axe features than retain them), money (you don't make or lose on something that's been there for years) or progress (as if retaining AFP and HFS compatibility for older Macs would have somehow held back OS X from moving forward). No, it's about engineering foolishness. Nevertheless, Steve Jobs has the power to be as big a fool as he sees fit.

"Stay Foolish."

— Steven Jobs, Stanford University commencement address, June 12, 2005

I just found out that Snow Leopard treats old HFS disks as read only, and the Disk Image Utility will no longer create HFS disks!!
Oh you have got to be KIDDING ME! Seriously? So Snow Leopard can no longer create an HFS disk for use with an older Mac? What the hell is wrong with them? I mean imagine ... you need to prep a disk for use with an older Power PC. I mean this is really taking the forced upgrade thing way too far. What is the harm in allowing HFS? It's simply a file structure. I have hope that if MFS could be implemented under Tiger that someone will add HFS to Snow Leopard, which (as I've pointed out) is still currently far more useful and relevant.
It gets worse, but I have to disagree with you on this being Apple's desire to force us to upgrade. These Classic Macs are NOT our production machines! The very reason we have them is because they are antiques, and we like fooling around with them. Cutting off support to them isn't going to make us buy a new machine! We have them because they are what they are.

That being said, I've ran into some more challenges with Snow Leopard. First, the disk mounting utility doesn't seem to launch Disk Copy 4.2 images or older anymore. Disk Copy 6 images mount ok.

2nd, I have a folder where I keep my classic apps and installers. Many are stuffed, but many are just laying around in folders. I noticed most of my un-stuffed file are not showing up correctly. Several apps appear as text files now. Even if I take them to my 6500, and rebuild the desktop, they don't work. It seems the resource fork has been screwed up. A few seem OK, though, so I'm not sure what the difference is. Point is, we can no longer trust that the resource forks are going to work when the bare files are exposed in 10.6.

Solution: On a OS 8.1 or later Mac, create a Disk Image with Disk Copy 6.3.3 large enough to house your retro files. Format it HFS+, and copy all your files to it. Next, covert the image to read only. Now place this image on 10.6, and mount it. As read only, the resource forks will be safe. From this mounted disk image, they can be shared with ZTerm directly to the Mac128k.

Why HFS+ instead of HFS you ask? After all, HFS mounts as read only in 10.6 to begin with. Well, I figure, how much longer will Mac OS X read HFS disks? HFS+ is still the foundation of OS X, and I figure it will be with us for many years as a supported format. A lot longer than HFS I would gather!

All excellent sentiments I enjoyed reading because I for one share them. It's not about time (it probably took longer to axe features than retain them), money (you don't make or lose on something that's been there for years) or progress (as if retaining AFP and HFS compatibility for older Macs would have somehow held back OS X from moving forward). No, it's about engineering foolishness. Nevertheless, Steve Jobs has the power to be as big a fool as he sees fit.
Steve Jobs is not a fool, and was not involved in this technical kind of a decision. I've already dispelled your argument earlier in this thread.

Steve also didn't like Amleio, but our Finder icon is still from his era too. :)
Actually the Finder icon is from the Spindler era, first being used with the release of System 7.5 in 1994.
I believe it first showed up in 7.5.3 splash screen, which was released around the time Amelio took over. I wasn't implying that Amelio personally designed the icon, just that it is most closely associated with his tenure at Apple.

I've already dispelled your argument earlier in this thread.
You have not dispelled any such thing in my mind, as evidenced by my continued posting on the subject. Your previous post contained your own speculation about Mr. Jobs and the fish he prefers to fry (and perhaps even the oil he uses for the frying).

You and I simply have a difference of opinion on the matter.

Well, hold your horses on my resource problem. I re-downloaded some of them from the internet, and they seem to be fine. It's quite possible I screwed something up along the way. My disk image thing would be the safest, but it may not be necessary. I'd like some more input on this from other Snow Leopard users. Have you seen resource forks go bad after upgrading?

I've already dispelled your argument earlier in this thread.
You have not dispelled any such thing in my mind, as evidenced by my continued posting on the subject. Your previous post contained your own speculation about Mr. Jobs and the fish he prefers to fry (and perhaps even the oil he uses for the frying).

You and I simply have a difference of opinion on the matter.

So you really believe he was on his death bed waiting for a liver transplant, and he PERSONALLY made sure legacy support was dropped????

So you really believe he was...
First of all, you underestimate Steve Jobs.

Second, our "difference of opinion" is largely irrelevant to how I (and perhaps a few others here) personally feel about the loss of AFP (prior to ver.3) and HFS compatibility as discussed in this thread. As my earlier post clearly stated, I merely felt the same remorse that Mac128 did. I posted that without having any desire to inflame your passions or debate you about Steve Jobs.

I come back to this thread in hopes of seeing how others are finding solutions for the unfortunate decision Apple engineers made (with or without the prodding of Mr. Jobs himself). And I wish to thank Mac128 for partly answering my question about OS 10.6 compatible emulators possibly being a solution for my connectivity aims.

So you really believe he was...
First of all, you underestimate Steve Jobs.

Second, our "difference of opinion" is largely irrelevant to how I (and perhaps a few others here) personally feel about the loss of AFP (prior to ver.3) and HFS compatibility as discussed in this thread. As my earlier post clearly stated, I merely felt the same remorse that Mac128 did. I posted that without having any desire to inflame your passions or debate you about Steve Jobs.

I come back to this thread in hopes of seeing how others are finding solutions for the unfortunate decision Apple engineers made (with or without the prodding of Mr. Jobs himself). And I wish to thank Mac128 for partly answering my question about OS 10.6 compatible emulators possibly being a solution for my connectivity aims.
I started this thread. My discussion was technical in nature. This argument only started when you brought up personal insults to Steve Jobs, which has no place in this forum. I would be glad to getting back to a technical discussion. I consider this debate between us closed.

All right, scratch my 10.6 resource fork worry. I went into my Time Machine backup, and they were screwed up long before I upgraded to Snow Leopard. Whew!!!!!

Far be it from me to offend the reigning author of a 68kMLA thread over my inadequate reverence of a mere mortal, Steve Jobs. Although some may choose to differ, my personal belief is that he is flesh and blood. None of my words concerning the man in this thread could in any way be construed as libelous, although they would not be in line with the tremendous reverence an Apple worshiper may demand. And since my words were speculation over why certain features of 10.6 were removed, it cannot properly be said that such comments (however personal they may have been) were "excessively off-topic." My words merely excited the emotions of at least one here, which is a bit surprising to me.

I love Apple Macs, both new and vintage. And I have paid my "respect" to Mr. Jobs and company in cold hard cash through many years of purchases, and my respect for his genius continues to this day. I never had a formal "debate" with the author of this thread to begin with, nor do I or any other 68kMLA member owe excessive respect to anyone for their merely having started a particular thread. This is an open forum for members to discuss issues pertaining to a given topic, which I and others have done even if the author or a select few others personally feel otherwise. Even so, the author of this thread has participated in it very well, offering insight into his own personal testing, for the good of the community. I have great respect and thanks for that.

I once again offer thanks to those who so kindly reply with great wisdom and knowledge in this thread and others, concerning the things which I and the author of this thread write about. We are a community united by our love for old Macs. But that doesn't mean we must agree in all cases. If we did agree on most things, we would probably all be Windows users, for goodness sake.

Mac128, had I copy of 10.6 myself I would give the emulator a try. But for now I look forward to hearing your findings. Thank you also for speaking to Paul Pratt concerning Mini vMac on that issue.

Sincere thanks to all for the information in this thread (even the comments that are not 100% of a technical nature).

Darn, I was just getting ready to set up a network with my SE/30, Orange iMac, and Macbook...Guess I'll have to stick to the old floppies and zip disks then. $1 to anybody who can guess what my avatar is!! :(
SneakerNet, with a pass-thru a Mac that handles floppies or Zips and USB thumbdrives, - I use my Pismo, less high tech than a network, but at least I get to run the machines for another good reason.

I'll PM you about your avatar, but you can keep your $1...

SneakerNet, with a pass-thru a Mac that handles floppies or Zips
Nope. That won't be happening either.

Since Snow Leopard only reads HFS, there will be no writing to disks, external 1.44MB floppy, ZIP or otherwise for use with any Mac which cannot run System 8.1. That rules out all the Compacts (with the possible exception of the 8.1 hack for the SE/30 and possibly CC/CC II & Classic II), which is where this topic is posted.

So no, Apple has effectively eliminated Snow Leopard as a practical platform from which to maintain a vintage Compact Mac. A suitable emulator like Mini vMac should allow disk images to be manipulated and then read directly into ZTerm for serial modem transfer, however, there is no way to write those files to a physical HFS disk in order to use the "SneakerNet" (that is sooooo 1984). In fact those files under Mini vMac will already have to exist on HFS images in order to even get them into Mini vMac (which does not yet support OS 8.1). In the interim, SheepShaver can be used (the latest 2006 build still mostly works under SL) to read HFS+ disks and transfer them to HFS. However, anything that can run 8.1 will also not be able to work with MFS disks, so keep Mini vMac handy (much more stable under SL anyway).

FTP works from the Mac Plus forward, thought not as elegant as AFP. Just out of curiosity, we know for sure they have dropped support for AFP 2.x and earlier? I know AFP 3.0 corresponds with OS X, but it had roots in OS 8 & 9, right? So did they essentially remove AFP support prior to the introduction of HFS+ with 8.1? If so there's an interesting parallel with dropping AFP on any System which did not support HFS (i.e. 128K/512K & MFS). Perhaps AFP 3.0 requires HFS+ files structures only to be optimized?

Here's an interesting articleabout losing legacy support under SL.

SneakerNet, with a pass-thru a Mac that handles floppies or Zips
Nope. That won't be happening either.

Since Snow Leopard only reads HFS, there will be no writing to disks, external 1.44MB floppy, ZIP or otherwise for use with any Mac which cannot run System 8.1. That rules out all the Compacts (with the possible exception of the 8.1 hack for the SE/30 and possibly CC/CC II & Classic II), which is where this topic is posted.

So no, Apple has effectively eliminated Snow Leopard as a practical platform from which to maintain a vintage Compact Mac. A suitable emulator like Mini vMac should allow disk images to be manipulated and then read directly into ZTerm for serial modem transfer, however, there is no way to write those files to a physical HFS disk in order to use the "SneakerNet" (that is sooooo 1984). In fact those files under Mini vMac will already have to exist on HFS images in order to even get them into Mini vMac (which does not yet support OS 8.1). In the interim, SheepShaver can be used (the latest 2006 build still mostly works under SL) to read HFS+ disks and transfer them to HFS. However, anything that can run 8.1 will also not be able to work with MFS disks, so keep Mini vMac handy (much more stable under SL anyway).

FTP works from the Mac Plus forward, thought not as elegant as AFP. Just out of curiosity, we know for sure they have dropped support for AFP 2.x and earlier? I know AFP 3.0 corresponds with OS X, but it had roots in OS 8 & 9, right? So did they essentially remove AFP support prior to the introduction of HFS+ with 8.1? If so there's an interesting parallel with dropping AFP on any System which did not support HFS (i.e. 128K/512K & MFS). Perhaps AFP 3.0 requires HFS+ files structures only to be optimized?

Here's an interesting articleabout losing legacy support under SL.
I'm confused by what you mean about dropping AFP. AFP has never been dropped. AFP is just another name for AppleShare. AppleTalk has been dropped as a low level protocol, and replaced with IP, but AFP (AppleShare) is still with us. Nevertheless, 10.6 seems to require AFP 3.0, and dropped support for AFP 2.1 and 2.2 (Which could use IP instead of AppleTalk).

Mac128, have you gotten the new build of SheepShaver from 2008? It's at this link.

http://www.emaculation.com/doku.php/sheepshaver

Random notes:

Mac OS X will let you format a USB floppy with HFS+. Classic Mac OS would never let you do this. HFS+ floppies can be read by System 8.1 and up.

Classic Mac OS let's you share USB floppies over AppleShare, but won't share internal floppies. Mac OS X won't share USB floppies.

What's happened to HFS disks mirrors what happened to MFS disks. Starting with 7.6, MFS floppies were read only. 6 months laster, by System 8, they were unreadable and ejected upon insertion.

My gut feeling, Mac OS 10.7 will require a 64-bit Intel processor, will not support Rosetta (optional already in 10.6), and not read HFS disks.

10.8 drops Carbon apps. The transition Apple is trying to make will be compete! :lol:

Just my two cents. Thoughts everyone?

I have to disagree with you on this being Apple's desire to force us to upgrade.
You are correct of course, but the net effect is that anyone still using HFS must upgrade. And anyone who does not need a more advanced system or features might opt out because they do want to maintain backwards compatibility. Is that going to be a large number of users? No. But there are still plenty of people running G4s & G5s with Leopard (or Tiger with Intels) because they want Classic compatibility for use with old software (some of it custom for which there is no OS X counterpart) that continues to work. But imagine if you will that you have a number of drives which you have carried forward since 1995 (think ZIP disks and removable drives for which there are USB counterparts now) and continued to use in their originally Mac formatted HFS. No harm no foul. They continued to work normally as OS X happily reads and writes those files. Now, a user might be faced will converting all of those drives needlessly, because Apple felt like eliminating a perfectly useable file system which wasn't harming anybody.

I'm confused by what you mean about dropping AFP. ... 10.6 seems to require AFP 3.0, and dropped support for AFP 2.1 and 2.2 (Which could use IP instead of AppleTalk).
That's what I meant. I went on a search for dates the various versions were released and came up dry. So when did AFP 2.1 appear? OS 7.5? What version appeared with OS 8.1, and 9?

Mac128, have you gotten the new build of SheepShaver from 2008?
Thanks for that link. I had been going to Gwenole Beauchesne's site.

My gut feeling, Mac OS 10.7 will require a 64-bit Intel processor, will not support Rosetta (optional already in 10.6), and not read HFS disks. 10.8 drops Carbon apps
Yeah I think that's about right.

However, with any luck, Paul Pratt will finish his Mac II emulator before that happens and all the built-in vintage Mac support anyone needs will be in it and it will play nice with OS X 10.6 and up. The problem of course will be that there will still be no way to write to physical media like ZIP disks and floppy disks. Theoretically couldn't a disk copy program write the correct data to a disk from an image made in an emulator like Disk Copy does for MFS under 8.1+? That would solve at least part of the problem of transferring files out, but not necessarily transferring them in. I wonder if it's possible for Mini vMac to tap into the USB ports and control external drives directly? Probably need some custom drivers. The best thing would be for Mini vMac to access the serial drivers directly and use good old fashioned AppleTalk, slow but functional.

Yup. Dropping HFS has pretty much made a requirement an intermediary OS X Mac running Leopard or less to work with any vintage Macs running a 68030 or less. The only positive is that there are numerous Macs available that can likely run 10.7 & 10.8 as well as 10.5 and serve this function. Once the next generation of Macs requiring Snow Leopard hits the streets, the writing will truly be in the snow.

That's what I meant. I went on a search for dates the various versions were released and came up dry. So when did AFP 2.1 appear? OS 7.5? What version appeared with OS 8.1, and 9?
Mac128, check out your email. I sent something you might find useful about AFP......

Apple felt like eliminating a perfectly useable file system which wasn't harming anybody.
Which causes one to recall what OpenStep developers did when they took over at Apple and released the OS X Beta: the Apple menu was gone and a new Finder (from OpenStep) came on the scene. However, due to a user outcry, a more traditional Mac OS Finder and something similar to the traditional Apple menu were restored in OS 10.0. (Even so, Apple never did put the Trash back where it belongs.)

Such a glorious turnabout unfortunately won't happen now with respect to the loss of AFP 2.x and full HFS disk support due to an insufficient number of us crying out about it, but the loss is nevertheless something to openly mourn. For truly AFP and HFS were not harming any users, but it so very clearly was harming the agenda (and "not invented here" mentality) of those who gave birth to OS X.

I haven't seen anybody mention the fact that Snow Leopard is a from-scratch 64-bit Intel rewrite of most of MacOS. Now given that your job is to write the network stack for OS 10.6, you're going to write a modern TCP/IP stack and test and debug it. Would you take on the additional task of writing a new AppleTalk stack? This isn't a case of some old feud resulting in code getting ripped out, it's new code not being developed. Same for file system support. And the brand new Finder looks just like the old Finder except has different bugs. If you don't like 10.6, don't upgrade. Or at least wait till 10.6.5 or so when things have settled down.

It just means that same as 10.4 and 10.5, you need an intermediate machine or two to get stuff from the early OSes to your shiny new Mac. A G3 or G4 which can boot either OS9 or OSX is your friend. I keep intending to look into XModem file software for OSX for file transfers to Apple][s and early Macs. I hope there's a good thread or two on this forum to help. (Noob here.)

If you don't like 10.6, don't upgrade.
If new Macs come on the scene that will only run 10.6 and higher, then the suggestion of "don't upgrade" would apply to the purchase of an entire computer as well.

If new Macs come on the scene that will only run 10.6 and higher, then the suggestion of "don't upgrade" would apply to the purchase of an entire computer as well.
Hang on to that Cube! It's a good bridge machine as well as being "the most beautiful computer ever" in most polls.

Hang on to that Cube! It's a good bridge machine as well as being "the most beautiful computer ever" in most polls.
Exactly! That's what I plan on doing! There's no reason Classics Macs can't be maintained by......a Classic Mac!

I want to get a Cube and install an SSD drive into it. That would make for totally silent computing. And a Mac 512k can connect to it over AppleShare.

I haven't seen anybody mention the fact that Snow Leopard is a from-scratch 64-bit Intel rewrite of most of MacOS. Now given that your job is to write the network stack for OS 10.6, you're going to write a modern TCP/IP stack and test and debug it. Would you take on the additional task of writing a new AppleTalk stack? This isn't a case of some old feud resulting in code getting ripped out, it's new code not being developed. Same for file system support. And the brand new Finder looks just like the old Finder except has different bugs. If you don't like 10.6, don't upgrade. Or at least wait till 10.6.5 or so when things have settled down.
It just means that same as 10.4 and 10.5, you need an intermediate machine or two to get stuff from the early OSes to your shiny new Mac. A G3 or G4 which can boot either OS9 or OSX is your friend. I keep intending to look into XModem file software for OSX for file transfers to Apple][s and early Macs. I hope there's a good thread or two on this forum to help. (Noob here.)

Is it really such a substantial re-write?

Why would they discard a perfectly good network stack? Does a network stack really need to be 64-bit? There are no frames or packets I know of larger than 4 GB.

You must also remember than Snow Leopard is not a "64-bit" rewrite, if it is a true rewrite at all. The very first Intel Macs, based on the Core Duo and Core Solo, are 32-bit Macs.

I want to get a Cube and install an SSD drive into it. That would make for totally silent computing. And a Mac 512k can connect to it over AppleShare.
There are a couple of folks doing just that over at cubeowner.com.

Is it really such a substantial re-write?
Exactly, Darwin started from FreeBSD which already ran on 64bit environments. UNIX has been in 64bit environments for donkey's years, it's the Apple specific code which may not have been 64-bit tested.

Why would they discard a perfectly good network stack? Does a network stack really need to be 64-bit?
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.

These are the same screams as were heard when floppies went away, and serial ports, and SCSI ports.
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.

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

Isn't FTP broken? Most contemporary sites require that the client uses SFTP or FTP over SSL. Not easy on a classic or vintage Mac.
Not easy ???

Use MacSFTP for SFTP at 8.6 & 9 and NetFinder for SSL, …

I keep intending to look into XModem file software for OSX for file transfers to Apple][s and early Macs. I hope there's a good thread or two on this forum to help.
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.

Mac OS X will let you format a USB floppy with HFS+. Classic Mac OS would never let you do this. HFS+ floppies can be read by System 8.1 and up.
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?

Mac OS X will let you format a USB floppy with HFS+. Classic Mac OS would never let you do this. HFS+ floppies can be read by System 8.1 and up.
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?

It's formatting as 720K you mean?
Yes, or 737k under the new Snow Leopard math!

I keep intending to look into XModem file software for OSX for file transfers to Apple][s and early Macs. I hope there's a good thread or two on this forum to help.
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.
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!

Ok, well, some more news.

I borrowed a friend's old iBook and installed 10.1 on it. I was able to connect to Snow Leopard just fine. This confirms my hunch that an AFP 3.0 client is now needed to connect to 10.6.

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.

Triplite (Keyspan) has released a Snow Leopard driver for the Serial Adapter. Although the old driver worked, it was buggy I found. The new one is even 64-bit compatible! We should be set for the future for connecting back to the 128k.

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.

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?

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?
A 60030 running 7.5.5 with properly updated Open Transport and AppleShare client. IE... Mac IIx from 1988.