Vcpkg: Support for XP compatible builds

[FadiBitar]

I absolutely love vcpkg, but there seems to be one missing feature that makes it unusable for our purposes. The software we build needs to be compatible with all the platforms that our users have, which (unfortunately) still includes quite a lot of Windows XP machines.

Is there a way to build a package in vcpkg with an XP compatible toolset (similar to the 140_xp setting in VS), short of making our own ports? Otherwise, is xp support coming on the horizon?

[smasherprog]

and win98 too!

[smasherprog]

Kidding...

[Mixaill]

Please check #1732

[alexkaratarakis]

Similarly to our stance regarding older VS versions (see #1718 ), we are happy to see users using vcpkg to build for Windows XP and are willing to accept non-intrusive changes in mainline to make that smoother.
However, supporting an end-of-life operating system like Windows XP will be quite burdensome to maintainers. This will detract from the overall quality of ports and could discourage potential maintainers from creating/updating ports.

There is a trade-off between what we have to explicitly support and not becoming over-encumbered, so for now we feel that Windows7+/VS2015+ strikes a good balance for explicit support.

Having said that @Mixaill ’s PR is very useful towards building for XP, so we intend to merge as much of it as possible in mainline (as long as it is not too intrusive or WindowsXP-specific).

Notably, having the XP triplets in mainline is problematic because it implies that vcpkg has first-class support for Windows XP, which is not true.

[VikingExplorer]

what change do I have to make in order to support Windows XP?

Is it: set(VCPKG_PLATFORM_TOOLSET v141_xp)

[fawdlstty]

vs2017的v141_xp模式实际编译后再xp上运行不成功，我这边测试结果是，最高vs2013的v120_xp才能在xp上成功运行，暂时不清楚v141_xp有什么用，不过要想在xp上完美运行，至少得兼容vs2013工具集

[fawdlstty]

或者使用VC_LTL编译

[1354092549]

@fawdlstty
Please speak in English here though I'm a Chinese.

[ppatpat]

Similarly to our stance regarding older VS versions (see #1718 ), we are happy to see users using vcpkg to build for Windows XP and are willing to accept non-intrusive changes in mainline to make that smoother.
However, supporting an end-of-life operating system like Windows XP will be quite burdensome to maintainers. This will detract from the overall quality of ports and could discourage potential maintainers from creating/updating ports.

There is a trade-off between what we have to explicitly support and not becoming over-encumbered, so for now we feel that Windows7+/VS2015+ strikes a good balance for explicit support.

Having said that @Mixaill ’s PR is very useful towards building for XP, so we intend to merge as much of it as possible in mainline (as long as it is not too intrusive or WindowsXP-specific).

Notably, having the XP triplets in mainline is problematic because it implies that vcpkg has first-class support for Windows XP, which is not true.

If VS 2017 team decided to support XP I do not see why you want to be more restrictive than them.
XP support could be added to vcpkg and packages could add a minimum VCPKG_PLATFORM_TOOLSET requirement then at the end of the day would be a set of packages not supporting XP but not vcpkg itself.

[BillyONeal]

In addition to what Alex said above ( https://github.com/microsoft/vcpkg/issues/1015#issuecomment-329048800 ) no current version of Visual Studio supports targeting Windows XP, so I don't believe we will ever add support for this.

[orinem]

Not true.

Visual Studio 2017 is still supported:

https://docs.microsoft.com/en-us/visualstudio/releases/2019/servicing

Scroll down to "Support for older versions of Visual Studio".

There are those of us that work for companies that produce software specifically designed to move from XP and therefore must run on XP.

[BillyONeal]

VS2017 is supported, but it is not a current version. As you said it's in the 'support for older versions' section. Moreover, we are aggressively adding things which will be impossible to support on XP. For example, we are looking to start shipping a signed vcpkg.exe binary to avoid a need to build during bootstrap for most customers. It is impossible to produce such a binary that can run on XP, because XP does not support SHA2 signing certificates, and we can't use SHA1 signing certificates on a new product because SHA1 has been broken.

We left this item open for 3 years with the open statement that while we weren't investing in XP support at the time, we would listen for an outcry of community feedback and/or accept noninvasive patches to enable such support. In that 3 years, no such patches have been forthcoming, and with the removal of XP targeting from VS it's now clear that we, the vcpkg team, will never invest in such support. As a result, I closed this issue as 'won't fix forever'. The 'we will accept noninvasive patches' part still stands but if nobody has tried since 2017 I don't think it's likely someone will contribute such a patch in 2020.

[ppatpat]

Billy,
who cares if 2017 is the "last" version or not? It is supported, people use it; that's it.
Problems with signatures? you can double sign and that "works" on XP.
It's hard to grasp why a packet manager "must" depart from XP in order to do a decent job.

[VikingExplorer]

ppatpat,

You're absolutely right. However, there seems to be some horrible design
flaw in vcpkg that prevents them from easily supporting functionality
supported by VS. I once pointed out that the differences in the vcxproj
files required to build for XP are trivial. Sad!

On Wed, Jun 17, 2020 at 9:24 AM ppatpat [e-mail] wrote:

Billy,
who cares if 2017 is the "last" version or not? It is supported, people
use it; that's it.
Problems with signatures? you can double sign and that "works" on XP.
It's hard to grasp why a packet manager "must" depart from XP in order to
do a decent job.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vcpkg/issues/1015#issuecomment-645371480,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADTIYWBNGJTXSGFNS2AFKX3RXC72HANCNFSM4DJXKC3A
.

[Mixaill]

So, if someone is interested in this I could revive my PR from 2017-2018 and split it into two parts:

1) support for setting the target PE SUBSYSTEM
2) V141_XP toolset support

But I don’t have a clear understanding of the current position of the project maintainer, if it will be ever merged?

[ppatpat]

No programmer really "enjoys" supporting (and testing on) XP but it is many times a customer requirement as mentioned before.
Then let's avoid making programmer 's life even harder and let's add the required support for XP (and PE off course). This should not be rocket science.

[VikingExplorer]

ppatpat, it shouldn't be rocket science, but there must be some design flaw
that makes it very difficult for them. For some reason, they seem to think
it implies that all the libraries need to be able to build w/ XP. Not sure
if the word "optional" is in their vocabulary. This conversation has been
going on for about 3 years.

On Wed, Jun 17, 2020 at 11:18 AM ppatpat [e-mail] wrote:

No programmer really "enjoys" supporting (and testing on) XP but it is
many times a customer requirement as mentioned before.
Then let's avoid making programmer 's life even harder and let's add the
required support for XP (and PE off course). This should not be rocket
science.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vcpkg/issues/1015#issuecomment-645439422,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADTIYWDMHR6HEI4ZRGEWZHDRXDNCZANCNFSM4DJXKC3A
.

[orinem]

I suspect vcpkg 'customers' have been working around this issue. Given the surprising number of responses - I expected to be ignored - it's still relevant.

I think one thing should be clear. I don't think anyone wants to run vcpkg.exe on XP. We just need to target XP.

And I don't think anyone is saying that all libraries need to run on XP. Just that we should be able to build those that can run on XP.

I don't think it's the role of a package manager to insist that every package runs on every OS that they claim to support. That is crazy. What would you do with a UWP library? Ignore it as it wouldn't run on < Win10 or drop support for < Win10?

[ppatpat]

@VikingExplorer You might be right but I find hard to imagine a "design flaw" forcing to drop XP as target.

@orinem Spot on.

[Mixaill]

@BillyONeal I'm not able to response in the #1732 PR because comments is limited to members.

I can try to rebase it during the next weeks.

[BillyONeal]

@ppatpat

who cares if 2017 is the "last" version or not? It is supported, people use it; that's it.

Supported doesn't mean "currently getting new features", it means 'will continue to work and you'll get critical bugfixes'.

Problems with signatures? you can double sign and that "works" on XP.

Microsoft will not mint the necessary SHA-1 certificate for a new product even in dual signing mode.

No programmer really "enjoys" supporting (and testing on) XP but it is many times a customer requirement as mentioned before.

I'm not making a statement about enjoyment, I'm making a statement about investment.

@Mixaill I apologize your PR got missed during PR review mess a while ago, I've reopened it but it doesn't merge cleanly right now. Can you take a look?

@VikingExplorer

there must be some design flaw that makes it very difficult for them

The design flaw is in XP, that it cannot be safely connected to the internet.

For some reason, they seem to think it implies that all the libraries need to be able to build w/ XP.

It is a bad customer experience if we add a feature that makes it look like vcpkg has supported and tested most of the catalog, like we do for other triplets, and it explodes in the users' face for common libraries they'd like to use. Even the 'community' triplets get some level of incidental testing.

[BillyONeal]

@Mixaill Huh? You should be able to comment on your own PR (and there are comments from you in that PR)

[Mixaill]

@BillyONeal

[VikingExplorer]

"I don't think anyone is saying that all libraries need to run on XP. Just
that we should be able to build those that can run on XP."

Actually, this was exactly one of the reasons given.

"I don't think it's the role of a package manager to insist that every
package runs on every OS that they claim to support."

Agree 100%. When quite simple functionality can't be added, it's almost
certainly a design flaw. I've been pushing this since 2017.

On Wed, Jun 17, 2020 at 2:16 PM Mikhail Paulyshka [e-mail]
wrote:

@BillyONeal https://github.com/BillyONeal
[image: image]
https://user-images.githubusercontent.com/704382/84934308-d373d200-b0df-11ea-9b1a-5f169de18eee.png

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vcpkg/issues/1015#issuecomment-645539217,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADTIYWCXHWGNRJP4CM7LDXTRXECBVANCNFSM4DJXKC3A
.

[ppatpat]

@BillyONeal

Supported doesn't mean "currently getting new features", it means 'will continue to work and you'll get critical bugfixes'.

Are you going to code only for the OS and Compiler that is today "receiving new features"?

Microsoft will not mint the necessary SHA-1 certificate for a new product even in dual signing mode

We can avoid discussing about this; it was said before that the goal is to get a vcpkg.exe able to "target" XP not running on it.

I'm not making a statement about enjoyment, I'm making a statement about investment.

And my point is that we are not asking this because we are XP lovers; unfortunately XP is still out there and ignoring it does not make it disappear

Thanks for your patience.

[Mixaill]

We can avoid discussing about this; it was said before that the goal is to get a vcpkg.exe able to "target" XP not running on it.

Yeah, just to clarify, I have no plans to make vcpkg runnable on Windows XP, only add ability to create a triplet which produces compatible with Windows XP binaries.

[orinem]

"The design flaw is in XP, that it cannot be safely connected to the internet."

Irrelevant to the current discussion IMO. Not all copies of XP still in use are connected to the internet.

Our product doesn't require connection to the internet, nor even a network connection. By its very nature and purpose, it has to run on XP - whether it communicates over a USB cable, external storage, a back-to-back ethernet cable, an non-internet connected LAN or an internet connected LAN is up to the customer.

[VikingExplorer]

In my 3 year battle, it was NEVER about running vcpkg ON XP. It was ALWAYS
about targeting XP. They refused.

One discussion got so heated, the whole issue was deleted from GitHub. I
made all the same arguments you are making now.

On Wed, Jun 17, 2020 at 2:36 PM orinem [e-mail] wrote:

"The design flaw is in XP, that it cannot be safely connected to the
internet."

Irrelevant to the current discussion IMO. Not all copies of XP still in
use are connected to the internet.

Our product doesn't require connection to the internet, nor even a network
connection. By its very nature and purpose, it has to run on XP - whether
it communicates over a USB cable, external storage, a back-to-back ethernet
cable, an non-internet connected LAN or an internet connected LAN is up to
the customer.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vcpkg/issues/1015#issuecomment-645548835,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADTIYWEU2SSCR5IQRDCBLN3RXEEJFANCNFSM4DJXKC3A
.

[orinem]

"And my point is that we are not asking this because we are XP lovers; unfortunately XP is still out there and ignoring it does not make it disappear"

Indeed. We too would like to drop support for it, but while we can still target it and customers are still using it, it isn't going away as far as we are concerned.

[BillyONeal]

@BillyONeal

I see, it looks like it was locked because discussion there devolved into the kinds of personal attacks I'm starting to see here. Many of them from the same people! :( I don't want to lock the issue or the PR but if folks keep up personal attacks and similar we have no choice.