X hits on this document





82 / 120

technique is employed even when the complete source code of a legacy application is

available for several reasons: (1) the number of lines of code in any one component or

layer is extensive and poorly documented—making the cost of understanding the code

well enough to make changes too high, (2) modifying the legacy application to be

reusable without a wrapper would require locating all of the application's dependencies so

that it can be recompiled and tested (3) application modernization, where a non-

traditional interface to the application such as XML in the case of Web or RESTful

services is desired.

Creating a wrapper to a legacy machine code application can be quite challenging

  • especially if all of the source code for the application has been lost. Unless enough of

an application's source code remains such that it's possible to identify the names of

reusable entry points (procedures) and their I/O data structures, attempting to reuse the

application is haphazard at best. While it is possible to learn the names of entry points

that have been explicitly exported by an application in the case of a DLL, the names

don't indicate the layout of the expected I/O data structures. Probably the best way to

discover the entry points and I/O data structures in legacy machine code is to read the

source code of other applications which depend on it. For example, if a program α calls

procedure θ of program β passing an I/O data structure δ, and α produces correct results,

there is good reason to believe that procedure θ in program β can be reused by a third

program ρ using signature δ.

The COBOL programming language is most often associated with legacy


Document info
Document views478
Page views479
Page last viewedThu Jan 19 20:02:15 UTC 2017