implemented [TC 11.50b3] Internal 7-Zip packer unavailable in Windows XP

[ghisler(Author)]

No, because it's not a bug in ghc, but probably in the Visual C++ compiler.

[Usher]

2ghisler(Author)
I think that you should let the ghc author decide whether he wants to implement this bugfix or workaround.

[ghisler(Author)]

I don't want to take up their time with Windows XP support, which they must have dropped years ago, just for a few users here who insist on XP support.

[Usher]

2ghisler(Author)
So leave current TC as legacy version for 32-bit systems and move to developing only 64-bit TC. You can use a year for new versions numbering - TC24 in 2024, TC25 in 2025 etc.- like other developers do.

[ghisler(Author)]

32-bit vs 64-bit is not the problem here. It was actually much easier to get the 32-bit version to work on XP than the 64-bit version.

[JOUBE]

I don't want to take up their time with Windows XP support, which they must have dropped years ago, just for a few users here who insist on XP support.

Thanks

[JOUBE]

2ghisler(Author)
So leave current TC as legacy version for 32-bit systems and move to developing only 64-bit TC. You can use a year for new versions numbering - TC24 in 2024, TC25 in 2025 etc.- like other developers do.

Bad suggestion.

[Usher]

2ghisler(Author)
1. So leave current TC as legacy version for 32-bit systems and move to developing only 64-bit TC.
2. You can use a year for new versions numbering - TC24 in 2024, TC25 in 2025 etc.- like other developers do.

Bad suggestion.

Which one and why? (Numbers added for clarity).

[Fla$her]

2Usher
Let me share my point of view:

1. The first suggestion is inherently destructive and deviates from the logic of your XP requests. If you are looking for a reason for yourself not to report problems for this Windows version anymore, then you don't need any announcements from the author, just your desire is enough for this.
   AFAIU, the author has not been pre-debugging on XP for a long time before complaints appear. So I would also not worry that he spends time on this instead of developing. I think it's as crazy to drop support because of a single compiler inconsistency as it's to drop any other version/architecture support for any other unresolved reason that arises here and there.
2. The second suggestion looks like a sharp deviation from the usual practice and it's unclear what the benefits of such an approach might be. I don't think this will find support from others. You can create a poll here to make sure.

[ghisler(Author)]

I don't have any plans to drop the 32-bit version.