Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1998-04-27
2001-06-26
Courtenay, III, St. John (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
Reexamination Certificate
active
06253258
ABSTRACT:
BACKGROUND
1. Field of Invention
The invention relates generally to computer systems in which two or more program modules, each having internally prelinked portions, are loaded into system memory and further in which, either at the time of loading or during a subsequent run-time of a given module, further links are established from the given module to an external module.
The invention relates more specifically to the problem of how to perform subclassing for an operating system that operates with modules conforming to the portable-executable (PE) format or to a like format wherein modules have import and export data sections that are consulted for purposes of creating inter-module links.
2. Cross Reference to Related Publications
The following publications are believed to be loosely related to the present application and are cited here for purposes of reference and background:
(A) M. Pietrek, “Peering Inside the PE: A Tour of the Win32 Portable Executable File Format”, Microsoft Systems Journal, March 1994, pp 15-34; and
(B) M. Pietrek, “Learn System_Level Win32 Coding Techniques by Writing an API Spy Program”, Microsoft Systems Journal, December 1994, pp 17-44.
3. Description of Related Art
The term ‘subclassing’ refers generically to a method wherein one starts with a predefined computer operating system (OS), or another predefined program, that has predefined, callable services and one thereafter adds one or more new features to the operating system (or to another like program) such that, when one of the predefined services of the OS (or of the other like program) is requested by an external application program, the newly added features will be executed in place of or in addition to the original services.
Traditional subclassing relies on an operation referred to here as ‘global vector-table thunking’.
In ‘global vector-table thunking’, an alteration is made to a globally-constant location of memory through which all application programs normally gain access to services of the memory-resident OS.
The alteration to this globally-constant location forces global redirection of the normal service calls of all application programs to a new location of memory rather than to the location originally dictated by the globally-constant memory-location.
In terms of a more concrete example, consider the Microsoft DOS™ operating system that was established for 8086 class and higher microprocessors (e.g., 286, 386, 486, etc. versions of which are available from Intel Corporation of Santa Clara, Calif.).
Consider how application programs normally interface with MS-DOS™ through its API.
(API stands for application program interface. Microsoft DOS™ and its alternate designation, MS-DOS™ are recognized trademarks of Microsoft Corporation of Redmond, Wash.)
Under Microsoft DOS™, application programs normally access predefined operating system services by way of software interrupts (INT's in general, and more commonly through a software interrupt known as INT
—
21).
Each software interrupt (INT) vectors to a respective and globally-constant location in a lower address region of system memory. This region is sometimes referred to as the ‘Interrupt Vector Table’ (IVT). Here, the CPU finds a new address or vector to which the CPU automatically branches when the INT is executed.
During boot-up or other initialization of MS-DOS™, locations within the Interrupt Vector Table (IVT) are filled with vectors that point to predefined entry points of respective interrupt service routines found in the main body of MS-DOS™.
Thereafter, when an application program executes a software interrupt (e.g., INT
—
21)—after having set up appropriate values in the CPU registers—the corresponding interrupt vector in the IVT re-directs control to another location in system memory that contains the predefined interrupt service routine.
The interrupt service routine for INT
—
21 normally includes a dispatcher that redirects program flow to an entry point of a particular executable service module within the main body of the operating system in accordance with request flags indicated by the register settings of the interrupting application program.
The above, indirect approach of getting to MS-DOS™ service procedures through an IVT rather than going to directly to such service procedures is used so that newer versions of the operating system can be introduced while maintaining backward compatibility with application programs written for older versions of the OS.
To subclass within MS-DOS™ or a like operating system environment, a ‘vector-table thunk’ is performed on a given INT vectoring location within the globally-constant Interrupt Vector Table.
‘Vector-table thunking’ in this case simply means, overwriting the pre-initialized data within the globally-constant location of the given INT (e.g., the vector storing location of INT
—
21) with a new address value that redirects control to a new interrupt service routine. The new interrupt service routine may then dispatch (redirect program flow) to one or more newly-added subclassing procedures as desired.
From the above it is seen that subclassing of the OS is relatively trivial to carry out within an operating system environment such as that of Microsoft DOS™. Because API service calls are normally made through predefined, globally-constant locations of system memory, a simple thunk globally re-directs all calls to the desired new location.
When one works within other kinds of operating system environments where there is no globally-constant vectoring table (e.g., as is the case for the Win32 subsystem of Windows95™), one cannot rely on simple vector-table thunking for performing subclassing.
(Windows95™ is a recognized trademark of Microsoft Corporation of Redmond, Wash. Win32 is an industry-standardized operating system specification that is supported by Microsoft Corporation.)
These other kinds of operating system environments (e.g., the Win32 subsystem of Windows95™) provide more flexibility to software developers by allowing for upload-time or run-time dynamic-linking between pre-compiled, internally-prelinked modules (statically-linked modules).
The term ‘dynamic-linking’ is used herein to generally refer to the type of linking that occurs within the executing platform and/or executing software environment. The term ‘static-linking’ is used herein to generally refer to the type of linking that occurs outside the executing platform and/or executing software environment such as when object code is compiled on one platform for execution on another platform. However, static-linking could be carried out if desired on the same hardware platform that ultimately executes the statically-linked portions of the module. The above are therefor not bright line definitions. ‘Static-linking’ is to be understood as generally referring to the type of intra-module linking that is carried out for example at compile-time or link-time. ‘Dynamic-linking’ is to be understood as generally referring to the type of inter-module linking that is carried out for example at upload-time or run-time.
‘Upload-time’ refers to the time when a disk-image or a like, system-memory non-resident image of code is mapped or relocatably transferred into system memory.
Under the above-mentioned, more flexible kinds of OS's, software developers can independently write individual source code routines (e.g., in C code or C++ code) and compile each such routine for execution by a target CPU. These compiled object code packages may be only partially-resolved, meaning there may be some references to code or data structures outside of the pre-compiled object code packages.
Software developers can link a selected subset (e.g., a library) of the precompiled object code packages to form an internally-linked (internally cohesive) and relocatable ‘module’.
Many different modules can be generated. The linker-generated modules can then be stored on a system disk, or on a floppy diskette, or elsewhere as static-images.
Thereafter, when desirable, the code of one or more statically pre-linked, disk-resident m
Courtenay III St. John
Fliesler Dubb Meyer & Lovejoy LLP
Symantec Corporation
LandOfFree
Subclassing system for computer that operates with... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Subclassing system for computer that operates with..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Subclassing system for computer that operates with... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2483983