crash@ckctpa.UUCP (Frank J. Edwards) (08/21/90)
The Subject/Summary lines say it all: what's the difference? I've noticed that most of the PD-type stuff are handlers, with the notable exception of the MSH: software. ----- Frank J. Edwards, | "Be different! Join the American 2677 Arjay Court | Non-Conformist Society TODAY!" Palm Harbor, FL 34684-4505 | -- the above message is a public service Phone: (813) 786-3675 | -- bulletin brought to you by this station
markv@kuhub.cc.ukans.edu (08/23/90)
In article <082090.120745@ckctpa.UUCP>, crash@ckctpa.UUCP (Frank J. Edwards) writes: > The Subject/Summary lines say it all: what's the difference? I've noticed > that most of the PD-type stuff are handlers, with the notable exception of > the MSH: software. Actually the difference is quite simple. A "device" is an Exec device, like trackdisk.device. It typically is the lowest level of driver above the hardware. In the case of a floppy, the trackdisk.device handles commands like read a block, write a block, etc. It has no knowledge of a file system etc. You have to do I/O to a device at the programming level, via Do/Begin/SendIO and messages. A "handler" is a DOS level driver, like DF0:. It understands the concept of a file, and can be opened, closed, checked for EOF, etc. It can be "block structured" (ie: understand a file system, like DF0:, RAD:, etc.), or stream oriented (like SER:, PAR:, AUX: etc). A handler can be accessed at the use level like "COPY FOO RAM:FOO" or "DIR >PRT:". Most but not all handlers are layered/paired with a device driver, like: DFX: -> trackdisk.device SER: -> serial.device PAR: -> parallel.device PRT: -> printer.device SPEAK: -> narrator.device But not all handlers have a device driver, mainly those that dont use any hardware other than memory like PIPE:, NULL:, RAM:, etc. And of course not all devices have handlers like timer.device and audio.device. At a the programmed level handlers and devices are different. Devices resemble libraries and take messages and function calls. I/O is done via messages with (somewhat) standardized commands like CMD_WRITE, CMD_READ, etc. But there is quite a bit of difference between devices. Devices are free to vary the interface and behavior of these commands quite a bit since they are only accessed at the programming levels. Handlers on the other hand respond to DOS packets (which are messages, but different than exec I/O messages) and dont look much like a library. They also must respond to the packets in a consistant and defined way since the packet actions are things like Lock()/Open()/Close()/Read()/Write() at file, etc. Hope this somewhat long explanation helps. Devices and handlers are different and perform different functions. "PD" handlers are generally more common since they tend to perform software only functions, or provide new interfaces to existing hardware. On the other hand devices tend to be to interface to specific hardware, and most Amiga hardware (standard or addon) has a device driver provided. Finally the example of MSH: is BOTH a device and a handler. The MSH: part is a handler that provides a AmigaDOS interface to a MS-DOS file system. In practice this would be all that is needed. MSH also provides a device driver to access the floppy hardware because of bugs in trackdisk.device, so messydisk.device is a device. > ----- > Frank J. Edwards, | "Be different! Join the American > 2677 Arjay Court | Non-Conformist Society TODAY!" > Palm Harbor, FL 34684-4505 | -- the above message is a public service > Phone: (813) 786-3675 | -- bulletin brought to you by this station -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Gooderum Only... \ Good Cheer !!! Academic Computing Services /// \___________________________ University of Kansas /// /| __ _ Bix: markgood \\\ /// /__| |\/| | | _ /_\ makes it Bitnet: MARKV@UKANVAX \/\/ / | | | | |__| / \ possible... Internet: markv@kuhub.cc.ukans.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
peter@sugar.hackercorp.com (Peter da Silva) (08/24/90)
In article <25339.26d3ba57@kuhub.cc.ukans.edu> markv@kuhub.cc.ukans.edu writes: > Finally the example of MSH: is BOTH a device and a handler. The MSH: > part is a handler that provides a AmigaDOS interface to a MS-DOS file > system. In practice this would be all that is needed. MSH also > provides a device driver to access the floppy hardware because of bugs > in trackdisk.device, so messydisk.device is a device. Well, if you call "using a proprietary low-level format to pack 880K instead of 720K on a disk" a "bug", yes. I don't know about MSH:, but CrossDOS has an mfm.device for the same reason... but you can put an AmigaDOS filesystem on an mfm.device disk, or an MS-DOS file system on a trackdisk.device disk. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
janhen@sci.kun.nl (Jan Hendrikx) (08/24/90)
In article <25339.26d3ba57@kuhub.cc.ukans.edu> markv@kuhub.cc.ukans.edu writes: >Finally the example of MSH: is BOTH a device and a handler. The MSH: >part is a handler that provides a AmigaDOS interface to a MS-DOS file >system. In practice this would be all that is needed. MSH also >provides a device driver to access the floppy hardware because of bugs >in trackdisk.device, so messydisk.device is a device. And because the IBM disk format is different from the Amiga's. The messydisk.device CMD_READ and CMD_WRITE (et al) commands encode the data the user (or usually, the file system handler (MSH:)) wants to read or write different from the way the trackdisk.device does. So the messydisk.device is used as a kind of front-end for the trackdisk.device: it accepts all the same commands that trackdisk does, and actually performs some of them itself, while it delegates others to trackdisk. This way, a maximum hardware compatibility is maintained. (Actually, it does some fiddling with the hardware itself, but only because the 1.3 trackdisk.device does not allow some operations that I really need. I expect the 2.0 trackdisk.device has been improved in this respect.) >Mark Gooderum Only... \ Good Cheer !!! -Olaf Seibert.
p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) (08/25/90)
In article <6436@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >Well, if you call "using a proprietary low-level format to pack 880K instead >of 720K on a disk" a "bug", yes. No, you could access the hardware with trackdisk.device to use the standard 720K format. But due to a bug in trackdisk.device these functions (TD_RAWREAD,TD_RAWWRITE) won't work realiable unless the Amiga has two drives. -- Michael van Elst UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve Internet: p554mve@mpirbn.mpifr-bonn.mpg.de "A potential Snark may lurk in every tree."
walker@unx.sas.com (Doug Walker) (08/28/90)
In article <082090.120745@ckctpa.UUCP> crash@ckctpa.UUCP (Frank J. Edwards) writes: >The Subject/Summary lines say it all: what's the difference? I've noticed >that most of the PD-type stuff are handlers, with the notable exception of >the MSH: software. Devices are things like serial.device, parallel.device, etc. Handlers are things like SER: and PAR:. Sometimes they are also referred to as devices, but in my opinion that causes unnecessary confusion. File systems are a superset of handlers - DF0:, RAM:, etc. MSH: is a file system, I believe. ***** NOTE NEW BBS NUMBER (AGAIN): =*|_o_o|\\=====Doug Walker, Software Distiller====== BBS: (919)460-7430 = *|. o.| || | o |// For all you do, this bug's for you! ====== usenet: ...mcnc!rti!sas!walker plink: dwalker bix: djwalker
jms@tardis.Tymnet.COM (Joe Smith) (09/04/90)
>In article <25339.26d3ba57@kuhub.cc.ukans.edu> markv@kuhub.cc.ukans.edu writes: :: MHS provides a device driver to access the floppy hardware because of bugs :: in trackdisk.device, so messydisk.device is a device. In article <6436@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >Well, if you call "using a proprietary low-level format to pack 880K instead >of 720K on a disk" a "bug", yes. But Peter, there are bugs in the trackdisk.device, real ones. Including the one acknowleged by Commodore that was caused by a typo in the source code. The 880K feature is not was markv is talking about. -- Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or jms@gemini.tymnet.com BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-C41 | BIX: smithjoe | 12 PDP-10s still running! "POPJ P," San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga speaks for me."