duncan@csd4.milw.wisc.edu (Shan D Duncan) (02/07/89)
[might as well get all of my postings out at once!]
I followed the discussion of terminal programs with interest.
From that discussion specifically with Atalk III it seems clear that "ya
can't please all the people..." AND "they get bigger and bigger and bigger"
(software not people necessarily)
Most of the time all I need is a way to communicate with our unix
system and perhaps download\upload files from time to time.
Given the state of software to this date how difficult would it be to
design a "modular" type of terminal software? Forgive me for the use
of modular since it can mean different things to different people perhaps
what I really I mean by this term is a customizable terminal program.
Upon bootup a menu is presented that goes through all of the possible
options available (i.e. (1) startup options usually handled by scripts
(number(s) to call, strings to send, delays), (2) transfer protocols
(kermit, zmodem, ymodem whatever), (3) terminal options (vt100, vt220,
addsviewpoint again whatever) (4) and the list goes on and on.
Once the options are selected then a custom version containing only the
code necessary and perhaps only the FEW options YOU want is *somehow*
produced to be run. Then if any new options are provided and if you need
or change your mind them make up a new version of the program program.
As long as you do not wish to change anything then you should not need to
go through the setup procedure again.
Of course I am being somewhat naive. But there should be a way
to have a program that only executes the options you want without having
to carry around all of the options everyone else wants but you could care
less about! I know. I know the most obvious answer to this is
*****"write your own!"***** :-)
I would guess that source code plus a "small" compiler necessary to "make"
only that program might work but would anyone go to the trouble
to make life easier for the user if it meant more trouble for the publisher
:) OR in the long run would it?
How about Arexx gluing together all the necessary parts (i.e. terminal
emulator, serial port, scripts, file transfer protocols, with only the
code actually being used in memory)?
Perhaps OOPS?
If I speak in ignorance - educate!
I am looking forward to all of the education these musings might generate!
:-)
SIGH back to thesis typing.
shan duncan@csd4.milw.wisc.edudougp@sbphy.ucsb.edu (02/08/89)
In article <802@csd4.milw.wisc.edu>, duncan@csd4.milw.wisc.edu (Shan D Duncan) writes... >Given the state of software to this date how difficult would it be to >design a "modular" type of terminal software? Forgive me for the use This would be an ideal use for an overlay linker in which only certain parts of the code is loaded at any time. This way there could be overlays for the verious terminal emulators, and overlays for the verious transfer protocalls. This in no way reduces the size of the program on disk, but it greatly reduces the memory used when the program is run. The biggest advantage is that no customizing would be necessary, just select the terminal emulator you want and the code is automaticly loaded. Unfortunatly, I have not yet seen a C compiler which claims to have this feature working. I do remember seeing documentation about this feature in the Manx manual, but that was for a different computer. I have however seen commands in the verious Amiga reference manuals which would allow this to be done, but it would not be transparant like an overlay linker. Douglas Peale
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (02/08/89)
In article <1188@hub.ucsb.edu> dougp@sbphy.ucsb.edu writes: [...] >This would be an ideal use for an overlay linker in which only certain >parts of the code is loaded at any time. [...] >Unfortunatly, I have not yet seen a C compiler which claims to have >this feature working. Lattice certainly claims to have full overlay support in blink. I haven't had occasion to try it, but it seems to be thoroughly documented in the 5.0 manuals. -Dan Riley (riley@tcgould.tn.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell U.
rlcarr@athena.mit.edu (Rich Carreiro) (02/09/89)
In article <1188@hub.ucsb.edu> dougp@sbphy.ucsb.edu writes:
]This would be an ideal use for an overlay linker in which only certain
]parts of the code is loaded at any time. This way there could be
]overlays for the verious terminal emulators, and overlays for the
]verious transfer protocalls. This in no way reduces the size of the
]program on disk, but it greatly reduces the memory used when the program
]is run. The biggest advantage is that no customizing would be necessary,
]just select the terminal emulator you want and the code is automaticly
]loaded.
]Unfortunatly, I have not yet seen a C compiler which claims to have
]this feature working. I do remember seeing documentation about
]this feature in the Manx manual, but that was for a different computer.
]I have however seen commands in the verious Amiga reference manuals
]which would allow this to be done, but it would not be transparant
]like an overlay linker.
This sounds like what Lattice C (4.0 and 5.0) offers with BLINK. They
talk about overlays and say that you can automagically have the program
load and unload code as it needs it, transparent to the user (and to the
developer, except for making an overlay map to feed to the linker so
it knows what modules need what other modules.)
ARPA: rlcarr@athena.mit.edu
UUCP: {wherever}!mit-eddie!mit-athena!rlcarr
BITNET: rlcarr%athena.mit.edu@MITVMA.mit.edu
*******************************************************************************
* Rich Carreiro "Back off man, I'm a scientist." *
* rlcarr@athena.mit.edu - Dr. Peter Venkman *
*******************************************************************************peter@sugar.uu.net (Peter da Silva) (02/09/89)
In article <1188@hub.ucsb.edu>, dougp@sbphy.ucsb.edu writes: > In article <802@csd4.milw.wisc.edu>, duncan@csd4.milw.wisc.edu (Shan D Duncan) writes... > >Given the state of software to this date how difficult would it be to > >design a "modular" type of terminal software? Forgive me for the use > This would be an ideal use for an overlay linker in which only certain > parts of the code is loaded at any time. That's very Turbo-Pascal of you. On the Amiga the way to do this is just use multiple tasks. Pass messages from the mainline to the protocol program. Look at MIDI.DEVICE for inspiration. -- Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ...texbell!sugar!peter, or peter@sugar.uu.net 'U`
pmy@vivaldi.acc.virginia.edu (Pete Yadlowsky) (02/10/89)
In article <3406@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >On the Amiga the way to do this is just use multiple tasks. Pass messages >from the mainline to the protocol program. Look at MIDI.DEVICE for >inspiration. midi.device? "what is the sound of one ear pricking up?" Peter M. Yadlowsky Academic Computing Center University of Virginia pmy@Virginia.EDU
peter@sugar.uu.net (Peter da Silva) (02/11/89)
In article <1086@hudson.acc.virginia.edu>, pmy@vivaldi.acc.virginia.edu (Pete Yadlowsky) writes: > In article <3406@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: > >On the Amiga the way to do this is just use multiple tasks. Pass messages > >from the mainline to the protocol program. Look at MIDI.DEVICE for > >inspiration. > midi.device? Actually, Peter meant midi.library... but he typoed it. Peter is a real bozo about that. But, don't worry. Bill Barton's midi.library is truly awesome. It's basically the kernel of a freely-redistributable soundscape workalike. It was in comp.binaries.amiga a while ago, I think. If not, it should have been. > "what is the sound of one ear pricking up?" Five pounds of flax. -- Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ...texbell!sugar!peter, or peter@sugar.uu.net 'U`