mirror of
git://source.winehq.org/git/wine.git
synced 2024-11-05 18:01:34 +00:00
38 lines
1.3 KiB
Text
38 lines
1.3 KiB
Text
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.
|