Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!unido!fauern!faui43.informatik.uni-erlangen.de!csbrod From: csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) Newsgroups: comp.sys.atari.st Subject: Re: forcing media change Message-ID: <1991Feb21.151433.23353@informatik.uni-erlangen.de> Date: 21 Feb 91 15:14:33 GMT References: <931630@fiction> Organization: CSD., University of Erlangen, Germany Lines: 42 Daniel_Roedding@fiction.ms.sub.org writes: >Well, I *think* there's a method to set the media change state via a >Rwabs() call with strange parameters. At the moment I'm not quite sure >whether this is just a hack in some hard disk drivers or it's a function >supported by the standard bios routines. Does someone know more 'bout it? This method only works reliably with drive A and B, and it is undocumented. The method you discovered in Desktop's code is documented and works on any drive. It's tricky, but not dirty. >Yes, I know that. But there are some things that cannot be done on >bios level. For example, if you want to set up a central file server for >serveral machines, you *must* link your own routines into the GEMDOS trap. >And if you write these routines you're quite astonished when everything >works except the redraw routine on the desktop... The problem was >that the Desktop waited for a call of Getbpb() during the evaluation >of the Fopen(":\\x",0) call. And this confused us a little bit... Ah, now your problem clears up! >Yes ... but I don't think that an application should *expect* this be- >haviour. Furthermore, we didn't expect such reactions from the DeskTop >since all the other functions of this built-in application are on the >gemdos level or higher. There is no call of bios in it, so I think this >is stylistically not very nice. If you're reading your developper's documentation, this should be no unexpected feature to you, should it? >I was just very surprised and a little bit angry, because these little >"gags" make the implementation of file-system-oriented device quite >problematic. We were happy enough when we completed our new GEMDOS trap >handler and hoped that the largest problems were solved. Tell us something about your GEMDOS handler, now we're into it. ---------------------------------------------------------------------- Claus Brod, Am Felsenkeller 2, Things. Take. Time. D-8772 Marktheidenfeld, West Germany (Piet Hein) csbrod@medusa.informatik.uni-erlangen.de ----------------------------------------------------------------------