Browse Prior Art Database

(RSS) Autonomic method for hot fixing an executing application Disclosure Number: IPCOM000021183D
Original Publication Date: 2003-Dec-31
Included in the Prior Art Database: 2003-Dec-31
Document File: 6 page(s) / 71K

Publishing Venue



Structuring Applications to allow hot code fixes while the application is running.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 23% of the total text.

Page 1 of 6

(RSS) Autonomic method for hot fixing an executing application

  Disclosed is a method for structuring and building applications that safely allows portions of the application to be replaced while the application is executing.

    Today, the main module of an application is staticly linked which means that every call instruction has embedded in it the exact address of the routine being called. This makes it impossible to add, delete, or meaningfully modify an application which is running without invalidating the addresses embedded inside existing call instructions.This makes it a 'brittle' monolith which means that any attempt to change it will break it. If such an application uses a DLL, the absolute addresses of the routines in the DLL are embedded into the application's call instructions at load time effectively "welding them together" making replacement or modification of the code in the DLL equally problematic. This effectively precludes being able to hot-fix an application (apply fixes for code bugs) while an application is running.

The invention is as follows:

This disclosure is intended to apply to code within a staticly linked executable file (either a main application or a DLL). This invention is not about a method of dynamically linking an application with library code. This method changes the internal structure and code generation within a single executable file to make hot fixing of application problems possible.

The application's source files are analyzed and compiled by the build tools and are built into a series of "code bundles" where each code bundle contains one or more subroutines or methods from the application. The output is no longer as a monolithic executable that's "welded together" but a series of code blocks that are to be loaded by the OS at specified addresses for execution. (Note that "build tools" traditionally means a compiler and linker. With this invention the build tools will need some additional function and sophistication to implement this invention.)

The executable file that is shipped becomes an archive file containing all the code bundles (as individual entities) that make up the application, plus a data segment, information the OS needs to load and start the app, etc.

When the build tools build an application, they store data about how it was built that will be used as essential input for later hot fix builds. This data includes things like what routine(s) are in each bundle, the mapping of the inserted passpoint(n) calls to which bundle has been exited when the passpoint(n) is called (more later on passpoint), and the layout of the app's data segment. This stored data allows individual bundles to be rebuilt later containing code fixes in a fashion that is consistant with the rest of the app. .

When the application executes, function calls to another routine within the same bundle are done in the normal fashion (using absolute addresses) and function calls to a function in another bundle (a "fori...