CRAA055@VAXB.CC.KCL.AC.UK (08/27/87)
Dear friends,
There has been many a message posted to this list over recent months about
problems of "Software Package version X" not working with "Operating System
rev Y". I ask myself- why is so much work generated by this? Can we find a
solution to it?
I believe a solution is difficult though not impossible. It imposes a certain
discipline on both writers of user programs and on writers of operating system
software.
User Programs
a. Always design programs first! particularly, design data structures with
a view to future change by i. Trying to incorporate all items needed
now and anticipated for the future, and ii extending data structures
by additions at the end.
b. Always use manufacturers standard interfaces and system services. Dont
try to 'gain an extra microsecond' by bypassing them. In that way, you
are insulated from internal data structure changes.
In other words - keep the user interface the same. It then doesnt matter how
much you mangle the internal implementation from release to release.
c. If you MUST introduce a new format, at least recognize the old one for
the next couple of releases, to give users who build on your work time
to convert. You thus avoid programs suddenly falling over after an
upgrade! Remember of course to document when the old format will no
longer be supported.
d. Write code defensively (a la Kernighan and Plauger) so that i. if
something unexpected happens, you die gracefully with a SUITABLE error
message, and ii. NEVER assume anything! If you have a choice of two
things in a program and a test shows its not one of them, dont go and
assume its automatically the other one. Someday, when a third choice
is added (eg a new VMS device type code), your code will fail!! iii.
Under no circumstances, allow high-access level code to poke the system
when you are not entirely sure of compatibility. Any such code really
ought to be sure it can cope with the current level of operating
system; if it cant it should not attempt any work and simply tidy up
and abort. Im really saying, dont use old, quickly-hacked code in a
environment intended to be robust, such as VMS device drivers!
Operating System Writers
Of course, user programs are often not at fault, VMS software writers have
been known to introduce incompatibilities (!). What can they do about it?
Obviously, they too should follow ALL of the above rules, even more strictly
than the users. It is crucial that a new release of VMS does not fall over or
fail to work correctly because of two bits of software that dont quite match
up. Remember too thats its very frustrating for the user to put up a new VMS
and find he cant use his X25 network because the new 'compatible' tape has not
yet arrived (he may not find out until too late..). So:-
a. Documentation for a new release, should FULLY cover all areas likely
to crack because of data structure or interface changes.
b. New releases should ALWAYS be upwards compatible with AT LEAST 1 prior
release of ALL layered products. Eg a NEW VMS should still work with
the last version of PSI, even if the new PSI is far superior.
Final Points
Although I'm very fond of Public Domain Software as a way to get good cheap
and often excellent software, one should always exercise a natural caution
with such things. They are often very good in the original environment for
which they were written but, when ported to another system with a different
environment, fall down miserably - For example, a quickly hacked piece of code
to look at terminal parameters might only recognize directly connected ones
and go haywire on LTA or NVA terminals. Can you afford the worry this will
cause? Can you afford the time to enhance it? can you get the original
provider to make it work on your system? In many cases, i suspect not.
Another reason for exercising extreme caution with PDS software is, of course,
the Trojan Horse syndrome; code that appears to work fine but in fact is
sneakily blowing your system away behind the scenes! Always insist on full
source of any PD software you get and refuse 'Binary only' stuff. This applies
equally to both respectable and unknown suppliers. Strictly, it should also
apply to commercially available stuff and, If I had my way, I would entirely
boycott software that didnt let me at the source code! (Thats a personal gripe
against commercial software writers, sorry! Its part of a larger one that i
may make public one day!).
To wind up, a touching plea to all software writers out there, be they
commercial, academic, or just plain amateurs - Please dont put copy protection
or time bombs in your programs - it suggests an implict mistrust in your
purchaser and will eventually cause trouble for someone!
Thanks for listening - I hope this prompts at least some of you to do the
right thing and make VMS software what it always was and will continue to be -
the best in the world!
Regards,
Andy Harper,
Kings College London UK
+---------------------------------------------------------------------------+
I Computing Centre, Kings College, Strand, London, UK I
I Tel: +44 (0)1 836 5454 I
+-------------------------------------------+-------------------------------+
I JANET: A.Harper @ UK.AC.KCL.CC.VAXB I ARPA: A.Harper%KCL.CC.VAXB I
I I @ ucl-cs.arpa I
I EARN: A.Harper @ VAXB.CC.KCL.AC.UK I ARPA: A.Harper I
I or A.Harper%VAXB.CC.KCL.AC.UK @ AC.UK I @ VAXB.CC.KCL.AC.UK I
I I I
I UUCP: ...ukc!uk.ac.kcl.cc.vaxb!A.Harper I ARPA: A.Harper%KCL.CC.VAXB I
I I @ CS.UCL.AC.UK I
I EAN: A.Harper @ VAXB.CC.KCL.AC.UK I I
+-------------------------------------------+-------------------------------+