Glenn,
The Zinc Application Framework 4.0 is now available with full UNICODE
support via our UNICODE Key. Zinc has great internationalization support
built in (20 Locales and 14 languages) and is a great framework for
developing applications intended for many markets (i.e.. Japan, Korea or
any other Asia market, along with all of the single byte languages). I
have included a White Paper on Zinc's Unicode and Mutliplatform
capabilities. Below are the answers to your 6 questions-
1. Product name- Zinc Application Framework with Unicode Support
2. Supported Platforms- Motif/Windows/DOS/Macintosh/OS2/NEXTSTEP and
Curses.
3. Availability- NOW
4. Type- Developer
5. Contact Name-
Zinc Software
Troy Bartlett
405 South 100 East, 2nd Floor
Pleasant Grove, UT 84062
Phone: 801-785-8900 or 800-638-8665
EMail: barttk@zinc.com
6. Web URL: http://www.zinc.com
If there are any additional question I can answer please let me know.
Thank you.
Sincerely,
Troy K Bartlett
--$----Novell--Attachment----$
X-NVL-Content-Type: TEXT
X-NVL-Content-Typename: Text
X-NVL-Content-Charset: X-IBM-437
X-NVL-Content-Filename: WHTPIN.TXT
X-NVL-Content-Modification-Date: 27-Sep-1994 09:47:22 +0000
Software Globalization:
Zinc Application Framework
and Unicode
A Zinc White Paper
The ability to write an application that supports more than one
human language is essential as computers proliferate into more
and more areas of the world. A global marketplace provides
obvious new opportunities for growth, and many companies are
taking advantage of this potential. Especially alluring is the
prospect of existing applications gaining international market
share without rewriting them.
Unfortunately, internationalizing an existing application is a
nontrivial task. Many issues go beyond simply translating the
language used in the application. For example, date, time,
number and currency formats change; the language may use a
different character set; or foreign hardware and operating system
platforms may be incompatible with the original application
platform. All of these issues, and others, need to be addressed.
The most common method for internationalizing software has been
to retrofit the application, redesigning and rebuilding much of
the application. This is expensive, often costing as much as the
original development and resulting in new sets of source code to
support. International language versions of an application often
ship months or even years after the native language version,
thereby missing significant revenue opportunities. Needless to
say, developers have been looking for a better method for
supporting multiple languages.
Zinc Application Framework is the better way. With its global
architecture that includes Unicode(tm) support, Zinc provides the
ability to use many languages, even languages that require
multiple-byte character sets, making multiple language support
easier than ever before. By using Zinc Application Framework,
you bring the globalizing process back towards the realm of
simply translating the text.
Internationalization, or globalization, is the act of creating a
program that can support any written language. On the surface,
this sounds straightforward, simply translate the text. In
practice, however, it is much more complicated. Languages are
complex when you consider that some languages are alphabetic,
some are syllabic, and others are ideographic. And the language
is just the tip of the iceberg. Internationalization needs to
address a wide range of issues, including currency, date, time,
and number formatting, and so forth.
Zinc uniquely addresses these issues. Zinc's development staff
is multilingualmost of its developers have spent significant
time in other countriesand Zinc employs one of the industry's
leading Unicode architects. The talent and exposure of Zinc's
developers, combined with a mature, global architecture, results
in an elegant and effective solution for internationalizing
software.
COMPLEX ISSUES
Before discussing Zinc's internationalization strategy in detail,
gaining a basic understanding of the complex issues associated
with developing applications to run in multiple languages is
helpful.
Character Rendering
Character rendering, the display of characters on a screen, is a
fundamental issue in internationalization, sometimes abbreviated
as I18N because it starts with an "I," is followed by 18
characters and ends with an "N." In order to translate an
application's text into another language, it must be possible to
display the characters associated with that language. For
example, to display Japanese characters on the screen, a font
must be available that includes Japanese characters.
Usually, the operating system makes fonts available. Whether the
operating system is DOS, Windows, OS/2, or Motif is not important
at the conceptual level. What is important is that the character
exists and can be displayed. In the U.S. and most European
countries this is not a problem. The standard ASCII character
set, and its many variants, supported by popular operating
systems, generally includes enough characters to support
translation into Latin derived languages. However, non-Latin
languages such as Asian and Middle-Eastern languages pose
difficulties.
Fortunately, most of today's major operating system vendors are
working to support non-Latin languages. Almost all operating
systems are now available in Japanese, with Microsoft Windows now
available in over 20 languages including Japanese, Chinese,
Korean, Hebrew, and Arabic. For translators, this means that
operating system fonts may now display most international
characters. While all of this is promising, many problems still
exist. Each language version of the same operating system may
pose specific difficulties, and not all operating systems contain
the fonts necessary to support all languages. Current operating
systems contain little support for displaying multiple languages
simultaneously. And support is limited for difficult-to-render
languages like Arabic, which has multiple visual presentations
for the same character code.
Zinc addresses rendering issues by asking the native OS to
display characters, avoiding hassles for the programmer.
Zinc Application Framework addresses rendering issues by asking
the native operating system to display characters whenever
possible. This design benefits the programmer by avoiding
hassles connected with supplying fonts, display algorithms, and
the associated overhead. When the operating systems does not
supply a needed font, another font must be provided. For this
situation, Zinc ships a Unicode font for DOS graphics with its
DOS platform support module, other platforms supply their own
fonts. Zinc's Unicode font currently supports Latin languages,
Cyrillic, Japanese, Simplified Chinese, Chinese Traditional, and
Korean. Zinc's Unicode font profits the programmer by displaying
multiple languages on the screen simultaneously.
Input Methods
The flip side of rendering is the input method. An input method
is the means whereby an application user, or localizer, types
characters.
Obviously, Arabic and Japanese users have a totally different
input method for entering their native languages into the
computer. Right to left (Middle East) editing, multiple
keystroke character entry (Asia), and the combination of keyboard
and mouse character entry are good examples of input method
complexities often overlooked by American and European
application programmers.
Each input method requires a different approach. Asian versions
of Windows, for example, use the mouse, or a keystroke
combination, to toggle different input method modes, while
composing characters in the actual field being edited. The
visual effect is unexpected to a programmer not exposed to the
method. Additionally, when using DOS/V to support an Asian
language, the "Alt" key is used to access an input method on the
last line on the screen. The "last line" input method is used to
compose characters which are then transferred into the current
field using "Enter." Clearly, supporting multiple input methods
within a single set of source code can be difficult and
expensive, and isn't generally practical.
Zinc Application Framework eliminates programming of input
methods. Zinc Application Framework operates as a thin layer on
top of the native operating system. Therefore, Zinc supports the
input methods native to each operating system, and Zinc does so on
all currently supported international operating systems including
DOS/V, Windows J, Chinese Windows, and Korean Windows. Using
Zinc, then, the programmer gains support for international input
methods without needing to worry about them.
Each new version of Zinc Application Framework is tested on
multinational hardware and various language-dependent operating
systems. Input method issues are resolved as Zinc adds support
for additional languages to the product so that the application
programmer does not need to anticipate them. In fact, on the DOS
platform, Zinc provides a graphical Unicode table which can enter
any Unicode character into an application. With this tool, the
programmer can translate application text into any language
without the need for a foreign language operating system or input
method.
Character Mapping
Different operating systems often use different internal
character representations, Unix frequently uses a character
representation known as "EUC," while Japanese Windows uses
"Shift-JIS" and Macintosh uses "WorldScript", which creates
obvious difficulties for developers concerned with cross-platform
issues as well as internationalization. Unfortunately, the same
problems confront single-platform developers, too. Different
language versions of the same operating system may also use
different internal character representations, Windows offers a
good example. Without the use of an internationalization tool,
the Japanese Windows version of an application will not run on
Chinese Windows, neither version will run on English Windows, and
all versions of an application must treat character mapping
differently.
For the programmer, this poses a great challenge. Ideally, a
single character representation supporting all languages would be
the most generally applicable at translation time. Since each
operating system and language combination supports different
character representations, this is usually not possible. The
difficulty lies in designing and coding conversion tables to
change an application's internal character representation into
the representation used by an operating systemespecially since
this may need to be done differently for each operating system!
Anticipating this problem, Zinc provides an architectural
solution and implementation. When using the double-byte Unicode
enabled version of Zinc Application Framework, all characters are
stored internally as Unicode characters. Zinc applications
automatically identify the character set used by each operating
system and convert the internal representation appropriately at
run time. Every time a character is displayed, Zinc maps, or
converts, its internal Unicode representation to the
corresponding operating system representation. The reverse
process occurs whenever a user enters a character. This is
accomplished through the use of character mapping tables that may
be modified, replaced, or extended by the programmer to support
any operating system. Note: Zinc can also perform this mapping
function for 8 bit ISO8859-1 characters thereby freeing Zinc
applications from any language dependency whatsoever. Unlike
almost all other development tools, Zinc does not assume English
as the language of origin.
The great advantage of this design is that it allows Zinc to
support all languages, and all operating systems, without source
code changes and even without recompiling in the case of the same
operating system family.
Collation Sequences
Collation, or sorting of different languages, is another complex
yet often overlooked internationalization issue as each
individual language sorts itself uniquely.
U.S. programmers generally think of text sorting as a simple
table-based algorithm. This is not the case in most countries
and in most languages. Even in the U.S., telephone directories
often sort last names such as "Macfarlane" (all one word) and
"Mac Farlane" (two words) together rather than placing the
version with the embedded space before the name "Macallister," as
a simple table-based sort might suggest.
Outside the U.S. the complexity increases. In Spanish, the
letter combinations "ll," "rr," and "ch" have been considered as
individual characters for the purposes of sorting, while treated
separately for the purposes of storing and rendering. In Asian
languages the difficulties escalate dramatically. Characters,
syllables, and proper names may all create different sorting
complications, and often the national standards themselves are
unclear.
Zinc provides an elegant architectural solution to resolve
collation problems. For each language, the application uses both
a collation sequence table and a language-specific collation
algorithm to perform sorts. Zinc supplies these tables and
algorithms for many common languages, the number increases
continually, and documents them rigorously so that application
programmers may easily add support for additional languages.
Zinc also supports compiler collation algorithms and the major
emerging standard for Unicode collation.
Hardware Support
When writing an application for international distribution, the
programmer must realize that different hardware platforms and
operating systems dominate the computing landscape of each
locale. Nonstandard hardware, by U.S. and European perception,
is the norm in Japan, for example. In Europe, keyboard layouts
vary subtly in order to support the unique input needs of
individual locales. Due to the huge number of possible
combinations and the inaccessibility of translated documentation
it is prohibitively expensive for all but the largest commercial
software vendors to test their applications in all settings.
Zinc handles international hardware support, so the programmer
doesn't have to.
Zinc Application Framework mitigates the costly requirements for
internationalization. Zinc maintains relationships with many
international hardware manufacturers and operating system
developers, relationships which allow Zinc to design and test
hardware support for platforms that the programmer may never
consider. For example, Zinc supports popular Japanese hardware
such as the NEC PC-9800 series, a hardware platform incompatible
with standard U.S. hardware. Any Zinc application will run
without modification on this platform, thereby eliminating the
programmer's need to devote scarce resources to
internationalization.
Internal Representation and Portability
The internal representation of characters is the most critical of
all issues in dealing with internationalization. In order to
support all language versions and operating system versions of a
product with a single set of source code, it is necessary to have
a single standard character representation.
Unicode support is vital to completely globalize an application.
Without a unified character standard, moving data files from one
platform to another is difficult. A good example of this
difficulty might be moving files for Windows-J Shift-JIS format,
to Unix which uses the EUC format. Even though both files
contain Japanese language characters, both are incompatible due
to their character representation and must be mapped to a new
code table before use.
Recognizing the incompatibilities of different character
standards, Zinc makes internationalization easier with support
for the only broadly accepted standard for multilingual character
representationUnicode. Unicode (ISO10646), which will be
discussed in greater detail in the next section, is a single
table of 2^16 (or 65,536) members containing the fundamental
characters of written languages worldwide.
The advantages to this architecture are numerous enough to
warrant detailed attention. It is enough here to note that
Unicode support is vital to completely globalize an application.
Unicode allows a single source code strategy and general
operating system independence, which cannot be addressed
adequately in any other implementation.
THE UNICODE STANDARD
Any internationalization discussion would be incomplete without
discussing Unicode. To provide truly international language
support, a program must be capable of using the Unicode character
set. (A complete description of the Unicode standard can be
found in The Unicode Standard, published by The Unicode
Consortium. They can be contacted at Unicode, Inc., 1965
Charleston Road, Mountain View, CA 94043, at phone number
1-415-961-4189, or e-mail address unicode-inc@unicode.org.)
In 1984, the International Organization for Standardization (ISO)
started work on a worldwide character set. ISO published a
report in 1991 called the Draft International Standard (DIS) that
described the work pertaining to the ISO10646 standard which
described the universal character set. This standard was
rejected when voted on, however, because another group was
completing a standard called Unicode and there was concern that
two competing standards would further complicate the issue.
Thus, ISO and the Unicode Consortium, a nonprofit organization
created to develop and maintain the Unicode standard, joined
forces and co-developed a standard. Unicode was modified to be
compatible with the 16-bit specifications of ISO10646, ISO10646
also defines a 32-bit standard, but also extends the specification
somewhat.
The Unicode standard provides a comprehensive character set and
sets rules for its use. Currently, the character set contains
definitions for more than 30,000 characters. The character set
is organized as a table of 16-bit values and thus is capable of
representing 65,536 characters. The characters represented in
the Unicode character set include alphabetic, syllabic, and
ideographic characters as well as many mathematical and
scientific symbols and dingbats, etc.
Clearly, Unicode takes internationalization to a higher level by
providing a standard character set from which a program can
obtain character definitions for any of thousands of characters.
The Unicode character set contains character definitions for most
written characters in most languages, and expansion room for
more. The Unicode character set also provides information on how
characters should be arranged such as the placement of characters
in some languages, such as Thai, that depend on the context of
surrounding characters.
Because Zinc Application Framework supports Unicode, Zinc
applications support languages that use a double-byte character
set (DBCS) as well as more familiar languages, and all with one
set of source code.
INTERNATIONALIZING AN APPLICATION
Internationalization is a two step process: enabling and
localization. In the enabling phase the programmer adds support
for multiple languages and locales at the code level. During the
localization phase the application get translated, preferably
without recompiling the source code.
Enabling
Enabling a program means to create the program in such a way that
it can be easily ported to any locale, where a locale is a
distinct set of cultural language assumptions usually determined
by country or geographical area. This is the first, and most
important, step in internationalization. Typically, a program is
not enabled unless the program can be localized without
recompiling the source code. This implies run time detection of
locale. This also means that any hardware dependencies can be
resolved at run time. For example, most Japanese computers are
non-ISA compatible and must use different device drivers;
therefore an enabled application will detect these differences
and configure itself at run time.
Zinc Application Framework itself is enabled, so applications
created with Zinc are also automatically enabled. All text used
by a Zinc application can be stored externally and accessed at
run time and all editable fields know the presentation rules for
many locales. For example, Zinc's numerical objects will, when
formatted as currency, display the appropriate currency symbol
for any supported locale. The Zinc date object is similarly
robust, reordering and separating dates in a format relevant to
the locale. Also, Zinc provides run-time loadable device drivers
for non-IBM compatible hardware configurations, including major
Japanese hardware platforms.
Localization
Localization is the process whereby a program is adapted to use
data formats appropriate for a particular locale. This means
that the program formats date, time, currency, and number fields,
and displays text in a manner consistent local practice. Using
one of the examples stated above, a currency-formatted Zinc
object might appear as $1,234.50 in the U.S., while appearing as
F1.234,50 in the Netherlands.
Zinc Application Framework determines the locale at run time and
appropriately adjust the operation of objects to provide proper
formatting. The application user could even change the default
language while the application is running! Library text can
either be bound to the program at link time or at run time by
shipping the provided data file or files.
ZINC APPLICATION FRAMEWORK
As we discussed previously, Zinc applications are enabled for
internationalization, which means that any application developed
with Zinc Application Framework is automatically aware of
country-dependent differences, such as number formatting.
Additionally, all Zinc library strings, including error messages,
default help, and other embedded strings, are pretranslated into
14 different languages and 20 locales.
Because Zinc has done the enabling work already, globalizing an
application consists mostly of translating the application text.
Without Zinc, however, the programmer's coding decisions can
cause text translation to be extremely burdensome. If strings
are embedded in the source code, translation is usually difficult
since finding the strings and encoding them with double-byte
in-line values can be frustrating, and text translation is the
easy part! Zinc offers a much better way.
Zinc Designer, Zinc's interactive interface builder
application, included at no additional cost with all of Zinc's
platform keys, makes translation easy. Using Zinc Designer, the
programmer interactively defines the windows, dialogs, menus,
help screens, and other visual components of an application.
This information is stored in a binary .DAT file which contains
complete definitions of all objects used by the application, as
well as any resources such as bitmaps, icons, text, etc. The
internationalization programmer finds that Zinc's string
isolation and true object persistence makes his task easier.
Zinc's string isolation allows the translator to use Zinc
Designer to translate all text in the application in an
interactive and contextually accurate way. All that is required
is to select each interface element (menu, window, button, etc.)
by clicking on it, and then translate its text contents in a
pop-up object editor. The benefit is tremendous: a programmer
can write an application in his native language using Zinc
Application Framework and Zinc Designer without worrying about
the translation aspect of the program. Later, after the
application is compiled and linked into a working executable
program, the translator can use Zinc Designer to translate the
strings and save the edited data to a Zinc delta file. At run
time, the application can then automatically select the
appropriate language for the user (depending on the country
code), or the user can manually select the language.
Using Zinc Designer, a translator can resize and reposition
interface objects without causing the programmer to recompile.
However, Zinc's object persistence technology allows more than
simple string translation. During string translation, sizing and
positioning issues often become important. For example, a four
character Japanese input prompt may expand to 20 characters in
French. This expansion (or contraction) makes the original
interface look wrong in the new language. Using Zinc Designer,
the translator can resize or reposition interface objects without
causing the programmer to recompile. At runtime, a Zinc
application can read the object definitions contained in the
persistent object file and instantiate the objects in the proper
sizes and positions.
Zinc's technical advantages bring numerous benefits to
internationalization:
- Single set of source code for all languages and all
platforms
- Single executable for all languages within the same platform
- String isolation and localization tools for rapid
translation
- Interactive interface builder for easy "fine tuning" of
multilingual GUIs
- Existing Zinc applications can be recompiled for
international support
- Support for both 8-bit (ISO8859-1) and 16-bit (Unicode)
internal storage
- Support for international hardware platforms like PC-9800,
Fujitsu, etc.
- Unique language independence allows original development in
any language and locale
- Library strings (help and error messages) are pre-translated
to 14 languages and 20 locales
- Logically extensible Internationalization architecture and
specific language support
ZINC UNICODE INTERNALS
An application using Zinc Application Framework may or may not
support Unicode. Although all traditional 8-bit characters are
included as 16-bit entries in the table, thereby allowing all
languages in Unicode mode, because Unicode uses a 16-bit
character set and normal operation uses an 8-bit (ISO-8859-1)
character set, the two modes cannot be mixed in a single
executable. Supporting Unicode in an application allows the use
of double-byte languages with that application. If only
single-byte languages will be used, Unicode may not be
necessary, but the application can not be fully globalized.
To make use of the Unicode character set using Zinc, the
programmer must do two things. First, compile the library for
Unicode. This is accomplished by purchasing the Zinc Unicode
key, a software module, and defining ZIL_UNICODE (#DEFINE
ZIL_UNICODE) when rebuilding the base library for all Zinc
operating system platforms. This changes the internal character
representation of Zinc Application Framework from 8 bit ISO8859-1
to Unicode, and overloads all string functions found in Zinc and
in most compiler libraries, including strcmp, strcpy, strcoll,
etc.
Second, the programmer must build the application for Unicode.
This is also accomplished by defining ZIL_UNICODE when building
the application. If the programmer uses Unicode characters, he
must take special care to create and use 16-bit strings by using
Zinc's ZIL_ICHAR type and the overloaded ANSI Ctype, string, and
file functions provided with Zinc's UI_INTERNATIONAL class, which
is the base class for internationalization in Zinc Application
Framework. This class maintains localization information, such
as the currency symbol, and also provides many replacement
functions for the ANSI Ctype, string, and file functions. These
functions must be overloaded to support Unicode 16-bit
characters.
All windows objects in the library are derived from Zinc's
UI_INTERNATIONAL base class through UI_WINDOW_OBJECT, thus
giving the objects access to these overloaded functions through
inheritance. Because of this, accessing the overloaded ANSI
functions from within a member function is transparent; by
calling strdup(), for instance, you get the Zinc-overloaded
strdup(). In addition, all these overloaded ANSI functions are
static members and most are public, so the functions can be
accessed globally as well. This portability, then, comes with no
extra effort to the programmer.
Each environment uses its own character set, Shift-JIS for
Japanese characters, Big Five for Chinese characters, ASCII for
Latin characters. But in Unicode mode, the underlying operations
of Zinc translate all characters to and from the Unicode
character set to provide consistency across environments. All
processing in Zinc will use Unicode characters when in Unicode
mode. Zinc provides several functions that are used to map
characters between the hardware character sets and the Unicode
character set.
In short, by following Zinc's documented coding conventions, and,
of course, using Zinc's Unicode module, supporting Unicode is as
simple as remaking Zinc's libraries and recompiling the
application. With this process completed, the resulting
application can support any characters that the user can enter,
display or store, in any language.
Actually, we can't convey the tremendous revenue opportunity Zinc
Application Framework offers to software developers any better
than Peter Coffee of PC Week:
PC WEEK, MARCH 28, 1994
Peter Coffee, "Soft Talk"
"The most remarkable thing in Zinc, which gives it the best
definition of `multiplatform,' is its support for
internationalization. Unlike some implementations of the Unicode
standard for multi-byte characters, Zinc's is not a simple
mapping that applies to the entire screen: This means Zinc-based
applications can display Chinese, Korean, and Hebrew characters
at the same time in a single display. Yes, under DOS as well as
in GUI environments [provided that fonts are present.]
This is the most overlooked opportunity for revenue growth if
you're a developer, or for adding value to in-house and customer
interface applications if you're in the corporate sector.
It's not the chance to offer users the option of running your
code on machines with trivial market share, which is what
Microsoft and XVT are touting. It's the chance to offer your
software to nonEnglish speakers, running on the low-cost
platforms that dominate desktops outside the United States.
A lot of the world doesn't speak `File' and `Edit.' Sell to
these users."
Software Globalization Using Zinc Application Framework and
Unicode
Copyright (c) 1994 Zinc Software Incorporated.
All Rights Reserved.
Zinc is a registered trademark and Zinc Application Framework and
Zinc Designer are trademarks of Zinc Software Incorporated. All
other trademarks and tradenames used herein are owned by their
respective companies.
No part of this publication may be reproduced, stored in a
retrieval system, or transmitted in any form or by any means,
without the prior written permission of Zinc Software
Incorporated.
Zinc Software Incorporated
405 South 100 East, 2nd Floor
Pleasant Grove, Utah 84062
Tel +1 801 785 8900 or +1 800 638 8665
Fax +1 801 785 8996
BBS +1 801 785 8997
Email info@zinc.com
CompuServe GO ZINC
Zinc Software (UK) Limited
106-108 Powis Street
London, SE18 6LU
United Kingdom
Tel +44 (0)181 855 9918
Fax +44 (0)181 316 7778
BBS +44 (0)181 317 2310
Zinc Software (Japan)
1-10-26 Nakata Chikusaku
Nagoya, Japan 464
Tel +81 (052) 733 4301
Fax +81 (052) 733 4328
BBS +81 (052) 733 4359
--$----Novell--Attachment----$
X-NVL-Content-Type: TEXT
X-NVL-Content-Typename: Text
X-NVL-Content-Charset: X-IBM-437
X-NVL-Content-Filename: WHTPMP.TXT
X-NVL-Content-Modification-Date: 27-Sep-1994 09:55:54 +0000
Multiplatform
Development Using
Zinc Application Framework
A Zinc White Paper
The ability to write an application that supports more than one
operating system or hardware platform is essential as operating
systems continue to compete for market share. A multiplatform
marketplace provides new opportunities for growth, and many
companies are taking advantage of this potential. Especially
appealing is the prospect of existing applications gaining market
share in all operating system environments.
Unfortunately, porting an application to multiple platforms is
non-trivial. Many issues need attention beyond simply
recompiling the application. For example, hardware resources
vary significantly between platforms, compilers may be
incompatible or unavailable, and user expectations may change, to
name just a few.
In the past, the most common method for porting an application
between platforms has been to retrofit the application, literally
redesigning and rebuilding it. This is expensive, often costing
as much as the original development and resulting in new sets of
source code to support and maintain. Needless to say, developers
have been looking for a better method for supporting multiple
platforms.
Zinc Application Framework is the better way. With Zinc's
multiplatform architecture, Zinc provides the ability to support
most popular hardware and operating system platforms, including
international and vertical market platforms, making porting
easier than ever before. By using Zinc Application Framework,
you bring the porting process back towards the realm of simply
recompiling the application.
COMPLEX ISSUES
Before discussing Zinc's multiplatform strategy in detail,
gaining an understanding of multiplatform graphical user
interface issues is helpful
Look and Feel Standards
End users demand that the overall look and feel of their
applications be consistent with other applications on the same
platform. While reasonable, this requirement poses difficult
problems for multiplatform developers. An application running in
Microsoft Windows, for example, may support Multiple Document
Interface (MDI) in order to satisfy the desires of Windows users.
However, users of the same application running on Macintosh might
not want this feature since other Macintosh applications don't
use it-, -the Macintosh API does not include support for MDI.
In fact, end users rigorously defend the merits of their
operating system's native graphical user interface (GUI).
Cross-platform developers have learned this fact through hard
experience. For instance, Zinc once displayed support for
Macintosh by running a beta version of Zinc's demonstration
program for the Macintosh and was surprised at vocal criticisms
evoked by enhancements to the native Macintosh interface. Zinc
applications running on Macintosh can display buttons with 3-D
sculpting-, -similar to Windows, OS/2 or Motif buttons, and can
display context sensitive help in a more general way than native
Macintosh balloon help. Offended Macintosh users condemned
efforts to enhance their interface, instead insisting on native
"flat" buttons and balloon help, supported by Zinc but not
displayed in the demonstration. Clearly, while user interface
enhancements are often desirable, platform independent graphical
user interfaces (PIGUIs) must be capable of faithfully meeting
the expectations of native GUI users.
Emotional issues cross all platforms when discussing the merits
of individual GUIs. Motif does not support child windows;
NEXTSTEP omits horizontal lists; OS/2 users demand extreme
flexibility with fonts and colors; Macintosh users require
multiple option menus; and DOS users want the best of
everything, in graphics, and at high speed. Unfortunately,
these examples barely scratch the surface of platform independent
GUI issues.
Any cross platform GUI development tool must address these
complex problems in some way. Common approaches fall into two
basic categories. Single GUI emulation defines one end of the
look-and-feel spectrum, least common denominator GUI marks the
other end.
Single GUI emulator products provide a consistent interface
across all platforms. This means that a feature such as MDI
operates exactly the same on all platforms from Windows to
Macintosh to Motif, even though MDI functionality is not
normally defined, or even desired, on all platforms. Taken to
extremes, emulator GUIs may even look identical on all platforms.
While this alienates some users, it simplifies the programmer's
job by ensuring consistent operation in all environments.
Least common denominator GUIs approach the problem from another
direction. With this type of product, MDI is not even a legal
feature to include in a multiplatform user application since it
is not directly supported on all platforms. Combo boxes,
horizontal lists, child windows, bitmapped buttons, tool bars and
many other features are similarly illegal for use in a
multiplatform application if the least common denominator
approach is followed. Least common denominator products avoid
alienating users by ensuring that no unusual interface objects or
behaviors are ever presented, thereby simplifying the
programmer's choices.
Clearly, products at either end of the look and feel spectrum
disappoint programmers, and users, with their limitations.
Most platform independent GUI products make a stand by
compromising on look and feel issues.
Zinc works to avoid this compromise, delivering the best of both
worlds wherever possible. Zinc Application Framework supports
robust objects and architectures, including difficult concepts
like MDI, by implementing them in a way that feels native to
users on each individual platform. Zinc does not shy away from
implementing features natively supported on only one system.
Programmers can choose to utilize objects such as notebook,
slider, and spin control, native only to OS/2 or Windows, on
any or all platforms. By including a superset of native platform
objects, Zinc avoids the least common denominator pitfall.
Respecting the desires of native users, Zinc also avoids
emulation compromises. Zinc programmers benefit from a fully
multiplatform, yet automatically native-GUI-adapting development
tool that crosses platform barriers without crossing users.
Layered vs. Emulation Implementations
Designing platform independent GUI tools requires difficult
decisions about architecture and implementation. Perhaps the
most difficult architectural question concerns the interface to
operating systems. Since every platform implies a different
operating system, and thereby a different way of handling every
user interface object, GUI architects debate the merits of
either working with (layering on top of) or around (emulating)
the operating system's native GUI. Advocates of both religions
argue convincingly.
Emulation based products avoid the use of standard operating
system GUI (OSGUI) application programming interfaces (APIs).
Generally, an emulation based GUI will use proprietary or low
level system calls to render, or display, the GUI and interact
with the user. Emulators in Microsoft Windows, for example,
usually access low-level graphics (Windows GDI layer) primitives
directly and bypass the Window Manager, the OSGUI in this case.
Proponents of these products contend that the OSGUI is an
unnecessary layer of code. Since the OSGUI API contains support
for many functions, a smaller and better layer can be written to
avoid the standard API. Furthermore, OSGUIs sometimes feel slow
and working around them could improve performance. As anyone who
has worked with OSGUIs can attest, emulation arguments sound
logical, OSGUI APIs are large and can seem slow at times.
The emulation technique brings another advantage as well. If the
operating system GUI is bypassed, any look and feel can be
presented on any operating system. An application might look and
feel like OSF/Motif while running on Microsoft Windows, for
example. The programmer thereby benefits from look and feel
independence and flexibility.
On the other hand, layered API products use the native operating
system APIs whenever possible. Proponents maintain that strict
compliance with OSGUI APIs ensures compatibility. Future
upgrades to the operating system could make emulation products
incompatible or at least visually inconsistent. Strict operating
system compliance also allows less complicated interprocess
communication and multitasking, and provides programmers with
easy access to the native API.
Moreover, advocates of layering take issue with many emulation
arguments. Operating system GUIs benefit from massive
optimization and testing efforts and are thereby efficient and
stable. Furthermore, if an emulator is used to write an
application the emulation code, which is huge, must be distributed
with the application thereby increasing executable size and
complexity. Why write, or worse, distribute, an emulation to
an OSGUI when one already exists in the operating system? Also,
since emulators mimic the actual look and feel of native GUIs
they can never be totally identical to the look and feel of the
real thing. And imagine the effort involved in updating the look
and feel to be compatible with a major operating system update
like Microsoft's Chicago! Finally, many programmers, and most
users, cannot imagine wanting an OS/2 look and feel on
Macintosh, or any other nonstandard combination. A layered
implementation provides the only platform independent GUI
architecture that can ensure total compatibility with other
native applications, easy access to the OSGUI API, and a look and
feel faithful to the native GUI.
Zinc Application Framework uses a layered architecture. When
running on Microsoft windows, a Zinc application asks Windows to
draw interface objects whenever possible, thereby ensuring that
each object is rendered exactly the same as in every other
Windows application. In short, when running on Windows, a Zinc
application is a native Windows application. When running on
OS/2, or Macintosh, or OSF/Motif a Zinc application is a native
application to each individual operating system. Not all
interface issues can be handled entirely by the operating system,
however. Non-native GUI objects, such as combo boxes on Motif,
and all objects in DOS, must be emulated by Zinc. When
necessary, Zinc renders these objects, and handles their
interface, in a compatible and optimized way, using the OSGUI
whenever possible. The programmer benefits from a superset
approach to multiplatform GUI without forfeiting compatibility,
performance, or strict adherence to operating system standards.
Developer Preferences
Just as users are vocal in support of their favorite operating
systems, developers also have favorites. With development
experience in a particular platform environment comes comfort and
habit. Each individual operating system and GUI API approaches
the same user interface issues differently, and programmers
develop distinct preferences. Platform independent GUIs, like
Zinc Application Framework, must provide an API which balances
developers' desire for familiarity with multiplatform technology
requirements.
One difference between platform development environments concerns
their approach to event processing. On some platforms
user-defined events trigger user functions. In these message
based systems, user functions don't get called directly by
interface objects themselves. Other platforms take the opposite
approach by utilizing callback functions to perform all
application work. Proponents of both methods make convincing
arguments. Zinc handles this issue deftly by allowing
programmers to use either method, or both, in Zinc-based
applications.
Compilers and code editors represent additional important
developer preferences. Zinc attempts to free the developer from
undue constraints regarding the use of familiar development
tools. Most popular compilers are supported on each platform,
and make files are provided. Likewise, developers may use their
favorite program editor when developing with Zinc Application
Framework.
Multiplatform developers need this degree of flexibility since
they often venture into uncharted territory when porting to a new
platform. Zinc understands that productivity tools like Zinc
Application Framework cease to be productive if they inhibit the
developer's natural skills.
Clearly, Zinc Application Framework offers flexibility in
developer technique and approach. And because Zinc is an object
oriented class library, with complete source code included at no
extra charge, extending it with customizations and additions is
straightforward. Programmers benefit from Zinc's power without
rigidity.
GUI Portability Issues
Portability defines the multiplatform development tool category.
It seems obvious that without complete portability, a
multiplatform tool could not claim to provide a portable
solution. Unfortunately, this is not the case.
Each OSGUI provides a unique feature set. Windows provides
object linking and embedding (OLE) and dynamic data exchange
(DDE) for example, while OS/2 includes system object model (SOM)
and container classes, and Motif provides geometry management, to
name just a few. Each feature beckons to the programmer with
compelling arguments. However, inclusion of platform specific
features in a multiplatform application usually results in
nonportable code.
Platform independent GUIs must take a stand on platform specific
features. Usually this stand takes one of three forms:
1. Support platform specific features in a nonportable way;
2. Emulate platform specific features across platforms; or
3. Avoid platform specific features altogether.
Most development tools choose the first, non-portable, position.
Zinc's philosophy emphasizes portability. To achieve this goal,
Zinc Application Framework combines approaches 2 and 3, emulation
and avoidance.
Zinc takes a portability-first stand. Zinc analyzes platform
specific features to determine technical advantages, then designs
a platform independent implementation to encapsulate platform
specific functionality. Customer requests determine which
platform specific features are chosen for this treatment, MDI has
been ported to all platforms, for example. Zinc Application
Framework does not directly support any feature that cannot be
ported to all platforms, OLE is a good example, but does allow
developers to implement them if desired. This architecture and
philosophy benefits the programmer by providing a superset of
native platform features without constraining creativity or
portability.
Another common roadblock to complete portability concerns
dependency on underlying APIs. Platform independent graphical
user interfaces (PIGUIs) often exhibit a tendency to favor one
operating system or another depending on the tool's roots, its
original development platform. Products initially developed for
Windows, for example, may needlessly bind themselves to the
Windows API. While this dependency poses a greater challenge to
the tool's developer, it makes the tool difficult to port, than to
the tool's user, it also causes problems for programmers. Tools
with API dependency often require third-party ported APIs, and
incur their associated overhead, to achieve portability. The
portability, then, doesn't really come from the high-level tool
but from the unseen third party API port underneath.
Furthermore, these tools may "feel" too much like a specific
platform API, thereby alienating programmers from other platforms.
Zinc has carefully chosen a strategy to avoid API dependency. In
Zinc Application Framework a thin code layer (see layered vs.
emulation section above) binds Zinc's high level API to the OSGUI
API. When no OSGUI exists, DOS is a good example, Zinc directly
replaces the OSGUI functionality rather than incorporating a
third-party OSGUI emulation. Programmers enjoy a completely
independent, high level API that "feels" open and portable while
free from the overhead of third-party products.
ZINC APPLICATION FRAMEWORK
Zinc Application Framework is an object oriented, multiplatform,
internationalized class library for the rapid development of
portable user interfaces. Optimized for size and speed, Zinc
provides a level of productivity not found in other tools.
Object Orientation
Object orientation offers tremendous productivity improvements
over traditional programming paradigms. Time to market and code
size decrease significantly using object oriented techniques,
while code extensibility and re-usability expand.
Zinc Application Framework's C++ code base stands out as an
example of object oriented benefits. A small 95,000 lines of
code in Zinc, the total for all platforms combined, attests to the
power of object oriented programming (OOP). Zinc's competitors
often boast of code sizes two to twenty times larger while
providing similar functionality.
Clearly, OOP techniques give Zinc an edge when extending and
debugging code, but these benefits reach to programmers as well.
Zinc uses fundamental OOP techniques such as inheritance,
multiple inheritance, and polymorphism to provide massive code
reusability. Programmers developing with Zinc can code
extensions and enhancements by deriving from Zinc's existing
objects, thereby eliminating significant coding and debugging
time. This approach contrasts sharply with the use of
traditional, C based tools that require bottom-up coding to
support new functionality. Caution must be exercised when
selecting an object oriented tool since, under pressure from
users, many old C based tools have encapsulated their code into a
C++ wrapper. This approach allows limited access to OOP
techniques but adds an additional code layer while providing less
flexibility than true OOP tools.
Zinc's use of OOP in Zinc Application Framework offers much to
developers. High extensibility, small code size, simplified
programming, and leading edge technology benefit the programmer
through greater productivity.
Multiplatform Support
Zinc Application Framework supports most popular operating
systems including DOS in text and graphic modes, Windows, Win16,
Win32 (NT), Win32s and Win32c (Chicago), OS/2, Macintosh and
Power Mac, OSF/Motif running on ten platforms, UNIX text mode
using Curses, and NEXTSTEP. Support for additional platforms
emerges regularly from Zinc's prolific multiplatform developers
who are currently working on even more new platforms. Today,
Zinc Application Framework provides the broadest multiplatform
support available anywhere, and Zinc's leadership continues to
expand.
But the most important and impressive aspect of Zinc's
multiplatform support is not the long list of platforms, other
companies may create similar lists. Portability is the key.
Simply recompiling the source code to a Zinc application ports
the application to any supported platform, providing of course
that proper Zinc coding conventions are followed. When ported,
Zinc applications alter their behavior subtly to provide a native
look and feel to any user on any platform. On the DOS
platform, DOS lacks a native look and feel, Zinc allows the
programmer to select an appropriate look and feel from a list
including Windows, OS/2, Motif, and three different text mode
interfaces. Users praise Zinc applications for their familiarity
and robustness while programmers praise Zinc's rapid
multiplatform development environment and freedom from platform
dependencies, and marketers love new multiplatform opportunities
provided by Zinc Application Framework.
Internationalization
In today's global marketplace, portability no longer refers
exclusively to multiplatform support. International markets
provide another source of new revenue opportunity. Recognizing
this as a critical opportunity, Zinc provides programmers with
rapid internationalization support built into Zinc Application
Framework. Any application built with Zinc is automatically
architecturally enabled for international markets.
Zinc Application Framework supports both 8 bit (ISO8859-1)
characters, like standard ASCII and European characters, and, with
Zinc's optional Unicode support module, 16 bit Unicode
characters. In essence, this means that Zinc applications can
support any written language. Porting to another language can be
difficult with some tools, even tools with internationalization
support, if the tool lacks rapid porting functionality.
Zinc Application Framework includes a high level of support for
rapid internationalization. Zinc's visual programming component,
Zinc Designer, discussed in the next section, offers string
isolation, rapid translation, and no-code interface adjustments
for the international programmer or localization group. Zinc
enables programmers to develop an application in their native
language, and later translate the application to another
language, usually without the need to recompile! Zinc also
transparently handles locale dependent formatting such as date,
time, and currency formats. Zinc Application Framework provides
programmers with a worry free environment for international
programming.
(For detailed information about Zinc's handling of
internationalization issues, please refer to a separate white
paper entitled Software Globalization, Zinc Application Framework
and Unicode.)
Visual Programming
Zinc Application Framework includes a powerful, interactive, user
interface builder called Zinc Designer. Using Zinc Designer
frees programmers from the need to manually calculate screen
positions, initialize user interface objects, and maintain help
and resource files. Zinc Designer uses Zinc's industry leading
object persistence technology to virtually eliminate the need for
code generators and resource builders.
Developers interactively drag and drop user interface elements to
create a complete user interface in Zinc Designer. Zinc Designer
saves the work into a platform independent, persistent object
file that contains complete definitions and initialization
information for all interface elements. This persistent object
data file contrasts sharply with traditional resource files
because it contains "live objects", a term borrowed from visionary
Steven Jobs at NeXT, as opposed to the "dead objects" normally
found in standard resource files. Truly persistent "live
objects" exist entirely outside of source code, the technical
definition of persistent. At run-time, applications request user
interface elements from a Zinc data file and initialize
them, without knowing anything about the objects beforehand.
Object types, hooks to callback functions, help contexts,
validation ranges, initial object states, visual representations,
and other data are all read from the file in order to bring the
objects to life. The data file may also contain help text,
icons, bitmaps, or any other resource desired by the programmer.
Run-time initialization of a Zinc Designer data file allows
programmers to make no-code modifications and enhancements to the
user interface, including internationalization, thereby
streamlining the development process.
ZINC PORTING INTERNALS
A detailed description of how Zinc achieves portability would
fill volumes, but the basic concepts are simple. Zinc
Application Framework relies on an elegant, object oriented class
hierarchy that compartmentalizes the differences between
platforms in a manageable way, and then addresses those
differences internally. The resulting API hides platform
specifics and eliminates portability concerns.
In the context of Zinc Application Framework, differences between
platforms can be placed into two major categories, display
management and event management. Unfortunately, the following
discussion hugely oversimplifies the issues involved in porting
applications without a portability tool, but this cannot be
avoided.
Display management refers to the method used by each platform to
show user interface objects on the screen. To handle
differences, Zinc confines display issues to a handful of
locations within the class library. Zinc's UI_DISPLAY class
presents the most notable of these locations. UI_DISPLAY defines
classes which contain member functions for low-level graphics
primitives including line, rectangle, ellipse, polygon and
others. Each Zinc platform implements these primitives
differently, but provides identical API access to the application
programmer.
Individual objects can rely on these platform independent
primitives whenever it becomes necessary for them to draw
themselves. As discussed earlier, Zinc objects request operating
system GUI assistance whenever possible, registering with Windows
to draw radio buttons for example, but use the display class
graphics primitives to take over otherwise. In a list box,
Windows cannot display radio buttons so Zinc's button object must
know how to do this for itself. When necessary, Zinc objects
display themselves using a technique called owner draw, utilizing
their DrawItem() member function for this purpose. Platform
specific object drawing, necessary to ensure native look and feel
on each platform, remains isolated within this function where it
can easily be overloaded, or ignored, by application developers.
Similarly, Zinc's platform independent fonts and colors map to
corresponding native OS equivalents in static tables, fontTable[]
and palletteMapTable[], which differ between platforms, a detail
which is thankfully abstracted to the application programmer who
accesses fonts and colors without regard to platform specifics.
Event management poses the other major set of portability
hurdles. Again however, Zinc isolates the complexities to
internal members of Zinc Application Framework, thereby freeing
developers from portability concerns in their own code. To
accomplish this, each Zinc object contains an Event() member
function which compartmentalizes platform specific event handling
when necessary.
Most event handling differences disappear through the use of
Zinc's -event---Map-Table[] for each platform. This table
contains entries for native events on a platform, along with
corresponding Zinc logical events. By mapping native events to
logical events Zinc allows developers to use events in a platform
independent way. Furthermore, Zinc provides access to events
using both portable and platform specific methods to allow
maximum flexibility for programmers.
Finally, Zinc abstracts the platform specific handling of logical
events such as object creation and information access by
restricting platform specifics to discrete member
functions, RegisterObject(), DataSet() and DataGet(). Internal
implementation of these members differs between platforms but
application programmers enjoy identical access through the Zinc
API.
Effective use of object oriented design and a unique architecture
enable Zinc to attain true portability without compromising
programmer flexibility or control. A single set of application
source code can be recompiled on any supported platform to
produce an application with a native look and feel. At Zinc,
portability is more than marketing hype. Zinc Application
Framework opens a new world of opportunities to developers.
Multiplatform Development Using Zinc Application Framework
Copyright (c) 1994 Zinc Software Incorporated.
All Rights Reserved.
Zinc is a registered trademark and Zinc Application Framework and
Zinc Designer are trademarks of Zinc Software Incorporated. All
other trademarks and tradenames used herein are owned by their
respective companies.
No part of this publication may be reproduced, stored in a
retrieval system, or transmitted in any form or by any means,
without the prior written permission of Zinc Software
Incorporated.
Zinc Software Incorporated
405 South 100 East, 2nd Floor
Pleasant Grove, Utah 84062
Tel +1 801 785 8900 or +1 800 638 8665
Fax +1 801 785 8996
BBS +1 801 785 8997
Email info@zinc.com
CompuServe GO ZINC
Zinc Software (UK) Limited
106-108 Powis Street
London, SE18 6LU
United Kingdom
Tel +44 (0)181 855 9918
Fax +44 (0)181 316 7778
BBS +44 (0)181 317 2310
Zinc Software (Japan)
1-10-26 Nakata Chikusaku
Nagoya, Japan 464
Tel +81 (052) 733 4301
Fax +81 (052) 733 4328
BBS +81 (052) 733 4359
Zinc Software Incorporated
--$----Novell--Attachment----$--
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:30 EDT