Open system call failing on System 6 but working on System 7

[atommclain]

Woah! Major hat tip @Crutch! Somehow I missed this in my initial research, this is awesome!

Well I am loath (playfully) to share the following but it only seems fair. I contacted the Purdue Xinu group regarding getting a copy of the source code for the Mac edition (my book did contain a post card where you could purchase a copy for like $80). I got a reply on a Sunday morning from Douglas Comer one of the co-authors (and a quite influential person in computer history) providing me the source code. Apparently he had to pull it off a tape backup.

This was a project I was thinking about working on mid-next year, but given your interest and discovery of the "lost" compiler, would you be interested in being the first person in 20+ years to create a Mac Xinu build?

 

[cheesestraws]

Not strictly relevant, but wasn't Aztec C also available for the Atari ST? I think I might have a copy of that version, including manuals, for some bizarre reason...

Also, even further off-topic: was glad to see John Barrow in that bibliography. A fascinating person. His Gresham College lecture series are interesting, in a "public engagement" kind of way

 

[Crutch]

@atommclain I am extremely interested in trying to get this to work, though time commitment is definitely an issue. I that same reply card in my book for $80, it never occurred to me to try sending it in! Brilliant. Is there a way you can share the source code?

@cheesestraws — yes! There is an Aztec C binder for Atari ST for sale right now on eBay I believe. It hadn’t occurred to me before but maybe the command line interface is identical to the Mac version? Ohhhh never mind I just checked, it’s an empty binder with some Atari floppies but devoid of any actual pages …. could be yours for $150! Sad.

Is that the John Barrow who wrote The Artful Universe (which I loved) and The Constants of Nature (which I really strongly disliked)? I bet he is an interesting guy.

 

[cheesestraws]

— yes! There is an Aztec C binder for Atari ST for sale right now on eBay I believe. It hadn’t occurred to me before but maybe the command line interface is identical to the Mac version?

When I get back to my books, I will try to remember to see if what I think is Aztec C actually is, and if so I am happy to scan in / photograph stuff if it would be useful!

Is that the John Barrow who wrote The Artful Universe (which I loved) and The Constants of Nature (which I really strongly disliked)? I bet he is an interesting guy.

That's the one! I love the wideness of his perspective on things. I haven't read The Constants of Nature, though, so can't either corroborate or disagree with you there

 

[atommclain]

It hadn’t occurred to me before but maybe the command line interface is identical to the Mac version?

You know I took a closer look at that Aztec C link and it looks like its for a Dos version that compiles 68k code? I guess in theory it should work since what I've read so far Xinu doesn't use any toolbox/rom routines.

I'll send you a link shortly

 

[PB170]

That'd work.

PBOpenDFSync fixes a long-standing wart (in my opinion; the fact they fixed it suggests they also thought this) where the Open family of functions decided whether to open a file or a device based on the name, which means that Open can't open files with names that begin with full stops (.), whereas the OpenDF family can.

Oooh, that answers something I’ve been curious about for a long, long time! I frequently transfer stuff from OS X to my PowerBook, and as a result, hidden .DS_Store files are scattered all over the disk. Then whenever I run Norton Disk Doctor to check the system, it neatly puts together a list of all of them with the comment ”The following files have periods as the first character of their names. Apple recommends not doing this”. I always thought this was a curious coincidence considering how OS X wasn’t around at the time, and wondered what the reason might be. Finally an answer!

 

[atommclain]

At the risk of derailing our derailed conversation, I'm curious if I could get feedback on another issue I'm running into.

In brief, the codebase is using FSpOpenResFile and FSpCreateResFile, which are System 7+ functions. I'm trying to figure out how to correctly create and open a resource file on a HFS system with System 6.

I found MoreFiles which is a helpful set of tools provided by Apple Macintosh Developer Technical Support that adds some backwards compatibility with the new System 7 FFSpec based functions but their FSp*ResFile functions just fall back to H*ResFile functions that are also limited to System 7+.

Reading up on FSpOpenResFile and FSpCreateResFile.
IM 6 13-16

These routines are based on the CreateResFile procedure, which is documented in the Resource Manager chapter of Volume I.
These functions are based on the OpenResFile function, which is documented in Volume I.

Looking at CreateResFile and OpenResFile
IM 1-114

When calling the CreateResFile or OpenResFile routine, described below, you specify a resource file by its file name; the routine assumes that the file has a version number of 0 and is on the default volume.
...
If you want the routine to apply to a file on another volume, just set the default volume to that volume

IM 4-107

SetVol sets the default volume to the mounted volume specified by volName or vRefNum.

IM 4-98 Working Directories

When the File Manager makes a particular directory a working directory (using the function OpenWD), it stores the directory ID, as well as the volume reference number of the volume on which the directory is located, in a working directory control block. The File Manager then returns a unique working directory reference number which you can use in subsequent calls to refer to that directory.
...
Directories can be seen as mini-volumes. (The root directory is, in fact, just another mini volume; it contains only the files and directories immediately below it in the tree structure.) A working directory reference number is just like a volume reference number for a directory.
...
A working directory reference number can be used in place of a volume reference number in any File Manager call.

So as I think I understand it, in theory, I would do the following:

1. Call GetVolInfo to restore when we are done; check for error
2. Get the vRefNum of the applicable directory (hand waving here)
3. Call OpenWD with the vRefNum of applicable directory; check for error
4. Call SetVol with a vRefNum returned from OpenWD; check for error
5. Call CreateResFile with the name of the file I want to create; check for ResError
6. Call OpenResFile with the name of the file just created; check for ResError (may be able to use OpenRFPerm as well)
7. Do stuf
8. Call CloseResFile; check for ResError
9. Call CloseWD; check for error
10. Call SetVol with info at go beginning of routine to restore the previous working volume; check for error

Is that correct? Do I need to do the GetVol/SetVol dance, or does OpenWD handle that already?

 

[Crutch]

HOpenRF (for which HOpenResFile is an alias) is supported back to the 512KE and Mac Plus. Does that give you what you need?

Otherwise yes you can do what you say. I don’t normally restore the default volume (GetVol/SetVol) after changing it, curious why you think you need to do this?

 

[cmholm]

I found this thread while trying to track down a copy of the Macintosh XINU source. I had a copy of the Comer Mac Edition book when it was new, but never bought the code disk, and wasn't able to build from just what I typed in from the book. Comer had to dig it up from tape? Wow.

I realize I'm jumping in a year and a half late, but I succumbed to a retro bug at the 2024 VCF in Orange, CA a week back, and came home with a Mac SE. Perhaps now that Comer *may* have a MacOS Xinu archive on disk, it won't be as tall an ask the second time. I'm glad I found this discussion to alert me to that.

The Aztec C on Macintosh Garden is a DOS-based cross compiler. I've seen period and retrospective reviews noting that there was a Macintosh native version available standalone or within MPW.