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
+
+clean:
+
+rebuild: clean build
+
+#
+# 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"
+
+copy:
+        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"