Accelerator Tables

[zooba]

Just been working on these for my ASM Runtime (excuse the shameless self promotion) and I discovered something strange.

The current definition of the ACCEL structure, according to both MSDN and MASM32, is this:

Code Select Expand

    ACCEL STRUCT
        fVirt   BYTE    ?
        key     WORD    ?
        cmd     WORD    ?
    ACCEL ENDS

This, while according to Microsoft, is correct, however, it doesn't work. After much angst (and a bit of debugging...  :wink) I found that the following works:

Code Select Expand

    ACCEL STRUCT
        fVirt   WORD    ?
        key     WORD    ?
        cmd     WORD    ?
    ACCEL ENDS

However, I have nothing (besides the fact that this actually works) to back this up.

[hutch--]

zooba,

> However, I have nothing (besides the fact that this actually works) to back this up.

Thats probably a reasonable start.  :bg

It is not uncommon to find stuff ups in the API and related reference.

[PellesC]

AFAIK, default packing applies to this structure - the second field needs to be WORD aligned, so a padding byte is inserted after the first (BYTE) field by the C/C++ compiler...

Pelle

[MichaelW]

zooba,

AFAICT the compiler would align the structure on an 8-byte boundary, and the structure members at an address that is a multiple of the member's size. I don't know about the structure alignment requirements, but Windows apparently assumes that the structure members are aligned as they would be by the compiler. There have been discussions here of this sort of problem, with this and other structures/unions, but I don't recall which forum or topic.

MSDN: Data Alignment Examples

MSDN: Structure Alignment

With MASM, you can specify an alignment for structures/unions:

name{STRUCT|UNION} [alignment] [,NONUNIQUE]
field declarations
name ENDS

The actual alignment will be the minimum of the alignment and the field's size. For MASM 6.14 the alignment can be specified as 1, 2, 4, 8, or 16, with 1 the default. (I realize that for you a bare description would suffice, but in the interest of illustrating it for the beginners...):

Code Select Expand


; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    include \masm32\include\masm32rt.inc
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    .data
      accel ACCEL <>
      _ACCEL STRUCT WORD
          fVirt DB ?
          key   DW ?
          cmd   DW ?
      _ACCEL ENDS
      _accel _ACCEL <>
    .code
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
start:
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    print uhex$(offset accel.fVirt),13,10
    print uhex$(offset accel.key),13,10
    print uhex$(offset accel.cmd),13,10
    print uhex$(offset _accel.fVirt),13,10
    print uhex$(offset _accel.key),13,10
    print uhex$(offset _accel.cmd),13,10
    mov   eax, input(13,10,"Press enter to exit...")
    exit
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
end start


Code Select Expand


00403000
00403001
00403003
00403005
00403007
00403009


And I verified that the modified structure works correctly. In my test app this worked as expected:

accel _ACCEL <FVIRTKEY or FCONTROL,VK_Z,10001>

But this did not:

accel ACCEL <FVIRTKEY or FCONTROL,VK_Z,10001>

[zooba]

Thanks Pelle and Michael.

I think Pelle's answer sums it up best - MASM takes things literally while C/C++ messes around with them and doesn't tell you  :P

Michael's solution is probably 'best', but it makes it slightly harder to read. In any case, (and this should probably go into the WINDOWS.INC forum now), can it be fixed for the next release?

BTW. will the SIZEOF operator correctly interpret the WORD alignment?

Edit - I'll answer my own question - yes it does  :wink

Cheers,

Zooba

[hutch--]

Let me see, if I have it right, the structure should be something like this.

Code Select Expand


    ACCEL STRUCT WORD
        fVirt   BYTE    ?
        key     WORD    ?
        cmd     WORD    ?
    ACCEL ENDS


[zooba]

Yep, that's right. :U

[hutch--]

Done,

Its now in the reference version files that build WINDOWS.INC.  :cheekygreen:

[zooba]

And after all that I see Donkey raised the exact same issue almost a year ago here  ::)

[hutch--]

The reason why I changed the method of building the file is so it could be edited. A year ago it was a melodrama to successfully edit the file as it was very large, I have a different system that is broken up into about 30 categories.

It is still no joy to edit and the sequential dependencies must be correct but at least its under control now.

[zooba]

...it was a melodrama...

Is that the one where someone holds up signs saying "Yay!" and "Boo!"?

Out of interest, how are you dividing it? By DLLs? And how come you havent written yourself a tool to deal with sequential dependencies  :P :toothy

[hutch--]

zooba,

> ...it was a melodrama...

No, like Sarah Bernhardt. The problem was it had been edited in bits by various people over a number of years and to fix it up and get it to work took a mountain of work and testing to make sure the dependencies were in the right order. Once I had the basic layout working I split the file into as many categories as was convenient, some by equate list, others as structures and the rest by DLL when it was a large collection.

Putting it all back together is as simple as a batch file to list the files which are named with a leading pair of numbers into a list then I use another simple tool to copy them sequentially into the WINDOWS.INC file. It is as simple as changing the correct file, saving it and running a batch file that does the rest.