lldb (and LLVM) supports running on Windows Vista and newer versions of Windows. I would like to raise the required version for lldb only (not LLVM) to Windows 10 RS5 (released in Nov 2018).
Motivation
I am trying to implement the Windows Pseudo Console API in lldb (also called ConPTY), which is the equivalent of a PTY on POSIX systems. lldb-dap uses a PTY on Linux and macOS to separate the output of the server from the the one of the debuggee. Using a ConPTY on Windows would allow to enable ~10 lldb-dap tests on Windows.
As @AaronBallman noted in a similar RFC, according to Desktop Windows Version Market Share Worldwide, this would impact less than 3.5% of Windows users. It’s unclear how many users are using Windows 10 with a version prior to 1809, but I think it’s safe to say the vast majority are running on the latest update.
This matches the details I was finding online, which is not too different of a picture from when this was last discussed (then it was 4% of Windows users on 7 & 8).
This is the consequence I really don’t like, but it’s more about ethics than about technological concerns. I just don’t like seeing tools which used to work on a platform no longer work on the assumption everyone upgrades their OS (which contributes to creating e-waste and needless expense). If this was just “you need a new Windows to build lldb”, I think that’s reasonable. But “you need the latest Windows to run lldb” feels like an unfortunate situation. The way we usually handle this is to dynamically load the APIs and gracefully fall back if the API isn’t available. Is that not a possibility in this case?
On the other hand, supporting arbitrary versions of Windows is also costly. These versions of Windows have been deemed obsoleted by Microsoft for a reasonable period of time. I don’t believe that we handle Apple platforms similarly - do we still test/have LLVM and LLDB running on unsupported versions of macOS?
Agreed. I’m not worried about Windows 7 and Windows 8. I am more worried about early Windows 10 because that’s “the previous release” of Windows as far as a lot of folks are concerned. Windows 10 is still roughly 40% of the market and we don’t know how disruptive this will be there. This bumps beyond what Microsoft EOLed (Windows 10 1607 is an LTS release which seems to still be in service for about another year)
It is possible. My concern is how well lldp-dap is going to work on Vista/7/8 without ConPTY support.
To give some context: lldp-dap and lldb on Linux/macOS rely on the PTY to separate the output of the debuggee from the debugger. On Windows, we currently do not make that separation, causing some tests to fail. Adding support for the ConPTY would allow to enable those tests on Windows.
If we add ConPTY support through dynamic loading, lldb-dap and lldb would behave on Vista/7/8 just as they do now, i.e nothing would change. The only benefit would be that we get to run more lldp-dap tests on Windows and Windows 10+ users get a better experience.
I think I need to figure out “how much of a better experience that is”. If lldb-dap is unusable on Windows without the ConPTY (I don’t think that’s the case), then I think we should bump the requirement as the tool does not work. If the only benefit we get is adding some more tests, I’m happy to do dynamic loading in order to maintain backward compatibility.
Thank you for checking on that! FWIW, I agree with you that if if lldb-dap is significantly worse without ConPTY, we should just do the jump (at least for that tool, if not for all of LLVM).
FWIW, this is maybe splitting hairs - but technically, if it’s only `lldb-dap` that requires it, we’d ideally just bump the requirement for `lldb-dap` but not all of `lldb`. It’s quite possible that the number of users of `lldb-dap` (with integration into fancy IDEs and all) on older versions is low, while there could be some users who would want to just do plain command line debugging, with less requirements on fancy new IDEs and such.
Practically, I understand that it may be hard to bump the requirement just for one tool under the LLDB subproject, instead of bumping it for all of them though. (Or does `lldb-dap` with ConPTY support require the matching ConPTY support in the main `liblldb.dll` as well?)
Anyway, thanks for looking into how hard it would be to do it with dynamic loading!
Since the primary concern here is the PTY support, I wanted to point out that we don’t necessarily need to give up supporting older versions of Windows as a remote debug target, where a more modern LLDB runs on a modern OS and connects to a debugserver on the older OS.
Oh, that’s completely different then. I can see the value in that. I think it can be good to consider the release period - the 1807 (RS5) release was 10/2/18. That is nearly 7 years ago, so it’s not an unreasonable period. But, bumping up to windows 10 at least would be good.
My concern with doing something like this is that it becomes harder for users to use the suite of related tool when they’ve got different platform (hard) requirements. For example, I’d even push back on lldb having different platform requirements from clang; the two are used together often enough in practice, it would be a real shame for one to work and the other to fail on the same platform. It’s not that it’s an impossibility we’d never do, more just something I’d personally prefer to avoid when possible.
After some testing on Windows with the current lldb-dap, i.e without the PseudoConsole, lldb-dap I think that lldb-dap is very much usable. I was able to step through a simple C++ program in VSCode, print variable values, the backtrace etc.
However, I don’t get any output from the program:
Using the PseudoConsole will allow us to get the program’s STDOUT (and STDIN) from lldb-dap, just like on POSIX platforms.
In parallel, I was able to dynamically load the CreatePseudoConsoleAPI which is needed for this update. This means we can still have an executable which runs on Vista/7/8 and also on Windows 10/11, but with the PseudoConsole enabled on these versions.
Given that, I think we don’t need to bump the Windows version, because despite missing the program output, lldb-dap is still usable on Windows without the PseudoConsole (stepping, stacktrace, variable printing work), and lldb can print the output of the program when running from the CLI.
I think we can disregard/close this RFC as “will not be implemented”. With the latest changes in https://github.com/llvm/llvm-project/pull/168729, there is no need to update the minimum Windows version.
