|  | Some notes concerning accelerators. | 
|  |  | 
|  | There are _three_ differently sized accelerator structures exposed to the | 
|  | user. The general layout is: | 
|  |  | 
|  | BYTE   fVirt; | 
|  | WORD   key; | 
|  | WORD   cmd; | 
|  |  | 
|  | We now have three different appearances: | 
|  |  | 
|  | - Accelerators in NE resources. These have a size of 5 byte and do not have | 
|  | any padding. This is also the internal layout of the global handle HACCEL | 
|  | (16 and 32) in Windows 95 and WINE. Exposed to the user as Win16 global | 
|  | handles HACCEL16 and HACCEL32 by the Win16/Win32 API. | 
|  |  | 
|  | - Accelerators in PE resources. These have a size of 8 byte. Layout is: | 
|  | BYTE   fVirt; | 
|  | BYTE   pad0; | 
|  | WORD   key; | 
|  | WORD   cmd; | 
|  | WORD   pad1; | 
|  | They are exposed to the user only by direct accessing PE resources. | 
|  |  | 
|  | - Accelerators in the Win32 API. These have a size of 6 byte. Layout is: | 
|  | BYTE   fVirt; | 
|  | BYTE   pad0; | 
|  | WORD   key; | 
|  | WORD   cmd; | 
|  | These are exposed to the user by the CopyAcceleratorTable and | 
|  | CreateAcceleratorTable in the Win32 API. | 
|  |  | 
|  | Why two types of accelerators in the Win32 API? We can only guess, but | 
|  | my best bet is that the Win32 resource compiler can/does not handle struct | 
|  | packing. Win32 ACCEL is defined using #pragma(2) for the compiler but without | 
|  | any packing for RC, so it will assume #pragma(4). | 
|  |  | 
|  | Findings researched by Uwe Bonnes, Ulrich Weigand and Marcus Meissner. |