This structure defines the format of data found in a Jexegen-created image.
struct { DWORD dwNameOffset; DWORD dwDataSize; DWORD cbFileSize; DWORD dwDataOffset; JEXRESID ResourceID; JEXRESID ResourceType;};
dwNameOffset | Offset from the beginning of the main resource to a null terminated UTF8 string which contains the name of the java resource. The name must be a complete name (class files must be terminated with a '.class' extension). Forward slashes ('/') must be used as package separators. |
dwDataSize | If set to 0xFFFFFFFF (JEX_USE_RESOURCE_LENGTH), then the length of the java resource is the size of the Microsoft® Win32® resource that it lives within. Otherwise, this value is simply the length of the Java resource in bytes. |
cbFileSize | File size. |
dwDataOffset | Offset from the beginning of the owning resource to the data for this java resource. Must be 0 if dwDataSize is set to 0xFFFFFFFF. |
ResourceID | Specifies the Microsoft® Win32® resource ID within the jexegen-generated PE image which contains the bits for this Java resource. See JEXRESID for details of how to map these values to an actual Win32 resource. |
ResourceType | Specifies the Microsoft® Win32® resource type within the jexegen-generated PE image which contains the bits for this Java resource. See JEXRESID for details of how to map these values to an actual Win32 resource. |
There are two versions of the exegen format. The original format, version 1, only supported .class files, and could not store arbitrarily named resources. Version 4.79.2582 and earlier of the Microsoft virtual machine only support the version 1 format. Newer Microsoft VMs support the version 2 format, which adds the ability to store non-class resources. The version 1 format also required that all the data be stored within a single Microsoft® Win32® resource. The version 2 format removes this restriction.
All classes are stored in a single Microsoft® Win32® binary resource within the PE. This resource begins with a table that lists the names of the files contained within the resource, and information that indicates where the raw bits for those files are located. The actual data for the contained files follows this table.
If IJavaExecute2::SetClassSource or AddModuleResourceClassSource is used to tell the Microsoft VM about the module, then this resource can be stored with any resource ID (although the resource type must be RT_RCDATA), since those APIs allow you to specify the resource ID. If you are building a DLL to be placed on the class path, then 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 layout of this resource consists of three sections in this order:
[JEXHEADER] [FILEINFO SECTION] [RAW DATA SECTION]
java/lang/Class
The following are incorrect:
java\lang\Class java.lang.Class java/lang/Class.class
The exegen version 2 format adds two features that the version 1 format did not support.
This allows image files, audio clips, and so on to be stored in addition to class files. These named resources can be retrieved from the Java side with any APIs that can load class path-relative data (such as java.lang.Class.getResourceAsStream).
The version 1 format required that all class data be contained within the exegen resource. The version 2 format allows class/resource data in Win32 resources other than the primary exegen resource. This allows individual Java resources to be stored as individual Win32 resources. This makes it possible to utilize Win32 internationalization of Java resources.
As with the version 1 format, there is a primary exegen resource that contains the JEXHEADER and file information structures. The rules for how the Microsoft VM locates this information have not changed. The resource identifier specified with either IJavaExecute2::SetClassSource or AddModuleResourceClassSource refers to this primary resource. This main resource must be stored as resource ID JEX_DEFAULT_CLASS_RESOURCE_ID in DLLs intended for the class path.
The layout of the main resource is essentially the same as version 1. A header is followed by a list of file information structures, which is followed by string data and possibly file data.
The JEXHEADER structure remains unchanged, with the exception that the dwFormatVersion field must be set to 2.
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) which specify the Win32 resource which contains the bits for each Java resource. Following the list of JEXFILEINFOV2 structures is the string data for the file names, and resource names (if any). Some of the java resource files may be found here as well, although all the file data may be found in other resources.
Note that the fields ResourceID and ResourceType do not contain Win32 resource IDs. See the JEXRESID type in %SDKDIR%\Include\jexefmt.h for mapping these values to Win32 resource IDs.
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 original format, this name is 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
The following are incorrect:
java\lang\Class.class java.lang.Class.class java/lang/Class
The version 2 format gives a good deal of flexibility in laying out the Java resources within the .exe or .dll file.