erv@everest.TANDEM.COM (E. Videki) (03/23/91)
Archive-name: languages/oberon/oberon-m/1991-03-22
Archive: ucsd.edu:/pub/oberonm.* [128.54.16.1]
Original-posting-by: erv@everest.TANDEM.COM (E. Videki)
Original-subject: Oberon-M Q's and A's
Reposted-by: emv@msen.com (Edward Vielmetti, MSEN)
This is about the Oberon-M(tm) package for the MSDOS
environment. Here are answers to questions that I've
been repeatedly asked:
Q: Does this use real Intel/MSDOS-like object files?
A: Yes, in fact in a form that I expect is even compatible
with all older releases. This causes some non-Intel-based
linkers (such as one from Borland) to give occasional
warning messages, but everything works fine even
under those cases.
Q: What kind of garbage collector do you use?
A: The MSDOS environment (particularly older releases)
don't work well with programs taking over full
storage management -- especially when many and varied
terminate and stay resident programs are present.
As with Oberon itself, simplicity is refreshing, so
although I once had a garbage collector its use was
questionable under DOS, and it is not present in this
package. You can, of course, do NEW(objectptrs) on
anything that will fit, but there is no automatic
retrieval of storage (until your program ends). Of
course you could always write your own storage manager
(it can be very powerful while still being very
simple).
Q: What about the Oberon System?
A: As explaned in different words in my earlier posting,
the Oberon system is an extensible operating
environment with user interfaces and automatic
storage management. MSDOS likes to own these things
all by itself mostly. My compiler
and package is best thought of as a way to write
programs using the advanced and elegant features of
Oberon in the popular MSDOS world.
Q: What's the product's official name?
A: It is called Oberon-M(tm), and I hold the trademark
rights as well as copyrights to it. Further, it
is my sole intellectual property. It is being
released in the form of license-to-use.
Q: What about other legal requirements, etc ?
A: The package itself specifies these, but a summary of
the details are:
1) I retain full copyright of this package,
especially the compiler and the implementation
approach.
2) Use of the package is by license, at the moment
with fee waved. The user does not own the
package, only has rights to use it.
3) The user may not redistribute the package or
the compiler or the associated tools to other
users, in any way. This means I don't want
it given out by third parties, and of course
never sold by them, nor represented as being
their property. Network distribution is
an exception to the prohibition of
multi-level distribution.
4) Users may write programs, use the distributed
library modules with their programs, and
even modify for their own use the library
modules (but not the compiler). Such user
programs may be distributed without fee or
royalties to me.
5) My copyright notices may never be removed from
the package contents itself.
6) No warrantees or guarantees are expressed or
implied. Use of the package in any and all
ways is entirely the user's responsibility
and risk.
Q: How long will use of this be "no charge", ie: the
license fee is waved?
A: On this release, no specific period has been decided
upon.
Q: What are the specific, technical things the compiler
does not do?
A: Here are the things that the compiler does NOT do now,
or could be viewed by some as being deviations from
the Oberon language report by Niklaus Wirth:
1) No floating point support in this release.
2) 8088 and 8086 (ie: the oldest processors) do
not have Enter and Leave instructions which are
generated by the compiler. Thus, only PCs
with 80x86 (where x >= 1) processors can
use the produced code. The compiler itself will
run on an older machine, though.
3) The produced code has not been tested under all
versions of MSDOS that exist in the world, but
I anticipate no problems. Some of the library
modules may have differences in internal
calls for very-odd MSDOS flavors; source for
these are supplied so you may make modifications
if you are running one of these rare DOS systems.
4) The ETH Zurich Oberon System permits "code
procedures" identified by a minus sign in the
procedure header. This is non-standard, very
machine dependent, and not allowed on my compiler.
However, module SYSTEM exports a predefined
CODE procedure which takes bytes to insert
in the instruction stream.
5) You MUST use the compiler hint "*" on a procedure
definition if that procedure is going to be
assigned to a procedural-typed variable (so
that 80x86 long-calls will be generated).
This looks like this, and is part of the
Oberon language:
PROCEDURE * MyHandler(....
Trying to assign a procedure without the "*"
indicator results in a type incompatibility
error at compile time. Note that this is
different than the export mark "*" which
follows the procedure name.
6) Due to the irregularities of the 80x86
architecture, code generation for it is
ponderous. In my experience
most professional programmers don't need
or want the overhead of range or stack
checking, so that is not provided. Of course,
this is a debatable issue.
7) To make very sure programs using system
dependent features (ie: the built-in machine
specific system support module) are identified
by the compiler, our system support module
is called "SYS" (whereas the one from ETH
is named "SYSTEM"). Excepting the exported
CODE procedure, it functions the same as defined
as SYSTEM in Niklaus Wirth's report.
I am considering changing this name to SYSTEM
in the next release, and if you have a strong
opinion, please tell me about it.
Q: Can't I please get this package in some way other than
FTP or uudecode of mail messages ?
A: Sorry, the demand is too great to respond to special
requests for free.
Q: What's the size of the whole package?
A: In compressed (ZIP) format, it is about 151K, expanding
to about 250K or so, including the PostScript(tm)
documentation. In uuencode format (in mail messages)
it is about 210K. The compiler itself is merely 78K.
Q: What's in the package, specifically?
A: Compiler, library modules in source/symbolic/object forms,
sample programs, an extensive README file instructing
how to use the package, a report on the Oberon language,
and an EBNF summary of the syntax (these must be
downloaded to a PostScript-handling printer or printer
driver).
Q: "I sent you a logon/password/subdirectory to put the
files on my machine. What are you going to do with
that information now that you are distributing this
package through anonymous FTP and uudecode mail?"
A: Nothing. It is destroyed as confidential information.
I come from the old school of hacking that respects
privacy as a rule of existence.
-- E. R. Videki 18 March 91
erv @ k2.tandem.everest.com (130.252.59.153)
....