GENERATE SELF-EXTRACTING EXECUTABLE ----------------------------------- This documents describes the files necessary for performing the generation of the self-extracting-executable. The main entry-point is GenerateCAB(), which in turn manipulates INF and CDF objects, gencab - CAB control module. geninf - INF object methods. gencdf - CDF object methods. files: ----- gencab.cxx, gencab.h - Cab generation control. gencdf.cxx, gencdf.h - Cdf object for IExpress file. geninf.cxx, geninf.h - Inf object for Setup file. gendbg.cxx, gendbg.h - Internel debug logging. genmem.cxx, genmem.h - Memory routines, tracks corruption. genglobl.cxx, genglobl.h - Global variables used in gen routines genpch.h - Common header includes gen*.h This design has seperated responsibilities of the various components into object-type modules. For example, anything which has to do with an INF-file is handled in the (geninf.c/geninf.h) modules. Likewise, the CDF routines use an INF interface to obtain information concerning the INF. Previous implementations of which this code was derived, utilized a monolithic approach where the CDF, INF and CAB routines had integral knowledge of each others functionality. We diverged from this approach to a more object-oriented design which we believe is more maintainable and somewhat self-documenting. Structure/Flow: cab: if (Create INF Object) { if (Create CDF Object) { query CDF, INF objects for pertinent information. if (CDF newer than CAB) { Execute IExpress to generate new cab. } else { utilize cached cabname. } Free CDF Object. } Free INF Object. } return cabname. Issues: ------- 1) How do we determine op-sys versioning and archetecture? We need this to determine where to pull our INF driver-files. This should be passed in at GenerateCAB() time. 2) Generating an INF (to be or not to be)...although not huge, this could change our implementating of caching of the CDF/CAB files. Currently, we will generate a layout-file (sort of).