To:ALL

From: LATTICE INCORPORATED
P.O. BOX 3072
GLEN ELLYN, IL 60138

Date: 08/28/87

Subject:LATTICE & OS/2 PART 1 (FOR PUBLIC RELEASE)

------------------------------------------------------------------------------

Part 1: LATTICE C PROGRAMMING
UNDER
OPERATING SYSTEM/2
May 8, 1987

Operating System/2 (formerly called ADOS) is probably the most
advanced disk operating system ever developed for microcomputer
workstations. And while it brings a rich set of "big system"
features to 80286 and 80386 computers, it also retains a great
deal of compatibility with DOS. Lattice congratulates IBM and
Microsoft on this impressive technical achievement and is pleased
to have been selected as an early test site.

This report describes Lattice's experiences with Operating
System/2 while developing a new version of the Lattice C Compiler
that will be available when the operating system is released.

Early copies of this compiler, currently called Version 5, have
been in use for several months at Lattice and at some test sites
selected by IBM, and the initial results have been very
encouraging Both the compiler and the operating system are quite
stable and perform well. And even though some features remain to
be developed in both areas, we have already been able to transport
very complex C programs to the new environment, most notably
Lattice's electronic spreadsheet (Unicalc) and screen editor (LSE).

We expect to have most of Lattice's programming tools transported
by the time the operating system is released or shortly thereafter.


Part 2: SUMMARY OF OS/2 EXPERIENCE

Lattice has worked with OS/2 for more than six months, testing
its DOS compatibility mode, modifying the Lattice C Compiler for
use in protected mode, and developing techniques for transporting C
programs from DOS and other environments.

In a nutshell, we've found OS/2 to be very receptive to C programs
that were written for DOS using the generally accepted guidelines
for portability. Also, the compatibility mode accepts a surprisingly
large number of existing DOS programs with no complaints and good
performance.


Part 3: Converting Well-Behaved Programs

Well-behaved programs can be converted by simply re-compiling and
re-linking. Furthermore, if you link with the Family API Library
as described later, these programs will work under OS/2 in either
real or protected mode and under DOS 3.3 as well.

By "well-behaved", we mean that the program interfaces with DOS only
through the standard library supplied with the compiler. Furthermore,
it cannot use certain library functions (e.g. int86, intdos, bdos,
and bios) which provide low-level DOS access that is not supported in
protected mode.

Several good examples of this type of software are the print utility
(PR), the library manager (OML), and the object module disassembler
(OMD), which are included with the Lattice C Compiler. Each of these
programs obtains some command line arguments, opens one or more input
files, reads these files, and produces one or more output files or
reports. It took less than one day of effort to convert them all to
run in family mode.


Converting Highly Interactive Programs

Programs that are heavily oriented towards the keyboard or screen
usually require more work because all interfaces with the BIOS and
video RAM must be changed. However, if you've followed the
recommended practice of isolating these into a few modules, you'll
only be dealing with a small percentage of the code.

OS/2 provides service functions that are, in effect, equivalent to
the BIOS interrupts, and so the keyboard conversion is pretty easy
and has little effect on performance. These service functions also
offer several ways to replace the direct video RAM interface, and
it is possible to tune things up so that the visual performance is
close to the "no holds barred" DOS environment.

Several examples in this category are the Lattice Unicalc Spreadsheet
(about 25,000 C source lines) and the Lattice Screen Editor (about
15,000 C source lines). Each of these required less than one person
week to convert, and although both need some further tuning, we found
their initial performance to be quite acceptable.

Converting I/O Drivers and TSR Programs

I/O drivers and the so-called Terminate-and-Stay-Resident (TSR)
programs probably present the toughest conversion challenges, if only
because they hook into the messy guts of DOS and typically require a
large amount of assembly language code. Furthermore, the rules for
creating such programs have never been well documented, and so
designers have had to use "it ad hoc" techniques learned by
experimentation.

We were initially concerned that the techniques for creating such
programs would be much different under OS/2 and that this knowledge
could not be obtained experimentally, since OS/2 is so well-protected
from its users. And, sure enough, our concerns were justifiable.
However, IBM's documentation has been a pleasant surprise even at
this early stage in the life of OS/2. These arcane areas are
explained quite well, which has led us to conclude that IBM wants to
encourage independent software vendors to write drivers and TSRs.

What's more, the operating system includes some exciting features
that will greatly simplify this work, such as multi-threading,
multi-programming, I/O monitors, and inter-process communications.
So, even though driver and TSR designers will face the task of
re-designing their programs, OS/2 will make it much easier to do
this type of work in C rather than assembly language.

We have not yet converted any of our drivers and TSRs, but at this
point we don't see any insurmountable obstacles.


Part 4: Real-Mode Programs

OS/2 provides a so-called "compatibility box" (which is not a piece
of hardware) for running unmodified DOS programs. At present, only
one such program can be in the system at any time, and that program
can only execute when it has control of the screen, that is, when it
is the "current session".

Just about every DOS program that we've tried to run in the
compatibility box has worked. The exceptions have been debuggers and
other programs that probe around in the DOS internals. Also, we've
observed some glitches in the critical error handler, but these are
probably just bugs that will (hopefully) be exorcised by the time OS/2
is released.

The Family Mode

In addition to providing forward compatibility for DOS programs
via the compatibility box, OS/2 also allows you to create programs
for protected mode that will execute correctly back in the DOS real
mode environment. Such programs are said to operate in "family mode",
and they must adhere to several simple rules:

First,they can only use a subset of the OS/2 services for which
there are DOS equivalents. This subset is called the "Family
Application Programming Interface", or "Family API".

Second, all code sequences that manipulate 32-bit pointers must
be sensitive to the differences between real-mode and
protected-mode addresses.

Third, after you link a family-mode program, you must use an
OS/2 utility called "BIND" to attach a special "stub" to the
EXE file that will simulate the OS/2 service calls when the
file is loaded by DOS or in OS/2 real mode. The stub is ignored
in OS/2 protected mode.

We designed the Lattice OS/2 C Compiler so that it will normally
produce family-mode programs. Specifically, the low-level support
library dynamically adapts itself for the addressing differences
between real and protected mode, and the rest of the standard library
uses the Family API. As a result, it was very easy to build all of
our well-behaved programs (e.g. the compiler itself) in family mode.
Surprisingly, we were also able to construct the interactive programs
mentioned above (i.e. Unicalc and LSE) in this way because all of the
necessary screen and keyboard services are included in the Family API.

Although we've observed a few glitches in the family-mode stub when
using these products under DOS 3.3, it looks like the problems are
being cleared up as OS/2 evolves. Therefore, family mode looks like
a real winner for those who don't want to ship separate DOS and OS/2
versions of their products.


Part 5: Compatibility between IBM and Microsoft Versions

From a C programmer's viewpoint, Microsoft's MS-DOS has remained
nearly identical to IBM's PC-DOS, and this will probably remain true
after Microsoft releases MS-DOS 3.3. If there are any differences,
they have usually shown up in the ROM BIOS functions of an MS-DOS
computer that is not 100% IBM-compatible. And these differences only
affect a C programmer who calls the BIOS directly instead of going
through the operating system. Therefore, we don't anticipate that
there will ever be a need for separate Lattice C compilers for these
two operating systems.

IBM OS/2 and Microsoft OS/2 could present a more difficult situation.
The two companies have announced their intention to use a common
nucleus with the same Application Program Interface. As if to
emphasize this commonality, IBM is allowing Microsoft to use its
trademarked names Operating System/2 and OS/2. To a C programmer,
this means that the traditional C language and library features will
be the same for both systems, and so an executable program (i.e. an
EXE file) would behave identically on an IBM computer with IBM OS/2
or a non-IBM computer with MS OS/2.

However, each company intends to bundle it's own implementation of
a sophisticated "presentation layer" with the basic OS/2 package.
Microsoft's is essentially their "MS Windows" package, while IBM's
is reported to be mostly a new design with some low-level pieces
from Microsoft. If this is true, then it is unlikely that they will
use exactly the same programming interface, which means that
different function libraries might be required for C programmers
writing code to connect with the presentation layer. For example,
we might need to implement different versions of the "printf"
function for use with the different presentation layers, and you
would then have to select the appropriate one when you constructed
your EXE file. The "printf" in the standard library would, of course,
use the basic API, bypassing the presentation layer completely.

But do you think that many software product developers will support
both "standards" if they are substantially different? Just as in the
days when IBM offered PC-DOS, CP/M-86, and UCSD, a Darwinian selection
(i.e. survival of the fittest) will occur. It's a good bet that the
company controlling the hardware standards will ultimately prevail,
and so you can expect to see Microsoft's presentation layer become
more like IBM's. This process has already begun with Microsoft's
recent decision to abandon tiled windows in favor of overlapping.
The latter is, of course, the method chosen by IBM.



Part 6: Performance

Performance is always a big concern with a new operating system,
and this is especially true with OS/2 because its predecessor has
served well in many demanding applications. Moreover, the new
operating system runs the 80286 chip in {it protected mode}, which
exhibits different (and often worse) performance than the "real mode"
used by DOS.

Much performance analysis needs to be done in order to fully
understand the characteristics of OS/2, and we are sure that IBM
will be giving this area a lot of attention before the final release.
But as a quick measure, we developed the following figures on an
IBM Personal System/2. Since the benchmarks were relatively simple,
we rounded all the results to the nearest second in order to avoid
the appearance of high precision.

BENCHMARK DOS OS/2 REAL OS/2 PROT
===================================================================
Integer Math 2 3 3
Float Math 24 25 27
Disk I/O 6 6 6
Memory Allocation 38 39 41


Incidentally, the same tests yielded the following results on
an IBM-AT:

BENCHMARK DOS OS/2 REAL OS/2 PROT
====================================================================
Integer Math 5 5 6
Float Math 42 43 47
Disk I/O 10 10 10
Memory Allocation 65 67 73



Part 7: LATTICE C COMPILER RELEASE STRATEGY

After IBM briefed us on OS/2, we were convinced that it would become
a new standard for personal workstations and would draw the attention
of the professional software developers who have traditionally used
Lattice C. Accordingly, we made plans to inject a new version of the
compiler into our already busy release schedule. The result of this
planning is the Version 5.0 compiler, currently scheduled for release
in the fourth quarter of this year.

We are now shipping Version 3.2 of the compiler. So if the ADOS
release is called Version 5, what happened to Version 4? Well,
it's still in our plans as a completely ANSI-standard DOS compiler
with major improvements in both size and speed optimization. The
release dates for Version 4 are under review, partly because of our
pre-emptive work on Version 5 and partly because of the organization
changes resulting from Lattice's recent acquisition by SAS Institute.

Regardless of how our dates and version numbers finally settle, we
intend to give full C compiler support to both DOS and OS/2. In
addition, beginning with Version 3.2, the compiler package will
contain both 3.5-inch and 5.25-inch diskettes for full compatibility
with theIBM personal computer family.


Part 8: VERSION 5 COMPILER FEATURES

Version 5 is very similar to the just-released Version 3.2, in terms
of the new programming features being offered. The most important of
these for the OS/2 environment are:

Mixed memory models, via the "near" and "far" keywords;

Direct calls to the operating system via the "far" and "pascal"
keywords;

Elimination of the 64K static data limitation via either the "far"
keyword or the "huge" memory model;

An option to make the default integer size be 32 bits.

Versions 3.2 and 5.0 contain a great many other new features, most of
which were the result of suggestions from our customers. In addition,
as work progresses on Version 4, its new optimization and
ANSI-standardization features will be moved into Version 5.

Version 5 Library Changes

The function library has been extensively re-worked for the
new operating environment, and it now consists of the following
components for each memory model:

LC.LIB, containing the low-level compiler support functions and the
user-level functions for "Family Mode";

LCM.LIB, containing the low-level and user-level math functions, which
are all compatible with "Family Mode";

LCR.LIB, containing DOS functions that can only be used in
"it Real Mode";

LCP.LIB, containing functions that can only be used in "Protected
Mode";

NDP.LIB, containing "LCM.LIB" overrides that improve size and
speed for applications that will always run in the presence of a
math co-processor;

NONDP.LIB, containing "LCM.LIB" overrides that improve size and
speed for applications that will never run in the presence of a
math co-processor.

The compiler package will soon include shareable versions of LC.LIB,
LCM.LIB, and LCP.LIB. You will then be able to construct
applications in which the library elements are dynamically linked
when your program is loaded. This feature of OS/2 leads to smaller
load modules and faster program loading, although it presents us
with some interesting marketing challenges.

Even though all services of OS/2 can be invoked directly by the C
programmers, we are adding a few functions to LCP.LIB that should
simplify some of the more complex services. For example, the afork
and await functions are very similar to Lattice's traditional fork
and wait, except that they allow asynchronous process execution
(i.e. multitasking).


Part 9: Version 5 Documentation

The documentation for the Version 5 compiler is being greatly
expanded to describe how a Lattice C programmer can use the many
advanced features of OS/2. The topics include:

A general description, from the Lattice C programmer's viewpoint,
of the operating system's Application Program Interface (API).

Efficient programming with mixed memory models;

Constructing applications for "Protected Mode"
and "Family Mode";

Multi-tasking techniques, including inter-process
communication methods;

Using the keyboard, screen and mouse pathways in
protected mode;

Writing I/O drivers and keyboard monitors in C;

Adapting assembly language functions from the DOS environment
for "Protected Mode" and for "Family Mode".

This documentation is not intended to replace the stuff that will
be supplied with the OS/2 Development Toolkit. Specifically, we will
not include a detailed description of each operating system service
function, even though these are directly callable from Lattice C.
However, our words should help you to understand IBM's documents
from a C programming perspective.


Part 10: SUMMARY

Lattice's experiences with OS/2 have been very positive. This
sophisticated operating system looks like it will be a worthy
upgrade for venerable old DOS, and we believe that C programmers
will find it to be a terrific base for many exciting new
applications.

Lattice Incorporated
Post Office Box 3072
Glen Ellyn, IL 60138

Business Office Phone: 312-858-7950