edit-git-bash: update LCID when updating resources

When this developer compiled `edit-git-bash.c` to an EXE,
`edit-git-bash.exe` did not behave as expected. Two string tables appeared
in the resources section of the resulting `git-bash.exe` executable.

Furthermore, this did _not_ occur when installing Git for Windows 2.7.2
using the InnoSetup installer on a test VM. However, this developer did
confirm a problem with this program.

When installing Git for Windows 2.7.2 and choosing the Windows Command
Console as the terminal emulator, the string resources for `git-bash.exe`
were updated. In fact, all resources were wiped out of `git-bash.exe` and
a new STRINGTABLE resource was created containing the command to execute
to start the BASH shell in a Windows Command Console. Resources that were
wiped out included the Git for Windows icons that are embedded in the
`git-bash.dll` (the file size went from 137KB to 28KB). This appears to be
due to the fact that
1. This DLL is not recompiled from source whenever an installer is
generated
2. The existing `edit-git-bash.dll` was compiled from an earlier version
of the source which replaced resources instead of just updating them

When this developer compiled the current source of `edit-git-bash.c` and
proceeded to run the resulting EXE on `git-bash.exe`, `git-bash.exe` now
contained two string tables in its resources section of the executable,
both with ID 1. How can this be? It turns out the original `git-bash.exe`
string table resources were added using LCID 1033 (0x0409 a/k/a en-US
locale). The EXE produced by the current `edit-git-bash.c` updated
`git-bash.exe` resources using the LCID 1024 (0x0400, language-neutral,
default sub-language). Since the source code is now _updating_ the
resources, and not replacing them, the net effect was to add a second
string table. Apparently, then, string table are uniquely identified by
their ID and (at least) their locale.

Why does this matter? Because my computer is set to LCID 1033 (en-US),
so when `git-bash.exe` was executed, it used the original string resources
(the one matching my current computer's Locale) and started the BASH in
mintty, not the Windows Command Console.

Furthermore, when looking at the embedded resources for the installation
of Git for Windows 2.7.2 set to use the Windows Command Console for the
BASH, it worked correctly even though the string resources were for LCID
1024 (the neutral locale). That's because there was only one STRINGTABLE,
(since the resources in that version of the DLL were being completely
replaced) and the neutral locale is the fallback locale. Since a string
table resource for LCID 1033 could not be found, the neutral resources were
used, resulting in correct behavior.

This commit, then, changes the updating of the string resources in
`git-bash.exe` such that the new string resources are written in LCID
1033, just as the original resources of `git-bash.exe` are. This will
prevent additional string table resources (in different locales) from
being created and ensure that the proper resources are updated, resulting
in correct behavior.

Signed-off-by: Craig E. Shea <[email protected]>

Author: fourpastmidnight

edit-git-bash.c

@@ -60,7 +60,7 @@ int edit_git_bash(LPWSTR git_bash_path, LPWSTR new_command_line)
 		return 2;
 
 	if (!UpdateResource(handle, RT_STRING, MAKEINTRESOURCE(1),
-			MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
+			MAKELANGID(LANG_ENGLISH, SUBLANG_ENGLISH_US),
 			buffer, alloc))
 		result = 3;