Support Windows Vista/Server 2008 SP2 and later

[josephsl]

Hi,

The following is meant to serve as a public discussion about dropping support for NT 5.x (XP/Server 2003) and posted for record keeping purposes:

NVDA is opening the doors of opportunities for thousands around the world, with NVDA running on various versions of Windows from XP onwards. Although it is a good idea to allow NVDA to leverage features from old Windows releases, we cannot forget that technology is changing rapidly these days, and sometimes it is necessary to say goodbye to old tricks as we move on.

Due to the fact that Microsoft stopped supporting Windows XP and Server 2003 in 2014 and 2015, respectively, and to leverage newer API's offered by newer Windows releases and remove legacy code, I propose upgrading the code base to support Windows Vista and Server 2008 Service Pack 2 and later.

The justifications are:

1. Windows XP/Server 2003 does not have a user-visible concept of elevated processes and User Account Control (UAC). With support for Vista and Server 2008, NVDA can assume that, for the most part, it'll run as a standard user, thereby improving security (exceptions include when UI Access token is granted and if UAC is turned off).
2. A dedicated service for Windows XP/Server 2003 is no longer necessary. The service is needed to allow NVDA to run at logon alongside other services in Windows XP/Server 2003 because there's no proper concept of sessions prior to Windows Vista. With Vista/Server 2008 and later, all that's needed is a session 0 copy of NVDA that'll let Ease of Access know that it should receive certain privileges and run in session 0 (EOA facility is used properly in Windows 8 and later).
3. Calling certain Windows API functions becomes simplified. For instance, in app module handler, one needs to keep an eye on differences between Windows XP and later Windows releases when querying executable image name and other information. Support for Vista/Server 2008 would mean simplifying this check by assuming that the new routine will be there (unless changed by Microsoft in a future build of Windows 10).
4. UIA checks are simplified. As noted by several NVDA developers, UIA cannot be used properly in XP. Although Windows 7 introduces a more "proper" UI Automation implementations, it is sometimes error-prone, thus workarounds were devised. Apart from this, support for Vista would mean one less check for UIA availability.
5. Potentially improved compatibility and standings with Windows kernel. When NVDA is compiled and linked, subsystem value is set to 5.0x in order to guarantee compatibility with Windows XP and Server 2003 (5.01 for XP 32-bit, 5.02 for Server 2003 and XP Pro X64). Supporting Vista and Server 2008 means just one subsystem can be set (6.00), potentially improving compatibility and standings with Windows kernel in that the C runtime can allow NVDA to leverage features in Vista and later.
6. Simplified build environment. A person who wants to compile NVDA from source will need to install Windows SDK 7.1A in order to provide compatibility with XP and Server 2003. This is no longer required when supporting Vista and Server 2008 - one must check Windows SDK 7.1A in Visual studio 2015 installer, and by default, this option isn't checked.

Drawbacks:

1. Loss of market and portions of user base. NVDA is currently one of the last screen readers to support XP and Server 2003. Pulling the plug means we would lose some users who insist on using XP for various reasons.
2. Massive code changes and testing required. Removing support for a Windows version isn't trivial, as careful testing must be done in order to avoid introducing regressions.
3. Resources are inadequate. There are higher priorities, including braille support, Windows 10 issues and workarounds, supporting different office suites and more.

Other things to consider:

1. Why do we need to support Vista and Server 2008? First, even though Vista will exit extended support in April 2017, Server 2008 (same code base as Vista SP1) will be supported until 2020, and there might be server administrators who are using Server 2008 GUI mode with NVDA.
2. Why not Windows 7/Server 2008 R2 and later? Although Windows 7 is used by many and allows NVDA to assume that UIA is always available, cutting off Vista support means losing support for Server 2008 (see above) and not many can afford to upgrade to Windows 7 and later yet.
3. Isn't XP supported on specialized devices? Yes, but these devices (ATM's, point of sale and other embedded and specialized devices) are not general-purpose computers, and it would not be advisable to support NVDA running on these devices.

Things to do if this proposal is adopted:

1. A special interest group )SIG) should be formed to coordinate this effort.
2. People working on this should go through the current NVDA source code and identify code paths that could benefit from moving to support Vista/Server 2008 SP2 and later.
3. For each code path, people should assess potential regressions and workarounds.
4. A snapshot series should be created to allow users to test builds from this project.
5. An exit plan must be formulated to allow XP users to flow into the new version by announcing the last version of NVDA that'll support XP/Server 2003. This should be done at least two NVDA releases prior to removing support for XP and Server 2003 so people can prepare.
6. The last version of NVDA that'll support XP/Server 2003 should be archived publicly so people can download old releases. This version should not support updating to newer builds.
7. Translators and add-on writers should be informed about this in order to allow translators to alert local user communities and add-on writers to plan transition steps for their add-ons.

If this proposal is adopted, I expect this project to take at least nine months to implement: at least six months from start of design/implementation/testing to announcement of the last NVDA version to support XP, with at least three months after that for people to plan ahead for this transition.

Thanks.

[LeonarddeR]

I am a great advocate of this. Honestly, I've never understood why we still do support XP, apart from the huge amount of changes it requires to drop support for it. We should realise that dropping XP support doesn't mean at all that XP users are stuck, they just won't be able to use the most recent version of XP. If the inability to use the most recent version has security implications, we can always consider backporting relevant features. For example, if the latest XP proof version is 2017.3 and the most recent NVDA is 2018.4, we can still release 2017.3.1 for the XP user base. The most major concern I have with keeping XP support, is that we do not motivate people to upgrade to a newer version of Windows. I agree that we should support people who can't afford upgrading, but a major drawback of the current situation is that people can just lazily stick to XP, since their screen reader still supports it. I think a good first step to bring this ticket forward is to add a new dialog to NVDA which gives information to XP users about security implications of using it.

[jscholes]

Windows XP/Server 2003 does not have a user-visible concept of elevated processes and User Account Control (UAC). With support for Vista and Server 2008, NVDA can assume that, for the most part, it'll run as a standard user, thereby improving security (exceptions include when UI Access token is granted and if UAC is turned off).

A significant number of users of Vista and later completely discard the new security model, many others will use it slightly differently from how it comes set up out of the box. As a result, NVDA can not, and should not, make lazy assumptions when it comes to security. Not to mention the fact that all the code to handle UAC and elevated permissions has already been written, and will need to continue to be improved no matter what.

A dedicated service for Windows XP/Server 2003 is no longer necessary.

The commit history for nvda_service.py shows that the last truly XP-related work was done in 2013, with the last service-related bugfix not performed since June 2011. So supporting an XP service is not a drain on developer resources by any means.

With Vista/Server 2008 and later, all that's needed is a session 0 copy of NVDA that'll let Ease of Access know that it should receive certain privileges

Again, negating any benefit from making security assumptions, because NVDA will still need to concern itself with security differences between desktop and secure screens.

in app module handler, one needs to keep an eye on differences between Windows XP and later Windows releases when querying executable image name and other information.

This code has already been written and has no impact on the users of appModuleHandler.AppModule._setProductInfo, i.e. the developers of app modules. I'd wager that most people who develop app modules have never needed to concern themselves with this difference and probably don't even know it exists, especially given the fact that most of them will use the convenient productName and productVersion attributes.

Support for Vista/Server 2008 would mean simplifying this check by assuming that the new routine will be there (unless changed by Microsoft in a future build of Windows 10).

The whole fact that this difference existed in the first place shows that developers can't assume anything about Windows API changes. Whether NVDA drops XP support or not, testing will still be required with new Windows versions to ensure that Microsoft haven't introduced a better way of accomplishing something or deprecated a function that NVDA makes use of.

A person who wants to compile NVDA from source will need to install Windows SDK 7.1A in order to provide compatibility with XP and Server 2003. This is no longer required when supporting Vista and Server 2008 - one must check Windows SDK 7.1A in Visual studio 2015 installer, and by default, this option isn't checked.

If this is documented for people wishing to build or run NVDA from source, then this isn't a significant problem. The only slight issue is that the older SDK will take up extra disk space.

[jcsteh]

Thanks for taking the time to thoroughly outline your thoughts.

At this stage, there is no notable benefit to either users or developers to drop support for XP/Server 2003. In contrast, there is a significant amount of work to "upgrade the code base", with a significant potential for regressions. Furthermore, it would negatively impact the users still using these operating systems (at least 5.6%). To put this another way, imagine explaining to those users that we're dropping support for them without being able to provide an actual practical reason. We can't even argue we're sacrificing 5% for the majority because the majority don't gain anything.

At some point in the future, there will undoubtedly come a point where our support for XP/Server 2003 will hold us back in some significant way. Alternatively, it may be that there are too many unresolved issues specifically related to these operating systems that we obviously don't want to fix. When that happens, we should and will consider dropping support. At that point, there will be a clear reason: if we continue to support XP, we can't have feature x... or we're spending x hours doing additional testing on XP.

Even when that time comes, it is not an efficient use of resources to go through the code base, hunting for and removing XP/2003 specific code, upgrading to a newer SDK, etc. We should do those things as and when they become necessary, because again, they take time and could cause regressions. Obviously, there are certain things that are easy to remove and those are fine (e.g. the service). The key point is that we should invest effort as it becomes necessary to provide benefit, not for the sake of principle or using the latest and greatest.

I certainly agree that we will need an exit plan, but this will need to be developed when we decide to make the change, taking into account all relevant factors at the time.

Finally, I'll address a few specific points:

1. Security: Dropping XP/2003 doesn't impact our code in terms of security at all. That is, there are no specific code paths or assumptions relating to security in XP/2003.
2. Service: It's true that we don't need the service post XP/2003, but as @jscholes noted, it does not require any development investment at all.
3. Conditional Windows API calls: Yes, there are some conditional checks for API functions, but there aren't many and they don't complicate the code in a notable way.
4. UIA: We disable UIA for Vista as well, so this code would be unchanged.
5. Motivation to upgrade: It's not our responsibility and is beyond our scope to teach or enforce security principles beyond NVDA itself. Again, imagine telling 6% of users "we're going to drop support for you just to make you upgrade to a newer version of Windows because we're being responsible technology citizens".

I'm closing this issue. If you have any major questions you feel haven't been answered, feel free to comment here.

[josephsl]

Hi, after thinking about it last night, I came to the conclusion that private research would be the more appropriate alternative at this time – that is, allow interested community members to research this further on their own or collaboration with other parties. I recommend reopening this issue when the opportunity presents itself (five percent of users using XP is a statistically significant evidence, and this gives us a more clear picture as to what’s at stake). Thanks for clarifying things. From: James Teh [mailto:notifications@github.com] Sent: Wednesday, January 11, 2017 5:03 PM To: nvaccess/nvda <nvda@noreply.github.com> Cc: Joseph Lee <joseph.lee22590@gmail.com>; Author <author@noreply.github.com> Subject: Re: [nvaccess/nvda] Support Windows Vista/Server 2008 SP2 and later (#6718) Thanks for taking the time to thoroughly outline your thoughts. At this stage, there is no notable benefit to either users or developers to drop support for XP/Server 2003. In contrast, there is a significant amount of work to "upgrade the code base", with a significant potential for regressions. Furthermore, it would negatively impact the users still using these operating systems (at least 5.6%). To put this another way, imagine explaining to those users that we're dropping support for them without being able to provide an actual practical reason. We can't even argue we're sacrificing 5% for the majority because the majority don't gain anything. At some point in the future, there will undoubtedly come a point where our support for XP/Server 2003 will hold us back in some significant way. Alternatively, it may be that there are too many unresolved issues specifically related to these operating systems that we obviously don't want to fix. When that happens, we should and will consider dropping support. At that point, there will be a clear reason: if we continue to support XP, we can't have feature x... or we're spending x hours doing additional testing on XP. Even when that time comes, it is not an efficient use of resources to go through the code base, hunting for and removing XP/2003 specific code, upgrading to a newer SDK, etc. We should do those things as and when they become necessary, because again, they take time and could cause regressions. Obviously, there are certain things that are easy to remove and those are fine (e.g. the service). The key point is that we should invest effort as it becomes necessary to provide benefit, not for the sake of principle or using the latest and greatest. I certainly agree that we will need an exit plan, but this will need to be developed when we decide to make the change, taking into account all relevant factors at the time. Finally, I'll address a few specific points: 1. Security: Dropping XP/2003 doesn't impact our code in terms of security at all. That is, there are no specific code paths or assumptions relating to security in XP/2003. 2. Service: It's true that we don't need the service post XP/2003, but as @jscholes <https://github.com/jscholes> noted, it does not require any development investment at all. 3. Conditional Windows API calls: Yes, there are some conditional checks for API functions, but there aren't many and they don't complicate the code in a notable way. 4. UIA: We disable UIA for Vista as well, so this code would be unchanged. 5. Motivation to upgrade: It's not our responsibility and is beyond our scope to teach or enforce security principles beyond NVDA itself. Again, imagine telling 6% of users "we're going to drop support for you just to make you upgrade to a newer version of Windows because we're being responsible technology citizens". I'm closing this issue. If you have any major questions you feel haven't been answered, feel free to comment here. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#6718 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AHgLkNJRNbf_ow6QalVuhO6JQesyirLLks5rRXvLgaJpZM4LgOmK> .

[LeonarddeR]

@jcsteh commented:

I certainly agree that we will need an exit plan, but this will need to be developed when we decide to make the change, taking into account all relevant factors at the time

Since the move to python 3 seems to mean end of support for Windows XP, I think that it might be a good idea to incorporate the said exit plan in the python 3 transition plan (#7105). If keeping XP support has more priority than the transition to Python 3, the latter should probably be delayed until Python 2.7 end of life, which will be at 2020-01-01.

[josephsl]

Superseeded by #7546. Thanks.

[LeonarddeR]

@josephsl commented on 31 aug. 2017 06:37 CEST:

Superseeded by #7546. Thanks.

Please note that this issue brings up points that are not covered in #7546. I think we shouldn't start actively removing every bit of xp related code from the code base just yet, but there are some points that can be done without much effort. This includes:

@josephsl commented on 11 jan. 2017 07:11 CET:

2. A dedicated service for Windows XP/Server 2003 is no longer necessary. The service is needed to allow NVDA to run at logon alongside other services in Windows XP/Server 2003 because there's no proper concept of sessions prior to Windows Vista. With Vista/Server 2008 and later, all that's needed is a session 0 copy of NVDA that'll let Ease of Access know that it should receive certain privileges and run in session 0 (EOA facility is used properly in Windows 8 and later).
3. Calling certain Windows API functions becomes simplified. For instance, in app module handler, one needs to keep an eye on differences between Windows XP and later Windows releases when querying executable image name and other information. Support for Vista/Server 2008 would mean simplifying this check by assuming that the new routine will be there (unless changed by Microsoft in a future build of Windows 10).
4. Potentially improved compatibility and standings with Windows kernel. When NVDA is compiled and linked, subsystem value is set to 5.0x in order to guarantee compatibility with Windows XP and Server 2003 (5.01 for XP 32-bit, 5.02 for Server 2003 and XP Pro X64). Supporting Vista and Server 2008 means just one subsystem can be set (6.00), potentially improving compatibility and standings with Windows kernel in that the C runtime can allow NVDA to leverage features in Vista and later.

[jcsteh]

@leonardder commented on 31 Aug 2017, 16:11 GMT+10:

With Vista/Server 2008 and later, all that's needed is a session 0 copy of NVDA that'll let Ease of Access know that it should receive certain privileges and run in session 0 (EOA facility is used properly in Windows 8 and later).

We already use Ease of Access in Windows 7. The Windows 7 implementation has some problems which we work around with nvda_eoaProxy, but we don't need any special session 0 stuff. Long story short: that work is already done. All we have to do is drop the service, which is now only required for XP.

Dropping the service also eliminates the major reason we depend on pywin32. Currently, I think we do still use it for clipboard stuff and OLE embedded objects, but we have a better chance of eventually switching that to ctypes/comtypes.