WiX: rewrite the package identities

[compnerd]

Restructure the packaging to be more homogeneous and concise.

  - Swift Software Development Kit
    * Swift Compiler Tools
    * Swift Developer Tools
    * Swift Windows Runtime (AMD64|ARM|ARM64|x86)
    * Swift Windows SDK (AMD64|ARM|ARM64|x86)

This gives a more concise description that is also easier to understand
and map. This sets up the path for further refinement of the installer
to provide more control over the installed components.

We do not suffix the Software Development Kit nor Compiler and Developer
Tools as there will be a singular version that matches the host that is
installed. Therefore, there is no value in differentiating that.
However, multiple SDKs and Runtimes may be present, so identify the
architecture for them.

[stevapple]

Argue a bit on the naming: why not x86, x64 and Arm64, which are the Windows convention?

[compnerd]

AMD64, IA32, and ARM64 are the Windows convention.

As an example: https://answers.microsoft.com/en-us/windows/forum/all/why-are-there-amd64-files-on-an-intel-machine/7482ee8f-511a-45c0-b3a3-8542a74801c9

[stevapple]

I'd rather refer to MSVC instead of other Windows internal stuff:
https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-170#vcvarsall-syntax

[compnerd]

That too uses amd64 and arm64. The only difference is capitalization.

[tristanlabelle]

IA32 is not the convention though. I've always thought that referred to Itanium. Both Visual Studio and Windows refer to x86 as x86. See:

• x86 Native Tools Command Prompt defining VSCMD_ARG_HOST_ARCH=x86 and VSCMD_ARG_TGT_ARCH=x86
  -C:\Program Files (x86)
• C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\bin\Hostx86\x86
• C:\Program Files (x86)\Windows Kits\10\bin\x86

[compnerd]

Yeah, IA32 is not very common for user visible stuff and was introduced by Microsoft around the time of Itanium (IA64). It is referenced in a few places in documentation, so changing that to x86 might not be a bad idea. I'll do that in a bit.

[etcwilde]

For the architecture/bitness portion of the name, since I can’t find clear consistent guidance from Microsoft, I’d like to propose “32-bit Intel”, “64-bit Intel”, “32-bit ARM”, and “64-bit ARM”. It makes it clear what it’s for without jargon.

[compnerd]

For the architecture/bitness portion of the name, since I can’t find clear consistent guidance from Microsoft, I’d like to propose “32-bit intel”, “64-bit intel”, “32-bit ARM”, and “64-bit ARM”. It makes it clear what it’s for without jargon.

I like this - it makes it clear and avoids ambiguity.

[stevapple]

It’s actually pretty clear IMO. Microsoft refers to these three architectures in Visual Studio documentation as x86, x64 and ARM64, and in Microsoft App Store as x86, x64 and Arm64. These two scenarios are typical for developers and users, and they almost agree.

[stevapple]

For the architecture/bitness portion of the name, since I can’t find clear consistent guidance from Microsoft, I’d like to propose “32-bit intel”, “64-bit intel”, “32-bit ARM”, and “64-bit ARM”. It makes it clear what it’s for without jargon.

@etcwilde It’s untypical to refer to the x86 family as "Intel" on Windows. This makes sense only for Macs because Apple never used x86 CPUs from AMD and other manufacturers. It will certainly cause more confusion than clarity.

[compnerd]

@stevapple Microsoft does often refer to 64-bit Intel as AMD64 as well. %PROCESSOR_ARCHITECTURE% is one example. They have previously done so in Visual Studio as well. They reference that in the SDKs at various sites. Microsoft uses the following:

32-bit Intel: x86, Win32, IA-32, i686
64-bit Intel: x64, x86_64, AMD64, EM64T
32-bit ARM: ARM NT, thumb2, ARMv7 (the other spellings are confusable with the Windows CE support)
64-bit ARM: ARM64, Arm64

I think I prefer either

• (32|64)-bit (Intel|ARM)
• x86, x64, ARM, ARM64

[compnerd]

FTR, the values that I had originally selected match the MSBuild ProductArchitecture spellings.

• x86
• amd64
• arm
• arm64

[stevapple]

• x86, x64, ARM, ARM64

This should look more familiar for Windows users. They (and their case-insensitive variants) are seen in UWP, App Store, WinGet, NuGet, … as well as MSDN.

[compnerd]

I would say that the original variants are just as familiar: they are after all the values that Visual Studio/MSBuild use.

[gwynne]

Speaking as a long-time macOS and Linux dev who has spent only a middling amount of time on Windows, the architecture naming I'm most used to are x86, arm, x86_64, arm64. That being said, I've been seeing amd64 more and more often versus x86_64 despite the typographical similarity between it and arm64, so I think I'd go with:

• x86
• ARM
• AMD64
• ARM64

Reasoning:

• The uppercase versions are both easier to visually distinguish and feel more "grammatically correct" (for lack of a better term) in this context.
• The lowercase x86 is a long-standing "marketing" convention and further visually distinguishes Intel from ARM in the 32-bit pair.
• The "human-readable" versions (e.g. "64-bit Intel" etc.) are nicest to look at but are relatively verbose and would make for the widest package names in the list, which would make visual truncation of the most critical part of the name on small displays (or in the extremely common severely squashed and poorly-constructed layouts of many Windows UIs).

[etcwilde]

FWIW, Visual Studio refers to them a x64 and Win32, x86, and ARM from what I'm looking at. Not entirely sure what the difference between Win32 and just x86 are. I see MSDN refer to them as x86 and x64 in some places (no mention of ARM).

I'm not a huge fan of all-caps ARM and AMD just because they look super similar (I guess the same can be said for arm64 and amd64 though ¯\(ツ)/¯), but I'm fine with those spellings.
I don't mind x86 and x64, but there's also the amd64 spelling. amd64 is probably the most "correct" from a history standpoint, but x86_64, x64, and amd64 all work and are used.
I liked Python's approach of just saying (32-bit) and (64-bit) for intel-based architectures and ARM64 for ARM. Python is usually pretty approachable. That said, if we ever end up with more architectures, we'd probably want to disambiguate which is why I suggested adding intel afterward. If we wanted to follow rust's lead, they use i386, i686, and x86_64 for the x86 family of chips. Zig refers to it by x86, x86_64, and aarch64 in its installer.

So anyway, if we're looking for leads, we're probably never actually going to agree because nothing is consistent. My vote just to unblock things is to go with @gwynne and use

x86
ARM
AMD64
ARM64

[etcwilde]

I think this looks fine