Suspicious duplicate structs that differ in architecture and pack only

[DoctorKrolic]

I was ivestigating the underlying issue for microsoft/CsWin32#1617 (comment). It turned out metadata defines 2 nearly identical RASDIALPARAMSW structs which differs only in supported architecture and pack size:

.class public sequential ansi sealed beforefieldinit Windows.Win32.NetworkManagement.Rras.RASDIALPARAMSW
	extends [netstandard]System.ValueType
{
	.custom instance void [Windows.Win32.winmd]Windows.Win32.Foundation.Metadata.UnicodeAttribute::.ctor() = (
		01 00 00 00
	)
	.custom instance void [Windows.Win32.winmd]Windows.Win32.Foundation.Metadata.SupportedArchitectureAttribute::.ctor(valuetype [Windows.Win32.winmd]Windows.Win32.Foundation.Metadata.Architecture) = (
+		01 00 06 00 00 00 00 00 // X64 | Arm64
-		01 00 01 00 00 00 00 00 // X86
	)
+	.pack 4
+	.size 0

	// Fields
	.field public uint32 dwSize
	.field public char[0...256] szEntryName
	.field public char[0...128] szPhoneNumber
	.field public char[0...128] szCallbackNumber
	.field public char[0...256] szUserName
	.field public char[0...256] szPassword
	.field public char[0...15] szDomain
	.field public uint32 dwSubEntry
	.field public native uint dwCallbackId
	.field public uint32 dwIfIndex
	.field public valuetype [Windows.Win32.winmd]Windows.Win32.Foundation.PWSTR szEncPassword

} // end of class Windows.Win32.NetworkManagement.Rras.RASDIALPARAMSW

This seems suspicious. The struct has nothing to do with memory or any other hardware access, so it seems wrong that it is emitted as architecture-specific. I am not an expert in such low-level stuff as memory alignment on different architectures, but I have a suspicion that on x86 .pack 4 is a default value, so it isn't emitted explicitly and that makes the wrong split later on. If true, both definitions can be collapsed into a single one without need for architecture-specific structs. I would like to either confirm or deny my suspicion

[DoctorKrolic]

@jevansaks Can you please take a look?

[jevansaks]

We sometimes have headers which annotate structs as having different packing on x86 versus x64. The Shell_NotifyIcon APIs are a similar case that frustrate consumers. I think in that case as well that we could fold these together (see #2126) but someone just needs to analyze the memory layout in a native program versus what the metadata layout would be in CsWin32 if we combined them.

[DoctorKrolic]

Well, the VS hover says alignmen is 4 on both x86 and x64. Also looking at Ras.h it seems that the inclusion of pshpack4.h, which defines pack size 4, is unconditional (although, C being C, so it is hard to tell that with 100% reliability for such big file just by looking at it). In any case, this info can be computed programatically and if alignment is identical between x86 and x64 (I think, we can exclude arm from the descussion since the point here is bitness rather than instruction set), no split between architectures is needed