CodeProject

The good news first: You can get a Verisign Authenticode code signing certificate for $99. Just check out https://sysdev.microsoft.com/ for details. This price even applies to the renewal when the original certificate expires after a year.

Today I was looking for the source of frequent delays when setting permissions from my new application SetACL Studio. I sprinkled the code with timestamped debug statements like these… System.Diagnostics.Debug.WriteLine(DateTime.Now + " - 1"); // Do something System.Diagnostics.Debug.WriteLine(DateTime.Now + " - 2"); …and found that the delays always had a duration of seven seconds. Wait - “inexplicable” delays of constant length - that smells of timeouts!

There are two equivalent ways trustees can be assigned a specific set of permissions on Windows: via generic rights and via a combination of standard and specific rights. Generic rights are identical for all object types. There are only four of them:

When dealing with Windows NTFS file system permissions, one quickly encounters the SYNCHRONIZE access right, the purpose of which may not be obvious. SYNCHRONIZE belongs to the standard access rights, just like DELETE, READ_CONTROL, WRITE_DAC and WRITE_OWNER.

Sometimes you need a list of all the files and/or folders in a directory with their full path, without any additional information. “DIR /B” would be the right command, if it only printed out the full path (it does that only if combined with the recursion parameter /S).

Here is an interesting tidbit related to Windows security: Create a test file share, e.g. C:\temp\test, and share it with full permissions for everyone (share, not NTFS permissions) as “test” Create the following directory hierarchy below the share: C:\temp\test\1\2\3\4 Assign ownership of the four folders 1, 2, 3 and 4 to any user (but do not use your own account, just anyone else’s) Set permissions on 1, 2, 3 and 4 that only the user from the previous step has full access, nobody else, not even the SYSTEM Now try to use SetACL to change the owner of directory “4” over the network (SetACL uses backup and restore privileges so this should be no problem) by issuing the following command locally: setacl -on \localhost\test\1\2\3\4 -ot file -actn setowner -ownr n:domain\administrator SetACL will fail with access denied (full message: “ERROR: Writing SD to <\?\UNC\localhost\test\1\2\3\4> failed with: Access is denied.”) Now issue the same command, but instead of using a UNC path use the local drive letter: setacl -on c:\temp\test\1\2\3\4 -ot file -actn setowner -ownr n:domain\administrator That works! Why is this so? I have no clue.

Generally I am not the type to recommend re-implementing functionality present in some API. But with the Windows function CopyFile(Ex) there may be no alternative, because of the less than sub-optimal way Windows copies EFS-encrypted files:

Finding good information on how to enable drag and drop for MFC applications is hard enough (why?). But just when you think you should have it working, you hit a very solid wall: UIPI (User Interface Privilege Isolation, a variant of UAC, User Account Control). Because of “security” reasons, UIPI disables drag and drop from medium integrity processes (Explorer) to high integrity (aka elevated) processes by filtering out most window messages, including those required for drag and drop. In essence drag and drop from Explorer to your elevated application does not work.

If you create a C++ project in Visual Studio and configure it to “Use MFC in a Shared DLL” (the default) you need to make sure the C runtime (CRT) and the MFC libraries are installed in the correct versions on the end user’s computer. That can be difficult.

Let’s assume you have a C# project in Visual Studio. In that project, you reference an assembly (DLL) created by another of your projects. Because both projects are in active development, the version number of the referenced assembly changes frequently.

If you get weird errors in Visual Studio that basically state files like Windows.h cannot be found, the reason may be a missing or incorrect WindowsSdkDir variable. In my case, working with Visual Studio 2008 SP1 (32 bit) on Windows 7 x64 (64 bit) everything was fine until I installed the Windows 7 SDK. After that, no SDK files could be found any more and nothing would compile. Uninstalling the SDK (which I did not really need anyway - I had installed it only to get at XPerf) did not help. After some research, I found out that the Visual Studio internal variable WindowsSdkDir (which is not an environment variable) was missing from the registry. After adding the following, everything worked like a charm again:

I just found out the following, which does not seem to be documented anywhere: The Windows API has a function for displaying a dialog that lets the user select a specific performance counter from all counters available on the local or a remote computer. The dialog is used by perfmon.exe, for example, and looks like this:

This is a quick and dirty description of how to use radio buttons in MFC, written because I could not find this information in a single place on the web.

[Update 1: Fixed bugs in the batch file and made it available for download] [Update 2: Wildcards are now supported] [Update 3: Timestamps are now copied from source to destination files. For this, touch.exe is needed.] [Update 4: File names with spaces in them are now handled correctly]