Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

C++ Product List and Description - Version 2.05 - Part 8/10

1 view
Skip to first unread message

Saumen Dutta

unread,
Feb 27, 1993, 2:29:39 PM2/27/93
to
3.9. Zinc
_ _ ____

+ Platform: DOS

+ This was the most commonly mentioned library for DOS.
It was generally praised. Several people noted the
documentation could be more helpful but the tech sup-
port phone people seemed to make up for that failing.
One respondent noted his release didn't handle variable
fonts but said that may be fixed in the current
release. The only respondant to explicitly mention
using Zinc in graphics mode found it "intolerably
slow."

+ Information provided by ben...@math.ksu.edu

3.9.1. Netcomments
_ _ _ ___________

From a...@dsbc.icl.co.uk (Andy Wardley)

POINTS FOR....

The Zinc Interface Library "...gives a fast nice GUI, that
somewhat reminds me of windows.", "the library is well-designed."
and "you can get it to do most things and its Windows capabilities
are at last getting into shape."

"I will also add that I'm very impressed with the company. My
friend who has it told me he got an update in the mail without
even asking and he was offered a Windows version (beta?) from
their BBS for free. Very impressive for a software company."

"For DOS I've heard it's very good but their Windows version is
buggy, but I think they're coming out with a much-improved
version"

"See a recent c.l.c++ summary of PC GUI libs -- it did well."

"We are developing DOS applications using Zinc (with Borland BC++)
and are reasonably well-satisfied with it. Our application is not
pushing Zinc very hard, however. We are using it in graphics
mode, although we are mostly putting text objects & menus on the
screen."

"They provide much sample code & studying it is essential."

"Tech support is free & good; they have a BBS."

"But as a UI library it is really great. They have just released
version 2.01 with a lot of bug fixes this means it is pretty solid
now."

"The design tool saves a lot of time. The documentation is
extensive and good. There is a lot of good example code too."

POINTS AGAINST...

"The Zinc designer has lots of bugs and quirks, but you can get
around them"

"Some things could have been better done, and is surely better
implemented in the OS of the Macintosh."

"For top-professional use there are some limitations. We even
considered returning the package. But if you can live without a
100% product, but rather a late beta, then this is for you."

"It took me a while to get into their approach, partly because
their documentation goes into detail but seems to leave out
overviews."

"The library is somewhat lower level than I would like. For
example, check boxes and dialog boxes are not built-in, but they

provide examples to show you how to build them."

"They do not currently support variable fonts, although their tech
support told me it is planned for a future release."

"Incidentally, applications seem to be pretty large with it."

"The major problem I have with it is I wish it worked with a DOS
extender under Zortech"

OTHER POINTS...

"If you can't find what you need in the docs, then look in the
sources"

"Rumours says that they are working on Macintosh, OS/2 and UNIX
version too. Apple programmers has seen an early version of the
mac version."

REVIEWS IN...

Dr. Dobb's (12/90),
Computer Language (12/90)
PC Week (12/26?/91).
Byte (01/91)

SUMMARY...

It seems that generally, people are happy with it and think it's a
good UI library. The older version (pre V2.01) was slightly
buggy, particularly in the designer and the MS windows parts, but
this has mostly been fixed in V2.01. Most of the bugs had work
arounds.

The library is fast and flexible, although radio buttons, check
boxes etc, are not built in classes and have to be derived from
existing classes - fairly easy for the more advanced programmer -
maybe slightly difficult for others..

Documentation, was reasonable in the older versions and is now
greatly improved in the new one, with over 1100 pages. Technical
support from the company was generally regarded as VERY good.

Thanks to people who contributed...

po...@daimi.aau.dk (Povl H. Pedersen)
jam...@emx.utexas.edu (Jamish Afshar)
fer...@coyote.datalog.com (fred jarvis)
bork...@dcs.qmw.ac.uk
a...@ee.wpi.edu (Arthur J Butler)

3.10. Starview C++ Graphical User Interface Library
_ __ ________ _ _________ ____ _________ _______

+ Designed to be independent of OS and Hardware vendors

+ Author: Andreas Meyer, STAR DIVISION

Contact:

STAR DIVISION GmbH
Andreas Junge
Sachsenfeld 4
D-2000 Hamburg
Germany

Phone: ++49 40 23646 500
Fax: ++49 40 23646 550
Email: svi...@stardiv.de

+ The development of large applications for Graphical
User Interfaces (GUI's) like MS-WINDOWS, MS Presenta-
tion Manager or OSF/Motif is a very time consuming job.
In addition, the application programming interfaces
(API's) of the different GUI's are totally incompatible
making a direct port of source code to another GUI
platform impossible, almost all code driving the user's
interface must be re-written by the programmer.

Two years ago, STAR DIVISION decided to develop a set
of new applications for GUI's which should fulfill the
requirements of modern software standards this entails:

- Portability between the operating systems MS-DOS,
OS/2, Macintosh and different UNIX flavours

- At least portable between the GUI's MS-WINDOWS,
MS-Presentation Manager, MacApp and OSF/Motif

- Fulfillment of the requirements of the different
GUI Style Guide's

- Data exchange and direct communication between the
applications in homogeneous and heterogeneous net-
works (groupware approach)

Because of the indifferent "political" situation (i.e.
MS-DOS or OS/2 or UNIX or everything, WINDOWS or PM or
X.11 or everything) we decided to develop a set of
tools which helps us to be mostly independent from the

decisions of the OS and hardware vendors. In addition
tools help to improve productivity and are the base for
a successful software project. C++ is the programming
language of our choice because we could use our large
experiences in C programming and C++ provides all major
advantages of Object Oriented Programming (OOP) that is
- from our point of view - the best available paradigm
for complex software development today.

+ Information provided by Stefan Taxhet
(...!unido!starlab!st)

3.11. TEGL Library
_ __ ____ _______

+ Supported on Borland C++

+ Address not known

+ Price around $99

+ One respondant faulted it for "ignoring CUA" while
another praised it as having the look and feel of
presentation manager. The source code apparently is not
highly polished and it does recommend using more than
one mouse button.

+ Information provided by Andrew G. Bennett
(ben...@math.ksu.edu)

3.12. Linpack Math Library
_ __ _______ ____ _______

+ MSDOS, UNIX, and many other platforms including a vec-
torised version of CRAY

+ Commercial software from:
Rogue Wave Software Inc.
1325 NW 9th Street,
Corvallis, OR, 97330,
(503) 754-2311.

+ No information on the compatability with the proposed
ANSI/ISO standard

+ The classes are available now. Prices range from $199
to $995 for Matrix.h++ and $299 to $1195 for
Linpack.h++.

+ Linpack.h++ is an object-oriented C++ version of the
widely used Fortran library. Linpack.h++ includes 100%
of the functionality of the Fortran version, plus much
more. Because Linpack.h++ is written in C++ it has
capabilities that far exceed the Fortran version.

Both Matrix.h++ and Linpack.h++ are completely compati-
ble with Rogue Wave's other C++ class libraries,
Tools.h++ and Math.h++, which are accepted standards in
the industry.

Matrix.h++ includes all the funtionality of Math.h++.
For example: general matrices, vectors, statistics,
complex numbers, Fast Forier Transformation (FFT's),
etc. Matrix.h++ adds specialized matrix classes such
as banded, symmetric, positive-definite, Hermitian,
tridiagonal, etc. Because Matrix.h++ includes
Math.h++, it can take advantage of Math.h++'s highly
optimized low-level assembly routines, making it fast
as well as graceful.

+ Information provided by Dave Riches (d...@bnr.co.uk)

3.13. Objectkit\C++ 1.0
_ __ ___________ _ _

+ Commercial software available from:

ParcPlace Systems, Inc.
999 E. Arques Ave.
Sunnyvale, CA 94086
Tel: (408)481-9090
Sales: 1-800-759-7272
email: in...@parcplace.com

+ Features the AT&T Standard Library Extensions:

- variable length bit strings

- adjustable 1-d vectors of parameterized type
(implemented via macros)

- classes for date, time-of-day, timezone and time-
duration arithmetic

- finite state machine classes

- simple exception handling using Objection classes

- parameterized linked lists (parameterization via
macros)

- associative arrays (i.e., keys/value associations)

- fast memory allocation class: Pool

- program execution time measurement class:
Stopwatch

- String class and specializations of iostream and
streambuf for String

As a convenience for purchasers, Objectkit\C++ 1.0 also
includes the NIHCL and InterViews class libraries as
*unsupported* free software.

Objectkit\C++ OI - based on technology licensed from
Solbourne, OI is a C++ class library for rapid develop-
ment of graphical user-interfaces that allow runtime
selection of OSF/Motif or OPENlOOK look-and-feel.

+ Information provided by Mike Khaw (kh...@parcplace.com)

3.14. MFC (Microsoft Foundation Class Library)
_ __ ___ _________ __________ _____ _______

+ Included with the MS C7 compiler. Please refer to the
Microsoft Compiler section.

+ Includes complete source. Supports all standard memory
models. Supports DLLs [dynamic link libaries aka shared
Libraries].

Also sometimes referred to as AFX "Application
FrameworX", and/or "The C++ API for Microsoft Windows"

+ Information provided by: ji...@microsoft.com

3.14.1. Introduction
_ __ _ ____________

MFC's primary design goals are to provide an efficient,
compact, fast, easy-to-use, typesafe, and portable version
of the Windows API for the C++ programmer. A secondary goal
is to provide Collection classes, diagnostic memory manage-
ment, etc, for DOS and Windows programmers. MFC is imple-
mented without the use of language-extensions, allowing the
library to be ported to other C++ conformant compilers
[although right now MFC is only shipping with the C7 com-
piler.] MFC closely follows the naming conventions and use
of the "C" Windows API so that programmers experienced in
Windows programming find it easy to switch from C to the C++
APIs. However the "lower level" aspects of Windows program-
ming are improved upon by MFC. For example wparam, lparam
packing/unpacking is handled automatically and in a type
safe manner. Also the main message loop is handled automat-
ically. Switch statements are replaced with the use of vir-
tual functions and/or cached message dispatch that avoid
slow message searches. Finally, the C++ Windows classes are
implemented in such a manner as to remain compatible with
the C implementations, such that Windows programmers can
still use the C APIs where desired, and/or can mix old
implementations of Windows classes implemented in "C" with
new Windows classes written in C++. Namespace collisions
with other libraries are avoided by using an uppercase "C"
prefix on the MFC Windows classes. MFC includes support for
OLE, DDE, Multimedia, and Windows for Pen Computing. Appli-
cations written using MFC are automatically pen aware.

3.14.2. Window Application Classes
_ __ _ ______ ___________ _______

CWinApp Main windows application class

Window Classes

CWnd Base class for all windows
CFrameWnd Main window base class for the SDI (Single Document
Interface) desktop window
CMDIFrameWnd Base class for the MDI (Multiple Document Interface)
desktop window
CMDIChildWnd Base class for MDI child windows
CDialog Base class for modeless dialog windows
CModalDialog Base class for modal dialog windows
CButton Button control windows
CComboBox Combo box control windows
CEdit Edit control windows
CListBox List box control windows
CScrollBar Scroll bar control windows
CStatic Static control windows

GDI (Graphical Device Interface) Classes

CDC Base class for display contexts
CClientDC Display contexts for client areas of windows
CMetaFileDC Metafile device contexts
CPaintDC Display contexts used in <OnPaint> member functions
CWindowDC Display contexts for entire windows
CGdiObject Base class for GDI drawing tools
CBitmap GDI physical bitmaps
CBrush GDI physical brushes
CFont GDI physical fonts
CPalette GDI physical palettes
CPen GDI physical pens
CRgn GDI physical regions

Other Windows Classes

CMenu Menu structures
CPoint (X, Y) points in a device context
CSize Relative positions or coordinate pairs
CRect Rectangular regions in a device context
OLE (Object Linking and Embedding) Classes
OLE Classes Object Linking and Embedding Classes

Run-Time Object Model Class

CObject Root class in the Foundation class hierarchy

File Classes

CFile Binary disk files

CMemFile In-memory files
CStdioFile Buffered stream disk files, usually text mode

Object Input/Output

CArchive Persistent storage for objects
CDumpContext Destinations for diagnostic output

Exceptions

CException Abstract base class for exceptions
CArchiveException Archive-specific exceptions
CFileException File-specific exceptions
CMemoryException Out of memory exceptions
CNotSupportedException Function not supported exceptions
CResourceException Windows resource not found exceptions

Collections

CByteArray Arrays of bytes
CDWordArray Arrays of 32-bit double-words
CObArray Arrays of CObject pointers
CPtrArray Arrays of void pointers
CStringArray Arrays of strings
CWordArray Arrays of 16-bit words
<template array class>

CObList Lists of CObject pointers
CPtrList Lists of void pointers
CStringList List of strings
<template list class>

CMapPtrToWord Mappings of void pointers to 16-bit words
CMapPtrToPtr Mappings of void pointers to void pointers
CMapStringToOb Mappings of strings to CObject pointers
CMapStringToPtr Mappings of void pointers to CObject pointers
CMapStringToString Mappings of strings to strings
CMapWordToOb Mappings of 16-bit words to CObject pointers
CMapWordToPtr Mappings of 16-bit words to void pointers
<template map class>

Miscellaneous Support Classes

CString Character strings
CTime Absolute time and date values
CTimeSpan Relative time and date values

Global Functionality

Diagnostic Services Global memory diagnostic functions
and macros (Debug only)
Exception Processing Global exception throwing and
catching functions and macros
Message-Map Reference CWnd message map entries

with message-handler function
prototypes

3.15. NetClasses
_ __ __________

+ Commercial software available from:

PostModern Computing Technologies, Inc.
1032 Elwell Court, Suite 240
Palo Alto, California 94303
Telephone: (415) 967-6169
Facsimile: (415) 967-6212
Email: plam...@cs.stanford.edu

+ No information on compatability of the future ANSI/ISO
standard.

+ NetClasses is a set of C++ class libraries for distri-
buted object-oriented communications that will begin
beta testing June 15 and is scheduled for production
release in the 3rd quarter of 1992.

+ Information provided by Thane E. Plambeck
<plam...@cs.stanford.edu>

3.15.1. Introduction
_ __ _ ____________

One of the major stumbling blocks of developing and
fielding complex distributed applications is the difficulty
in implementing and debugging using existing communication
tools. The focus of the NetClasses architecture has been to
provide the tools necessary for programmers to develop

complex distributed applications without having to deal with
the esoteric details of low-level communications.

NetClasses is a set of C++ class libraries that is organized
as a software toolkit. The typical user of the NetClasses
libraries will be a distributed systems application
developer who requires an object-oriented framework for dis-
tributed, message-passing based programming. By linking the
appropriate NetClasses libraries, application programmers
are then able to:

+ Transport objects over a network.

Currently, there are three object varieties that NetC-
lasses can transport:

1. Arbitrary C++ objects---once derived from
PostModern's TransObject class

2. arbitrary NIH-derived objects; and provide an
object-oriented data transport in which the struc-
ture and organization of network transportable
objects is specified externally in configurable
files using a simple, programming language
independent abstract syntax notation, the NetC-
lasses Abstract Syntax Notation (NASN).

+ Perform remote method invocations (RMI)

Using RMI, an application on machine B can invoke a
method on machine A. RMI insulates distributed applica-
tions from the complexity inherent in traditional,
RPC-based distributed systems development tools such as
protocol compilers, TCP/IP code writing, and detailed
socket handling. RMI makes fault tolerance and connec-
tion management transparent to the application program-
mer. The RMI layer is built on top of the distributed
services package that is described below.

+ Build complex information distribution systems on top
of Distributed Services, PostModern Computing's
object-oriented approach to client-server connection
management and fault tolerance.

+ Use the NetClasses application programmer interface in
order to create, manipulate, and destroy typed objects
given NetClasses Typed Object data type definitions.
(NIH-derived and native C++ objects are created,

manipulated and destroyed from C++ itself).

+ Read and write all three varieties of NetClasses-
transportable objects on streams using machine-
independent external representations. All three
varieties of objects can be stored to and read from
files.

3.15.2. Objects as transportable data
_ __ _ _______ __ _____________ ____

One of the most common needs in distributed applica-
tions development is the ability to ship objects over a net-
work. Currently, when data has to move from one machine to
another this is usually done using hard-coded structures
over a low-level communications interface such as Berkeley
sockets or the System V Transport Layer Interface. Moving
data in this way has several disadvantages:

+ If the format of the data changes, e.g. a new field
must be added to a structure, all programs using that
structure must be recompiled, whether or not they actu-
ally make use of this new field.

+ Developing programs using low-level interfaces require
programmers to concentrate on details such as sockaddr
structs, byte ordering routines such as htonl, port
numbers, and so on. These are details that are
irrelevant to most applications and simply stand in the
way of efficient distributed application programming.

+ Because of the low-level nature of the interfaces, the
resulting distributed programs are generally not very
scalable. In order for distributed programs to scale
up to large size implementations it is necessary to
provide an infrastructure whereby data and processes
can be managed efficiently as the number of machines on
the network grows. This has proven to be very diffi-
cult using low-level interface tools.

Engineers developing distributed systems using object-
oriented methodologies place great emphasis on data encapsu-
lation and clean interfaces. One of the goals of NetClasses
has been to preserve these properties in the communication

interfaces.

Therefore, instead of shipping byte buffers over the net-
work, NetClasses allows applications to ship objects. In an
object-oriented program virtually all information is stored
in objects, making objects the most natural form in which to
transfer information over a network.

3.15.3. Varieties of object transport
_ __ _ _________ __ ______ _________

PostModern Computing's NetClasses package provides a
set of flexible C++ tools for object transport.

The NetClasses NIH-based and Typed Object-based transports
are built on top of the National Institutes Health (NIH)
class library. However, the NetClasses Typed Object appli-
cation programmer interface is not NIH-dependent. In par-
ticular, the Typed Object interface does not in any way con-
strain C++ developers who prefer not to use the NIH library
themselves.

The TransObject transport offers C++ programmers a third
facility for object transport that is entirely NIH indepen-
dent. The TransObject class library offers end-user appli-
cation programmers a way to migrate existing C++ class
definitions to a network-transportable framework. The Tran-
sObject facility is independent of both the NetClassses
Typed Object transport and the NIH-based object transport
described above.

3.15.4. Distributed Services
_ __ _ ___________ ________

In addition to transporting objects over a network,
another common need in distributed application development
is the management of object dissemination and connections
between clients and servers.

PostModern Computing's Distributed Service paradigm is a
connection and service management mechanism that is organ-
ized around the idea that network service providers should
not have to set up explicit port numbers and RPC connections
but rather should simply ``advertise'' themselves on the
network. ``Agents'' are active processes on the network
that monitor network service advertisements and manage con-
nections between information producers and consumers. The

Distributed Service package is organized as a combination of
C++ class libraries and configurable ``dsagent'' execut-
ables. The Distributed Services paradigm is a powerful and
flexible package that provides an object oriented framework
for integrating and connecting applications on a network.

Distributed Services provides the following features:

+ Fault Tolerance

+ Load Balancing

+ Multicasting

3.15.5. Remote Method Invocation (RMI)
_ __ _ ______ ______ __________ ___

The distributed services paradigm enables methods to be
invoked on objects from remote machines. The RMI facility
is a higher level communications facility that again shields
the developer from port number and host name considerations.
The focus of RMI is on ease of use. An RMI invocation
requires no stub or skeleton files, protocol compilers, or
RPC mechanisms. To enable object X of class C to have its
method M invoked from a remote machine, a programmer uses
the RMI::advertise method to advertise method X.M.

If an application wants to invoke the M method on object X
from a remote machine, it uses the RMI::invoke("X.M")
method.

Parameter passing in RMI can be based on any of the three
NetClasses object transports (generic C++, NIH-object, or
TypedObject). Synchronous and asynchronous RMI versions
exist.

Multiple agents can advertise method X.M. The one that is
actually invoked is transparent to the client. RMI thus
provides an easy mechanism for developing scalable distri-
buted applications.

3.15.6. Transport mechanisms
_ __ _ _________ __________

In the first developer's release, NetClasses includes
TCP- and UDP-based object transport mechanisms.
PostModern's Reliable Broadcast Protocol (now under alpha
testing) is a UDP-based layer for reliable object transport
in nonconnection-oriented environments. The TCP, UDP, and

Reliable Broadcast Protocol facilities are all organized as
C++ class libraries.

0 new messages