A/UX "MacTCP" driver—where is it?

[cheesestraws]

I'm trying to track down an A/UX oddity where I'm getting spurious MacTCP errors.

I know that A/UX's MacTCP isn't really MacTCP, but is a compatibility layer. Presumably this compatibility layer is a driver somewhere, because, after all, its published API consists almost entirely of PBControl calls.

But where is this driver? It's not in the shim MacTCP control panel, which contains no DRVRs at all. It's not in the System file. Where on earth does it live?

 

[Phipli]

Can you catch it by running a big copy and peeking at ps?

He says, anticipating not being hugely helpful, but willing if nothing else.

 

[cheesestraws]

<3

Unfortunately, it's not there: it's the mac-side code I'm looking for, which isn't even a process in MacOS's model of the world, let alone in the UNIX side.

 

[Phipli]

<3

Unfortunately, it's not there: it's the mac-side code I'm looking for, which isn't even a process in MacOS's model of the world, let alone in the UNIX side.

Hum, so does that mean it must be in a CDEV or an INIT? Or might it be some random file elsewhere?

While most INITs are in the extension folder, some hide in the System Folder from Sys 6 days (shakes fist at the midi driver that clearly has a hard coded path in it to the System Folder), plus a small number (31?) built into the System File?? That last point won't be pertinent.

You'll have looked in Control Panels and Extensions, have you checked inside the System Folder, and perhaps the Finder and System File just in case. Are there any other... AUX System Enabler files or anything?

Can you write an app that iterates through the file hierarchy, and checks for resources of a type and spits out file name, path and "has DRVR"? To spot them in funny locations?

 

[cheesestraws]

It'll be a DRVR resource somewhere. Could, in theory, be loaded from anywhere.

I think I'm going to have to spelunking into the device manager.

 

[Crutch]

I think it’s fundamentally not that easy to find out where a DRVR came from, since they are identified by name, then loaded and detached and the name isn’t kept around anywhere. No doubt you’ve thought of something like this but, have you tried doing “ATB Open” in Macsbug? Then you’ll know every time anyone opens a driver. After each call check the ioRefNum offset from A0 to see the reference number of the newly opened driver. Presumably you know the reference number you are looking for (since you’re making those PBControl calls?), so you’ll know when you’ve found the Open call that’s opening the driver you want.

You could do this most conveniently by telling Macsbug

ATB Open ‘;t;dw a0+xxxxx’

where xxxxx is the ParamBlock offset of ioRefNum (not sure offhand but easy to check). This will break every time Open is called, then automatically step over the Open call and show you the word at a0+xxxxx on exit. (There might be a lot of Open calls though in a typical OS load cycle, so this could be an annoying process but you’d only have to do it once.)

Now you can look at the ioNamePtr in the same ParamBlockRec to get the resource name of the DRVR you want. You can then code up a little depth first search to check all resource files in your hard disk for DRVR resources with that name, Or, at the point where that Open is called, you could do ’HD DRVR’ in Macsbug and find out what file that DRVR is in, I think.

Might work?

 

[cheesestraws]

Oh, the HD is a good thought. I knocked up a quick thing to find the driver in memory, and it's definitely a real driver, but looking at HomeResFile() for the driver handle doesn't say anything very useful.

 

[Crutch]

Unless I’m missing something, I would not expect HomeResFile to work at all, because I think it’s true that DRVRs are (almost) always detached once loaded?

 

[cheesestraws]

You're not missing something, I was That explains why that didn't work...

 

[cheesestraws]

Closure for you both @Phipli and @Crutch : it's not in a resource at all. It's in the A/UX Patches at /mac/bin/Patches/..., which is a UNIX-side library, and it looks like it's forcibly inserted into the unit table by the patched device manager initialisation code.

No wonder I was confused trying to find it.

 

[Nixontheknight]

Closure for you both @Phipli and @Crutch : it's not in a resource at all. It's in the A/UX Patches at /mac/bin/Patches/..., which is a UNIX-side library, and it looks like it's forcibly inserted into the unit table by the patched device manager initialisation code.

No wonder I was confused trying to find it.

View attachment 47197

it's probably a UNIX side library so that all programs can use it, not just Macintosh programs, and it's probably inserted into the Mac side's unit table so that apps think it's MacTCP instead of having to code the pipe through to the patch themselves, breaking compatibility with standard Mac OS

 

[cheesestraws]

it's probably a UNIX side library so that all programs can use it, not just Macintosh programs

It's not. When I say "library" I only mean in file format. It is an undocumented internal part of the A/UX Toolbox environment.

UNIX applications under A/UX are meant to use the BSD Sockets API, per the documentation. A/UX Toolbox hybrid applications link to libmac (I think that's what it's called), not to Patches_XXXX. Hybrid applications could, if they really wanted, use MacTCP, but they could do that even if the MacTCP driver was in a resource, because MacTCP is controlled through the Device Manager. And you can't use the driver outside of the context of a hybrid or Mac application because you won't have the Device Manager available.

So it's pretty certainly a matter of developer convenience rather than API availability to other software. It feels icky, but I suppose there's no reason it shouldn't be there: the word "patches" on the Mac can cover ... rather large changes in functionality, after all.

 

[MindWalker]

I can't offer any help here, but this is fascinating to read and I hope this investigative work will help getting more stuff working in the A/UX's Mac side, fe. GetDown Classic (which currently does not work there). That would be nice

 

[cheesestraws]

fe. GetDown Classic (which currently does not work there). That would be nice

Oh, try this for that:

This extension creates a MacTCP gestalt selector so that stuff can find A/UX's MacTCP that looks for the gestalt. I think that's why GetDown Classic doesn't work.

It doesn't implement any other APIs though so if this doesn't work, welp.

 

[MindWalker]

Oh wow, that was an interesting piece of software... thanks!

I just tested it and it kinda works! After adding the fudger, GetDown would then complain about missing Thread Manager. After adding that too, I was able to launch it! However the downloads were very slow and it was be very unstable (if nothing else, attempting to quit the application would freeze the machine). Perhaps it hangs waiting for some API that doesn't exist here.

Fortunately I still have wget

 

[cheesestraws]

Ah, well, it was worth a try .

 

[CC_333]

Ah, well, it was worth a try .

And the fact that it did allow GetDown Glassic to load, even if brokenly, suggests that something along the lines of the "fudger", but more advanced, could work more completely and reliably, so this try provides some very valuable information (watching what goes on in a debugger (does A/UX use regular Macsbug, a special variant thereof, or something else entirely?) would be an important next step.

I have been meaning to install and play with A/UX, but I don't have any compatible real hardware handy (it's all in storage) and finding and configuring an emulator that can run it reliably (if at all) is, last I checked, somewhat of a pain, so I really haven't had much of a desire to actually try anything because it just seems too daunting....

c

 

[Corgi]

I have been meaning to install and play with A/UX, but I don't have any compatible real hardware handy (it's all in storage) and finding and configuring an emulator that can run it reliably (if at all) is, last I checked, somewhat of a pain, so I really haven't had much of a desire to actually try anything because it just seems too daunting....

c

I'm typically the last one to recommend emulators, but I do like seeing the development scene for A/UX grow, so…

Recent version of Qemu "just work" running A/UX as long as you have a Quadra 800 and its ROM. A tutorial for a Windows host is available; it works pretty much the same on the Mac OS. There's also Shoebill.

 

[cheesestraws]

I have been meaning to install and play with A/UX, but I don't have any compatible real hardware handy (it's all in storage) and finding and configuring an emulator that can run it reliably (if at all) is, last I checked, somewhat of a pain, so I really haven't had much of a desire to actually try anything because it just seems too daunting....

Recent version of Qemu "just work" running A/UX as long as you have a Quadra 800 and its ROM. A tutorial for a Windows host is available; it works pretty much the same on the Mac OS. There's also Shoebill.

Agreed, emulation for A/UX is much less painful than it used to be, and A/UX itself is dead easy to install (it does not deserve its reputation for difficulty). Give it a go!

I do like seeing the development scene for A/UX grow, so…

I'm hardly an organised source of information, given that I never finish anything and my brain is prone to glitching, but if people would be interested I'll try to write up things I find out (I'm currently taking the Patches file to bits in IDA to work out which bits of "MacTCP" work properly, for example)...

That said, I procrastinated the last A/UX howto I promised to write so long that it became irrelevant, so