United States Patent os
`Bramnicket al.
`
`[54]
`
`[75]
`
`NAMESPACE REGISTRY WITH
`BACKWARD COMPATIBILITY FOR OLDER
`APPLICATIONS
`
`Inventors: Arnold H. Bramnick, Boca Raton.
`Fla.; Douglas G. Elkins. Lawrenceville,
`Ga.
`
`[73]
`
`Assignee:
`
`International Business Machines
`Corporation, Armonk. N.Y.
`
`(21)
`
`[22]
`
`(51)
`
`[52]
`[58]
`
`[56]
`
`Appl. No,: 08/516,544
`
`Filed:
`
`Aug. 18, 1995
`
`Tint. Cho oececscssesscsesseeeee GO6F 15/163; GO6F 9/00,
`GO6F 9/46
`
`TS. C1. eeeseeccsesneeeneee
`.
`.. 395/680; 395/712
`Field of Search .........scccsssseceesseenes 395/680. 681.
`395/683. 712
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`.
`1/1992 Haff, Jr.
`5,083,262
`.
`3/1992 Burgeret al.
`5,097,533
`9/1993 Bachman et al. .
`5,249,300
`5,257,369 10/1993 Skeen et al.
`.
`5,261,080
`11/1993 Khoyi et al.
`.
`5,291,585
`3/1994 Sato et al. .
`5,297,279
`3/1994 Bannonet al.
`5,317,722
`5/1994 Evans .
`5,333,298
`7/1994 Bland etal. .
`
`.
`
`LL
`
`US005903753A
`(11) Patent Number:
`[45] Date of Patent:
`
`5,903,753
`May 11, 1999
`
`OTHER PUBLICATIONS
`
`Configuration Manage and Registry, Kyle Marsh. MicroSoft
`Developer Network Technology Group Jan. 3, 1994.
`Test Drive Win32 from 16-bit Code Using Window NT,
`James Finnegan, MicroSoft Journal Jun. 6, 1994,
`Load Your 32-bit DII into Another Process’s Address Space
`Using INJIB. Jeffrey Richter, MicroSoft Journal May 5.
`1994,
`
`Primary Examiner—Alvin E. Oberley
`Assistant Examiner—Peter Stecher
`Attorney, Agent, or Firm—Mark S. Walker;
`Musgrove; Andrew J. Dillon
`
`Jack V.
`
`[57]
`
`ABSTRACT
`
`A name space registry manages name space data within a
`computer operating system including configuration and ini-
`tialization data. The registry provides access to the configu-
`ration information by means of an application program
`interface (API) for programs which can operate with the
`name space registry. Backward source-code compatibility is
`provided for older applications by maintaining configuration
`andinitialization files that the older applications use to store
`configuration and initialization data under their traditional
`file names and with the traditional contents. Thus the older
`applications can directly access these files. The registry
`provides newer programsaccess to these configuration and
`initialization files through API program calls.
`
`17 Claims, 3 Drawing Sheets
`
`302
`
`304
`
`“aro*
`APPLICATION
`
`“NEW*
`APPLICATION
`
`306
`
`REGISTRY
`DATA
`ACCESS
`PROGRAMS
`308
`
`NAME SPACE AEGISTRY AP?
`
` PAOFILE
`
`FILES
`LATOR
`TRANS -
`
`DEFAULT
`PROVIDER
`SERVICE
`
`osy2
`SERVER
`
`320
`
`NAME SERVER API
`326
`
`328
`
`Q
`FILES
`
`REGISTRY
`SERVER
`
`ROOT
`SERVER
`NAME
`
`tara
`REGISTRY
`CONFIG.SYS
`
`AUTOEXEC. BAT] [STORAGE]|cro page
`
`344
`
`“336
`
`330
`
`Google Exhibit 1041
`Google v. VirtaMove
`
`Google Exhibit 1041
`Google v. VirtaMove
`
`

`

`U.S. Patent
`
`May 11, 1999
`
`Sheet 1 of 3
`
`3,903,753
`
`Srl
`
`G9Ot
`
`09}
`
`SS}
`
`NOILVIINNWWOO
`
`YITTOYLNOD
`
`YSTTOYLNOOD
`ASNOWCNV
`
`VA
`
`QUVOSAIy
`
`Vibl
`
`Lyh
`
`YITIOYLNOSD
`
`O3CIA
`
`HATIOYULNOOD
`
`SOL
`
`weseveregeseseaan
`
`9S}
`
`Oe}
`
`YITIOYLNOD
`WITIOYLNOO
`
`¥S10
`
`YITIOWLNOD
`
`Ort
`
`jli3aysia
`
`JALYG
`
`W3ALSAS
`
`Get
`
`Ob
`
`AYOWIW
`
`YITTOWLNOD
`
`0c}
`
`001
`
`Sth
`
`HITTONLNOS
`
`sng
`
`LdNdain!
`
`YSTTOYLNOO
`
`
`
`
`
`
`
`
`
`

`

`U.S. Patent
`
`May 11, 1999
`
`Sheet 2 of 3
`
`3,903,753
`
`"NEW"
`PROGRAMS
`
`PROGRAMS
`
`
`
`SERVICE
`PROVIDERS
`
`FILES
`
`REPOSITORIES
`CONFIGURATION
`AND
`INITIALIZATION
`
`Fig. 2
`
`

`

`U.S. Patent
`
`May 11, 1999
`
`Sheet 3 of 3
`
`5,903,753
`
`302
`
`304
`
`
`"OLD"
`APPLICATION
`
`APPLICATION
` NEW"
`
`
`
`
`
`
`Fig. 3
`
`306
`
`
`
`REGISTRY
`DATA
`ACCESS
`PROGRAMS
`
`308
`
`
`
`NAME SPACE REGISTRY API
`
`
`
`
`
`
`316
`
`DEFAULT
`SERVICE
`PROVIDER
`
`318
`
`OS/2
`SERVER
`
`NAME SERVER API
`
`326
`
`328
`
`REGISTRY
`SERVER
`
`
`AUTOEXEC.BAT
`
`
`
`
`REGISTRY
`
`STORAGE
`
`
`
`CONFIG.SYS
`
`334
`
`336
`
`330
`
`

`

`5,903,753
`
`1
`NAMESPACE REGISTRY WITH
`BACKWARD COMPATIBILITY FOR OLDER
`APPLICATIONS
`
`FIELD OF THE INVENTION
`
`The present invention relates to computer operating sys-
`tems and more particularly to mechanisms for maintaining
`system configuration data for configuring operating systems.
`BACKGROUND OF THE INVENTION
`
`A cconventional personal computer comprises a processor
`whose actions are controlled and coordinated by means of
`programs stored in main memory. For example, such pro-
`grams may consist of operating system programs and appli-
`cation programs. The main memory is typically “volatile”
`and requires external electrical power to maintain its storage
`capability so that the programs in the main memory are
`erased whenever the electrical power is turned off or the
`computer is “powered down”.
`The computer is generally provided with additional non-
`volatile mass storage. typically in the form of magnetic
`media such as a “hard”or “floppy” disks on which relatively
`permanent copies of the programs can be stored. When the
`computer is initially turned-on or “powered up”, or when an
`application program is loaded, some process or method must
`be used to both load the programs from the non-volatile
`mass storage into the volatile main memory and configure
`the programs to work with the hardware which comprises
`the computer.
`The phrase commonly used to denote the process of
`loading andinitializing both the operating system and the
`application programs is “bootstrapping” the computer or
`simply “booting” the computer or the application program.
`A boot process is a sequence of steps which are performed
`during the booting procedure. During the boot process.
`various set up parametersare usually determined by reading
`the contents of one or more “configuration”or “initializa-
`tion”files containing a list of selected programs,definitions
`and parameters which are used to initialize the operating
`system or application program.
`On earlier versions of operating systems, the configura-
`tion files were given specific, predefined names and the
`programs searched for these names when booted. For
`example, on personal computers that use the MS-DOS®
`operating system developed and sold by Microsoft
`Corporation, Redmond, Washington, the operating system
`definitions and the system commands are kept in two login
`files that work in tandem. System definitions are normally
`placed in a disk file which is named CONFIG.SYS and
`system commands are placed in disk batch file named
`AUTOEXEC.BAT. During the booting process, the com-
`puter will first
`load the device drivers and the system
`definitions specified in the CONFIG.SYSfile and run the
`programs in the AUTOEXEC.BATfile. Once execution of
`the system commands in the AUTOEXEC.BATfile have
`been completed the system is ready for operation.
`Operating systems also store data in files and memory
`locations, which data is provided to other programs, such as
`application programs. In general, a location in operating
`system stores data, and from which it provides this data to
`application programs.device drivers, and other programsis
`called herein a “repository.” Repositories can include disk
`files, such as the CONFIG.SYSfile, and memory wherein
`data on a floating-point processor is stored.
`Programs and operating systems use the data thatis stored
`in the repositories. For example. The MS-DOS operating
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`45
`
`50
`
`55
`
`65
`
`2
`system also stores, in memory. environmentvariables thatit
`finds in the AUTOEXEC.BATfile. Application programs
`can then retrieve the contents of the environmentvariables
`and alter their own behavior based on these contents. For
`example, a word processing program can use the contents of
`the TEMP variable to locate scratchpad space on disk for
`temporary files.
`Various application programs and system components can
`also read their own configuration and initialization files
`whentheystart up. For example. the WINDOWS™ program
`developed and sold by the Microsoft Corporation.
`Redmond, Washington is a well-known graphic interface
`program which has its own initialization files. When this
`program starts,
`it reads five initialization files, some of
`which contain parameters that specify the appearance of a
`user interface, a list of application programs to start
`automatically, and the size and location of a swapfile.
`Configuration and initialization files pose problems
`because they are difficult to maintain. For example, some
`operating systems such as the MS-DOS operating system
`referred to above use user-defined configuration files in that
`changesto the file are generally made by the user directly on
`the file in order to change the basic system configuration.
`User-defined configuration files require that the user know
`what hardware is resident on the system and also know how
`to edit the login files in order to properly inform the system
`of the presence of the hardware.
`Developers of prior art installation and configuration
`procedures have attempted to overcome these problems by
`providing automatic procedures that updated the configura-
`tion and initialization files. These procedures reduced the
`risk of introducing errors because no human interactions
`were involved, For example. some operating systems auto-
`matically detect, and store data about. the presence and
`amount of various hardware resources, such as memory.
`disks, and floating-point processors, that are available on a
`computer. These latter operating systems relieve the user of
`the responsibility of actually manually editing the configu-
`ration file. Many other automatic application installation
`proceduresalso create application-specific initialization and
`configuration files.
`However. there are still other problems. Some of these
`latter prior art systems, such as the OS/2® operating system
`developed and sold by the International business Machines
`Corporation, Boca Raton, Fla.. use configuration and ini-
`tialization files, e.g. OS2.INI, which contain binary data and
`cannot be updated with a traditional text editor.
`Even ASCII text configuration and initialization files are
`difficult to maintain with a traditional text editor because text
`editors do not check syntax. A user or system administrator
`can thus introduce syntax errors or “pathological” interac-
`tions amongstentries in these files. Further, text editors do
`not check for missing critical sections. Hence,it is possible
`for a user or system administrator to create a configuration
`orinitialization file from which the system or an application
`will not start.
`
`These ad hoc solutions create other problems because of
`the wide variety of configuration andinitialization files they
`create On many computers. Sometimesrelated data is stored
`in two or morefiles and in several directories. For example.
`the MS-DOS operating system typically requires entries in
`both CONFIG.SYS file and in AUTOEXEC.BATfile in
`order to use CD-ROM hardware devices.
`In addition, many of the configuration and initialization
`files, particularly those that relate to applications programs,
`are poorly documented. This poses problems for operating
`
`

`

`5.903.753
`
`3
`system and application developers. They must learn the
`location, syntax and semantics of each of these files because
`no common format exists for these files.
`Developers of some prior art operating system software,
`such as WINDOWS NT®, have attempted to impose a
`uniform structure on the data stored in the various reposi-
`tories by providing “name space”services. A name space is
`a collection ofall the data that an operating system manages.
`Anamespaceservice,or “registry,” stores and organizes the
`data into a hierarchy, much like the objects in an object
`oriented programming system. Each piece of data has a
`nameand a class and can optionally have one or more values
`associated with it. A registry is generally accessed by a
`predefined set of functions or function calls called an
`application program interface (API) and stores all the data
`formerly stored in the various repositories, e.g. memory
`locations and files. such as CONFIG.SYS. Programs, via
`calls to a registry API, can request. add, modify and delete
`data in a name space. With a single name space service API.
`one documentation standard can be used by both users and
`application programmers.
`Automatic application installation procedures call a name
`space service API to register the installation of application
`software. check for the existence of prerequisite hardware
`and/or software components, and, when appropriate, locate
`and remove superseded versions of an application.
`However, the use of a single name space service poses
`problems for developers and users of “older” application
`programs and automatic installation procedures. “Older”
`applications and procedures are ones that assume the exist-
`ence of. and directly access, configuration and initialization
`files with predefined names such as CONFIG.SYS. Since
`these names are generally coded into the program, these
`older application programs and procedures mustbe rewritten
`to make calls to a new API in order to run with prior art
`systems that provide a name space service. This probiem is
`significant because many older applications exist and users
`and system administrators are reluctant to upgrade to oper-
`ating systems that provide a single name space service if
`they cannot use their existing application programs. Forcing
`application developers to rewrite existing applications to use
`a name space server API and forcing users and system
`administrators to buy updated application programs is
`expensive, wasteful and impedes the movement to more
`modern and robust operating systems.
`
`SUMMARY OF THE INVENTION
`
`In accordance with the invention, a name space registry
`provides both an application program interface (API) for
`“newer” applications while maintaining the configuration
`files under their predefined names so that older applications
`can still directly access and usethe files. In accordance with
`one illustrative embodiment. the inventive registry is part of
`an operating system.
`The name space data that the inventive registry manages
`is distributed among several repositories. These repositories
`include disk files and memory and these files include the
`“traditional” repository files such as CONFIG.SYS and
`OS2.INI which store selected name space data. Application
`programs that are written to run under older operating
`systems directly access the traditional repository files.
`“Newer” application programs that are written to use the
`name space registry access name space data exclusively
`through the name space registry API, regardless of which
`repository contains the data (even if the data is in the
`traditional repository files such as the CONFIG.SYSfile.)
`
`4
`Older application programs do not reference name space
`data beyond that which is stored in the traditional
`repositories, so older applications need not, and do not,
`make API calls to the registry.
`The inventive registry provides backward compatibility
`for older programs by preservingthetraditional repositories
`and allowing older applications to read from and write to the
`traditional repositories as they did under prior art operating
`systems. At the same time. the registry allows new applica-
`tions access, via API calls, to the data stored in the tradi-
`tional repositories. as described above and to additional
`repositories which are not used by the older applications.
`
`BRIEF DESCRIPTION OF THE INVENTION
`
`The above and further advantages of the invention may be
`better understood by referring to the following led
`description,
`in conjunction with the accompanying
`drawings. in which:
`FIG. 1 is a block diagram of a computer system, for
`example a personal computer system. on which the inven-
`tion may be practiced.
`FIG. 2 is a block diagram of the name space registry.
`FIG. 3 is a block diagram of the name space registry
`having more detail than FIG.2.
`
`DETAILED DESCRIPTION OF AN
`ILLUSTRATIVE EMBODIMENT
`
`FIG. 1 illustrates the system architecture for a conven-
`tional computer system, such as an IBM PS/2® personal
`computer (“PC”) on which the present invention can oper-
`ate. The exemplary computer system of FIG. 1 is for
`descriptive purposes only. Though the description below
`may refer to terms commonly used in describing particular
`computer systems, such as an IBM PS/2® PC.the concepts
`equally apply to other systems,
`including those having
`dissimilar architectures.
`The exemplary computer 100 includes a central process-
`ing unit (“CPU”) 105, which may include a conventional
`microprocessor; a random access memory (“RAM”) 116 for
`temporary storage of information; a read only memory
`(“ROM”) 115 for permanent storage of information; a
`diskette controller 146 for controlling a diskette 142 that
`may be inserted into computer 100; a disk controller 150 for
`controlling a hard disk 152 thatis local to the computer 100;
`a keyboard and mouse controller 155 for controlling a
`keyboard input device 156 and a mouse input device 157; a
`DMAcontroller 160 for performing direct memory access to
`RAM 110; a video controller 165 for controlling a video
`output display 170; a memory controller 120 for controlling
`RAM 110; a bus controller 125 for controlling bus 130; and
`an interrupt controller 135 for receiving and processing
`various interrupt signals. Communication controller 145
`communicates via medium 147 to a network. Controller 145
`may correspond to a local area network communication
`controller, for example, or a modem controller. Similarly.
`medium 147 may correspondto a tangible medium,such as
`local area network cable or a telephonelink. Or, medium 147
`may use wireless techniques. such as microwaveor infrared
`transmission techniques.
`The computer 100 is generally controlled and coordinated
`by operating system software, which has a name space
`registry. An example of such an operating system is
`WARPOS/2®. developed and sold by the International Busi-
`ness Machines Corporation (“IBM”), Boca Raton, Fla. Such
`an operating system performs memory management. pro-
`
`20
`
`25
`
`30
`
`35
`
`45
`
`55
`
`65
`
`

`

`5.903.753
`
`5
`vide file system services, provide networking and I/O
`services, provide a user interface. such as a graphical user
`interface (“GUI”), and the like. User applications, such as
`editors and spread sheets, directly or indirectly, rely on these
`and other capabilities.
`As is known in the art, operating systems often include
`most, if not all, of the above functionality; some provide
`more; some provide less. To better understand the system
`structure of two conventional operating systems. the follow-
`ing sections are provided.
`Each program that is run on the computer 100 requires a
`path that will give it access to various configuration and
`initialization data subsets (hereinafter “repositories”) that
`are existent in some data storage device within computer
`100. FIG. 2 shows a block diagram of a preferred embodi-
`ment of a name space registry 200 (hereinafter “registry”)
`that enables both “new” programs schematically represented
`by box 202 and “old” programs schematically represented
`by box 210 to access and manipulate the various repositories
`208. Generally speaking,the registry 200 provides a uniform
`interface represented as box 204 between the repositories
`208 and any “new” program 202 that requires access to
`them. Accordingly. the term “new” program refers to those
`programs 202 that access the repositories 208 throughthis
`uniform interface 204. The term “old” program therefore
`refers to programs 210 that do not access the repositories
`208 with the uniform interface 204, but rather access certain
`repository files directly.
`As shownin FIG. 2, new programs 202 request access to
`the repositories 208 through interaction with name space
`registry application program interface 204 (“APTI”). API 204
`accordingly employs a numberof service providers 206 that
`store and retrieve data in the repositories 208. Although a
`service provider 206 can manage more than one repository
`208,
`it is preferred that cach repository 208 have one
`associated service provider 206 that acts between API 204
`and each respective repository 208.
`Before the API 204 system was implemented in many
`computer systems, old programs designed for use with those
`systems were programed to access the data subsets stored
`within the repository 208 by directly calling them by their
`predefined system names. For example, an old program 210
`used with an MS-DOS® operating system loads device
`drivers by directly accessing the contents of CONFIG.SYS
`file which is part of repositories 208 as indicated schemati-
`cally by arrow 212. Many current computer systems,
`however, do not have a specific configuration file named
`CONFIG.SYS,thus rendering the old programs 210 unus-
`able on such systems.
`Registry 200 overcomes this problem by maintaining
`selected configuration files using the predefined system
`names that will be expected by the older programs and
`maintaining in these files the information required by the
`older programs. Registry 200 also provides a path 212
`directly to selected files in repository 208 for old programs
`210. Accordingly, both old and new programs can effec-
`tively utilize newer computer systems.
`Some computer systemsuse sets or portions of other data
`files, generally referred to as “portions”, in accessing con-
`figuration data. A newer system, for example, might access
`a portion of CONFIG.SYSand a portion of a more recent
`configuration file.
`FIG. 3 shows more detail of various elements within an
`operating system employing the inventive registry con-
`structed in accordance with the principles of the present
`invention. In particular, an illustrative operating system
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`45
`
`30
`
`55
`
`65
`
`6
`which is suitable for use with the present invention is the
`OS/2 WARP CONNECT (Power PC edition) operating
`system mentioned above, although other operating system
`could also be used. Such operating system includes a name
`space registry which comprises a plurality of databases
`which are controlled by a plurality of service providers
`310-318 which are,
`in turn. accessed via a name space
`registry API 308. The API 308, which is represented by a
`box actually consists of a number of standard functions
`which can be called by an application program to request
`information from the database via the service providers and
`the mechanism to handle calls to the functions and route the
`calls to the proper “service provider” to obtain the requested
`information.
`
`Information in the name space registry database can be
`entered, changed and deleted by means of access programs
`306. These can include a graphical user interface which
`provides a user with a view of the database information in
`a windowing environment and various utility programs.
`These programs operate in a well-known fashion and will
`not be discussed further herein. The name space registry
`information can also be accessed via the API 308 by “new”
`applications 304 which have been written to interact with the
`API calls.
`
`Calls to the API functions are actually serviced by a
`number of service providers 310-318 which can each
`request, add. modify, and/or delete data in a specific reposi-
`tory 322, 324, 336. 334 and 336.
`In a illustrative
`embodiment. each repository has one associated service
`provider, although a single service provider can manage
`more than one repository. In response to an APIcall from a
`new application program 304 to retrieve data, the registry
`API 308 forwards the program callto a service provider (one
`of providers 310-318) that is associated with the desired
`data. The service provider retrieves the requested data and
`returnsit to the registry 308, which, in turn, returnsit to the
`application program. Similarly. API calls from new appli-
`cation programs 304 to store, modify. or delete data are
`routed by the registry 308 to the associated service provider.
`The service provider then stores or modifies data in the
`associated repository. The registry typically performs all-or-
`nothing transactions when updating the repositories 322,
`324, 330. 334 and 336 to insure data integrity.
`The registry system uses several service providers to store
`and retrieve data in the traditional repositories in response to
`the name space registry API calls. For example, a profile
`translator service provider 310 gives a requesting program
`access to information in binary initialization files which are
`commonly used in some operating systems and application
`programs. For example.
`these files might
`include the
`OS2.INL OS2SYS.INLand other OS/2 binary initialization
`files (indicated collectively by *.ini) maintained in database
`322. The server 310 translates the binary files in accordance
`with a predetermined profile to place the results in a standard
`format for return to the application program 304.
`An information variables service provider 312 gives a
`program 304 access to environmentvariables and to system
`information normally provided queries generated through an
`API such as the DosQuerySysInfo API. This system infor-
`mation might
`include the amount of physical memory
`installed, the boot drive identification or address, OS major/
`minor/revision numbers and various other information typi-
`cally needed by an install program orscript.
`A file translator service provider 314 gives a program 304
`access to information which is typically used in, or to
`identify, files in other operating systems. This information
`
`

`

`5,903,753
`
`7
`could include volume information (Le. “logical” drives used
`in some operating systems such as the OS/2 and MS-DOS
`operating systems),file names,data, attributes, and extended
`attributes. As with the other service providers this informa-
`tion may be translated into a standard form before being
`retumed to the application program 304.
`Finally. a default service provider 314 gives a program
`304 access, through a name server API 320. to additional
`information including configuration information stored in
`databases 330, 334 and 336 which are generally “persistent”
`(information remains after the system is powered down.)
`Various data stored in the repositories 330, 334 and 336
`mightincludeinitialization files such as the CONFIG.SYS
`file mentioned above stored in database 334, other files
`stored in database 336 and boot information files stored in
`database 330. The files in the latter three databases are
`accessed by “new” programs by means of registry server
`326 via name space API 320. Additional booting informa-
`tion whichis “transient” (not maintained after the system is
`powered downand recreated during the booting process) is
`available to the application program 304 from the root name
`server 328. This latter information is also available to an
`older operating system such as OS/2 by means ofa special
`server 318. Server 318 allows the OS/2 operating system
`access to the boot system information.
`As shown in FIG. 3, certain configuration fifes such as
`CONFIG.SYS, AUTOEXEC.BAT andtheinitialization files
`OS2.INI and OS2SYS.INI are maintained in the inventive
`registry under their original names. In addition, the infor-
`mation storedin these files remains the sameasin the prior
`art systems. “New” programs can accessthis information via
`the registry system. In addition. “old” programs. such as old
`OS/2 applications 302, still have direct access to these
`configurationfiles by using their specific system namesas
`generally coded into the old program code. In addition, the
`original file structure of the stored files (illustrated as OS/2
`files 324) is maintained so that these older programs canstill
`operate with the files, It should be noted. however. that old
`programs do not need to access many of the data subsets
`existent within the repositories 312, 330 and 336 that must
`be accessed by new programs. Accordingly, no path exists to
`reach these files except through the registry API 308.
`the
`Thus, unlike computer systems of the prior art,
`inventive registry provides backward source-code compat-
`ibility for the older programs, such as 32-bit OS/2 2.x
`applications, by not requiring them to undergo a source code
`change when recompiled and executed on. for example, a
`computer system running the OS/2 WARP CONNECT
`(Power PC edition) operating system incorporating the
`inventive registry system. Such programs can directly read
`and write CONFIG.SYSand other applications within the
`repositories 322 and 334. Similarly, new programs written
`for the inventive registry system can uniformly and effi-
`ciently access the same information using the API 308.
`The namespaceregistry 320 is arranged in a conventional
`manner. More specifically, the registry treats the data stored
`in the namespace as nodesin a tree structure. Each node has
`a type and zero or more attributes. Each link between a pair
`of adjacent nodes has an ID. Theidentity of a particular node
`is formed by concatenating all the link IDs, starting with the
`root of the tree and ending with the nodeitself. The registry
`performs all-or-nothing transactions when updating the
`namespace to insureits integrity. In cases where a requested
`change to the name space involves changing more than one
`node, the registry insures that either all or none of the nodes
`is changed as a result of an API cali to change the name
`space. The namespace remainsconsistent and reflects either
`
`8
`the state before any change was made.or the state after all
`the changes were made, but never an inconsistent state
`wherein only some of the nodes are changed.
`The registry 320 also synchronizes access by old appli-
`cations 302 and new applications 304 to the traditional
`repositories 322, 324 and 334 sothat the data stored therein
`is always consistent. If a service provider such as profile
`translator 31@, receives a request to access data that resides
`in a traditional repository file 322 and the file 322 is already
`open for write access, ¢.g.. by an older application 302, the
`service provider 310 waits until the application 302 closes
`the file.
`
`In response to a requestto access data in the name space,
`the API 308 and the appropriate service providers 310, 314
`and 326 can cooperate to open. for write access, all the
`necessary files before updating any of them. This ensures
`that no other program. e.g.. an older application 302, can
`open one of the files and make changes therein after the
`registry 308 has made some, but not all, of the changes
`requested by the APIcall.
`The registry storage server 326 consists of two sides: the
`client-side which interfaces with name server API 320 and
`the server side which accesses the databases 330, 334 and
`336. There are many instances ofthe client-side but only one
`instance of the server-side. The client-side is typically
`implemented as a library executed in the client context by a
`process, task, or shared library subsystem. The server-side is
`preferably a “personality neutral” server implemented as
`kernel task. “Personality neutral” means that the server side
`task is not tailored for a particular operating system. Com-
`Tounications between client and the server sides are accom-
`plished by allocating and constructing data structures on
`both the client and server side and then communicating
`betweenthestructures via messages. When large amounts of
`information need to be shared between client and server in
`either direction, the information may be sent out-of-line in
`messages, or mapped directly into the receiver’s address
`space in order to improve performance.
`The primary memory stores for data structures are a
`workspace which consists of a memory heap on the client-
`side. The workspace is used to fabricate node and attribute
`structures that are returned to the client application for the
`aforementionedtree structure. It is also used to record a list
`of storage segments mapped into the client address space
`and to maintain a reference to the storage segments. A
`workspace is created by an API call such as “NS,, Create-
`Workspace”. An application can optionally share its work-
`space with other applications.
`Storage segments, in turn, are portions of the memory
`stores 330, 334 and 336 served up by the registry storage
`server 326. Storage segments may be sent out-of-line or
`mapped by clients. The primary difference between the
`information structures in the application and workspace
`memory and the same structures in memory segments is how
`the structures are linked together. In memory. pointers are
`used while in segments, segment index/offsets are used.
`There are two ways an application can request informa-
`tion. One wayis for the application to provide a result buffer.
`The requested information is copied from storage segments
`into the buffer. The other way is the application can ask for
`the registry to supply memory that contains the requested
`information. In this case, the application receives a pointer
`to a node or attribute structure created in a workspace. and
`the workspace contains pointers directly to any information
`strings in the storage segmentas it was read into memory by
`the registry storage server 326.
`
`20
`
`25
`
`30
`
`35
`
`45
`
`30
`
`65
`
`

`

`5,903,753
`
`9
`In an alternate embodiment, the invention may be imple-
`mented as a computer program product for use with a
`computer system. Such implementation may