Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!mordor!styx!ames!ucbcad!ucbvax!decvax!decwrl!sun!imagen!atari!dyer
From: dyer@atari.UUcp (Landon Dyer)
Newsgroups: comp.sys.atari.st
Subject: Re: Two questions about TOS
Message-ID: <510@atari.UUcp>
Date: Sat, 10-Jan-87 17:32:42 EST
Article-I.D.: atari.510
Posted: Sat Jan 10 17:32:42 1987
Date-Received: Sun, 11-Jan-87 09:41:23 EST
References: <1973@batcomputer.tn.cornell.edu>
Organization: Atari Corp., Sunnyvale CA
Lines: 61

> The question: Since GEM is supposed to call GEMDOS, and not the other
> way around (says my brand new Balma and Fitler book), where do those
> dialog boxes come from?  Are they due to some initiative of mCS?  It
> seems paradoxical that from the desktop (a GEM environment) they are
> absent (in this case) while in mCS (a TOS text-only environment) they
> appear.  How can I make them appear, or in any other way get automatic
> disk-swap user-directives?

The disk-swap request comes through the critical error vector, as an
EOTHER (-17) error.  An extra word argument on the stack is the number
of the disk (0 or 1) the user should insert.  Thus:
	-------
	#define EOTHER -17
	my_critical_error_handler(errno, arg)
	    WORD errno;
	    WORD arg;
	{
	    if (errno == EOTHER)
	    {
		printf("Hey!  Stuff in disk %c and hit a key!",
			'A' + arg);
		getchar();
	    }
	    else if (errno == another_error_we_want_to_handle)
	    {
		.. etc...
	    }
	    else follow_the_old_critical_error_handler_vector;
	}
	-------

(If you try to compile that pseudo-code, you are in trouble.)  So GEM
intercepts the critical error handler (as indeed, you can do) and starts
an appropriate dialouge.  EOTHER isn't really an error condition, and
it's return value doesn't matter.


> The other question:  A program uses Rwabs() to copy a bunch of sectors
> off a floppy to the 'eternal' RAMdisk.  These sectors include the FATs,
> root directory, some files, and some subdirectories.  Results:  Everything
> seems fine at root level, files usable.  BUT: trying to open a subdirectory
> (from the desktop) causes the usual animation but leaves me in the
> root.  No error messages.  Trying the same in micro-C-Shell yields
> a "not found" error, even though the names of the subdir's appear in "ls".
> Snooping around with a debugger failed to show anything wrong with the
> RAMdisk data:  The subdirectory files are where the root says they are,
> and the files in the subdir's are both listed there and physically
> present in the RAMdisk area where it says they are.  What's going on?

I'll bet you modified the RAMdisk without letting the DOS know about a
media change.  If the media changes, the driver's Rwabs() handler must
return E_CHNG (-14) until a Getbpb() call is performed.

-- 

-Landon Dyer, Atari Corp.		        {sun,lll-lcc,imagen}!atari!dyer

/-----------------------------------------------\
| The views represented here do not necessarily | "If Business is War, then
| reflect those of Atari Corp., or even my own. |  I'm a Prisoner of Business!"
\-----------------------------------------------/