Path: utzoo!mnetor!uunet!nuchat!peter From: peter@nuchat.UUCP (Peter da Silva) Newsgroups: comp.sys.amiga Subject: Re: Multiple serial ports Message-ID: <590@nuchat.UUCP> Date: 22 Jan 88 11:27:17 GMT References: <2245@cup.portal.com> <22374@ucbvax.BERKELEY.EDU> <217@imagine.PAWL.RPI.EDU> Organization: Public Access - Houston, Tx Lines: 43 In article <217@imagine.PAWL.RPI.EDU>, jesup@pawl23.pawl.rpi.edu (Randell E. Jesup) writes: > In article <530@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: > >Also... even if the existing handler isn't guaranteed to work for ALL > >devices, is there some way of making it work for the serial.device and > >to get people writing new devices to work in concert. > What existing handler are you taking about????? The one returned by DeviceProc("SER:");. > Acutally, my latest proposals for serial port expansion include a new handler, > XSER:. This would tend to unify the device-level name-mapping for serial > ports and the dos-level file-naming. You would open XSER:modem, for example, > and the XSER: device would have the name-mapper get it a free serial port > with a modem attached. This would even allow things like list to tell > you which names exist, and allow assign to work. I don't see the advantage of XSER:modem over Modem:. With Modem: you can assign stuff, and even get a list of devices using assign with no args. It's a bit of a pain to get the devices from a program, but you can do it... my programs all look through the device list. To make it totally clean, you need a generic device-name device like my old suggestion of "dev:". But that's totally optional. 1> dir DEV: Workbench1.2 Auxilary VDISK RAM Disk AUX PIPE VD0 DF1 DF0 PRT PAR SER RAW CON RAM 1> cd DEV:VDISK 1> cd dev:prt Can't find dev:prt 1> cd DEV:VDISK -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.