marlersoft / win32jsongen Goto Github PK

Some languages cannot handle cyclic dependencies between modules (i.e. Go, Odin). I've created this issue to see if we can address this.

The current idea is to create a post-processing tool that will transform the JSON files in such a way that languages without inter-module cyclic dependency support can use a set of JSON files without any of these cyclic dependencies.

My current idea is to split JSON files into multiple "levels" in such a way as to remove all cyclic dependencies. I believe this could be done by ensuring that declarations from "higher level" JSON files never reference types from "lower level" ones. So a module "Foo.json" could get split into multiple files like this:

Foo.json
Foo.level1.json
Foo.level2.json
...

The transformation guarantees that types from "higher levels" never reference types from "lower levels". So in this case, "Foo.level2.json" never references declarations from "Foo.level1.json" nor "Foo.json".

Also note that constants/functions are never referenced within the metadata itself, it is only types that are referenced. This means that "Foo.levelX.json" files will only contains types.

Along with this, the transformation will also add an extra field to all ApiRef types that indicate the "Level" the type is now located, so binding generators can know which file the type come from.

Also note that I expect that the main module generated from "Foo" would also expose the types from its higher level modules through aliases. In order to do this, maybe we can add additional typedef types inside the main module that point to the types in the higher level modules.

Note that if there are types that have "direct cyclic dependencies" between modules, then this solution will need an additional mechanism, namely, the generation of new modules for holding the combination of types that contain these directly cyclic dependencies.

I tried running the generator on the latest metadata file as of this writing.

It produces a number of errors, the first one having to do with "Windows.Win32.Interop" being named "Windows.Win32.Foundation.Metadata" in CustomAttrDecoder.cs now.

The next error is in JsonGenerator.cs where the line Enforce.Data(false); fails, telling me an assumption about the win32metadata winmd data was violated.

I tried my luck all day to work with the winmd file and was hoping you might find the time to update the code to handle the latest version.

Specifically, I was not able to find the TVN_ constants, like TVN_ASYNCDRAW in the version used here.

As an example, the wsprintf API function has the following signature as shown in ILSpy or ildasm when disassembling

[DllImport("USER32.dll", CallingConvention = CallingConvention.Cdecl, ExactSpelling = true, PreserveSig = false, SetLastError = true)]
[SupportedOSPlatform("windows5.0")]
[Unicode]
[Documentation("https://docs.microsoft.com/windows/win32/api/winuser/nf-winuser-wsprintfw")]
public static extern int wsprintfW([Out] PWSTR param0, [In][Const] PWSTR param1, __arglist);

However the generated json in Ui.WindowsAndMessaging.json shows

		"Name":"wsprintfW"
		,"SetLastError":true
		,"DllImport":"USER32"
		,"ReturnType":{"Kind":"Native","Name":"Int32"}
		,"ReturnAttrs":[]
		,"Architectures":[]
		,"Platform":"windows5.0"
		,"Attrs":[]
		,"Params":[
			{"Name":"param0","Type":{"Kind":"ApiRef","Name":"PWSTR","TargetKind":"Default","Api":"Foundation","Parents":[]},"Attrs":["Out"]}
			,{"Name":"param1","Type":{"Kind":"ApiRef","Name":"PWSTR","TargetKind":"Default","Api":"Foundation","Parents":[]},"Attrs":["In","Const"]}
		]

There is no indication of the calling convention in that description.

Is this by design or an oversight? If the latter, any possibility of an update with a fix?

Sorry, cannot provide a patch as I'm completely unfamiliar with both C# and .Net (old time pure C programmer) but if you have moved on to other things, I'll try to work on one.

Thanks, I found this very useful for generating bindings for a scripting language. Much easier than having to parse the winmd files myself.

/Ashok

It appears that some enums that are used to generate constants are generated with wrong integral type.

For example, here is the definition of the IMAGE_FILE_HEADER struct in C/C++, from the MSDN documentation:

typedef struct _IMAGE_FILE_HEADER {
    WORD  Machine;
    WORD  NumberOfSections;
    DWORD TimeDateStamp;
    DWORD PointerToSymbolTable;
    DWORD NumberOfSymbols;
    WORD  SizeOfOptionalHeader;
    WORD  Characteristics;
} IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER;

Here is the JSON generated for this struct:

{
		"Name":"IMAGE_FILE_HEADER"
		,"Architectures":[]
		,"Platform":null
		,"Kind":"Struct"
		,"Size":0
		,"PackingSize":0
		,"Fields":[
			{"Name":"Machine","Type":{"Kind":"ApiRef","Name":"IMAGE_FILE_MACHINE","TargetKind":"Default","Api":"System.Diagnostics.Debug","Parents":[]},"Attrs":[]}
			,{"Name":"NumberOfSections","Type":{"Kind":"Native","Name":"UInt16"},"Attrs":[]}
			,{"Name":"TimeDateStamp","Type":{"Kind":"Native","Name":"UInt32"},"Attrs":[]}
			,{"Name":"PointerToSymbolTable","Type":{"Kind":"Native","Name":"UInt32"},"Attrs":[]}
			,{"Name":"NumberOfSymbols","Type":{"Kind":"Native","Name":"UInt32"},"Attrs":[]}
			,{"Name":"SizeOfOptionalHeader","Type":{"Kind":"Native","Name":"UInt16"},"Attrs":[]}
			,{"Name":"Characteristics","Type":{"Kind":"ApiRef","Name":"IMAGE_FILE_CHARACTERISTICS","TargetKind":"Default","Api":"System.Diagnostics.Debug","Parents":[]},"Attrs":[]}
		]
		,"NestedTypes":[
		]
}

The Machine field has been translated to a value of type IMAGE_FILE_MACHINE, which is defined as follows:

{
		"Name":"IMAGE_FILE_MACHINE"
		,"Architectures":[]
		,"Platform":null
		,"Kind":"Enum"
		,"Flags":false
		,"Scoped":false
		,"Values":[
			{"Name":"IMAGE_FILE_MACHINE_AXP64","Value":644}
			,{"Name":"IMAGE_FILE_MACHINE_I386","Value":332}
			,{"Name":"IMAGE_FILE_MACHINE_IA64","Value":512}
			// More values here (omitted for brevity)
		]
		,"IntegerBase":"UInt32"
}

The IntegerBase is UInt32, which is 4 bytes; however the original field was of type WORD, which is 2 bytes.

This seems to cause utilities such as zigwin32gen that use the output of this tool to generate incorrect code.

For a few constants in win32.ui.windows_and_messaging the types are generated to be "Type":{"Kind":"Native","Name":"UInt32"} instead of "Type":{"Kind":"ApiRef","Name":"PWSTR","TargetKind":"Default","Api":"Foundation","Parents":[]}. This causes constants like IDI_ERROR to be generated down the line to u32 in zig when they should be [:0]const u16.

The main constants that this is happening to that I am using are IDI_WARNING, IDI_ERROR, and IDI_INFORMATION