Patent Application
20050050320
Embodiments of the present invention relate to the field of software architecture. In particular, embodiments of this invention relate to a branding framework for a software product, including an operating system.
As software products become larger and more complex, it is increasingly more difficult to create new products based on existing software products and to service these products as demanded by market and competitive needs. An operating system (OS) is an example of a relatively large, complex software product.
The operating system manages and schedules the resources of a computer or device in which it resides, and provides various function modules and interfaces that may be used by applications to accomplish various tasks. A conventional computer generally executes its operating system to manage various aspects of the computer as it is running. For example, the operating system is typically responsible for managing access to storage devices as well as input and/or output devices, and controlling the execution of one or more additional applications. Installation usually occurs before the computer executes the operating system (e.g., by copying multiple files from a distribution medium such as a CDROM onto a hard disk of the computer).
A conventional operating system has a large number of files (e.g., thousands) for instructions and/or data. Such instructions, when executed by the computer, provide the operating system's functionality. Typically, branding information appears throughout many of the operating system's files to provide users with a consistent, professional user experience. For example, the operating system very often presents user interfaces in which a product name, logo, bitmap image, or the like appears. Branding changes are usually made at key phases of product development and continue even after a product such as an operating system is released. These phases include the internal production cycle, beta (external) releases, and the final retail product.
The process of manually applying consistent brand identification throughout a large, complex software product such as an operating system tends to be complicated, time-consuming, and error-prone. This is due at least in part to the difficult task of finding and replacing every single branded area in the product. The manual branding process is particularly problematic because it must be repeated each time branding changes are made within a product cycle, when different versions of a product are released, when new products are created based on an existing product, and so forth. Branding is desired to be ubiquitous and, thus, conventional processes for making changes, testing the changes, and fixing branding bugs can require many thousands of hours for a large software product.
As products are developed and updated, it is extremely difficult to know whether all of the possible areas in which branding information appears are displaying properly. Products with visible inconsistencies in branding are highly undesirable.
Accordingly, a branding framework is desired to address one or more of these and other disadvantages and to allow, among other things, building improved operating systems and other software products.
Embodiments of the invention overcome one or more deficiencies in the prior art by simplifying the process by which branding elements are applied to a software product such as an operating system. The invention provides, among other things, a completely new way to handle every aspect of product branding. For instance, the invention centralizes all branding information and, thus, permits branding changes to be applied by making one change in one place rather than making countless changes throughout any given software product. Moreover, aspects of the invention benefit third parties that have purchased licensing rights to customize products with their own branding.
The invention in at least one of its embodiments encapsulates branding information into a single branding component, which decouples branding from core operating system code. Further aspects of the invention take advantage of a componentized architecture for applying branding elements to a software product. Moreover, the features of the present invention described herein are less laborious and easier to implement than currently available techniques as well as being economically feasible and commercially practical.
Briefly described, a computerized method embodying aspects of the invention is for use in branding a software product. The method includes assigning a namespace to each of a plurality of resource files. The resource files each contain one or more branding resources. The method also includes grouping the resource files according to the assigned namespaces and executing an interface to call a group of resource files as a function of a selected namespace. The called group of resource files is searched for one or more of the branding resources to be installed in the software product.
Another embodiment of the invention relates to computer-readable media including a plurality of centrally stored resource files and a branding engine. The resource files each contain one or more branding resources and has a namespace assigned thereto. The resource files are grouped according to the assigned namespaces. The branding engine calls a group of resource files as a function of a selected namespace and searches the called group of resource files for one or more of the branding resources to be installed in the software product.
Yet another method of branding a software product includes assigning a namespace to each of a plurality of resource files and embedding, in each of the resource files, metadata identifying branding resources contained in the resource files. The method also includes executing an interface to call at least one of the resource files as a function of a selected namespace and searching the called resource file for one or more of the branding resources to be installed in the software product based on the embedded metadata.
Computer-readable media having computer-executable instructions for performing methods of branding embody further aspects of the invention.
Alternatively, the invention may comprise various other methods and apparatuses.
Other features will be in part apparent and in part pointed out hereinafter.
Corresponding reference characters indicate corresponding parts throughout the drawings.
Referring now to the drawings,
In this instance, branding information in the form of a product name, logo, bitmap image, or the like appears throughout many of the files of operating system 152. Branding changes are usually made at key phases of product development and continue even after a product such as an operating system is released. These phases include the internal production cycle, beta (external) releases, and the final retail product. Embodiments of the invention simplify the process by which branding elements are applied to a software product such as operating system 152. The invention provides, among other things, a completely new way to handle every aspect of product branding. For instance, the invention centralizes all branding information and, thus, permits branding changes to be applied by making one change in one place rather than making countless changes throughout any given software product. Moreover, aspects of the invention benefit third parties that have purchased licensing rights to customize products with their own branding. As will be described in greater detail below, embodiments of the invention encapsulate branding information into a single branding component, which decouples branding from core operating system code. Further aspects of the invention take advantage of a componentized architecture for applying branding elements to a software product.
In addition to a large number of files, an operating system (e.g., operating system 152) usually has a large number of dependencies among files. For instance, many files may require the installation of one or more other files for their intended functionality to be carried out. Although the operating system's manufacturer may know of such dependencies at the time of installation, it can be difficult for a user, administrator, or other software developer to learn about these dependencies. This can prove troublesome, as software developers may not know what data or instructions in other files affect the particular file(s) with which they are concerned. Similarly, an administrator or user troubleshooting a malfunctioning computer may not know which files are applicable to the problem without knowledge of the dependencies.
Those skilled in the art are familiar with conventional operating systems, in which both server and client OS products are built from a giant central file that contains all of the binary files. In this example of a generally monolithic conventional operating system, a setup executable must specify which files are included in the different products. Thus, relationships between various parts of each product are difficult to understand. This lack of information hinders the ability to service pieces of an operating system during its lifecycle. In other words, it becomes more difficult for developers and others to keep track of all the different modules and files of the operating system to ensure that they will work properly together and individually as the operating system becomes bigger and more complicated.
As an example, a particular OS product may be sold as a “home” version while a premium product with additional features may be sold as a “professional” version. In this instance, the home and professional products will often include different branding information and other references interspersed throughout the many binary files making up the respective products. Unfortunately, creation and servicing of products is extremely laborious and requires extensive testing due to relationships between binary files and the existence of these branding references (each of which must be changed for a new product).
The operating system may be modified (e.g., updated or serviced) in any of a wide variety of manners, such as by adding or replacing one or more particular binary files, by any of a wide variety of people (e.g., a user, administrator, software developer other than the operating system developer, etc.). When such modifications occur, it increases the difficulty of identifying dependencies among files existing on the computer. For example, a change to a single file may necessitate a change to other dependent files. Further, it becomes even more difficult to troubleshoot a malfunctioning computer or update the operating system because the user or administrator cannot easily know exactly what functionality is or should be installed on the computer.
In the illustrated embodiment of
The operating system 152 of
Referring further to
Due to the complexity and size of existing operating systems, it is becoming increasingly difficult to create new products to meet market or competitive needs. Today's operating systems are more monolithic in nature and, thus, it can be difficult to understand the relationships between various constituent parts. The lack of this information makes servicing an operating system very difficult during the lifecycle of the product. To overcome these and other problems, embodiments of the present invention componentize the operating system. In other words, the invention permits representing a software product as a collection of components. Aspects of the invention involve several abstractions used to build an operating system in a componentized way to facilitate creation of new products and servicing the existing product. The abstractions can be applied to any software product including application programs and any operating system.
An exemplary component definition schema introduces several abstractions, namely, components (also referred to as assemblies), categories, features, packages, products, and SKUs (stock keeping units). In this instance, component 156 represents a reusable, sharable, self-describing atomic unit of distribution, servicing, and/or binding. It is the most basic abstraction that describes the component itself and all relevant information (i.e., metadata) used for installing, servicing, and/or binding to necessary resources in a declarative manner.
As described in greater detail below with respect to an embodiment of the invention, a category object 162 (see
Referring now to
The branding resource files 178 are separated into namespaces, which in turn are grouped into components. In one embodiment of the invention, the binaries of branding engine 176 contain an API for calling a group of resource files 178 (i.e., component) as a function of a selected namespace. Based on the specified namespace, branding engine 176 searches a DLL for requested branding resources. Advantageously, all of the branding resource files 178 need not be installed. Rather, this embodiment of the invention installs only the branding components that are required by the installed components 156.
Post-release, branding changes may also be required for each different SKU 170 that is released (e.g., premium version, home version, etc.). Over the long term, the branding framework of the invention enables all SKUs 170 to be serviced with the same binary files when the brand does not need to be changed. Service packs, QFE releases, and the like are understood to be brand agnostic as well.
Referring further to the binary containing the API interface, branding engine 176 knows in which DLL to look for a requested resource using the namespace specified. The following are examples of unmanaged APIs of branding engine 176:
HANDLE BrandLoadImage(LPCTSTR NameSpace, \\Name space of the branding (sub) component that contains the requested resource
HBITMAP BrandingLoadBitmap(LPCTSTR NameSpace, LPCTSTR IpszName)
HCURSOR WINAPI BrandingLoadCursor(LPCTSTR NameSpace, LPCTSTR IpszName)
HICON WINAPI BrandingLoadIcon(LPCTSTR NameSpace, LPCTSTR IpszName)
The branding engine 176 uses a NameSpace parameter in this embodiment to find the branding component (i.e., resource DLL 178). For an example, see the branding resource file below.
A “helper API,”
represents an exemplary branding resource file 178. The helper API is used for messages containing product names. The string that the caller passes in may contain replaceable parameters for the product names. The following are exemplary product name parameters:
The function in this example replaces the parameters with the corresponding product string, and returns the new string. A GlobalAlloc function, for example, is performed on the string. The caller frees the string using GlobalFree. The input string is not touched. Any other replaceable parameter (e.g. % Id (for sprintf) or % 1!Id! (for FormatMessage)) stays “as is.” The caller can call his/her preferred function to replace those before or after calling into BrandingFormatString. Alternatively, the caller can call BrandingLoadString to get the product strings and then pass them to his/her preferred function. BrandingFormatString is only a helper API that is provided for the convenience of the users of branding engine 176.
The following is an example of an input string: “% WINDOWS_LONG % is the best product ever.” The output would be: “Windows XP® Home Edition is the best product ever” if the computer is running the Windows XP® Home Edition operating system.
Referring now to
In one embodiment, one of the data fields in the XML file indicates whether a particular branding resource to be installed in the software product can be provided/overwritten by an OEM or other third party. As an example, the data contains the following information: ResourceType, ResourceID, and Overwrite. ResourceType describes identifies the branding resource by type (e.g., String=6, Bitmap=2) whereas ResourceID provides an identifier. Overwrite, which has a default value of NO, indicates whether a third party is permitted to provide a resource for the identified branding information. In addition, the manifest can also include embedded metadata describing characteristics other characteristics of the resource (e.g., size, length, color, format, etc.).
Beginning at 182,
At 186, branding engine 176 checks for a branding manifest based on, for example, namespace and resource ID. The specified namespace maps to a specific DLL in this example. At this point, branding engine 176 attempts to locate the DLL in its centralized location and to determine if the ID for the requested resource is known to the DLL. Branding engine 176 further examines the manifest for an override instruction at 188. With override set to a NO value, the regular resource is returned at 190. On the other hand, if override is set to a YES value, a third party will be granted permission to change an aspect of the visual appearance of the software product.
Proceeding to 192, branding engine 176 checks for the presence of third party override DLL. As before, branding engine 176 searches a known location based on the specified namespace for the override DLL. If the override DLL does not exist or does not specify that it wants to override the regular resource, operations return to 190. If the override DLL is available, the third party resource is returned at 194.
The following is an example of the data file (i.e., the branding manifest):
If a resource is not provided in the branding resource DLL in the first instance, an entry in the above data file is required. However, the resource may be provided by a third party rather than in the branding resource DLL. For example, an entry in the data file is used to indicate that the OEM/third party can overwrite a particular resource such as an OEM logo on the system property page of Windows XP® operating system. In this example, the branding resource DLL need not have a default if the OEM chooses not to provide the branding resource.
The component definition described herein may also be used to describe application components generally rather than operating system components specifically. In other words, any application may be described using this component definition. Accordingly, the branding framework may be applied to any operating system, application program, or other software product.
The componentization architecture described herein defines the concepts, component repository, and programming model for managing components both during design-time and run-time. There are several strategic benefits of componentization including agility, speed, supportability, and increased revenue opportunities. Creating a new software product, represented by a product or SKU object, is made much easier, even across client and server lines. It is a relatively simple task of selecting the right components and providing some additional configuration to build a new product. The agility in creating new products in a relatively short time provides the ability to compete efficiently and avoid missing a market opportunity. For example, it is possible to offer additional components to later add to a current product, which allows a customer to upgrade to a premium product, which increases the overall number of licenses, etc. All of these additional activities may result in additional revenues for the products.
Componentization also facilitates reducing the number of product images that an original equipment manufacturer (OEM) or corporation must maintain, which can lead to great cost savings. According to at least one embodiment of the invention, most of the component information is declarative such that components can be installed in an offline manner. This reduces the time it takes to install the whole product on a target device and results in great cost reductions for OEMs, corporations, end users and the like as well as increased customer satisfaction.
Those skilled in the art recognize the importance of service as part of the product cycle. Servicing a componentized product according to embodiments of the invention is relatively simple because it is easy to assess the impact of the changes based on the declarative information provided by each component. It is also much easier to test the components in a more isolated environment to improve the testing efficiency. In turn, this reduces the overall fragility in the software product.
The component definition schema described herein covers the information that component 156 describes in order to install, upgrade service, and bind to appropriate resources. In this regard,
The component 156 corresponds to manifest 158. In the illustrated example, manifest 158 includes a component identifier that identifies component 156 (e.g., by name or some other unique identifier). This correspondence can alternatively be maintained in different manners, such as inclusion of an identifier (not shown) of manifest 158 in component 156, storage of both component 156 and manifest 158 (or identifiers thereof) in a data structure that maintains an inherent correspondence between component 156 and manifest 158, etc. Manifest 158 may be an extensible markup language (XML) document.
As shown in the exemplary listing of
The manifest 158 in an alternative embodiment may also include a priority order and a version indicator to aid in installation and/or upgrading.
Alternatively, some or all of the information maintained in manifest 158 may be maintained in different locations. By way of example, some or all of the information may be incorporated into component 156 of
The example of APPENDIX A further illustrates aspects of the invention with respect to manifest 158.
The following description provides further details regarding the major abstractions used in a componentization architecture exemplifying aspects of the invention.
As described above, the object referred to as component 156 (or assembly) represents a reusable or sharable self-describing atomic unit of distribution, servicing, and binding. In the embodiment of
As set forth above, each component 156 is made up of one or more files as well as an associated manifest 158. Manifest 158 describes the details of component 156, as shown in
The category object 162 shown in
In the exemplary relationship diagram of
Referring now to
Referring further to
The product object 166 of
The operating system can be updated for any of a wide variety of reasons. By way of example, bug fixes to certain files of certain components may be available, new functionality (e.g., replacement or additional files) in a component may be available, new components may be available, etc.
Additionally, a new component may be installed as part of the operating system along side a previous component rather than replacing it. This allows different applications to use whichever version of the component they prefer (or are programmed to use).
By way of example, an OEM may offer various basic computer configurations corresponding to home use, business use, server use, and so forth. Each one of the configurations in this example is based on the same operating system but includes different functionality. Additional networking and communications functionality may be included in the server configuration that is not included in either the home or business configurations, and additional games or audio playback functionality may be included in the home configuration that is not included in the business or server configurations.
The operating system installation process is simplified greatly by the componentization of the operating system. OEM-specific functionality can be easily added to a computer by including the appropriate component and corresponding manifest. Further, updates to the operating system for improved functionality, bug fixes, and the like can be easily incorporated into the installation process by simply replacing the corresponding components. Alternatively, an additional update component and manifest set may be available to an operating system installation station that includes such updates.
Referring now to further aspects of the branding framework of the invention, internal branding scenarios are generally based on manual processes in at least one embodiment. As an example, components 156 may be authored to include product branding. This includes components 156 that display product branding in their UI as well as components 156 that have no unique branding UI in addition to the existing generic product branding elements. In this instance, the component author enables components 156 to display branding at points during the componentization process, such as planning and implementation.
At the planning phase, for example, the author of component 156 may check its UI for branding elements and find several instances of generic product branding elements. If the author does not find any branding that is unique to the particular component, he or she may conclude that component 156 can use the existing generic product branding elements in the branding category 162. In this instance, the author notes that component 156 will need to express a dependency on the branding engine 178 APIs.
At the implementation phase, for example, the author finds the branding resources inside the branding category 162, which lists all of the resource files 178 divided by branding resource component (DLLs). In the alternative, a root of all branding binaries may be available to the author. During implementation, the author chooses the branding resource components from the branding category 162 and codes the UI for component 156. At this point, the author adds a dependency from component 156 to the branding API. At build time, the specified branding elements are displayed in the UI.
In yet another embodiment, component authors may require unique or custom branding elements instead of generic branding (e.g., for a premium product). Referring now to
As shown in
A component repository in the example of
The component metadata and data interfaces are split under the component repository interface in
A serializer and deserializer interface allows first class objects in CMI to be serialized to and deserialized from a text file. For example, an XML serializer and deserializer reads and writes XML files. The serializer and deserializer generally read and write out carriers and configurations as described below.
The files that carry any of the first class abstractions in serialized format are referred to as either carriers or manifests. The carriers provide a means of populating the component repository data, i.e., tools create or edit a serialized instance of component in a carrier file and the component repository interface allows for the import of the carrier into the component repository.
The primary advantage of using a carrier for information exchange is that it allows the tools to be decoupled from the component repository. Another advantage is that while importing the carrier information, the data can be imported into the component repository in a more consistent (or complete) format. The serializer and deserializer interface segregation also allows for other kinds of carriers (e.g., INF) to be implemented.
Configuration is a serialized representation of the CMI's IConfiguration object, which represents a collection of components and settings used to build a run-time image. The reason configuration is serialized in a separate file rather than a carrier file is that configuration cannot be imported into the database.
The CMI utility layer consists of blocks of functionality that frequently changes. The blocks of functionality are exposed and consumed as well known interfaces in the embodiment of
This type of particular functionality binding with core abstractions allows the implementation of assembly install logic to change as needed without affecting the core IAssembly interface. The same holds true for other core abstractions also.
The upgrader block has the logic for upgrading and downgrading a particular core abstraction on a windows installation. For example, IAssembly is upgraded or downgraded from the OS installation in an online or offline manner. The logic of upgrading and downgrading assemblies is present in this block. All the core abstractions are upgraded and downgraded using “IUpgradable” interface.
There is a separate implementation of these methods for each core abstraction. Since install and uninstall functionality is needed during the upgrade process, “IUpgradable” inherits from “IInstallable” to re-use the existing functionality of install and uninstall. For example, the assembly has an upgrader abstraction called “IAssemblyUpgrader”. IAssemblyUpgrader aggregates “IAssembly”, “IAssemblyInstaller” and implements “IUpgradable” to upgrade and downgrade an assembly instance on a windows installation. Again, this kind of binding allows the implementation of assembly upgrade logic to change as needed without affecting the core IAssembly interface and install or uninstall logic. The same holds true for upgrade functionality of other core abstractions also.
The dependency resolver block implements the dependency resolution logic for a particular core abstraction. In this instance, for each core abstraction this block has logic in terms of dependency resolution either in an automated or manual fashion. The dependency resolver is extensible for the client programs to extend the default dependency resolution functionality as needed in a particular client context. This block's functionality is exposed through “IDependencyResolver” interface. The method of resolving dependencies returns a tree of CMI objects or instance objects based on the scenario where it is being used. Dependency resolution is generally done with respect to a configuration or a repository according to at least one embodiment of the invention. The repository can be either installable or installed repository.
Generally, on run-time systems, dependency resolutions happen against an installed repository and existing configuration, whereas in a design-time scenario the dependency resolution happens against an installable repository and a current configuration which is being edited.
The CMI object model is an aggregated form of CMI core object model and different pieces of functionality exposed in the utility layer. The core CMI object model is also exposed out for authoring tools to manipulate the abstractions directly while serializing and de-serializing the carriers (or manifests).
One of the key things to notice in the above architecture is that the same programming model is advantageously exposed for design-time, run-time and build-time scenarios. This helps in keeping the object model consistent with respect to different requirements and helps in programmer's productivity. This also helps in re-using a single implementation of CMI to be used for different scenarios such as design and run-time and is therefore more maintainable in comparison to different implementation for design-time and run-time scenarios.
In the illustrated embodiments, computer 70 has one or more processors or processing units 72 and a system memory 74. In the illustrated embodiment, a system bus 76 couples various system components including the system memory 74 to the processors 72. The bus 76 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus.
The computer 70 typically has at least some form of computer readable media. Computer readable media, which include both volatile and nonvolatile media, removable and non-removable media, may be any available medium that can be accessed by computer 70. By way of example and not limitation, computer readable media comprise computer storage media and communication media. Computer storage media include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. For example, computer storage media include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can accessed by computer 70. Communication media typically embody computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism and include any information delivery media. Those skilled in the art are familiar with the modulated data signal, which has one or more of its characteristics set or changed in such a manner as to encode information in the signal. Wired media, such as a wired network or direct-wired connection, and wireless media, such as acoustic, RF, infrared, and other wireless media, are examples of communication media. Combinations of the any of the above are also included within the scope of computer readable media.
The system memory 74 includes computer storage media in the form of removable and/or non-removable, volatile and/or nonvolatile memory. In the illustrated embodiment, system memory 74 includes read only memory (ROM) 78 and random access memory (RAM) 80. A basic input/output system 82 (BIOS), containing the basic routines that help to transfer information between elements within computer 70, such as during startup, is typically stored in ROM 78. The RAM 80 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 72. By way of example, and not limitation,
The computer 70 may also include other removable/non-removable, volatile/nonvolatile computer storage media. For example,
The drives or other mass storage devices and their associated computer storage media discussed above and illustrated in
A user may enter commands and information into computer 70 through input devices or user interface selection devices such as a keyboard 120 and a pointing device 122 (e.g., a mouse, trackball, pen, or touch pad). Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are connected to processing unit 72 through a user input interface 124 that is coupled to system bus 76, but may be connected by other interface and bus structures, such as a parallel port, game port, or a universal serial bus (USB). A monitor 128 or other type of display device is also connected to system bus 76 via an interface, such as a video interface 130. In addition to the monitor 128, computers often include other peripheral output devices (not shown) such as a printer and speakers, which may be connected through an output peripheral interface (not shown).
The computer 70 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 134. The remote computer 134 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to computer 70. The logical connections depicted in
When used in a local area networking environment, computer 70 is connected to the LAN 136 through a network interface or adapter 140. When used in a wide area networking environment, computer 70 typically includes a modem 142 or other means for establishing communications over the WAN 138, such as the Internet. The modem 142, which may be internal or external, is connected to system bus 76 via the user input interface 134, or other appropriate mechanism. In a networked environment, program modules depicted relative to computer 70, or portions thereof, may be stored in a remote memory storage device (not shown). By way of example, and not limitation,
Generally, the data processors of computer 70 are programmed by means of instructions stored at different times in the various computer-readable storage media of the computer. Programs and operating systems are typically distributed, for example, on floppy disks or CD-ROMs. From there, they are installed or loaded into the secondary memory of a computer. At execution, they are loaded at least partially into the computer's primary electronic memory. The invention described herein includes these and other various types of computer-readable storage media when such media contain instructions or programs for implementing the steps described herein in conjunction with a microprocessor or other data processor. The invention also includes the computer itself when programmed according to the methods and techniques described herein.
For purposes of illustration, programs and other executable program components, such as the operating system, are illustrated herein as discrete blocks. It is recognized, however, that such programs and components reside at various times in different storage components of the computer, and are executed by the data processor(s) of the computer.
Although described in connection with an exemplary computing system environment, including computer 70, the invention is operational with numerous other general purpose or special purpose computing system environments or configurations. The computing system environment is not intended to suggest any limitation as to the scope of use or functionality of the invention. Moreover, the computing system environment should not be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics including mobile telephones, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
Embodiments of the invention may be described in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices. Generally, program modules include, but are not limited to, routines, programs, objects, components, and data structures that perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
In operation, computer 70 executes computer-executable instructions such as those described herein to assign a namespace to each of the resource files 178 and to group them according to the assigned namespaces. Computer 70 further executes an interface to call a group of resource files as a function of a selected namespace and searches the called group for one or more of the branding resources to be installed in the software product. In another embodiment, computer 70 executes computer-executable instructions such as those described herein for embedding, in each of the resource files 178, metadata identifying branding resources contained in the resource files. In this instance, computer 70 searches a called resource file for one or more of the branding resources to be installed in the software product based on the embedded metadata.
Those skilled in the art will note that the order of execution or performance of the methods illustrated and described herein is not essential, unless otherwise specified. That is, it is contemplated by the inventors that elements of the methods may be performed in any order, unless otherwise specified, and that the methods may include more or less elements than those disclosed herein.
Information in this document, including uniform resource locator and other Internet web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred.
When introducing elements of the present invention or the embodiments thereof, the articles “a,” “an,” “the,” and “said” are intended to mean that there are one or more of the elements. The terms “comprising,” “including,” and “having” are intended to be inclusive and mean that there may be additional elements other than the listed elements.
In view of the above, it will be seen that the several objects of the invention are achieved and other advantageous results attained.
As various changes could be made in the above constructions and methods without departing from the scope of the invention, it is intended that all matter contained in the above description and shown in the accompanying drawings shall be interpreted as illustrative and not in a limiting sense.
