Consider removing/reducing 64-bit prefix warnings

[qwertychouskie]

Back when the 64-bit warnings were added, things working properly with a 64-bit prefix were more the exception than the norm, and most applications worked just fine on 32-bit systems. Nowadays, many (if not most) applications only work on 64-bit systems, and most of the commonly used verbs have been updated to work properly in 64-bit prefixes.

Rather than always showing a 64-bit warning, perhaps it would be more advantageous to only show the warning for verbs with partial/missing 64-bit support. I propose adding a field to w_metadata called 64bit_support that has a few possible options:

• broken: verb completely broken in a 64-bit prefix
• missing: verb will install, but only install 32-bit versions of the DLLs
  • Example: msxml3 before msxml3: Update to newer version; add 64-bit support #2176
• partial: verb will install, but some components may be missing/inoperable in a 64-bit prefix
  • Example: msxml3 after msxml3: Update to newer version; add 64-bit support #2176 because for the resources DLL (msxml3r.dll), only the 32-bit version is installed
• full: Verb fully supported in a 64-bit prefix. For DLLs, this means all DLLs have both the 32-bit and 64-bit version installed. For apps, this means the app works just as well in a 64-bit prefix as a 32-bit prefix
  • Example: crypt32
• 64only: Verb only compatible with a 64-bit prefix

This has two main benefits

1. It gets rid of meaningless warnings
2. It makes the warnings that do remain actually mean something, which will also hopefully mean that more verbs get updated to fully support 64-bit prefixes, and therefore more applications can be easily ran on Linux.

Thoughts?

[austin987]

Thanks for your suggestion, I do like the idea in general. I've thought about doing something similar before, but didn't put much time into it.

Given upstream's recent work on aarch64, I think it would be prudent to also include architecture support. E.g., settings like nocrashdialog are arch independent and should work everywhere. Newer .NET versions now support aarch64/armv32.

I don't want to bikeshed your proposal, I think they could be done separately, but there would be some overlap. My initial concern is that '64bit_support' is a bit ambiguous, given that arm64 is now a thing and has upstream support. I don't have a great idea for a better suggestion right now, though.

Also important to keep in mind is that this will need a generic fallback for verbs missing the metadata (and for custom .verbs that a user may have). I'd suggest defaulting to partial for that case, or maybe a separate category of unknown that is treated like partial, but gives a warning.

That would allow adding metadata over time, instead of having to do it all in one pass.

[qwertychouskie]

Perhaps each verb could have a category for x86, x86-64, arm32, and aarch64. The categories (except 64only) would be the same. This is also more extensible for the future (RISC-V Windows? Never say never)

[austin987]

Great idea. I'd still add _support to each, so:
x86_support, x86_64_support, arm32_support, aarch64_support.

Are you interested in working on this?

[austin987]

Thinking about it a bit more, should also include something like anyarch or allarch for settings.

[qwertychouskie]

I'd err on the side of caution and explicitly define the support for each arch, even for settings verbs. No telling what weird things may change with new arches.