Building device drivers for System 7?

[derjanni]

Hiho Macintosh community!

I've written some applications for System 7 now. Mainly small stuff to familiarize myself with C on System 7. I am using Think C 5 and Resedit 2 and it's really wonderful to code for the small Macintoshes. I specifically enjoy writing stuff with MacTCP. The develop journal of Spring 1991 has a pretty nice in-depth explanation of how to code MacTCP, which I used to learn how to use MacTCP: https://vintageapple.org/develop/pdf/develop-06_9104_Spring_1991.pdf

Now, the journal mentions that there are "MacTCP Device Drivers" under the hood of MacTCP which is no surprise. A couple of other books (e.g. "Inside Macintosh Vol II") also explain how the Device Manager communicates with the drivers. I'm trying to dig through the develop journals and books, but haven't yet found any information.

• Can anyone recommend any material on how to write device drivers for System 7?
• How are device drivers generally registered with System 7?

Many thanks, J

 

[Phipli]

Cough...

@cheesestraws
@Crutch

 

[cheesestraws]

If you're talking about drivers in the strict sense, Inside Macintosh: Devices is the canonical reference, though of variable readability. Drivers fundamentally provide an abstraction over I/O: you provide the OS with a set of routines (open / close / prime (which handles read and write) / status / control) and the OS then orchestrates calls to those to service multiple applications calling you. If you want to write a driver that does a specific job, say to do SCSI or video or something, you implement a conventional set of status and control messages. If you want to write a driver that does something wildly different like, say, MacTCP, you make your own up.

This means you don't exactly 'register' drivers with the OS: they're code resources and you open them when you need them, a bit like files, and close them when you don't need them any more.

Things are made more complicated by the use of the word 'driver' to also mean 'any software that interacts with hardware and provides services', and not all drivers in this loose sense are drivers in the strict sense. For example, the "driver" for an accelerator will be an Extension (INIT) or Control Panel (cdev), which boil down to being chunks of code that run at startup and attach hooks for later shenanigans. Other drivers I've seen can even be background-only applications, which other applications send messages to.

So it kind of depends whether you mean 'driver' in the strict sense or in the loose sense, and what it is you're actually trying to drive. Which isn't helpful but is, unfortunately, true...

 

[cheesestraws]

I should add here that there are example drivers around: the version of CodeWarrior I use certainly came with one. They'll usually be filed under "code resources" and labelled DRVRs. A slightly bewildering example of the use of drivers is desk accessories, which boil down to being drivers with a user interface: those were used to get around the lack of multitasking in early MacOSes.

 

[derjanni]

If you're talking about drivers in the strict sense, Inside Macintosh: Devices is the canonical reference, though of variable readability.

Awesome, thanks! Will read through it now. I'm predominantly looking to write a MacTCP "driver" for a NIC so that I could build my own network card. Not sure if I will, but I just want to first learn how to do it.

 

[cheesestraws]

Awesome, thanks! Will read through it now. I'm predominantly looking to write a MacTCP "driver" for a NIC so that I could build my own network card. Not sure if I will, but I just want to first learn how to do it.

Are we talking an Ethernet card or some other networking technology? MacTCP will be the wrong layer to do that in, you'll want to go a layer lower so protocols that aren't IP can work, too. There is a mechanism for pluggable Ethernet drivers, though I don't actually know where the documentation for that is...

 

[derjanni]

Are we talking an Ethernet card or some other networking technology? MacTCP will be the wrong layer to do that in, you'll want to go a layer lower so protocols that aren't IP can work, too. There is a mechanism for pluggable Ethernet drivers, though I don't actually know where the documentation for that is...

I am specifically looking into TCP/IP. I am wondering if it is possible to create a driver for System 7 that uses an external TCP/IP stack (e.g. from an ESP32 or u-blox NINA-W102) over SCSI or RS422. My idea would be that the driver exposes the functions MacTCP requires and forwards them to the external chip with its own and faster TCP/IP stack. Alternatively the question may be if the MacTCP library could be replaced by a custom compatible library.

 

[cheesestraws]

Alternatively the question may be if the MacTCP library could be replaced by a custom compatible library.

I've wondered about this myself: I was wondering if you could offload SSL to the external processor as well .

Here's a bullet point overview of where I got throwing this idea around, which you can use or discard bits of as you see fit:

• It's totally possible to build a driver that provides the same interface as MacTCP. A/UX has such a driver in it, for example. There are subtleties, especially around RecvNoCopy and the like, which A/UX doesn't get right, and might require some tweaking and serious testing. But it's a totally viable approach and probably the one I would go with, rather than trying to hook into the back of MacTCP.
  
  
• Some of MacTCP's slowness comes from its design and the design of its interface as much as its actual innards. It's probably worth investigating how much of it is unavoidable before committing to a course of action.
  
  
• Doing this means that your network device won't be compatible with Open Transport. I suspect that machines that'll run OT are going to be fast enough not to derive a huge amount of benefit from this kind of approach, although SSL offload would still be cool for those machines. Though it would also be amusing if the only old macs that could speak modern TLS were pre-OT ones.
  
  
• TLS offload would be quite a bit of work on its own: the best option might be to be to leave hooks in for it but otherwise ignore it initially, and go back to it later.
  
  
• A lot of the useful network functions of pre-OT Macs require AppleTalk. It would be a shame, for example, for people to be unable to use a network device for file sharing, printer sharing, or time synchronisation. So I think you'd want a stub ethernet driver to at least allow sending and receiving of raw frames for non-IP ethertypes. The other option would be to hook it into the back end of the LAP manager, but that sounds much harder and would probably achieve a worse result.
  
  
• The protocols for both the NuovoLink (later focus) and Dayna SCSI->Ethernet boxes are pretty well understood now and might provide ideas for this bit. I was wondering whether the best thing to do was to implement this as extensions to, say, the Dayna protocol (the nuovolink one seems a little hairy, from what I understand) then allow the use of the Dayna driver with your extra MacTCP shim to talk to the IP offload functions. Doing it over RS422 will be too slow to be very useful: you can clock the line faster but you'll never make it go as fast as SCSI.

 

[derjanni]

It's totally possible to build a driver that provides the same interface as MacTCP. A/UX has such a driver in it, for example. There are subtleties, especially around RecvNoCopy and the like, which A/UX doesn't get right, and might require some tweaking and serious testing. But it's a totally viable approach and probably the one I would go with, rather than trying to hook into the back of MacTCP.

I'm totally fine with the ~230kbps through RS422.

My approach to the idea (MacTCP over RS422) would then be the following.

1. Hook up an ESP32 with the Mac RS422 and check the actual bandwidth (Prototyping)
2. Design a serial protocol for the Mac and the ESP32 to communicate (MacTCP over RS422)
3. Implement the serial protocol on the ESP32
4. Implement a MacTCP-compatible device driver/lib/chooser-gui for the Mac
   The MacTCP lib would essentially just forward the methods on the serial.

It's quite some work that needs to be done and I guess I'll start by prototyping the RS422 between the ESP32 and the Mac using the "Serial Driver" from both units. Microsoft published the Sourcebook, but unfortunately given it's release date of 1989, it doesn't have MacTCP in there: https://vintageapple.org/macprogramming/pdf/The_Programmers_Apple_Mac_Sourcebook_1989.pdf

Do you know where I could get a complete reference of MacTCP libs and its functions?

P.S.: target platform would be anything below System 7.5

 

[cheesestraws]

Do you know where I could get a complete reference of MacTCP libs and its functions?

This is probably the best you're going to get: this is the MacTCP Programming Guide, which is kind of ... not widely distributed for some reason, so I'm attaching it here.

 

[uyjulian]

If the documentation isn't enough, reverse engineering the MacTCP or Open Transport INITs with Ghidra is also an option.