| Marcus Meissner | 688c565 | 1999-01-22 17:09:46 +0000 | [diff] [blame] | 1 | Some notes concerning accelerators. |
| 2 | |
| 3 | There are _three_ differently sized accelerator structures exposed to the |
| 4 | user. The general layout is: |
| 5 | |
| 6 | BYTE fVirt; |
| 7 | WORD key; |
| 8 | WORD cmd; |
| 9 | |
| 10 | We now have three different appearances: |
| 11 | |
| 12 | - Accelerators in NE resources. These have a size of 5 byte and do not have |
| 13 | any padding. This is also the internal layout of the global handle HACCEL |
| 14 | (16 and 32) in Windows 95 and WINE. Exposed to the user as Win16 global |
| 15 | handles HACCEL16 and HACCEL32 by the Win16/Win32 API. |
| 16 | |
| 17 | - Accelerators in PE resources. These have a size of 8 byte. Layout is: |
| 18 | BYTE fVirt; |
| 19 | BYTE pad0; |
| 20 | WORD key; |
| 21 | WORD cmd; |
| 22 | WORD pad1; |
| 23 | They are exposed to the user only by direct accessing PE resources. |
| 24 | |
| 25 | - Accelerators in the Win32 API. These have a size of 6 byte. Layout is: |
| 26 | BYTE fVirt; |
| 27 | BYTE pad0; |
| 28 | WORD key; |
| 29 | WORD cmd; |
| 30 | These are exposed to the user by the CopyAcceleratorTable and |
| 31 | CreateAcceleratorTable in the Win32 API. |
| 32 | |
| 33 | Why two types of accelerators in the Win32 API? We can only guess, but |
| 34 | my best bet is that the Win32 resource compiler can/does not handle struct |
| 35 | packing. Win32 ACCEL is defined using #pragma(2) for the compiler but without |
| 36 | any packing for RC, so it will assume #pragma(4). |
| 37 | |
| 38 | Findings researched by Uwe Bonnes, Ulrich Weigand and Marcus Meissner. |
