Microsoft SDK for Java

JAVACLASSRESOURCE

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;};

Members

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.

Different Versions of the Exegen Format

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.

Version 1 Format

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] 
  1. [JEXHEADER]  The resource begins with a header that contains a signature, a format version, flags, and a count of the number of class files contained within the resource. The layout of the header is defined in the  JEXHEADER structure. The dwFormatVersion of the JEXHEADER structure must be set to 1 for the version 1 format.

  2. [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 specifies the name and location of a class file that is contained within the resource. Note that the dwNameOffset field points to the name of the class file. This name 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, so do not append a .class extension. For example, the following is correct:
    java/lang/Class
    

    The following are incorrect:

    java\lang\Class
    java.lang.Class
    java/lang/Class.class
    
  3. [RAW DATA SECTION]  Following the list of JEXFILEINFOV1 structures is the string data for the class names, and raw binary data of the class files. Note that there is no implied ordering on this data. The only requirement is that the resource offsets in the JEXFILEINFOV1 structures must point to the proper data. The jexegen tool happens to place all the string data immediately after the file information list, followed by the raw binary data of the class files, but no other generation tool must follow this layout.

Version 2 Format

The exegen version 2 format adds two features that the version 1 format did not support.

  1. The ability to store arbitrarily named resources within the module.

    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).

  2. The ability to store the class/resource data in multiple Microsoft® Win32® resources.

    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.

  1. Just like in the original format, the files can exist in the main resource. The ResourceID and ResourceType fields of the corresponding JEXFILEINFOV2 structures need to be set to JEX_MAINRESOURCE_MARKER. The cbFileSize and dwDataOffset fields need to be filled in to specify where in the main resource the resource file is located.

  2. You can have a one-to-one mapping between a java resource file and a Microsoft® Win32® resource that it is located in. ResourceID and ResourceType need to contain the proper values to point to the Win32 resource (either by name or integer IDs). cbFileSize should be set to JEX_USE_RESOURCE_LENGTH to indicate that the size of the Java resource is the same as the Win32 resource that it is found in. dwDataOffset should be 0.

  3. You can have external Win32 resources (that is, not the main resource) that contain multiple Java resources. ResourceID and ResourceType point to the Win32 resource, and dwDataOffset and cbFileSize specify which portion of that Win32 resource contains the data for the Java resource.

© 1999 Microsoft Corporation. All rights reserved. Terms of use.