Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

National Language Support Architecture

IP.com Disclosure Number: IPCOM000108540D
Original Publication Date: 1992-Jun-01
Included in the Prior Art Database: 2005-Mar-22
Document File: 2 page(s) / 93K

Publishing Venue

IBM

Related People

Reish, TG: AUTHOR [+2]

Abstract

All applications being developed within IBM must provide National Language Support (NLS) and Double-Byte Enablement (DBCS) to provide concurrent world-wide availability. As a result these applications are using string functions that try to support all character sets in all languages. These routines are by definition slower and provide more support than is needed in just the U.S., a Single-Byte or a Double-Byte environment. They are an inefficient fix-it-all for all languages. There needs to be a way to provide just the right amount of NLS string support for an environment independent of the application's knowledge.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

National Language Support Architecture

       All applications being developed within IBM must provide
National Language Support (NLS) and Double-Byte Enablement (DBCS) to
provide concurrent world-wide availability.  As a result these
applications are using string functions that try to support all
character sets in all languages. These routines are by definition
slower and provide more support than is needed in just the U.S., a
Single-Byte or a Double-Byte environment.  They are an inefficient
fix-it-all for all languages.  There needs to be a way to provide
just the right amount of NLS string support for an environment
independent of the application's knowledge.

      Current coding practice to provide NLS/DBCS support is to call
string routines that support all languages and all code sets.  This
entails a lot of unnecessary overhead for languages that do not need
this kind of support.  For example, why process English strings as if
they could contain double-byte characters?  It is inefficient to
treat a string as if it has double-byte characters when, in fact, it
never can.

      Another problem is when it is decided to market an application
in a language that was not planned for at development time.  This
change will require going into the application and possibly ripping
up large chunks of the code to provide the necessary support for the
new language.  A way to encapsulate and easily change the level of
NLS/DBCS support provided by the application is needed independent of
its knowledge.  This way new string routines or libraries could be
dropped in and the application will have no idea a change has
occurred.  It still calls the same string functions as before and
lets some other code worry about determining which function to call
for this system's language environment.

      This invention provides an architecture that provides only the
level of NLS/DBCS string support necessary to run an application in
the current system configuration.  It is also easily extendable
independent of the application's knowledge.

      What we will do is have an initialization routine that is
called once when the application is brought up.  This routine will go
to the system and determine what kind of language environment is
currently running.  The code will then initialize and array of
pointers to functions that will provide the most e...