The exegen format has the following two versions:
This format supports only .class files and cannot store arbitrarily named resources. This format also requires that all the data be stored within a single Win32 resource. Version 1 exegen format is supported only by the Microsoft VM version 4.79.2582 and earlier.
The Version 2 format, supported by newer Microsoft VMs, includes the ability to store non-class resources (such as image files). Additionally, the Version 2 format does not require that all the data be stored within a single Win32 resource.
For additional information, see Jexefmt.h in the \Include subdirectory of the Microsoft SDK for Java installation.
The Version 1 format stores all classes in a single Win32 binary resource within the PE. This resource begins with a table that lists the names of the files contained in the resource and indicates where the raw bits for those files are located. The actual data for the contained files follows this table.
If you use IJavaExecute2::SetClassSource or AddModuleResourceClassSource to tell the Microsoft VM about the module, this resource can be stored with any resource ID because those APIs allow you to specify the resource ID. The resource type must be RT_RCDATA.
If you build a DLL to place on the class path, this resource must be stored with a resource ID of 1000 (JEX_DEFAULT_CLASS_RESOURCE_ID) and the resource type must be RT_RCDATA.
The resource is laid out in three sections and are in the following order:
[JEXHEADER]
The resource starts with a header whose layout is defined in the JEXHEADER structure. The header contains a signature, a format version, flags, and a count of the number of class files contained in the resource. The dwFormatVersion of the JEXHEADER structure must be set to 1 for the Version 1 exegen format.
[FILEINFO SECTION]
Immediately following the header is an array of file information structures. The number of elements in this list is equal to the cNumFiles field in the header. The layout of each of these file information structures is defined in the JEXFILEINFOV1 structure. Each of these structures specifies the name and location of a class file contained in the resource.
The dwNameOffset field points to the name of the class file that must be in UTF8 form. Forward slashes (/) must be used as package separators. The name is the class name, not the name of a class file. Do not include the .class extension. For example, the following is correct:
java/lang/Class
But these are not:
java\lang\Class java.lang.Class java/lang/Class.class
[RAW DATA SECTION]
The string data for the class names and the raw binary data of the class files follows the list of JEXFILEINFOV1 structures. This data has no implied order. The only requirement is that the resource offsets in the JEXFILEINFOV1 structures must point to the proper data. The jexegen tool places all the string data immediately after the file information list followed by the raw binary data of the class files, but other generation tools do not need to follow this layout.
The Version 2 exegen format adds two features that the Version 1 format does not support:
In the Version 2 format, a primary exegen resource contains the JEXHEADER and file information blocks. The structure of these file information blocks is different from the Version 1 format, but the rules for how the Microsoft VM locates this information is the same.
The resource identifier specified with either IJavaExecute2::SetClassSource or AddModuleResourceClassSource refers to the primary exegen resource. As in the Version 1 format, this resource can be stored with any resource ID and the resource type must be RT_RCDATA.
This primary resource must be stored with a resource ID of 1000 (JEX_DEFAULT_CLASS_RESOURCE_ID) in DLLs intended for the class path, and the resource type must be RT_RCDATA.
The layout of the main resource is essentially the same as in the Version 1 format: a header, followed by a list of file information structures, followed by string data, and possibly file data.
[JEXHEADER]
The dwFormatVersion field must be set to 2. Otherwise, the JEXHEADER structure remains unchanged.
[FILEINFO SECTION]
Following the header is a list of JEXFILEINFOV2 structures. The number of elements in this list is determined by the cNumFiles field in the header. These are similar to the JEXFILEINFOV1 structures with the addition of two fields, ResourceID and ResourceType. These fields specify the Win32 resource that contains the bits for each Java resource.
ResourceID and ResourceType do not contain Win32 resource IDs. For details on mapping these values to Win32 resource IDs, see the JEXRESID type.
As in the Version 1 format, the dwNameOffset field in the JEXFILEINFOV2 structure is an offset to the name of the Java resource in UTF8 form. Unlike the Version 1 format, this name is a file name not a class name. Class files must be stored with the .class extension. Forward slashes (/) are used as package separators. For example, the following is correct:
java/lang/Class.class
But these are not:
java\lang\Class.class java.lang.Class.class java/lang/Class
The Version 2 format provides the following flexibility in laying out Java resources within an .exe or .dll file:
[RAW DATA SECTION]
The string data for the file names and the resource names (if any) follow the list of JEXFILEINFOV2 structures. Some of the Java resource files may be found here as well, although all the file data may be found in other resources.