Replace LARGE_INTEGER and ULARGE_INTEGER with Int64 and UInt64 respectively

[kennykerr]

These structs exist only to support very old compilers that don't natively support 64-bit integers.

[KalleOlaviNiemitalo]

Do they have the same alignment requirements as the native types?

[kennykerr]

Yep!

[kennykerr]

Both C# and Rust already map this to native compiler types. It would just be nice not to have to do this all over the place.

[KalleOlaviNiemitalo]

ZwWriteFile defines special semantics for LARGE_INTEGER where HighPart is -1 and LowPart is either FILE_USE_FILE_POINTER_POSITION or FILE_WRITE_TO_END_OF_FILE.

With Win32 WriteFile though, I suppose an application would store those values to the Offset and OffsetHigh members of OVERLAPPED, so it would not become more difficult if LARGE_INTEGER were replaced with Int64.

[KalleOlaviNiemitalo]

Ok, FILETIME is the 64-bit struct that has a 32-bit alignment requirement.

[marler8997]

Couldn't this change have an affect on certain ABIs? For example the ABI change that occurs on COM calls when the return type is a native type vs a struct? Maybe there's no examples of this though?

[kennykerr]

I don't believe so. Keep in mind that they are unions, not structs. And no, I'm not aware any such cases.

[marler8997]

I don't believe so. Keep in mind that they are unions, not structs.

Didn't you say yourself here that you change the ABI depending on if you're looking at a native typedef?

#636 (comment)

I limit it to those methods that return a type that is both a struct and doesn't have the NativeTypedef attribute. In my parser, structs automatically exclude enums and interfaces.

Are you saying unions are treated like primitive types when determing ABI rather than treated as structs would be?

[kennykerr]

I just mean that since these are unions, they have a different layout and alignment to structs. Feel free to take it for a spin to see how MSVC behaves. That's ultimately the litmus test for the calling convention issue.