Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Introducing a new way to run OS 9 on supported non-G4 and G5 macs, 100% compatible!
- Thread starter Rikintosh
- Start date
- Sort by reaction score
You're just a spoiled brat who got bitter because he thinks the world revolves around him.when you can’t deliver, you shut up.. basically it what means.
If you don't like it, go ahead and order it without a refund, oops! Oh, that's right, it was free, and yet you want to act like a Karen who bought something that didn't work lol
Perhaps this may be a bit off-topic, but since we are talking about improving OS 9 compatibility on OS X in this thread, I'm wondering if anyone has done work on getting MacIPX to work (or know why it doesn't work on a low-level technical level)? If not, would anyone be interested in teaming up to see if we can come up with a patch or fix?
From what I've read and tried, MacIPX seems to not load properly in Classic Environment on OS X 10.3 nor 10.4. But when I boot into OS9 on the same machine, it works perfectly. So, it's not just my installation, there's something that's not loading properly.
Examining the problem: The code for MacIPX seems to be entirely in 68000, but relatively short (~64k excluding Token Ring and AppleTalk drivers) and with a straightforward entry point (at least for INIT and cdev in the MacIPX resource fork). So, it should be relatively easy to debug and come up with a patch once we know what the problem is, if altering MacIPX is the way to go. However, it isn't clear at this point whether the problem is with how Classic Environment loads the MacIPX Ethernet driver or how the MacIPX Ethernet driver interacts with Classic Environment (e.g. Open Transport 2.8.3), nor whether it may be simpler to instead code a simple Ethernet IPX shim from scratch.
From what I've read and tried, MacIPX seems to not load properly in Classic Environment on OS X 10.3 nor 10.4. But when I boot into OS9 on the same machine, it works perfectly. So, it's not just my installation, there's something that's not loading properly.
Examining the problem: The code for MacIPX seems to be entirely in 68000, but relatively short (~64k excluding Token Ring and AppleTalk drivers) and with a straightforward entry point (at least for INIT and cdev in the MacIPX resource fork). So, it should be relatively easy to debug and come up with a patch once we know what the problem is, if altering MacIPX is the way to go. However, it isn't clear at this point whether the problem is with how Classic Environment loads the MacIPX Ethernet driver or how the MacIPX Ethernet driver interacts with Classic Environment (e.g. Open Transport 2.8.3), nor whether it may be simpler to instead code a simple Ethernet IPX shim from scratch.
Are you able to see if it works in 10.2.8's (or older) classic environment? That one is known to be much better than the one in 10.3 or 10.4
Unfortunately, the earliest OS X I have is Panther, albeit I have an install of OS 9 to compare in MacBugs if needed. MacBugs works pretty good in Classic.
I just found a better version of MacIPX 1.3.1, which no longer gives the FFD5 (file not found) error. It seems to partially work in that I can see proper 802.2 C&C IPX packets being sent from the PM G5 Classic machine in Wireshark on another machine in the network, but Classic seems to fails to acknowledge the packets sent from C&C running in OS 9. This version of MacIPX is supposed to wrap the OpenTransport API (presumably Raw Sockets?) for PCI ethernet cards (presumably some other versions may have instead accessed the card directly?).
So, I may find my answer by doing some digging into the calls to MacIPX and set a breakpoint or two. This would allow me to get an idea what MacIPX is receiving and processing and an idea of what C&C is seeing from MacIPX.
Looking briefly at the Doom source code, it seems that the MacIPX driver is found by calling PBOpen to look for NVL_IPX, and then PBControl is used thereafter to send and receive packets to the driver. (Since the API files seem to come from Novell directly, presumably C&C and other games are the same(?)). There are some good HTML versions of the Macintosh Inside pages regarding both system calls:
Examining the MacIPX control panel entry, there is a DRVR resource called NVL_IPX. From briefly examining the other resources in the MacIPX resource fork and the NLAP resource in the Ethernet extension, most if not all of MacIPX seems to be written in 68K. Noticing the 4E75 (RTS) commands before what appear to be debug symbols suggests that NVL_IPX is no different, and also written in 68K. However, from a static disassembly point, there seems be some sort of header, which is not yet clear.
So, I may find my answer by doing some digging into the calls to MacIPX and set a breakpoint or two. This would allow me to get an idea what MacIPX is receiving and processing and an idea of what C&C is seeing from MacIPX.
Looking briefly at the Doom source code, it seems that the MacIPX driver is found by calling PBOpen to look for NVL_IPX, and then PBControl is used thereafter to send and receive packets to the driver. (Since the API files seem to come from Novell directly, presumably C&C and other games are the same(?)). There are some good HTML versions of the Macintosh Inside pages regarding both system calls:
Examining the MacIPX control panel entry, there is a DRVR resource called NVL_IPX. From briefly examining the other resources in the MacIPX resource fork and the NLAP resource in the Ethernet extension, most if not all of MacIPX seems to be written in 68K. Noticing the 4E75 (RTS) commands before what appear to be debug symbols suggests that NVL_IPX is no different, and also written in 68K. However, from a static disassembly point, there seems be some sort of header, which is not yet clear.