Attachment NVDA_Install_Error_Log_2015-06-12.txt added by k_kolev1985 on 2015-06-20 07:57
Description:
Update:
File added from Trac
NVDA_Install_Error_Log_2015-06-12.txt

Attachment NVDA_Install_Error_Log_2015-06-19.txt added by k_kolev1985 on 2015-06-20 07:58
Description:
Update:
File added from Trac
NVDA_Install_Error_Log_2015-06-19.txt

Comment 1 by jteh on 2015-06-22 01:59
It's actually creating the website shortcut in the Start Menu that fails. Interestingly, creating the NVDA shortcut in the Start Menu happens before this and works fine. I see we don't pass all strings as Unicode. Python normally just assumes ASCII and converts in this case, but it seems ctypes does something different behind the scenes and I'm not exactly sure what. I'm not certain this is the issue, but it's the best I can come up with. When i get a chance, I'll try using all Unicode paths in a try build and perhaps you can see if that works.

@k-kolev1985 I know that this might be difficult to test, but do you think this issue is still occuring? cc: @josephsl

@Adriani90 Since there hasn't been any work done in order to fix this in NVDA, I doubt that is fixed now. I may be able to test it in one of my virtual machines these days and report the results here. I just need to find some free time to do it. :-)

@Adriani90 Yes, the bug is still reproducible with latest NVDA alpha snapshot and Windows 10 build 18323 Insider Preview, as described in the first post here. But if I check the beta option to use Unicode UTF-8 for locale support in Windows (under the combobox for selecting the language for non-Unicode programs), the problem does not occur, even if the display/UI language and the language for non-Unicode programs don't match.

I assume we can somehow fix this when switching to Python 3.

@k-kolev1985: Could you please test this with an Alpha version of NVDA? I assume it has been fixed implicitly, though if it is fixed, I think it deserves a change log entry.

I've tested with NVDA snapshot alpha 18450,8c27752f and the error during install still occurred. It wasn't on a clean install of NVDA, but I think that does not matter. The testing is done on Windows 10 (build 18963 I think), 32-bit, in bulgarian, with language for non-Unicode programs set to "English U.S.".

OK, here is the log from the failed installed of the alpha build.
NVDA_Log_2019-08-27_#5166.log

This looks like an issue in the WshShell interfaces. When I'm not using dynamic dispatch, the issue seems to be that the path is silently converted to mbcs, any unicode characters get lost and are replaced by a question mark. However, question marks are not allowed in file names, and therefore neither in shortcut names.
We could solved this by encoding to mbcs with errors="ignore" and than decoding back, however, this will cause anything that's not accepted by mbcs to get lost in the process.

@k-kolev1985 Couldn't you set the language for non-unicode programs to Bulgarian instead, or does that cause other issues for you?

@LeonarddeR I don't do that change intentionally. Neither are the other bulgarian Windows users. We know that we should set the language for non-unicode programs to "Bulgarian" for best results. But by mistake it may happen. Once, I was configuring a new virtual machine with Windows 10 and I forgot to set the language for non-unicode programs to "Bulgarian" and had to deal with problems with text in cyrillic not displaying correctly in non-unicode programs and text files, before I realized my mistake. Recently it happened to a friend of mine - he forgot to set the language for non-unicode programs to "Bulgarian" and got the same error during install of NVDA. So, such configuration is not intentional, but by mistake. I don't know of cases in which is/was required to set the language for non-unicode programs to something other than "Bulgarian" for some purposes, but there may be such cases - it wouldn't surprise me.

We've seen this problem before in #6326. Although this was reported as fixed in #6326 (comment), I don't think the underlying problem was really fixed. Perhaps the localisation worked around it or the user changed system settings.

I did a pretty in-depth analysis of this and provided a possible solution in #6326 (comment) . Including it below since that issue is now closed.

It looks like this happens for any character that can't be encoded using the system ANSI code page:

>>> u"\u2022".encode("mbcs")
'\x95'
>>> u"ț".encode("mbcs")
'?'
>>> u"‣".encode("mbcs")
'?'

If I try creating the shortcut with either of the latter two, I get an exception.

Even though we pass the string as Unicode, wScript.Shell seems to convert it to ANSI. It seems others have hit this problem too. Note that this is definitely not a file system issue; you can quite happily write a file containing these characters if you use native Unicode:

>>> file(u"c:\\users\\jamie\\junk\\jtd‣bar", "w")
<open file u'c:\\users\\jamie\\junk\\jtd\u2023bar', mode 'w' at 0x070573E8>

I wonder whether we'll need to switch to an alternative way of creating these shortcuts. We should be able to do this using IShellLink and friends. IShellLink specifically mentions IShellLinkA and IShellLinkW interfaces, which suggests the latter does explicitly do Unicode. See this article for further details. I did a bit of investigation on this in the labyrinth that is MSDN:

1. I found CLSID_ShellLink in ShObjIdl.idl (00021401-0000-0000-C000-000000000046). Unfortunately, it looks like there's no typelib registered for this.
2. There are also dispatch interfaces for most (all?) of this stuff. You access them by using the "shell.application" progId. See Scriptable Shell Objects and ShellLinkObject.Save for details/examples.