Daniel_Roedding@fiction.ms.sub.org (02/20/91)
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 <Esc> redraw routine on the desktop... The problem was that the Desktop waited for a call of Getbpb() during the evaluation of the Fopen("<drv>:\\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
fischer-michael@cs.yale.edu (Michael Fischer) (02/21/91)
In article <931630@fiction> 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? There is in the floppy driver, but I believe it is "undocumented", so you shouldn't use it. The official way of forcing media change is the one you uncovered. >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 concede the point. Gemdos ought to provide functions to deal explicitly with media change. -- ================================================== | Michael Fischer <fischer-michael@cs.yale.edu> | ==================================================
csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) (02/21/91)
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 <Esc> redraw routine on the desktop... The problem was >that the Desktop waited for a call of Getbpb() during the evaluation >of the Fopen("<drv>:\\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 ----------------------------------------------------------------------