Work around start-up crash in Adobe Reader protected mode (#13413)
Fixes #11568
Partial fix for #12920
Summary of the issue:
Recent versions of Adobe Reader introduced a Protected Mode, where by the Adobe Acrobat process has less privileges and is sandboxed. This ensures that insecure PDFs do not have a chance to affect the rest of the Operating System.
By default Adobe Reader is configured to enter its Protected mode on start-up, and to set the 'isAppContainer' attribute on its process token.
There seems to be a bug however, either in Adobe Reader, the Windows OS, or NVDA (NV access and Adobe cannot be sure) that causes the Adobe Reader process to become unstable when NVDA tires to register IAccessible2. Specifically, the call to CoGetPSClsid seems to start making things unstable. The further call to CoRegisterPSClsid fails, and then eventually the process completely crashes randomly in places such as TSF initialization.
The upshot is that If Adobe Reader is started when NVDA is running, many errors are written to NVDA's log, and Adobe Reader closes straight away.
Description of how this pull request fixes the issue:
NVDAHelper's IAccessible2 registration code now checks if the process token has the 'IsAppContainer' attribute, and of so refuses to install IAccessible2 support.
Note that Adobe Reader itself does not require IAccessible2 to function.
Also, the 'IsAppContainer' is only set on very heavily sandboxed sitations, and is not the same as the app container that is used for Windows Desktop Bridge apps. Thus, refusing to install IAccessible2 into processes with the 'IsAppContainer' attribute has no other known side affects.
