30.Mär.1999
C.S. Bridge Deady per eMail
|
KOSH summary Nr. 13
From: "Colin-Stewart Bridge Deady" <csbdeady@mythicz.u-net.com>
Date: 29 Mar 99 23:33:47 +0000
Subject: Summary 13
To: kosh-general@kosh.net
This is a MIME encoded multipart message. The fact that you are reading
this means you don't have a MIME capable mail program. You might still
be able to read part of the mail's content, but some of it may require
a MIME capable mail reader to decode. Following are some URLs where
you can find MIME-capable mail programs for common platforms:
Amiga............: MicroDot-II http://www.vapor.com/
Unix.............: Metamail ftp://ftp.bellcore.com/nsb/
Windows/Macintosh: Eudora http://www.qualcomm.com/
General info about MIME can be found at:
http://www.cis.ohio-state.edu/hypertext/faq/usenet/mail/mime-faq/top.html
--=_=8<==MD237000DDB-2E5C69D0==8<=_=
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi all
Summary 13 enclosed. Many thanks to Robert Wise and John Chandler who
helped out with writing it.
It's a long one - a very long one - and I decided to keep John's
excellent contribution in a separate file to reduce the size of the
main file - although admittedly this is a larger_than_average summary.
If we get this many contributions to the general mailing list in the
future I will need help summarising the ML on a regular basis -
alternatively -please- take a lot of topics to the appropriate other
lists as I can't summarise them for lack of time.
Regards
-Bridge
--
http://www.mythicz.u-net.com | csbdeady@mythicz.u-net.com
ICQ:29145054 | DT-MUD:sunsite.auc.dk:4242
Amigan | Vegan | KOSHan Go for a swim in the object sea,
http://www.kosh.net | Storm of the Eye GUI-PBEM http://www.2bp.com/
--=_=8<==MD237000DDB-2E5C69D0==8<=_=
Content-Type: text/plain; charset=us-ascii; name="ksum13.txt"
Content-Transfer-Encoding: plain (7/8 bit)
Content-Disposition: attachment; filename="ksum13.txt"
X-MD2-FilePath: Work:mythicz/ksum13.txt
KOSH [Kommunity Orientated Software Hardware]
Weekly Summary
Week Commencing: 20th March 1999
Number: 013
Mailing List: kosh-general
In the mailing list this week, the following items were discussed. Please do
not email the scribe regarding any of these topics, it is not his job to answer
these questions but merely to report the topics of conversation. If you have
any queries about this summary, please email ben@kosh.net, stating the Summary
Number, and Mailing List Name, and he will try to answer your queries.
The Summary this week was completed jointly by myself, Bridge Deady, Robert
Wise and John Chandler. I have incorporated Robert's sections into the main
summary but I have enclosed John's separately to allow for different
pagination.
a)
Subject: Keyboard mapping
Summary of debate: An idea posted is that it would be useful if you could swap
keys of the keyboard in software. For example, if you wanted
to replace "x" with "y" you would just run the appropriate
mini application, specify the keys to swap and choose OK.
This would allow people who would like keys to be mapped
slightly differently to be able to accomplish this.
It was further suggested that this could later be
implemented in hardware by allowing physical hotswapping of
keys on a keyboard. Does USB have the bandwidth and features
to enable this?
Each key could have the character it represents embedded in
it, interfacing through a quick-connect/disconnect plug. An
advantage of this is that if a key stopped working you could
just buy a new key rather than a new keyboard. If you needed
more space for a larger alphabet you could just clip on a
new section to the board and populate it with your chosen
keys. Perhaps this interfacing could be achieved with PIC
chips cut down to size?
It was pointed out that this is all part of a larger picture
about the ability to input into a computer in a native
language. To this end it would be nice to get involvement
from people in Asia in KOSH. The system should support many
languages as standard (presumably via language objects).
Keyboards could be handled via a keyboard driver object. The
actual keyboard can be anything the user wants to use. A
stream of input messages come from the keyboard which could
be unicode characters or special events (eg: Help key)/ If
its a smart keyboard (like USB) it will automatically start
the correct driver.
Suggested that a lot of what has been said could be
accomplished by a configurable touch screen although it
would lack tactile feedback. Tactile feedback could possibly
be handled via a gell that becomes progressively harder as
an electric field is applied to it - at the points where it
is pressed.
Different keyboard input objects based on Unicode could
handle any input required. Alternatively have an intermediate
object between the keyboard input object and the input
handler object, which may translate.
The Dworak keyboard that maps the most used keys closest to
where one has ones fingers was mentioned.
Could each key have a LED like the one on the Amiga Caps
Lock key?
b)
Subject: Cooling KOSH (was Waterproofing KOSH)
Summary of debate: Perhaps by using conductive fluid pipes in the computer one
could cool it.
Another idea would be to have slots on top of the machine
(not the side where they currently are), but this would take
us back to the first problem - coffee spills and dust.
Therefore the slits could be at the top edges of the case
facing out of either side with a slight V-shape in the
inside top of the case directing hot air that rises to these
outlets. Any foreign bodies entering these outlets could be
made to fall down channels in the inner side of the machine
and hopefully not enter the fragile innards.
c)
Subject: Chunky pixel and bit plane graphics modes
Summary of debate: When we get around to designing KOSH graphics cards can we
try to use the advantages of both systems mentioned above?
By connecting the vsync signal from the graphics card to a
hardware interrupt pin on the CPU we can make real-time
window dragging look smooth and fluid.
KOSH should use the inbuilt interrupt feature of many
graphics cards to accomplish this.
KOSH graphics cards could contain some form of copper, maybe
a more advanced version that allows 2D operation (which
would speed up the GUI).
Further questions raised: do we want a graphics card at all
when instead we could use a modular design, keeping the RAM,
DAC and custom chips as separate, scalable and optional
modules?
Do we want shared memory for graphics, data and sound like
the Amiga's chip RAM?
d)
Subject: Memory protection
Summary of debate: Would it be possible with today's memory management units to
protect private members of a single object?
Dave Haynie has previously suggested a system using flexible
context objects, which can live in at least four different
protection levels (app, global, object, and system).
Only if you wanted to devote a large chunk of memory to each
such object. An MMU, for good reason, works in page-sized
increments.
Could there be a standard way to lock an object in memory
for reading and writing to prevent another task or person
from changing the object that is curently being used?
Only if you wanted to devote a large chunk of memory to each
such object. An MMU works in page-sized increments.
However from the Amiga we can see that a system can be
stable without protection - it also shows where protection
is needed.
Only write-protection is needed to avoid having
applications trash each other's memory. However security
reasons would mean that you may not want someone to scan all
your documents and therefore read-protection is also needed.
What mechanism might exist to identify methods that a given
object understands? How would it be possible to tell that a
particular subclass of text object manipulator understands
font styles or not, or some similar thing? Not necessarily
determining whether it responds to a specific method, but
whether it has an equivalent method.
To physically protect objects from being altered by
malfunctioning classes each object could have its own memory
space. Knowing when to protect the object is as important as
actually protecting it.
e)
Subject: Book recommendations
Summary of debate: Booch's book about Object Oriented Analysis and Design,
(Grady Booch. 0-8053-5340-2) comes recommended.
Also recommended is Software Inspection by Gilb and
Graham (0-201-19246-2, 0-201-63181-4), which gives good
ideas about how to increase the quality of software.
Scribe's note: Books are summarised on the kosh booklist
website - see a previous summary for the URL.
f)
Subject: KOSH training
Summary of debate: Many people involved with KOSH may not that well versed in
the technology behind the proposals. Mario Saitti is willing
to help set up a system for KOSH to teach structured
programming methodology/Data Structures/SSADM/computational
to anyone interested.
Suggested that we should be thinking about teaching OO, not
structured programming. Structure programming doesn't really
go well with the object sea.
OO Design could also be a very valuable skill for all KOSH
members.
Could such training "courses" actually be devised?
Supplementing such training with books was recommended.
g)
Subject: Against hosted
Summary of debate: One scribe-e pointed out that they are against running hosted
versions of KOSH. Their reasoning is that there may be little
point in redefining computing to use modern methodology if we
put it atop of a base that is at least 20 years old. While
ensuring market compatibility is the compromise worth it?
h)
Subject: Why there should be an Object Sea
Summary of debate: One scribe-e pointed out they currently view the object sea
as just a set of descriptors and protocols made up of sub
classes which determine how the system will handle the
object.
The advantages of this approach include the fact that it
promotes really serious, heavy use of code reuse and
polymorphism. Together, these can lead to both better
performance and far more reliable code. It is then easy to
add behaviours to the system.
why is there a need for a frozen form?
A datatype still needs to open the JPEG file, close it later,
perhaps committing or forgetting edits at the same point.
i)
Subject: COMAL, REBOL, JIT & Basic KOSH
Summary of debate: Should KOSH come with a BASIC-like interpreted language?
A COMAL interpreter included with KOSH as standard was also
suggested. COMAL is very widely supported.
How about REBOL which is a messaging based interpretive
language currently going towards version 2.0 and developed
by Carl Sassenrath? See: http://www.rebol.com <=Some like
REBOL, others are less impressed.
Why bother with an interpreted language when with KOSH we
are thinking of the possibility of programs compiling at
either install or run time from a slim binary type of
format? How about a JIT compiled language as we would not
lose significantly in time that way?
Suggested is making a computer language that is more like
the equations that scientists and people in general have
been using all their life. Pointed out that we may not want
to create a new language. Mentioned that instead of a
compiled language one that halts and hilighted errors would
be good.
The standard compiler shipped with KOSH could be simple with
a more advanced highly optimised version available for
purchase.
In regard to OO rather than structured programming, see
Farenheit at http://www.sgi.com for some of the newest
declarative systems.
j)
Subject: CORBA links
Summary of debate: See:
http://www.corba.org ? Try searching for papers and AOOC.
http://www.cetus-links.org/ have some links that might be of
interest.
Also see: http://www.omg.org (or something similar) - the
parent organization is something like "Open Management
Group".
k)
Subject: Structured design methodology
Summary of debate: Suggested that we could all write a few lines on structured
design methodology and someone could summarize it for the
glossary.
l)
Subject: Accessing KOSH (continued)
Summary of debate: A completely aural interface for the system could be very
useful for those who are completely blind.
However this could have disadvantages such as if the
interface was left turned on next to a radio. Perhaps
preface commands to the computer with another word (aka Star
Trek).
Any audio control should be able to understand conceptual
terms - most likely via some AI.
A true 2-colour screen could be useful for someone who is
colourblind.
Avoiding colour clash (a form of colour blindness) when
certain colours are placed on other colours should be
paramount in KOSH.
Braille keyboards and a Braille screen were further
suggested.
Circular radar like pulses going to a mouse pointer when you
press a shortcut key could be used to help keep track of the
pointer.
The Amiga and Mac ability to flash the screen when there is
an error as well as provide a beep should be included.
We should also look at alternatives to keyboard + mouse
including joystick control amongst many possibilities.
Mario Saitti has suggested that issues like these would need
an entire working group of their own.
m)
Subject: DLL's
Summary of debate: Was mentioned by a number of people that we should stay away
from a system similar to Windows DLL files as these can
create severe problems when things go wrong.
n)
Subject: Garbage collection
Summary of debate: Garbage collection from LISP could be used. Object Seas
based on their existence are suggested as the way to go.
o)
Subject: Localised languages
Summary of debate: Locale on AmigaOS allowed easy adaptation to many languages.
By incorporating this in some form into KOSH the system as a
whole becomes even more inclusive.
To fully internationalise KOSH it was suggested that a
mixture of languages should be useable at once. An example
given was Swedish in a wordprocessor but something else in
the other applications.
KOSH from the ground up should be designed to be flexible
and powerful in respect to language implementation including
Kanji which appears to be very complex.
p)
Subject: Punch cards
Summary of debate: KOSH should support punch cards as there is a lot of data
stored on them which is currently difficult to access.
It was pointed out that this could be achieved by placing
the punch card in a scanner and then interpreting the
resulting picture.
q)
Subject: KOSH-OO-help ML
Summary of debate: A mailing list with the above title was suggested by John
Gustafsson so him, Dave and others can post a mail now and
then about something about OO and those interested could
talk about it.
r)
Subject: Get together
Summary of debate: Suggested we should all get together to celebrate the
release of KOSH 1.0 when it is out. Joel Newkirk wants to
know if we want to go to a party at his place? Such an
opportunity will give us all a chance to meet each other.
Dave Haynie then goes and invites us all to his place for a
Summer party in the year 2000 - what a nice gesture!. Mario
Saitti then makes further offers around the theme of a get
together.
Oh and ideas for the place to celebrate KOSH 2.0 are coming
in now as well:P
s)
Subject: Hardware Procurement WG
Summary of debate: Joel Newkirk suggests the above working group to establish
means of procuring hardware for testing, kommunity needs,
individual purposes, etc at the lowest available prices.
Maybe establish a specific physical/legal base in the state
of Delaware, which is conveniently free of sales tax, yet in
a convenient location at the heart of the US East Coast
Metro-Belt.
t)
Subject: Users as objects
Summary of debate: Suggested that we could tread users as objects or a set of
objects, with permissions for various things and levels
being objects or object-related as well.
u)
Subject: Multiuser systems
Summary of debate: Mentioned that would we need a multiuser system? With KOSH
being designed so that it is fast, easy and fun to use
rather than a mainframe OS with terminals and users perhaps
multiuser is unnecessary.
However multiuser systems may be a must for any connected
computer. File sharing would be hard and inefficient without
a multiuser system.
The multiuser model could be defined and then set the single
user model as the degenerate case.
By being able to boot the system into a configuration mode
that is free of user context software and hardware could be
easily added globally.
Data, applications and hardware could all be user-specific
(with the ability to add other users) or global in their
availability. Therefore we could have just one KOSH
distribution with many different levels of users. Sharing
like this could also be done over a network.
If every KOSH machine is fully multi-user it would mean that
identifying oneself to any machine would allow access to all
of that users resources and settings. Suggested that KOSH
should see multiuser as adding "personal" resources and
access privileges to the generic system.
v)
Subject: Resolving handles
Summary of debate: Resolving handles and finding methods/interfaces is likely
to take at least some processor time. Suggested these
things could be cached.
Further suggested is that we could have some objects built
at install time and updated at runtime if applicable, to
handle the resolving, on the machine the application or
object's installed on. The OS then wouldn't have to do a
new complete resolve each time the object were to be
invoked.
w)
Subject: KOSH Vocabulary WG
Summary of debate: Ruward F. Leenstra has suggested that it is time to create
the above named working group. As this will help with
reading Dave's paper on the Object Sea by defining and
explaining the terms contained within it.
A lot of interest was shown in this idea.
x)
Subject: KOSH FAQ
Summary of debate: Suggested that for subjects covered by KOSH mailing lists we
could have a frequently asked questions section of the web
site.
y)
Subject: Object synchronization
Summary of debate: One of the concepts arising in the discussions is the ability
to synchronize object by transferring the events (methods)
from one system to another. If the objects in question are
identical then no problem exists. If they are different, but
significantly similar then the same effect could be achieved,
in a limited fashion. The question is how can we determine
what methods a given object will respond to, and if those
methods are globally standard or intrinsic to that object?
By looking at the objects class hierarchy, the class
definition will determine the methods an object will
understand.
Suggested that we let the object manager be responsible for
almost everything related to this. Instead of calling an
object directly or using an object that pre-exists, we could
call the object manager to rebuild an appropriate object. All
calls to the object manager should be abstract under this.
Object Synchrony developed as an approach where two compatible
objects on different systems are synchronized by duplicating
the events therein or methods sent thereto between 2+ objects.
z)
Subject: Alternatives to the monitor
Summary of debate: Audio cues discussed in depth. They have advantages over
simply enlarging the text on screen, although having the
ability to work split at the OS level (not just in
applications) with one half at 100% magnification and the
other at anything you choose would be neat.
See http://www.cast.org - Center for Applied Special
Technology. Part of their purpose is to expand the
accessibility of computers. Their Blobby tool at
http://www.cast.org/blobby is very useful to check web pages
for accessibility.
Suggested KOSH could contact relevant organisations (eg:
Royal Society for the Blind in the UK) and tell them that we
are interested in getting opinions of our ideas from
experts in the field, and that we are eager to try to
incorporate capabilities they can show to be helpful.
It was stated by someone who is visually impaired that a
windowing system is useless for the blind and if you are
otherwise visually impaired such a system is poor.
1a)
Subject: Window shapes
Summary of debate: At the moment almost all windows are rectangular. If KOSH
implemented a form of masks from the outset the windows
could be any shape desired.
1b)
Subject: VB Problems
Summary of debate: See the following re Visual Basic and problems with it:
http://www.vb-zone.com/upload/free/features/vbpj/1999/mckinney/mckinney1.asp#1
1c)
Subject: Mouse movement
Summary of debate: The mouse pointer in KOSH must not be jerky, it must be
completely fluent.
1d)
Subject: More mouse control
Summary of debate: A small trackball under the finger on top of a mouse could
be used in addition to the mouse itself for panning and
zooming etc.
How about a horizontal wheel as well as the vertical one.
Mice that sense rotation were suggested.
Pointed out that if the drivers were written better the
support for the mouse could be automatic without an
application exactly having to support it.
A trackball or a trackpad in the center of a split keyboard
was suggested as an alternative.
1e)
Subject: Cartesian Coordinates
Summary of debate: Cartesian Coordinates were suggested to be used with the
Object Sea as 2D and 3D objects. However they can be
difficult to deal with a lot of non-rectilinear objects and
waveforms.
1f)
Subject: Alternative caching method
Summary of debate: Could we create a new 'protected' directory object that is
accessible only to the parent task and appears and
disapears along with it? This could be useable to get
around a new EU ruling that caching is against copyright
law.
1g)
Subject: Mutual NDA
Summary of debate: To protect KOSH work and the work of individuals involved it
may be necessary at some stage in the future to use mutual
non disclosure acts in some areas of the Kommunity - namely
in certain Working Groups set up for certain reasons. Anyone
could have access to this but they would have to sign a
mutual NDA with KOSH, Inc. to gain access.
1h)
Subject: High Performance Computing Users (HPCU) Group Annual Conference
Summary of debate: See: http://www.hpcu.org re the above, or the email posted
by Giorgio Gomelsky (gio1@interport.net) on the 26th March
entitled "Fwd: Computers/computation/standards" which is a
forwarded message calling for computer papers on an array of
topics.
1i)
Subject: Using a new object model rather than an existing one.
Summary of Debate: Several features were proposed for the KOSH object
model which do not exist in current object models
(specifically C++'s.) One of these features is
method transparency/translucence. Using this
feature it is possible to create a transparent/
translucent container class which receives methods
and passes those methods along to the objects the
class contains. Method transparency/translucence
can be utilized by an object to "broadcast" a
method to many recieving objects. There was some
concern that this would be wasteful, in that during
a broadcast many objects could receive methods they
do not implement, and be forced to ignore those
methods. Used appropriately, however, the ability
to "broadcast" methods would be a powerful tool.
An example of a translucent container would be a
generic-disc-object-container. This would be a
container class that held all the information
necessary to store an object that exists in memory
on the disc. The advantage of this is that while
the object is in memory it is not burdened with the
information about how it is stored on disc, and the
information about how to store an object on disc
can be implemented once, rather than over and over
again for each class.
Another feature proposed for the KOSH object model
was bidirectional polymorphism. Here methods can
be sent to a class which does not implement those
methods but may implement them at some point in the
future.
1j)
Subject: "Model-View-Controller" GUI Implementations
Summary of Debate: Under this common method for GUI implementation
each GUI component is broken into three pieces.
The Model consists of the logical representation of
the component, the View consists of the visible
representation of the component, and the Controller
consists of mechanisms to which the component
responds. This model originated in Smalltalk and
is used in QNX and in modified form in Java
JFC (SWING)
1k)
Subject: Polymorphism
Summary of Debate: Polymorphism was described as a subclass being
functionally the same class as it's parent class.
It was noted that this would be useful when
attempting to synchronize heterogenous objects. As
long as the objects shared a common ancestry they
would have a set of common methods. C++ uses
"pure virtual methods" in it's handling of
polymorphism, which are methods that are left
unimplemented in a parent class and must be
implemented in all subclasses of the parent.
1l)
Subject: Object Links
Summary of Debate: Anyone wanting to read more about object
orientation should check out the following:
Very Introductory Stuff
http://www.soft-design.com/softinfo/objects.html
Smalltalk ("Squeak" is a popular free subset
implementation)
http://www2.ncsu.edu/eos/info/ece480_info/project/
spring96/proj63/www/index.html
http://squeak.cs.uiuc.edu/
http://www.ddj.com/articles/1999/9901/9901k/
9901k.htm (funny)
http://www.stic.org/
Eiffel
http://www.eiffel.com/doc/manuals/language/intro/
page.html
Java
http://128.95.4.112/homes/gjb/doc/java-lang/
index.htm
http://www.javasoft.com/docs/books/tutorial/
http://www.javasoft.com/beans/docs/spec.html
--=_=8<==MD237000DDB-2E5C69D0==8<=_=
Content-Type: text/plain; charset=us-ascii; name="Ksum13a.txt"
Content-Transfer-Encoding: plain (7/8 bit)
Content-Disposition: attachment; filename="Ksum13a.txt"
X-MD2-FilePath: Work:mythicz/Ksum13a.txt
Object Technology & Resources Summary
** Efficiency, Flexibility & Classes
The discussion mentioned the trade-offs required to balance efficiency and flexibility. Concerns about
making unnecessary calls to objects which may not implement a specified method was countered with the
fact that broadcasting requests can often be more efficient than implementing suitability tests.
It was also pointed out that it is better to build an object in runtime from appropriate classes using
predefined methods. An 'upgrade flag' would be present in the system: objects could be 'frozen' to assist
with performance, but re-built by the object manager during each upgrade. Classes unable to fulfil a
functional requirement are ignored - this leaves a missing function, but is highly unlikely to cause
anything to fail.
Properties of objects shouldn't be restricted in general - UI characteristics, for example, could
legitimately be inherited by 'non-UI' objects in order to, say, provide display and user-interaction
parameters. Developing hybrid weirdity (great term!) is another reason for being able to want methods
mutating, but without the object code changing. A functional flow interface with user interaction provides
an example of this: streaming data and live interaction with adaption being performed - methods adapting
to the quality and quantity of data to change the visualisation. Dynamic artwork is also mentioned, as is
being able to change colour representation or whatever. To quote Paula Lieberman:
"let's add some purple dye up there at time N, and at time N+1 change the dye to yellow, and
when I press the Escape key, make it violent chartreuse with an A minor chord on a organ sample
at fff....."
In essence, you need to be able to ensure the flexibility is there to cope with the things we didn't
originally anticipate. [John's note: truly creative stuff comes from really bending things totally out of
shape - if you can't do that, creativity is limited]. The needs of users can often be different from the needs
of programmers, which suggests we must make it easy for developers to create the software the users
want, and not their own 'toy pet'.
** Selfmodifying Code
Comments on selfmodifying code spawned some interesting points. Experience of LISP has given a sour
opinion of selfmodifying code to many, and it is indeed a bad idea in most cases (selfmodifying code, that
is - not LISP!). Modern computers, with varying cache capabilities, can easily have performance
degraded by selfmodifying code. Well, if you do it wrongly it can - but if you do it right it can improve
things quite considerably. [John's note: compare to the issue of 'goto' - while a bad thing for almost all
situations, it does have its uses when handled properly].
The cache problem can be handled sufficiently by flushing the first level cache. However, as cache sizes
get bigger and more processors are added you have more caches to flush. The Intel Merced, for example,
will probably have an 8 MB cache, and be present in multiple-CPU configurations.
Furthermore, it's important not to get confused about what selfmodifying code is: it's code directly
changed during execution. However, if this code is actually rewritten to cover different cases as multiple
sections of code accessed through conditional branching you can develop alternatives for most uses of
selfmodification without cache problems and the like which can degrade performance. Of course, you
could create versions of functions/methods for a given system and just swap a pointer to direct code to the
right method - selfmodification would then only occur at the moment code is first loaded up. It was
mentioned that selfmodification should even be physically forbidden through techniques such as write-
protection of memory.
Are some of us trying to out-optimise modern optimising compilers by any means necessary? Apart from
keeping code compact (not really much of a necessity these days and still achievable through other means)
selfmodification can be replaced by more considered, structured programming approaches.
** Structured Programming
Ah, structured programming... In particular, criticism about universities and other institutions
(particularly in the west) not placing enough emphasis on structured design and programming techniques.
[John's note: Oxford Brookes University, UK taught me structured programming and design with great
emphasis, so not all universities are bad].
Good languages mentioned for teaching structured programming included Pascal and Modula-2 (praise to
Wirth!) as well as Java, while C and C++ came under fire for being unnecessarily complex,
unstructured and unfriendly. C++ has also helped destroy some companies, apparently! [John's note:
Sounds like C++ and ISO 9000 are related...]
--=_=8<==MD236FCC7A3-1EFDE8CC==8<=_=--
--=_=8<==MD237000DDB-2E5C69D0==8<=_=--
(end of MIME multipart message) (ps)
[Meldung: 30. Mär. 1999, 08:00] [Kommentare: 0]
[Per E-Mail versenden] [Druck-Version] [ASCII-Version]
|
