Developer installation from within Visual Studio

Makefile.DevInstall

 #
 # NMAKE is a 32-bit application, which makes it problematic to make 64-bit registry entries with the standard command-line tools such as "reg.exe".

[Wladimir Palant, 2013/06/18 15:18:33]

Quite frankly, I don't think that we want to use nmake in this project -
maintaining it is a pain. You can use a custom build step in the MSVS project to
run any commands you want
(http://msdn.microsoft.com/en-us/library/hefydhhy%28v=vs.80%29.aspx). And we
will soon migrate the build system to gyp which will make changing the project
files less awkward.

[Wladimir Palant, 2013/06/19 07:14:15]

So far no contradictions - that's why you made it a separate project, it can be
run separately.
Yes, we will merely use gyp to generate the project files because editing them
(with eight configurations) manually is messy.
You can use the AfterClean target for that:
http://msdn.microsoft.com/en-us/library/ms366724.aspx
While I didn't quite get the issue, I doubt that there is something you can do
with nmake here that cannot be done with a regular project file.

[Eric, 2013/06/19 15:22:54]

Probably. If we want to rewrite it later, I won't care. This whole thing was
intended to be a one-day hack and it's been way more than that, fighting random
Microsoft nonsense.

I've been more worried about the result (getting the right registry keys) than
control structure (using nmake). Once we have the right results, writing a
different control structure should be fairly straightforward. If you want to use
'gyp' to generate control structure, it's fine with me; I don't have a strong
opinion about it.

The parameter passing issue has to do with string quoting and spaces in path
names. My original idea was to write out a .reg file and import it with a single
command. That doesn't (easily) work because spaces need backslash escapes inside
the file. 'reg.exe' does not require them to be quoted on the command line, so I
went with multiple invocations of that tool.

[Eric, 2013/06/20 14:13:47]

Well, I could. But it's going to make me really cranky. I'm already fed up with
dealing with undocumented and badly documented Microsoft nonsense. Changing to
another project type and another packaging for the command line tools (a bunch
of batch files) is days long, not hours. It's basically starting from scratch on
half the project.

And it's going to be harder to understand, because whatever its faults, NMAKE at
least has a certain amount of modularity built in. The simple alternatives do
not. The other ways I know of dealing with this using standard tools are
inferior in terms of comprehension and maintenance.

The time to revisit this is when you convert to 'gyp'. There's necessarily going
to be some amount of overlap when that happens. Might as well address it later.

 # As a 32-bit application, when it loads "reg.exe" from the ordinary directory, %WINDIR%\System32, the WOW64 system redirects it load from %WINDIR%\SysWOW64.
 # So even if you explicitly put in the 64-bit path, because NMAKE is 32-bit it will load the 32-bit version anyway.
 # To get around this, we check for the existence of %WINDIR%\sysnative\reg.exe, which if present means a few things.
 # -- 1. We're running on Windows Vista or later, because 64-bit XP doesn't have "sysnative."
 # -- 2. We're running on a 64-bit version of Windows.
 # -- 3. We're running from a 32-bit process, which should always be true about NMAKE.
 #
 # See http://ovidiupl.wordpress.com/2008/07/11/useful-wow64-file-system-trick/ for more details.
 #
 !if [cmd /c if exist %WINDIR%\sysnative\reg.exe exit /b 1]
 REG=$(WINDIR)\sysnative\reg.exe
-CMD=$(WINDIR)\sysnative\cmd.exe
 X64=1
 !else
 REG=$(WINDIR)\reg.exe
 !message Warning: Developer installation not tested on XP or 32-bit Windows.
 !endif
 
 !message DLL=$(DLL)
-!message DLL32=$(DLL32)
 
 #
 # Default (first) target is a help message, in case anybody runs it outside Visual Studio.
 #
 help:
         @echo This Makefile is intended to be run from within Visual Studio to provide developer installations of Adblock Plus for IE.
 
-build: register64 copy
+build64: register64 check_BHO64 copy
 
-clean:
+rebuild64: clean64 build64
 
-rebuild: clean build
+build32: register32 check_BHO32 copy
+
+rebuild32: clean32 build32
 
 #
 # We're using "reg.exe" for the HKCU keys because the one with the DLL path name would need to be backslash-quoted to go into a .REG file.
-# We're using "regedit.exe" for the HKLM key because (by default) "reg.exe" does not trigger UAC to prompt the user for privilege elevation and will just fail instead.
 #
 # Note that the CLSID is register in HKCU, which avoids the need to elevate with UAC to high integrity in order to write.
 # Also note that the "Browser Helper Object" key is in HKLM, which is required because of IE.
 # IE only scans in HKLM for BHO entries.
 # IE does not scan HKCU for BHO entries, contrary to some sources online.
 # The tale for this is that it would be a security violation to allow an Administrator to run a BHO from HKCU,
 #    since anything might have written to HKCU (a low-integrity part of the registry).
 # On the other hand, IE could just run low-integrity BHO in a low-integrity container, but no, it can't do that.
 #
-
-# add "HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects\{FFCB3198-32F3-4E8B-9539-4324694ED664}" /v NoExplorer /t REG_DWORD /d 1 /f >nul
-
 register64:
         @echo Start 'register' action.
         $(REG) add HKCU\Software\Classes\CLSID\{FFCB3198-32F3-4E8B-9539-4324694ED664} /ve /d "Adblock Plus for IE Browser Helper Object" /f >nul
         $(REG) add HKCU\Software\Classes\CLSID\{FFCB3198-32F3-4E8B-9539-4324694ED664}\InprocServer32 /ve /d "$(DLL)" /f >nul
         $(REG) add HKCU\Software\Classes\CLSID\{FFCB3198-32F3-4E8B-9539-4324694ED664}\InprocServer32 /v ThreadingModel /d "Both" /f >nul
-        $(CMD) /c $(WINDIR)\regedit.exe /s <<temporary.reg
-Windows Registry Editor Version 5.00
-
-[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects\{FFCB3198-32F3-4E8B-9539-4324694ED664}]
-@="Adblock Plus for IE"
-"NoExplorer"=dword:1
-<<

[Wladimir Palant, 2013/06/19 07:14:15]

Yes, reg.exe runs with the privileges that you run it with. In other words, you
need to start it elevated.

I was somehow under the impression that you can do it with the runas command
line tool - you cannot. However,
http://technet.microsoft.com/en-us/magazine/2007.06.utilityspotlight.aspx links
to an elevate.vbs script. While I won't suggest using that script, we can easily
copy the approach in our own elevate.js that can be part of the repository:

var WMI =
GetObject("winmgmts:{impersonationLevel=impersonate}!\\\\.\\root\\cimv2");
var version = WMI.Get("Win32_OperatingSystem=@").Version;

var shell = WScript.CreateObject("Shell.Application");
var app = WScript.Arguments.Item(0);
var cmdLine = "";
for (var i = 1; i < WScript.Arguments.length; i++)
  cmdLine += ' "' + WScript.Arguments.Item(i) + '"';
var verb = (parseInt(version) >= 6 ? "runas" : "open");
shell.ShellExecute(app, cmdLine.substr(1), "", verb);

This should work correctly on XP as well - will use the "open" verb instead of
"runas" then. This script can be run during build like that:

  wscript //nologo elevate.js reg.exe ...

[Wladimir Palant, 2013/06/20 07:10:38]

In other words, you want to ask developers to run that registry file manually? I
would still rather have that happen automatically if necessary, that's the whole
point of having a separate build step for the development environment.

-        copy temporary.reg temporary.txt
         @date /t >"$(OutDir)registered.timestamp.txt"
         @time /t >>"$(OutDir)registered.timestamp.txt"
 
+#
+# This is exactly the same as 'register64' except it does not use the $(REG) macro but rather just 'reg'
+# On 64-bit Windows, invoking it this way ends up with the 32-bit version of 'reg'.
+# See above about 'sysnative' for why that is.
+# On 32-bit Windows, it does what you'd expect.
+# Thus we can use this for 32-bit build targets on both 32- and 64-bit Windows.
+#
+register32:
+        @echo Start 'register' action.
+        reg add HKCU\Software\Classes\CLSID\{FFCB3198-32F3-4E8B-9539-4324694ED664} /ve /d "Adblock Plus for IE Browser Helper Object" /f >nul
+        reg add HKCU\Software\Classes\CLSID\{FFCB3198-32F3-4E8B-9539-4324694ED664}\InprocServer32 /ve /d "$(DLL)" /f >nul
+        reg add HKCU\Software\Classes\CLSID\{FFCB3198-32F3-4E8B-9539-4324694ED664}\InprocServer32 /v ThreadingModel /d "Both" /f >nul
+        @date /t >"$(OutDir)registered.timestamp.txt"
+        @time /t >>"$(OutDir)registered.timestamp.txt"
+
+#
+# Fortuitously, the warning message below is actually parsed by Visual Studio and show up with a yellow flag in the error list.
+#
+check_BHO64:
+!if [$(REG) query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects\{FFCB3198-32F3-4E8B-9539-4324694ED664}" 2>&1 >nul]
+        @echo Warning: BHO key not registered. IE cannot find the plugin unless the BHO key is present in the registry. Use "BHO_add.reg" to add the key.
+!endif
+
+check_BHO32:
+!if [reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects\{FFCB3198-32F3-4E8B-9539-4324694ED664}" 2>&1 >nul]
+        @echo Warning: BHO key not registered. IE cannot find the plugin unless the BHO key is present in the registry. Use "BHO_add.reg" to add the key.
+!endif
+
 copy:
+        @echo Copying files
         copy "$(ProjectDir)files\settings.ini" "$(OutDir)settings.ini"
         xcopy /s /I /y /D "$(ProjectDir)html\*" "$(OutDir)html"
         xcopy /s /I /y /D "$(ProjectDir)locales\*" "$(OutDir)locales"
         @date /t >"$(OutDir)copied.timestamp.txt"
         @time /t >>"$(OutDir)copied.timestamp.txt"
+
+#
+# N.B. We don't delete the CLSID in HKLM for clean. That wouldn't be our key, but the installer's.
+#
+clean64:
+        $(REG) delete HKCU\Software\Classes\CLSID\{FFCB3198-32F3-4E8B-9539-4324694ED664} /f
+
+clean32:
+        reg delete HKCU\Software\Classes\CLSID\{FFCB3198-32F3-4E8B-9539-4324694ED664} /f
+
+#
+# This utility queries all the registry locations that might be present either in a developer install or a regular one.
+# The '-' annotation means to ignore the error code. '2>nul' means to ignore any error text. It's not an error for a registry key to be absent.
+# The BHO key is only relevant in HKLM. The CLSID keys may be either in HKLM or HKCU.
+#
+query:
+# BHO key
+        -@$(REG) query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects\{FFCB3198-32F3-4E8B-9539-4324694ED664}" 2>nul
+# Native platform keys
+        -@$(REG) query HKLM\Software\Classes\CLSID\{FFCB3198-32F3-4E8B-9539-4324694ED664} /ve 2>nul
+        -@$(REG) query HKLM\Software\Classes\CLSID\{FFCB3198-32F3-4E8B-9539-4324694ED664}\InprocServer32 2>nul
+        -@$(REG) query HKCU\Software\Classes\CLSID\{FFCB3198-32F3-4E8B-9539-4324694ED664} /ve 2>nul
+        -@$(REG) query HKCU\Software\Classes\CLSID\{FFCB3198-32F3-4E8B-9539-4324694ED664}\InprocServer32 2>nul
+!ifdef X64
+# WoW64 keys
+        -@$(REG) query HKLM\Software\Wow6432Node\Classes\CLSID\{FFCB3198-32F3-4E8B-9539-4324694ED664} /ve 2>nul
+        -@$(REG) query HKLM\Software\Wow6432Node\Classes\CLSID\{FFCB3198-32F3-4E8B-9539-4324694ED664}\InprocServer32 2>nul
+        -@$(REG) query HKCU\Software\Wow6432Node\Classes\CLSID\{FFCB3198-32F3-4E8B-9539-4324694ED664} /ve 2>nul
+        -@$(REG) query HKCU\Software\Wow6432Node\Classes\CLSID\{FFCB3198-32F3-4E8B-9539-4324694ED664}\InprocServer32 2>nul
+!endif