WMF, EMF and EMF+ files all consist of a series of records that are played back to produce graphical output. Some records define objects which can specify graphical objects used to determine how graphics should be drawn (e.g. pens specify the color and width of lines). Each of these objects are stored in metafiles and are placed into an object table, which tracks the usage of graphic objects while processing the metafile. The object table is an
associative array of indexes to graphical object structures defined within the metafile. WMF and EMF files handle object processing differently to EMF+ records in EMF files. As a WMF and EMF file is being processed, the records are read into an object table once an object is defined. If an object is deleted then the object is released from the table and the identifier can be reused. Notably an object will not be used until it is specifically selected during record playback. This differs for EMF+ files, which also use an associative array via a
hashmap which records the object along with an object identifier. However, unlike WMF and EMF files which can delete an object, when a new object is created that has the same index as an existing object, the entry in the table is replaced with the new object. An EMF file also does not need to specifically select an object before it is used.
WMF WMF files were not originally designed to be device independent, meaning that a file could not be played back on output devices that differed from the original device on which the file was recorded. A partial solution to this issue was invented by
Aldus Corporation, who added an additional "placeable" header, called the "APM header", which added a bounding rectangle, a metafile version, metafile size, number of objects in the metafile and the size of the largest single record in the metafile. This was later incorporated into the WMF format by
Microsoft, starting in
Windows 2000. WMF files are structured by a series of records, starting with a number of control records: the header record, the aforementioned optional placeable record, and finished by an
end of file record. Encapsulated by the control records are the records that make up the image itself. These records work within what is known as the
playback device context, which is the collection of properties and objects that make up a device's graphical environment as the metafile is being "played back" onto this output device. Records other than control records can be largely grouped into bitmap records, drawing records, object records, state records and escape records.
Bitmap records Bitmap records manage and output
bitmap images.
Drawing records Drawing records produce graphics output.
Object records Object records create and manage graphics objects. In WMF files there are two broad categories of objects – graphics objects and structure objects. Structure objects are not explicitly created or deleted in a WMF, they are instead of complex structures. For example, the BitmapCoreHeader contains information about the dimensions and color format of a device-independent bitmap, which is itself part of a DeviceIndependentBitmap object. A graphics object, however, specifies parameters for graphics output and during playback of the WMF it sets up the playback device context. Graphics objects can be
brushes (defines the style, color and pattern of a brush which defines how to paint an area of the graphic),
fonts (defines properties that affect how text is displayed),
palettes (specifies colors as device-independent values, defined by an application),
pens (specifies the graphical attributes of a line), and
regions (which specify line and curve segments that define a shape).
Escape records Escape records are a means to extend metafile functionality via records that are not otherwise defined as a WMF record type. Each escape record contains a record function, an escape function and potentially escape data. The following escape records make up a WMF file. There was a
major vulnerability found in escape records around the Abort escape record, which stores the abort procedure code within the record itself. This affected Windows systems (see ) and the
Wine project (see ). According to
Secunia, "The vulnerability is caused due to an error in the handling of Windows Metafile files ('.wmf') containing specially crafted SETABORTPROC 'Escape' records. Such records allow arbitrary user-defined function to be executed when the rendering of a WMF file fails." According to the Windows 3.1 SDK documentation, the SETABORTPROC escape was obsoleted and replaced by the function of the same name in Windows 3.1, long before the WMF vulnerability was discovered. However the obsoleted escape code was retained for compatibility with 16 bit programs written for (or at least backwards compatible with) Windows 3.0. This change happened at approximately the same time as Microsoft was creating the 32 bit reimplementation of GDI for Windows NT, and it is likely that the vulnerability occurred during this effort. After
Steve Gibson accused Microsoft of deliberately implementing a
backdoor into their code,
Mark Russinovich provided a rebuttal, and stated that: Peter Ferrie of Symantec Security Response, USA also disagreed with Gibson, noting that:
EMF EMF files have three possible versions of headers. The original headers is just a container for images, the second and third version encapsulates the original header and contains a pixel format record and support for OpenGL records, and the third version encapsulates the second header extension and increases EMF accuracy and scalability of EMFs as it adds the ability to measure distances of device surfaces using the metric system. Each EMF header starts with an EMR_HEADER record, and records the relevant properties of the device on which the metafile image was recorded. The original EMF header has an 80 byte header and an optional variable length description string. Other metafiles contain extension fields, which encapsulate the original header. EmfMetafileHeaderExtension1 is a record that is inserted directly after the original EMF header, specifies whether there is a pixel format descriptor and the offset to the descriptor object within the header, as well as a field that specifies if
OpenGL records exist in the metafile. The pixel format descriptor specifies the capabilities of the drawing surface and whether a pixel is encoded in
RGBA or is an index into a color table. EmfMetafileHeaderExtension2 is a record that is inserted directly after the EmfMetafileHeaderExtension1 record, and it contains two fields with the X and Y values to measure the device surface in micrometers. Like WMF files, records can be classified by function. However, there are more record types in EMF files than there are in WMF files. Records can be classified as control, bitmap, clipping, comment, drawing, escape, object creation, object manipulation, OpenGL, path bracket, state and transform records.
EMF+ With the release of
Windows XP, the
Enhanced Metafile Format Plus Extensions (EMF+) format was introduced. EMF+ provides a way to serialize calls to the
GDI+ API in the same way that WMF/EMF stores calls to GDI. There are also compressed versions of Windows Metafiles known as
Compressed Windows Metafile (WMZ) and
Compressed Windows Enhanced Metafile (EMZ), which are basically
gzip compressed WMF and EMF files correspondingly. == Implementations ==