jordan@Morgan.COM (Jordan Hayes) (10/06/90)
*Whew* So, I just spent nearly a lifetime grabbing stuff from that archive and the one at afsg.apple.com (thanks guys!) -- 30Mb via FTP, uuencode, mail -> uunet, uudecode, PC/NFS to PS/2, to floppies, through AFE in MacOS, uncompressed in A/UX 2.0 ... there's gotta be a better way! (By the way, AFE stuck a header on the files even though I used "default translation") that I had to get rid of by doing % dd bs=282 skip=1 before I could uncompress ... whatta pain! I tried "apropos file" and "apropos such and such" looking for something that might be of help, like "macbtounix(1)" or somesuch) So, I followed all the directions of the README file, and I double-clicked the X11 shell script, which brought up Commando and I just clicked OK, and I get this error message: can't ioctl(): invalid argument My main monitor is a Radius Pivot, which I thought was A/UX and X11R4 compatable. Was I wrong? Do I need the RadiusWare in the System Folder of the launch partition? (The control panel knows about it and I use it for Command Shells and such). I am running the latest RadiusWare stuff that was posted recently by the folks at Radius. Help? /jordan
jordan@Morgan.COM (Jordan Hayes) (10/06/90)
I wrote: can't ioctl(): invalid argument So, I switched my monitors around so that my trusty Apple 8-bit video card was installed as the first monitor, and tried it again, this time just from the command line. Here's what I got: localhost<7># XmacII ProcessCommandLine In while(1) InitBlockAndWakeupHandlers OsInit CreateWellKnownSockets InitProcVectors InitClientResources(sc) SetInputCheck InitAtoms InitEvents ResetScreenPrivates ResetWindowPrivates ResetGCPrivates InitOutput Fatal server bug! ioctl I_STR VIDEO_MAP_SLOT failed IOT trap (core dumped) ----- This occurs in macIIslotProbe ... anyone seen this before? /jordan
rmtodd@servalan.uucp (Richard Todd) (10/07/90)
jordan@Morgan.COM (Jordan Hayes) writes: >(By the way, AFE stuck a header on the files even though I used >"default translation") that I had to get rid of by doing > % dd bs=282 skip=1 The reason is that AFE is a MacOS program, and that "default header" is the resource and info forks of a MacOS style file. I don't know if you're familiar with the MacOS concept of file forks; basically, like Gaul, MacOS files are always divided into 3 parts, an info fork (which records various bits of status for benefit of the Finder, I believe), a resource fork (read Inside Mac for all the sorts of things this part can contain, it's really too complicated to go into here) and the data fork (just ordinary sequential file like most systems have). Since A/UX, like all other Unix systems, have only normal, single-forked files, there has to be a standard way to "include" the resource and info forks of a file when storing a MacOS file on a Unix filesystem. Actually, there are two ways, but files created by MacOS programs always are in the first format, AppleSingle. >before I could uncompress ... whatta pain! I tried "apropos file" and >"apropos such and such" looking for something that might be of help, like >"macbtounix(1)" or somesuch) Admittedly the right command here (fcnvt(1)) has a rather obscure heading ("convert a resource file to another format"), but they do have a program there to do it. What you are after is converting a file from AppleSingle format (where the resource&info forks of a Mac file are in a "header" on the file) to AppleDouble (where the resource and info forks are stored in a separate file and the data fork is left on its own like a normal file). To convert an AppleSingle file "foo" to an AppleDouble file "bar", you do fcnvt -i single -d foo bar This will create two files, "bar" (the data fork from file "foo" sans header, which is what you want), and "%bar" (the resource and info forks, which you can immediately rm). >So, I followed all the directions of the README file, and I >double-clicked the X11 shell script, which brought up Commando and I >just clicked OK, and I get this error message: > can't ioctl(): invalid argument Ah, so you were already in the MacOS environment when you tried to start X11? Don't do that. The deal there is that when the X server (XmacII) starts up it does some ioctls on /dev/console to do such things as map the frame buffer for your video card into its address space, activate mouse input, etc. Now, the MacOS emulator also has to do the same sort of things, so it also issues these ioctls. The reason your X server is failing is that the MacOS emulator has already "grabbed" the frame buffer and only one process is allowed to have it grabbed at a time. (Good thing, too; I suspect the results of having both graphics servers diddling the frame buffer would be rather uncool...) Log out and log back in under "Console Emulator" mode. In this mode, the console isn't doing any special graphics or the like, so X can start with no problems; just type "X11" at the shell prompt. -- Richard Todd rmtodd@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us rmtodd@servalan.uucp Motorola Skates On Intel's Head!
minich@d.cs.okstate.edu (Robert Minich) (10/07/90)
by rmtodd@servalan.uucp (Richard Todd): > The reason is that AFE is a MacOS program, and that "default header" is the > resource and info forks of a MacOS style file. I don't know if you're > familiar with the MacOS concept of file forks; basically, like Gaul, MacOS > files are always divided into 3 parts, an info fork (which records various > bits of status for benefit of the Finder, I believe), a resource fork > (read Inside Mac for all the sorts of things this part can contain, it's > really too complicated to go into here) and the data fork (just ordinary > sequential file like most systems have). Since A/UX, like all other Unix > systems, have only normal, single-forked files, there has to be a standard > way to "include" the resource and info forks of a file when storing a MacOS > file on a Unix filesystem. Actually, there are two ways, but files created > by MacOS programs always are in the first format, AppleSingle. This is not particularly helpful for the original problem, but I didn't want anyone thinking "Hmm, a MacOS file is a really screwed up thing." There are TWO (not three) forks. The "info fork" is actually info on the file as a whole, kept by the file system, like last modification date, name of the file, etc. (By Richard's explanation, one could call a UNIX file two-forked!) The data fork is just your typical linear byte stream. The resource is not a stream (as presented to a Mac app) but a set of tagged data chunks. These chunks typically are things like icons, text strings, window templates, code segments, sounds, etc. Each chunk has a type, an ID number, a name, and some flags. The type is a 32bit quantity typically viewed as four characters. ('CODE', 'MENU', 'snd ', ...) This way you can make a call like: myobj = GetNamedResource('DATA', "\pTranslation Table"); and not worry about the underlying structure of the resource file itself. (This is the job of the [gasp] Resource Manager.) One of the near things about the resource fork is the ability to edit user interface portions of a program without recompiling. You can also translate to you favorite vernacular! I'm not aware of exactly what the definition of AppleSingle format is but I suspect it is just "MacBinary", a format developed to facilitate the use of BBS's for exchanging Mac files. The idea is that you wrap both forks and some of the system info about the file in one chunk and present that to your host as a single file. When downloading, a Mac comm program will recognize the MacBinary format and unwrap the file on it's way to the disk. -- |_ /| | Robert Minich | |\'o.O' | Oklahoma State University| A fanatic is one who sticks to |=(___)= | minich@d.cs.okstate.edu | his guns -- whether they are | U | - Ackphtth | loaded or not.
jordan@Morgan.COM (Jordan Hayes) (10/07/90)
Richard Todd <rmtodd@servalan.uucp> writes:
The reason is that AFE is a MacOS program, and that "default
header" is the resource and info forks of a MacOS style file.
Oops. Forgot about the Info bit. od -c showed me the way; Thanks to
the others who also suggested fcnvt(1). dd bs=282 skip=1 also works
for you old-time UNIX hackers.
I also figured out how to start X11 from the Console Emulator -- after
trying to get the INIT for Rapport/Drive 2.4 to work and successfully
hanging the machine; this led me to find the Console Emulator so I
could remove the INIT. I couldn't get the high-bit characters to get
globbed by the sh that's on the launch partition, so I had to make a
new directory and mv * ../NewSysFolder and then "cd .. ; rm -rf
SystemFolder ; mv NewSystemFolder SystemFolder" ... the (TM) character
(252 or option-2) was getting stripped of the high-bit. Bummer.
Anyway, so now I can get X to launch, but the initial clients don't
come up. Which sucks because then you have to restart with dirty disks
and it takes forever to try something new. So, my only guesses are
that the shared libraries are somehow munged (but I tried running xterm
without X11 already running, and it eventually says "Couldn't open
Display" so that must mean that it was able to link successfully at
exec-time, so that must mean the shared libraries are ok, right?).
Sometimes I get a core file from xterm, sometimes not.
In better news, I was able to compile a bunch of X clients and port
over Motif 1.1, along with mwm with the shared libraries, so all has
not been frustrating. It's actually kinda fun ... ;-)
/jordanrmtodd@servalan.uucp (Richard Todd) (10/08/90)
minich@d.cs.okstate.edu (Robert Minich) writes: >by rmtodd@servalan.uucp (Richard Todd): > This is not particularly helpful for the original problem, but I didn't want >anyone thinking "Hmm, a MacOS file is a really screwed up thing." There are >TWO (not three) forks. The "info fork" is actually info on the file as a whole, >kept by the file system, like last modification date, name of the file, etc. >(By Richard's explanation, one could call a UNIX file two-forked!) Uh, doesn't it also contain the type/creator information? BTW, although I can't seem to find any trace of it in the Apple docs I have, I didn't invent the term "info fork" to refer to that little chunk of information; I seem to recall it being used in the CAP docs, and if I remember correctly, on AUFS (the Appleshare-on-Unix server), the "info fork" is indeed stored as a separate file, as is the resource fork. And yes, to those of use used to Unix files which only have a byte stream and a few bits of file modes, mod times, etc., MacOS files *are* really weird things :-). [good explanation of just what a resource fork is deleted.] > I'm not aware of exactly what the definition of AppleSingle format is but >I suspect it is just "MacBinary", a format developed to facilitate the use >of BBS's for exchanging Mac files. The idea is that you wrap both forks >and some of the system info about the file in one chunk and present that >to your host as a single file. When downloading, a Mac comm program will >recognize the MacBinary format and unwrap the file on it's way to the disk. Alas, no. Though an AppleSingle file does have all the system info, the resource fork, and the data fork all wrapped up in one file, the format is *not* the same as MacBinary. Fortunately, the "fcnvt" program does allow conversion to/from MacBinary.