Microsoft 64 bit MASM > MASM64 SDK

Structure conversion tool version beta 3

(1/2) > >>

hutch--:
This version is a lot closer to being a release version. It handles embedded unions with further embedded structures reasonably well but still has a problem with named embedded unions and structures. It seems to handle the anonymous unions and structures correctly in most instances. The results are indented to make them closer to human readable and easier to edit if there is a problem. The tool is designed to produce MASM and compatible structures so they should work OK with JWASM and the later forks.

This is an example of a structure that does not fully convert properly.

typedef struct _FILE_REMOTE_PROTOCOL_INFO
{
    // Structure Version
    USHORT StructureVersion;     // 1
    USHORT StructureSize;        // sizeof(FILE_REMOTE_PROTOCOL_INFO)
   
    DWORD  Protocol;             // Protocol (WNNC_NET_*) defined in wnnc.h or ntifs.h.
   
    // Protocol Version & Type
    USHORT ProtocolMajorVersion;
    USHORT ProtocolMinorVersion;
    USHORT ProtocolRevision;
   
    USHORT Reserved;
   
    // Protocol-Generic Information
    DWORD  Flags;
   
    struct {
        DWORD Reserved[8];
    } GenericReserved;

    // Protocol specific information
   
    struct {
        DWORD Reserved[16];
    } ProtocolSpecificReserved;
   
} FILE_REMOTE_PROTOCOL_INFO, *PFILE_REMOTE_PROTOCOL_INFO;

When converted it looks like this.

  FILE_REMOTE_PROTOCOL_INFO STRUCT QWORD
    StructureVersion dw ?
    StructureSize dw ?
    Protocol dd ?
    ProtocolMajorVersion dw ?
    ProtocolMinorVersion dw ?
    ProtocolRevision dw ?
    Reserved dw ?
    Flags dd ?
      STRUCT
      Reserved dd 8 dup (?)
      ENDS ; GenericReserved
      STRUCT
      Reserved dd 16 dup (?)
      ENDS ; ProtocolSpecificReserved
  FILE_REMOTE_PROTOCOL_INFO ENDS

The problem is with named internal unions and structures is that the name is in the wrong place, it should be after the STRUCT or UNION statement, not after the ENDS statement. With the indenting it should be reasonably intuitive to see when the name needs to be moved to.

This is what it should look like when its been edited.

  FILE_REMOTE_PROTOCOL_INFO STRUCT QWORD
    StructureVersion dw ?
    StructureSize dw ?
    Protocol dd ?
    ProtocolMajorVersion dw ?
    ProtocolMinorVersion dw ?
    ProtocolRevision dw ?
    Reserved dw ?
    Flags dd ?
      STRUCT GenericReserved
        Reserved dd 8 dup (?)
      ENDS
      STRUCT ProtocolSpecificReserved
        Reserved dd 16 dup (?)
      ENDS
  FILE_REMOTE_PROTOCOL_INFO ENDS

A very wide range of structures will not need to be edited but there is still potential problems in missing data types as the Microsoft headers often cook their own on the fly with #define statements. The default if a data type is not recognised is to write it as a structure with the trailing "<>" so with an unknown data type there will be an error.

Tools of this type are tedious bastards of things to get working as a C compiler reads structures as linear scans backed up with large data structures that hold equates and previous #define data which means you would have to write a C compiler front end.

habran:

--- Quote from: hutch-- on July 29, 2016, 11:53:51 PM ---Tools of this type are tedious bastards of things to get working as a C compiler reads structures as linear scans backed up with large data structures that hold equates and previous #define data which means you would have to write a C compiler front end.

--- End quote ---
This is why I am interested in precompiled headers. It would be great if we had some compiler front end so that we could just use C headers with .h extension. If I knew the structure of precompiled headers I would be able to make HJWasm able to work with it. That would solve the hassle with translating headers to include files.
That would make assembler more acceptable to programmers. I've been thinking of using Visual Studio for creating  precompiled headers first and than use them to run HJWasm in the same program.

hutch--:
habran,

I wonder if open source code like GCC would have the data you would need to read C header files. While I have no doubt you can write your own, getting the basic logic of what is done would make the task a lot easier. What I have done to get a wide range of structures is get the list of include files from "windows.h", copy them together in the order they are listed in so I have one single file to work on. I added a couple at the end, the common control and common dialog and by scanning the entire file I get about 1250 structures in their original C format minus the commenting and blank lines.

If I have the order right, to read the C header files you need to do the conditional parts first, #ifdef/#ifndef and clean out any junk (#ifndef __MAC etc..) you don't need, then load the #define statements into a data structure, then the structures, unions and enums.

jj2007:
Hutch,

Great work :t

I wonder what would the best and clearest way to make them usable for both 64- and 32-bit code. In the other thread, there is a list of the 300+ types that a C compiler uses. For assembler, how many would we really need? 4 or 5??

32/64-bit
1/1    BYTE or CHAR
2/2    SHORT, USHORT
4/4    LONG, ULONG
8/8    LONGLONG, ULONGLONG
4/8    HANDLE
4/8    POINTER

hutch--:
After working on these things for years, you may understand why I go for the fixed data sizes.

    BYTE
    WORD
    DWORD
    QWORD
    XMMWORD

I know what you are after but its a nightmare to get it going.

I use a one pass hash table word replace for the data types so it reasonably clean to just add word pairs for anything you want changed from C/C++ data types to generic ASM data sizes.

Navigation

[0] Message Index

[#] Next page

Go to full version