Before I finish up nasmx typedef'ing I have another need. That need is for structures and unions within other structures and unions. To use another example from the windows.inc include let's look at a before and after of what the new code should look like, ideally:
message:
NX_ISTRUC MSG
NX_AT .hwnd, NULL
NX_AT .message, NULL
NX_AT .wParam, NULL
NX_AT .lParam, NULL
NX_AT .time, NULL
NX_AT .pt, NULL
NX_IENDSTRUC MSG
Notice the MSG.pt structure field. Currently, to access the member var POINT.y in the message structure you have to code as follows:
mov ecx, message + MSG.pt + POINT.y
mov [ecx], 42 ; Answer to the Ultimate Question of Life, the Universe, and Everything
; - or - maybe this:
mov ecx, message
.
. do stuff
.
xor eax, eax
mov [ecx + MSG.pt], eax ; PT.x
mov [ecx + MSG.pt + 4], 42 ; PT.y
Wouldn't it make much more sense to code:
mov ecx, message
mov [ecx + MSG.pt.y], 42
So what's the big deal here? For this trivial example not much. However, when you have to deal with structures containing structures of structures and unions things can start getting a bit "hairy". You may be asking yourself - "Why do I care about this? I'll just keep my structures simple". Well, in your own code you are free to define and instantiate however you please. But at soon as you need to access operating system defined structures which are deeply nested what are your choices? What if those structure sizes change between OS releases or between 32 and 64 bit versions? Wouldn't it be nice if somebody else already did the hard part and made it simple to access those system definitions? NASMX to the rescue.
So a slight change is in order, specifically, allowing the nesting of structures and unions. Let's create the proper definition of the POINT and MSG structures:
NX_STRUC POINT
NX_RESERVE .x, int32_t, 1
NX_RESERVE .y, int32_t, 1
NX_ENDSTRUC POINT
NX_STRUC MSG
NX_RESERVE .hwnd, NX_PTR, 1
NX_RESERVE .message, uint32_t, 1
NX_RESERVE .wParam, size_t, 1
NX_RESERVE .lParam, size_t, 1
NX_RESERVE .time, uint32_t, 1
NX_RESERVE .pt, POINT, 1
NX_ENDSTRUC
When processing the MSG structure NASMX will see that field .pt is an embedded POINT structure. It will reserve POINT size space and define the following offsets accordingly:
MSG.pt.x
MSG.pt.y
Notice that the field .hwnd is defined as an NX_PTR, and fields .wParam and .lParam are size_t. This means that these particular fields will expand in size depending on the bitness of the current build ( ie: 32 or 64 bits ). When creating your code on 32 bit platforms the sizes are defined as DWORD but on 64 bit platforms they become QWORDs. The offsets of embedded structure members will be automatically adjusted accordingly freeing you from the task of modifying your own code.
This is all currently being designed and developed right now. No code is yet available to play around with but I'm hoping to have an alpha release within the next week or two. Comments, questions, or suggestions are welcome. Stay tuned for further developments.
