Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!spool.mu.edu!uunet!mcsun!unido!horga!veeble!fiction!Daniel_Roedding From: Daniel_Roedding@fiction.ms.sub.org Newsgroups: comp.sys.atari.st Subject: forcing media change Message-ID: <931630@fiction> Date: 19 Feb 91 20:33:44 GMT Lines: 71 X-Attributes: type 2, from 100, acclv 0, expires fischer-michael@cs.yale.edu (Michael Fischer) writes: > In article <208348@fiction> Daniel_Roedding@fiction.ms.sub.org writes: > >1) hdv_bpb and hdv_rw are patched > >2) hdv_mediach is changed to a routine that always returns "2" > >3) The DeskTop opens a file "Drv:\\X" > >4) This call *must* use the Getbpb()-function, otherwise the redraw > > routine is teminated! > >5) The vectors are restored and the new directory is shown > You have uncovered the approved way of forcing Gemdos to recognize a > media change. I knew what the code does, but I simply don't like it... :-) > The way in which it is done may seem like a dirty hack to you, but > think of what the possibilities are: (Explaining pro's and con's of this method and the other way of intro- ducing a new GEMDOS call) 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? > I don't know what you mean about writing device drivers "on GEMDOS > level". Device drivers are the lower-level things that Gemdos calls > in order to move data to and from a device. (explanations about device drivers follow here) 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... > I think your complaint is simply that Gemdos operates a little > differently than you had thought. Yes ... a little bit ... it's really astonishing that such little problems need weeks of debugging while greater tasks like Pexec() and the pool manager are done in a week-end or so. (about the logic of calling Getbpb() during the Fopen()-call when having forced the media change state to 2) > Doesn't seem that unreasonable, when you > think about it. 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. > I don't think this is a reason to flame. 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. Daniel