After years of investigating various packages for developing
Windows based applications, I think I've found one, Xbase++ by
Alaska Software (http://www.alaska-software.com), which appears to
hold enough potential for both power and accessibility that I'm
investing considerable time, effort, and cost to make the most of
it using a screen reader.  Whether I reach the point of producing
accessible, distributable Windows applications remains to be seen.
Toward that end, I'd like to network with anyone else interested in
learning Xbase++ with speech or braille access.  I hope such
discussions can occur on the dev-access mailing list.  To join, you
can send a message to [log in to unmask] with

subscribe dev-access

in the body of the message.  For anyone interested in this topic
who does not wish to be on the dev-access list at this time, feel
free to email me directly ([log in to unmask]).

Let me explain that I'm aware of blind programmers using Visual
C++, Delphi, and Visual Basic, among other languages.  I do not
wish to discount the gains they have achieved.  I was looking for
a relatively high level language with built-in database support,
especially one that transferred concepts and conventions from the
dBASE language and its various dialects under DOS.  Personally, I
was at my programming prime with the Clipper dialect by Computer
Associates, e.g., developing a speech friendly DOS shell called
Talking Directory (a trial version is on my home page at
http://www.empowermentzone.com/td20.zip).

the Xbase++ development package is not cheap, about $400 from
American distributors like GrafX Software
(http://www.grafxsoft.com).  While a demo version is being
prepared, I think there is a money-back guarantee.  I got the
product and have been studying it over the last month.  To get a
sense of its power, I'm including the Xbase++ white paper below
(converted from a PDF file).

Regarding accessibility, I have found several characteristics of
the Xbase++ package encouraging.  One can run the project builder,
compiler, and linker from a DOS box under Windows 95 and get
automatic output with a DOS screen reader.  Often, one will want to
silence speech during these processes, but it's nice to be able to
listen to the series of messages provided, especially when
debugging a program.

You use your own text editor, DOS or Windows, for writing source
code, so you can program in a familiar, efficient environment.  The
Xbase++ language generally does not care about capitalization,
indentation, spacing, and other formatting aspects that can
sometimes be tedious to set or proofread with speech output.

Locations in a Window can be specified either with mouse pixel
coordinates or with traditional row and column coordinates.  The
two types of addressing are not perfectly synchronized, but the
row/column approach seems to be robust enough to be quite useful
when designing a screen using source code rather than a graphical
layout tool (the approach sighted developers typically use).

Xbase++ seems to allow the creation of standard Windows controls
that work well with Windows screen readers, although some
configuration values (more precisely, object properties) sometimes
need to be set for this to occur.

For anyone with existing programs written in DOS versions of the
dBASE language, it should be possible to compile them with Xbase++
with little source code modification.  The programs will run under
Windows and can be gradually changed to have more of a Windows look
and feel.

Well, those are my thoughts for now on Xbase++.  I'm obviously
excited about its potential and hope I've interested some others
(blind or sighted) in investigating it too.  The goal is to create
an accessible development environment that permits relatively rapid
building of accessible Windows applications.  Perhaps some of us
could prepare a set of reusable Xbase++ commands, functions, and/or
objects that help to facilitate this.

Regards,
Jamal

----------
 © Alaska Software GmbH, 1997 1
WELCOME TO
THE FUTURE
The goal of Alaska Software is to successfully market and further
develop the Xbase ++
software development package. An Xbase development tool based on
modern 32-bit
operating systems such as OS/2, Windows 95 and Windows NT, Xbase ++
meets a real
need. This has been demonstrated by the success of Version 1.0. So
we won't stop there!
We're rolling up our sleeves to extend the functionality, scope and
power of this
package to benefit users around the world. Alaska Software intends
to live up to the
responsibility that it has toward present and future customers to
be open to other
platforms such as Sun Solaris and IBM AIX. Within the scope of our
Galaxy Server
Series products, moreover, we may also be extending our support to
include AS/400
and Novell's NetWare and IntranetWare. If you'd like to learn more
about this, please
request our Genesis Strategy Paper.
A SHARK'S BITE
Whitepaper
Xbase ++ : HEADING FOR VERSION 1.1
February 1997
Hauptstraße 71-79
D-65760 Eschborn/Germany
Tel.: +49/61 96/95 72-0
Fax: +49/61 96/95 72-22
eMail: [log in to unmask]
SOFTWARE
When we started out, our initial goal was to come up
with a development package for the OS/2 operating
system that was 100% compatible with the language
constructs and functionality of CA-Clipper 5.2x (for a
discussion of how great we succeeded, please read the
section entitled ''Compatibility`` below). We wanted to
offer developers a tool with real power and ''bite``,
which is also why we decided to give the overall
project the code name of ''SHARK``.
But we quickly realized that source code compatibility
with CA-Clipper alone wouldn't be enough. It would
fail to fully take advantage of the features that modern
32-bit operating systems must provide and, to a large
extent, already offer. So we planned and designed
Xbase ++ to take these features into account. And
the fruits of our labor are outstandingly suited to en-
abling the development of modern, secure and scalable
business applications.
Version 1.0 of Xbase ++ for the OS/2 platform de-
monstrated its compatibility and orientation to mee-
ting future needs. The next step will be the availability
on other operating systems such as Windows 95 and
Windows NT.
For a detailed discussion of the powerful enhance-
ments that characterize this new-generation Xbase
language and tool, please read the section ''Extended
Performance Attributes and Concepts`` below.
WHAT IS XBASE?
Xbase is the generic name given to a family of langu-
ages that originated in 1984 when Ashton-Tate laun-
ched dBase.
Over the last 10 years, the Xbase language has acquir-
ed increasing acceptance and popularity as new, com-
petiting products have emerged, including Clipper,
Visual FoxPro, and Visual Objects.
The success of these products has primarily been due
to the high degree of abstraction of the Xbase langu-
age, which makes it vastly simpler to access and use
operating system functions and resources. In addition,
Xbase is more than just a specialized programming
language, a database navigation language, or a user
interface description language --- instead, it combines
all of these roles, harmoniously integrating them with
one another.
The Xbase language also offers dynamic data typing,
and is generally described as being highly ''tolerant``.
Taken together, these benefits have persuaded a steadi-
ly growing community of users and developers to rely

© Alaska Software GmbH, 1997 2
SO WHY XBASE ++ ?
The snag is that, at least before the advent of
Xbase ++ , no Xbase development package available
in the marketplace was powerful enough to let users,
developers and third-party vendors fully exploit the
new generation of true 32-bit operating system such as
OS/2 and Windows NT. Why was this? Mainly because
of the huge effort involved in developing such a
package, plus the fact that only a truly new develop-
ment tool concept would genuinely do justice to 32-bit
operating systems. Otherwise it would fail to keep up
with the inevitable further development of these
operating systems --- necessitating a steady stream of
upgrades and forcing the developers to climb the
learning curve over and over again.
Moreover, today's workhorse platforms --- DOS and
Windows 3.x --- can no longer satisfy users' demands
and expectations. Xbase ++ offers a straightforward
path for migrating away from these platforms --- which
have nearly outlived their usefulness --- and jumping to
a new, better ship.
Another, important consideration is that past versions
of the Xbase language have had a number of short-
comings, as the fast-growing crowd of Xbase product
users has discovered. Various product vendors have
attempted to remedy these problems. But they have
only managed to do this by introducing proprietary
extensions which deviate from the original language
standard. This proliferation of products has greatly
diluted the original language definition --- an unfor-
tunate development.
To get a handle on these problems, when developing
Xbase ++ we knew it was indispensable to extend
the language and the capabilities of the overall tool.
These facts are outlined in the 6 primary design goals
of Xbase ++ :
.A consistent programming model to smooth the
transition from procedural to event-driven software
development.
. An object-oriented programming (OOP) model to
facilitate the creation of complex applications and
maintenance of existing solutions.
. Improved encapsulation procedures for writing code,
plus an enhanced compiler also able to generate
native code --- i.e., instructions that can be directly
executed by the CPU.
. Support for modern GUIs at a level of abstraction
appropriate to the Xbase language.
. Raising of the level of abstraction of the Xbase
Database Manipulation Language (DML) and un-
coupling of DML from the underlying database
model.
. Easier integration into existing IT infrastructures.
Alaska Software's goal has been to make avail-
able an Xbase development package that would
not only let software developers tap the full
potential of modern 32-bit operating systems
such as OS/2, Windows NT and Windows 95,
but also provide a solid foundation for deve-
loping software to run under future operating
system generations.
Xbase ++ also overcomes the shortcomings
of the Xbase language. It provides a stable,
forward-looking development platform that
you can also use to extend the life cycles of
applications now running under DOS/Win-
dows. These are, in a nutshell, the reasons why
we chose the name of Xbase ++ for our pro-
duct --- besides the wish to stress how this new
generation of Xbase technology differs from
its forerunners.
THED IFFERENCE
(32BIT VS. 16BIT)
Modern 32-bit operating systems offer much more
than such obvious benefits as linear memory addres-
sing (the 16-bit memory model is limited to 640k
bytes, compared with the ability to address 4.2 giga-
bytes in 32-bit systems). In fact, these operating sys-
tems pioneer completely new territory in numerous
ways. The basic underlying philosophy is a whole new
paradigm. Take preemptive multitasking, for instance,
or features like object-oriented user interfaces, exten-
ded file systems, multithreading, and complex inter-
process communication mechanisms.
Today's applications fail to take advantage of much of
what modern 32-bit operating systems have to offer.
The operating systems themselves are at least partially
to blame, since they can be hard to learn. Muscular
tools are needed to facilitate this.
What's more, it is also absolutely vital to anticipate
future advances by having development tools that take
all this into consideration today. Otherwise, both
upon it.
Over the years, Xbase has developed into the language
of choice for implementing mission-critical and
commercial PC desktop applications. In fact, world-
wide more than one-third of all DOS-based com-
mercial apps now in use were written in Xbase, with
CA-Clipper accounting for the lion's share.

© Alaska Software GmbH, 1997 3
XBASE VS. JAVA
Every experienced Xbase developer knows that many
of Java's functions first surfaced in Xbase languages
some ten years. And Xbase ++ developers even
conclude that their language of choice is superior to
Java: they don't have to learn a new programming
language to take advantage of this functionality --- Java
is structured like a C/C++ dialect --- and they can
when migrating from 16-bit to 32-bit environments
and as the 32-bit operating systems themselves evolve,
support for existing applications and/or their source
code will eventually dry up. This will incur hefty costs
reuse older source code written years ago, which won't
work with Java. So what if Java offers platform in-
dependence, they say --- Xbase ++ is available for
OS/2, Windows 95 and Windows NT, and also has a
hybrid compiler able to generate platform-indepen-
dent p-code, just like Java.
XBASE VS.
SMALLTALK
The two primary advantages of SmallTalk are its
object orientation and the fact that it has a Garbage
Collector. That means that you don't have to explicitly
request resources such as memory. But SmallTalk's
fanatically strict object-oriented philosophy makes it
hard to learn, thus pushing up costs. It is also very
difficult to migrate existing solutions, typically re-
quiring them to be redesigned and reimplemented
from scratch.
In any case, the most effective way to develop appli-
cations is to take a hybrid approach involving a com-
bination of object-oriented, structural and function-
based implementation. Unfortunately, SmallTalk lacks
this flexibility --- unlike Xbase ++ , which optimally
meets these requirements. It lets you use and freely
mix traditional command-oriented Xbase, functional
Xbase, and object-oriented Xbase ++ .
XBASE VS. C/C++
With regard to flexibility for combining object-orien-
ted and functional approaches to implementing code,
C++ shines where SmallTalk falters. The downside is
that in C++ you have to draw upon extensive class
libraries to handle database operations and manipu-
late the user interface. This applies to all system
languages that, like C++ and Pascal, do not have
built-in operating system models. This forces you to
plow through general-purpose class libraries to
achieve the same result, making you walk when you
could run.
But the most serious drawback of C++ is that you
must write additional code to request resources --- such
as memory, threads or GUI components --- from the
operating system or release them again afterwards.
When developing commercial applications, the extra
work involved can easily exceed what you spend on
actual programming. In Xbase ++ , by contrast, a
Garbage Collector automatically manages and moni-
tors all resources --- memory, threads and user inter-
faces --- for you. Xbase ++ thus combines the ad-
vantages of C/C++ --- object orientation and a func-
tion-oriented approach --- with those of SmallTalk.
and make life hard for the users of development tools.
And as the tools themselves develop in response, deve-
lopers will be obliged to learn how to use many of
their features over and over again.
XBASE VS. PASCAL
Pascal and Object Pascal are, like C/C++, typical
examples of ''system languages``, and consequently
share many of the same disadvantages. Although
modern Pascal systems let you build user interfaces
quickly, implementing complex business logic can be
much more difficult and laborious than it should be.
Another problem that crops up in connection with
database applications is Pascal's lack of dynamics, a
failing of all system languages. For instance, it is an
utter impossibility to dynamically generate and exe-
cute expressions of the kind that many database or
data-oriented applications require. Xbase ++ lets
you generate, execute and permanently save to disk
both expressions and code blocks at runtime.

© Alaska Software GmbH, 1997 4
NO UPPER LIMITS
#########
WHYCA-CLIPPER?
We decided to consistently model our system on
CA-Clipper, since this Xbase development tool has
historically been the most powerful --- and popular ---
of its breed. A number of purely technical aspects also
influenced our choice. For instance, Clipper 5.0 was
already equipped with a preprocessor that performs
translation of the source before passing it to the
compiler. This feature makes for easy compatibility
with other Xbase dialects. Plus, Clipper 5.0 introduced
modern encapsulation ideas that other Xbase
languages did not adopt until quite recently.
COMPATIBILITY
WITH CA-CLIPPER
Xbase ++ is complete-
ly source-code-compa-
tible with all Clipper ver-
sions from '87 to 5.2x.
This also ensures a rela-
tively high level of com-
patibility with most other
Xbase dialects, such as
FoxPro and dBase. The
table at right lists the
features that Xbase ++
shares with CA-Clipper.
(1) CA-Clipper has internal objects, whereas Xbase ++ possesses a
complete object model.
(2) We have further enhanced the extend system of Xbase ++ by
adding important API interfaces
and making it easier to use.
Language elements CA-Clipper 5.2x Xbase ++ 1.1
Commands yes yes
Functions yes yes
Code blocks yes yes
Objects yes (1) yes
Preprocessor directives yes yes
User-defined commands yes yes
User-defined functions yes yes
Macro evaluation at runtime yes yes
Private, public, local, static data types yes yes
Dynamic variables yes yes
Extend system yes yes (2)
EXTENDED CAPABILITIES AND CONCEPTS
LANGUAGE PHILOSOPHY
#########
The number one goal pursued while designing
Xbase ++ was to achieve a high degree of abstrac-
tion and transparency. We undertook to model the
complex mechanisms of modern operating systems
platforms such as OS/2 and Win32 at a level appro-
priate to the Xbase language, but without blocking
access to the underlying layers.
So now Xbase ++ lets you access a large number
of features in any of three different ways: by easy-to-
use Xbase commands, via a function interface (to im-
prove encapsulation and the quality of implementa-
tion), or with object classes for creation of complex,
robust applications.
In every situation, this three-tier model places the
required know-how and best possible tool at your
fingertips for implementing applications.
Because it consistently takes advantage of the me-
chanisms provided by 32-bit operating systems,
Xbase ++ is free of the upper limits that the DOS
and Windows operating systems impose on, for
example, CA-Clipper, CAVisual Objects and Delphi.
The 64k limit on character strings and the maximum
of 4,096 elements per array simply don't exist in
Xbase ++ .
Instead, the maximum size of any given data type is
limited exclusively by the amount of physical and
virtual memory made available by the operating
system. You can assign a 100,000-element array or a
4-megabyte text block to a single memory variable in
Xbase ++ . In practical terms, this means it is ab-
solutely no problem to perform an AEVAL on an array
with a million elements in an OS/2 Warp environment
with 12 MB of RAM, or to use the MemoEdit function
to edit 5 MB of text.

© Alaska Software GmbH, 1997 5
INTERCHANGEABLE
DATABASE ENGINES
#########
Instead of the replaceable database driver (RDD) used
in CA-Clipper and CA-Visual Objects, Xbase ++ em-
ploys an abstract database engine (DBE) composed of
individual components consisting, behind the scenes,
of objects that provide various services (methods) for
data and file management.
The architecture of the DBE components is based on
the system object model (SOM) of IBM, which is
available under OS/2 and Windows. It is an imple-
mentation of a language-independent, object-oriented
programming model along the lines of the CORBA
standard.
Because the DBE concept of Xbase ++ consistently
makes use of cutting-edge, standardized object-orien-
ted technology, it paves the way to state-of-the-art
client/server architectures and distributed application
systems.
In Xbase ++ , database engines are loaded, bound
and --- if wished --- released again at runtime. This
technology differs radically from the RDD approach
taken by CA-Clipper, which requires making mono-
lithic, memory-hungry database drivers available to an
application at link time.
Xbase ++ even lets you assemble the components
(objects) of different DBEs to build a new DBE.
Thanks to this modular approach you can, for
example, generate indices for files in system data
format (SDF). All you have to do is load the NTX
component of the DBFNTX database engine to the
SDF database engine. The result is an SDFNTX
database engine that permits logical sorting of files in
SDF.
This DBE technology opens up the unprecedented
possibility of using any desired DBM systems within
an application, either combined or separated from one
another.
The package you get with Version 1.0 of Xbase ++
includes DBF, NTX, SDF and DEL (delimited ASCII)
database engines. We will also be releasing a separate
SQLPack kit that supports SQLAnywhere, IBMDB2
and Oracle SQL-Server. Version 1.1 of Xbase ++
will also come with DBFBLOB and CDX database
engines to ensure compatibility with Microsoft FoxPro.
Within the context of our Galaxy Server Series pro-
ducts, we will be offering additional database engines
that are interchangeable across all Alaska products.
THE OBJECT MODEL
#########
CA-Clipper 5.x has four internal object classes, which
helps to explain its enormous flexibility. The Get sys-
tem and the TBrowse object are particularly impor-
tant. A serious drawback of CA-Clipper, however, is
that its object model is not directly accessible at the
language level. There is no way for you to implement
your own classes derived from those provided by
Clipper.
The Xbase ++ development package offers an ob-
ject-oriented programming model that gives you full
control over a range of capabilities including multiple
inheritance, class declaration, and attribute assign-
ment. This vastly facilitates the development of com-
plex applications. The resulting solutions are charac-
terized by greater robustness, greater ease of main-
tenance, and improved scalability. In Xbase ++ ,
''internal`` classes --- like Get and TBrowse in CA-
Clipper --- are derived from a built-in object model,
letting you take them as the basis for defining classes
of your own --- with full inheritance capabilities.
XBASE PARTS
#########
As an Xbase developer, you want the models for uti-
lizing graphical dialog components to be as easy to
use and platform-independent as possible.
To meet this need, we developed a special encapsu-
lation and linking mechanism: XbasePARTS, or XBPs
for short. The underlying idea is comparable with
technologies such as VBX (Visual Basic) and OCX
controls. You use the event management capabilities of
Xbase ++ and ''callback slots``, to which code blocks
can be assigned, to talk to them.
XbasePARTS are genuine objects defined in compli-
ance with the built-in object model of Xbase ++ .
This approach maximizes both reusability and inte-
gration.
You can use all XbasePARTS at several different levels.
For example, XBPs are simple to use in applications
without requiring you to get directly involved with
object-oriented programming techniques. A convenient
way to implement complex solutions is to derive a
new class from an XbasePART. But you can also use
OOP, via defined interfaces of XbasePARTS, to
perform manipulations at the message level of the
GUI. This makes it easy for you to develop your own
PARTS or user interface controls.

© Alaska Software GmbH, 1997 6
EVENT MODEL
#########
In our opinion, the underlying concepts of such
''modern`` GUIs as Presentation Manager and Windows
are no longer in touch with the times. They also clash
with the underlying philosophy of a language like
Xbase.
Xbase ++ therefore makes a radical departure: the
''dispatching mechanisms`` of a GUI are completely
encapsulated and implemented as a flexible, excee-
dingly easy-to-use event model.
The chief advantages of this event model are:
. It is extremely easy to migrate character-based
applications (in video input/output mode) to gra-
phical mode (Presentation Manager mode or
Windows GUI).
. Platform-specific event models are encapsulated in a
suitable Xbase ++ model, making it much easier
to build GUI applications.
. You can even implement character-based applica-
tions that are completely event-driven.
The resulting application program is considerably
more robust and runs more reliably.
MULTITHREADING
#########
So-called multithreading is a salient feature of modern
32-bit operating systems such as OS/2 and Windows
NT. We have therefore diligently incorporated it while
developing Xbase ++ , from its inception down
through every design phase.
All data types are completely encapsulated, and con-
sequently there are no restrictions whatsoever on
asynchronous, concurrent execution of Xbase ++
applications. In other words, you no longer have to
bother with the complex mechanisms that are re-
quired to achieve stable multithreading. No other de-
velopment tool available in the international market-
place offers comparable features to ensure automatic
separation and concurrent execution of multiple
threads and prevent conflicts, nor is this situation
likely to change anytime in the near future.
Because Xbase ++ consistently uses multithreading
features, and thanks to the event model just described,
you're no longer restrained by the ''1/10 seconds rule``
of present-day GUI application development.
As a result, now you can perform a statistical calcu-
lation on an array of 50,000 elements without having
to worry about what might happen if interaction with
the user interface is interrupted while this is going on.
No such interruption is possible with Xbase ++ .
This ''automatic`` multithreading of Xbase ++ appli-
cations enables XBPs to update information indepen-
dently and automatically in a separate thread. For
example, a message can be automatically sent to the
associated TBrowse object to ''stabilize``, and the
object then automatically does so in a thread of its
own. This lets you concentrate on creating the actual
application.
Database operations can also be ''transferred`` between
different execution paths of an application (thread).
Time-consuming operations can thus be carried out
either in the background (asynchronously) or in the
foreground (synchronously), as required. The mecha-
nisms needed to carry out such complex operations are
all incorporated in Xbase ++ .
This makes it a cinch to offload time-consuming
operations --- such as compilation of statistics or
transfer of information to a host system --- to a sepa-
rate thread. And, in contrast to other development
tools, you don't have to worry about handling the
details of complex synchronization tasks in order to
accomplish it.
DATATYPE S AND PERSISTENCE
#########
In Xbase ++ , all data types are persistent. This
applies to character strings, numerical and date values,
and arrays with any number of dimensions. All of
these data types can be saved and loaded.
Xbase ++ also provides this persistence for code-
blocks. These can now be saved and loaded as well ---
a world premier. In other words, they can be saved
beyond an application's life cycle along with the data
and functionality they hold. This opens up the possi-
bility of persistently saving dynamically generated
code to disk or transferring it to another application
elsewhere in a network.
So now you can deploy Xbase ++ to create ''data-
driven applications`` without having to fuss with
mechanisms for storing and loading the control data.
In fact, Xbase ++ no longer supports the primitive,
proprietary format for storing and loading dynamic
variables, i.e., ''private`` and ''public`` variables. This
results in a slight incompatibility with CA-Clipper, but
one you can easily live with.
NOTE:
If you work with Xbase ++ or would like to get
started, and want to port large MEM files to OS/2,
you can download several useful tools from our
Xbase ++ Support Section in CompuServe (see
''Technical Support`` on the last page) for converting
files from MEM to XB2.

© Alaska Software GmbH, 1997 7
All dialog components of the Xbase ++ develop-
ment package support the help system of the under-
lying operating system platform. A help compiler for
creating attractive online documents is included. Each
Xbase ++ PART also has a help link that enables it
to ''contact`` the help system.
THE PREPROCESSOR
#########
Xbase ++ also includes the ability to use STD.CH
files, which are well known from CA-Clipper, to im-
plement its commands. This provides smoother com-
patibility with Clipper and existing 3rd-party products.
COMPILER TECHNOLOGY
#########
We paid particularly great attention to optimizing the
compiler technology used. After conducting in-depth
analyses of the Xbase language and future require-
ments, we therefore opted for a ''hybrid technology``.
In plain language, what this means is that the gene-
rated code --- in other words, the object files produced
by our compiler --- consist of a mixture of ''native
code`` and ''pseudo code`` (p-code). Our test cycles and
analyses have clearly shown that this approach yields
the best performance for an untyped, dynamic langu-
age like Xbase ++ . As far as possible, a special
component of our compiler automatically optimizes
the balance of ''p-code`` and ''native code``.
We believe that the importance of p-code will increase
in the years to come for creating distributed appli-
cations able to run on different platforms. Particularly
when developing applications that need to work in
conjunction with ''business agents``, the availability of
p-code plays a central role.
MEMORY MANAGEMENT
#########
The architecture of the Xbase ++ runtime system
includes its own handle-based Memory Manager,
which has a separate thread with a ''Packer`` and
''Garbage Collector``. This elegantly solves the prob-
lems associated with fragmentation and irreversible
loss of main memory that have persistently dogged
Xbase languages.
In contrast to other programming languages,
Xbase ++ developers don't need to bother about
administering system resources. Incidentally, this
applies not just to main memory resources, but also to
GUI and thread resources. This lets you concentrate
on creating your application and makes you more
productive.
SCRIPTING
#########
The OS/2 operating system platform includes the
powerful interpreter/script language known as REXX.
The main purpose of REXX is to automate operations,
but it also serves as a powerful integration instrument.
Many products --- including fax software, the Internet
access kit of OS/2 Warp, and SQL database systems ---
install so-called REXX DLLs that permit sending of
faxes from within REXX or performance of FTP
connects, to cite a couple of examples.
Every application created with Xbase ++ is poten-
tially able to execute REXX scripts within its own
address space, with simple and direct access to the
application's functions and the runtime system by
calling a single function. This makes it easy to import
data from host systems or to automate any desired
tasks of an Xbase ++ application, similarly to a
macro language.
MISSION-CRITICAL-
APPLICATIONS
#########
In Xbase ++ , the approach to exception handling
taken by modern operating systems such OS/2 and
Windows NT has been implemented using the langu-
age construct BEGIN/END SEQUENCE-RECOVER-
BREAK that CA-Clipper first introduced.
All program errors, no matter whether they are errors
of the runtime system or of the operating system
itself, are stored in accessible ''error objects``.
Xbase ++ also includes functions you can use to
implement strategies for responding to specific error
conditions.
This enables Xbase ++ developers, for the first time
ever, to supply users and sensitive corporate clients
with true ''mission-critical applications``.
THE HELP SYSTEM
#########
This mechanism works in both directions additionally
under OS/2 (application to help system, and help
system to application), thus enabling you to build
complete interactive tutorials in Xbase ++ .
WHAT ELSE ...
#########
It would exceed the scope of this Whitepaper to ex-
haustively describe all the extended capabilities of
Xbase ++ . We should also mention, however, that
Xbase ++ provides general, automatic support for
things like country-specific settings (currency symbols,
date formats, etc.) and sorting of lists according to the
ISO standard (collation tables).

© Alaska Software GmbH, 1997 8
32-BIT NATIVE CODE
#########
The object files generated by the Xbase ++ compiler
comply with the ''object file format`` of the underlying
platform and will therefore run without any restric-
tions whatsoever.
Applications developed under Xbase ++ are genuine
32-bit OS/2Warp, Windows NT, or Windows 95
executables.
Xbase ++ also lets you create Dynamic Link
Libraries (DLLs). The linker required to do this is
included in the development package.
One of the prime ingredients in the success of CA-
Clipper was, and continues to be, its Extend system.
Xbase ++ offers a documented, open interface that
lets C/C++ developers access all data types at the
language level, to generate new ones, or to execute
code blocks.
OPEN IN ALL DIRECTIONS
#########
CONCLUSIONS
We believe that our development team has excellently
succeeded in creating a new generation of Xbase,
specifically the Clipper dialect, while enabling its
transition to a secure future.
This is because now, for the first time ever, it makes
available a full-featured development tool for modern
32-bit operating systems --- initially, OS/2 --- that is
conceptually tailored to their features. Here is what
relevant publications and journalists have had to say
about the beta version of Xbase ++ :
Mario Schneider,
freelance journalist specializing in Clipper:
''The pre-beta release of Xbase ++ has shown that
Alaska not only pays lip service to an interesting
concept, but is also able to put it into practice...``
PC-Intern:
''Xbase ++ makes it a cinch to migrate from con-
ventional Clipper to a modern Xbase-based develop-
ment environment. The source code compatibility
does the rest...``
Computerwoche:
''Porting applications is easier, since developers can
choose between character-based or graphical mode,
or a combination of both ...``
OS/2 Inside:
''Xbase ++ makes it feasible to create applications
in entirely new dimensions. Even if they gradually
emerge from old Clipper applications, they soon leave
their origins far behind ...``
OUTLOOK
During the course of the project, we naturally had
many ideas. And we built the basic capabilities for
most of them into Version 1.0, although not all were
actually implemented. For the transition from Version
1.0 to Version 1.1, our product support will provide
several patch levels for the following purposes:
. To enhance stability and eliminate bugs that Alaska
or existing customers have identified.
. To improve performance and runtime speed.
Version 1.0 showed us that there was considerable
room for improvement in the various parts of the
overall system. Our goal is to tap this potential.
. To enlarge the range of features. Alaska Software
takes its customers' needs very seriously. Today we
already offer add-on libraries for multimedia
support, OS/2 profile management and ISDN CAPI
control, which any registered Xbase ++ user can
obtain free of charge from our CompuServe Section
or our Technical Support team. These components
are not included in the basic package, since we think
we should concentrate on developing further the
core software.
We welcome any ideas you may have for enhancing
the features and capabilities of Alaska Software pro-
ducts. Please send them to us by fax, e-mail or snail
mail. We also test the practical suitability of new
features and functions on panels of selected customers.
Productivity: Xbase ++ Version 1.0 was already
equipped with a Dialog Painter, and this will be joined
by other tools such as a Report Generator and Exe-
cutor, an interactive Test Tool, a Menu Painter, and an
interactive, database-independent Design Tool.
The overall product strategy of Alaska Software is
explained in our Genesis Strategy Paper, which we
will gladly send you on request.

© Alaska Software GmbH, 1997 9
TRADEMARKS
PCDOS, OS/2 Workplaceshell, and Presentation Manager are registered
trademarks of International Business Machines Corp.
SOMObjects and System Object Model (SOM) are trademarks of
International Business Machines Corp.
MS-DOS, FoxPro, Visual FoxPro, and Visual Basic are trademarks or
registered trademarks of Microsoft Corp.
OLE2, Windows 95, and Windows NT are trademarks or registered
trademarks of Microsoft Corp.
dBase, Visual dBase, and Borland Delphi are trademarks or
registered trademarks of Borland International Inc.
CA-Clipper and CA-Visual Objects for Windows are registered
trademarks of Computer Associates International Inc.
OpenDoc is a registered trademark of Apple Computer Inc.
Smalltalk and PARTS are trademarks of Digitalk Inc.
JAVA and HOTJAVA are registered trademarks of Sun Microsystems Inc.
Xbase ++ , GALAXY APPLICATIONSERVER, DMLB, and XBP are trademarks
or registered trademarks of Alaska Software GmbH.
Advantage Database Server is a trademark or registered trademark of
Extended Systems Inc. Fortress is a trademark or registered
trademark of Loadstone Inc.
YOU CAN ALSO REACH US AT :
Alaska Software GmbH
Hauptstraße 71-79
D-65760 Eschborn/Frankfurt
GERMANY
ADDITIONAL
INFORMATION
Tel.: +49/61 96/95 72-0
Fax: +49/61 96/95 72-22
CompuServe: 100436,1375
Internet: [log in to unmask]
We hope that this Whitepaper has succeeded in filling you in on our
product and
our medium-term goals.
You can obtain more detailed information on the technical features
of the Xbase ++
development package from the sources described below.
DEVELOPERS
#########
Software developers may request a free test package from Alaska
Software by specifying article no. 109271.
This test version only runs for a limited time but is fully
functional. Our intention is for it to give interested
developers an idea of its compatibility and extended features.
JOURNALISTS
#########
Journalists can contact our Press Service to be placed on a free
mailing list.
You may also request a full version of our product for test
purposes.
3RD-PARTY VENDORS
#########
Makers of add-ons and developers who are interested in creating a
3rd-party product for Xbase ++ may
request additional information. They should make sure to find out
about our 3P (3rd-Party Product Program).
We have chosen CompuServe to be our official support channel. You
can reach the Alaska Xbase ++
section by visiting the OS2UGER Forum (Section 12). Or send an
e-mail directly to our support account
at 100571,1071 ([log in to unmask]).
TECHNISCHER SUPPORT

----------
End of Document