git branch -r | ?{ $_ -notlike "*/HEAD *" } | %{ git log $_.Trim() -n 1 --format=format:"%ct %d %h %an %ar" } | Sort-Object

The format is like:

1396576284  (origin/release) b3a96ad <name> 1 year, 1 month ago
1402418261  (origin/<alias>/Keyboard2) 83374b7 <name> 11 months ago
1402938550  (origin/<alias>/nopackages) 630cca0 <name> 11 months ago
1403027117  (origin/<alias>/SomeLongCompletedIntegration) ab7a735 <name> 11 months ago

Et voila, now I can find & zap branches with "git push origin --delete branchname"

Some bing-ing and stack-overflow later and I came up with the following powershell.

# Remove all pool members
Get-StoragePool -FriendlyName MyPool | Get-VirtualDisk | Remove-VirtualDisk
 
"x","y","z" | %{
 $letter = $_
 New-VirtualDisk -StoragePoolFriendlyName MyPool -ResiliencySettingName Simple -FriendlyName output_disk -Size 500gb -ProvisioningType Fixed -NumberOfDataCopies 1 -NumberOfColumns 4 | Get-Disk | Initialize-Disk -Passthru | New-Partition -DriveLetter $letter -UseMaximumSize
 $driveletter = $letter+":"
 format $driveletter /fs:ntfs /q /x /a:64K
} 

Note that you'll need to have created the pool with the name "MyPool".  Replace the "-Size" parameter with your desired size, and set "-NumberOfColumns" to the number of physical disks in the pool.  (I'm sure I could determine that from the pool object in the future.

Et voila - a real actual stripeset!  I had three builds, so I used x/y/z as the outputs.

FWIW, this setup got me within ~10% of the build time using an SSD for the output, without the SSD cost.

Last time got me a b&w-converted version of a picture, but didn’t do much with it.  Next up, I need a sequence of integer values from each row in the image for more processing.  Eventually I want to convert those numbers to simple on-and-off values for processing.  For starters, it seems like I should be able to convert each RGB pixel value into its 0-255 greyscale equivalent.  Once I’ve got a byte, my simple theory is that squaring that 8-bit grayscale will produce a 16-bit ushort to process.

Thus:

1. Access the bits of the image
2. Convert each pixel to greyscale
3. Push “light” pixels towards some high-value, push “dark” pixels down towards some low-value
4. Wrap that up in some sort of enumerator.

With a little yield fun, I ended up with an enumerator that produces ushort[] from each row in the image. 

• Why ushorts? 255*255 = 65025, which is less than 65535. 
• Why not put the RowData function into the enumerator with the yield?  Because C# doesn’t allow unsafe code blocks in iterators.  Wierd.
• I’ll need to put the Bitmap acquisition and the LockData outsidethe enumerator, but that’s OK.

public class ImageRowEnumerator : IEnumerable<ushort[]> {
    BitmapData _bmpData;
    int _rowSkip;

    public ImageRowEnumerator(BitmapData b, int skip) {
        _bmpData = b;
        _rowSkip = skip;
    }

    public IEnumerator<ushort[]> GetEnumerator() {
        for (int row = 0; row < _bmpData.Height; row += _rowSkip)
            yield return RowData(_bmpData, row);
    }

    IEnumerator IEnumerable.GetEnumerator() {
        return GetEnumerator();
    }

    unsafe ushort[] RowData(BitmapData bmpData, int row) {
        ushort[] row_data = new ushort[_bmpData.Width];
        byte* pData = (byte*)bmpData.Scan0 + (bmpData.Stride * row);
        for (int col = 0; col < _bmpData.Width; col++, pData += 3) {
            ushort color = (ushort)((pData[0] * .3f) + (pData[1] * .59f) + (pData[2] * .11f));
            row_data[col] = (ushort)(color * color);
        }
        return row_data;
    }
}

Next time, converting from the ushort values to on/off.  It’s not just checking for 50%.

    public class GreyscaleBitmap
    {
        // Magic conversion to greyscale matrix
        static float[][] _grayScaleMatrix = new float[][] {
            new float[] {.3f, .3f, .3f, 0, 0},
            new float[] {.59f, .59f, .59f, 0, 0},
            new float[] {.11f, .11f, .11f, 0, 0},
            new float[] {0, 0, 0, 1, 0},
            new float[] {0, 0, 0, 0, 1}
        };

        // Doubles contrast
        static float[][] _increaseContrast = new float[][] {
            new float[] {2, 0, 0, 0, 0},
            new float[] {0, 2, 0, 0, 0},
            new float[] {0, 0, 2, 0, 0},
            new float[] {0, 0, 0, 1, 0},
            new float[] {0, 0, 0, 0, 1}
        };

        // Dumb and slow.
        static float[][] MatrixMult2(float[][] first, float[][] second)
        {
            float[][] result = new float[5][];

            for (int i = 0; i < 5; i++)
                result[i] = new float[5];

            for (int j = 0; j < 5; j++)
                for (int k = 0; k < 5; k++)
                    for (int i = 0; i < 5; i++)
                        result[i][j] += first[i][k] * second[k][j];

            return result;
        }

        // Only bother making one of these
        static ColorMatrix _matrix = new ColorMatrix(MatrixMult2(_grayScaleMatrix, _increaseContrast));

        // Cache this as well?
        static ImageAttributes GetAttributes()
        {
            ImageAttributes result = new ImageAttributes();
            result.SetColorMatrix(_matrix);
            return result;
        }

        public static Bitmap Convert(Bitmap bmp)
        {
            Bitmap newBitmap = new Bitmap(bmp.Width, bmp.Height, PixelFormat.Format24bppRgb);

            using (Graphics g = Graphics.FromImage(newBitmap))
            {
                Rectangle r = new Rectangle(0, 0, newBitmap.Width, newBitmap.Height);
                g.DrawImage(bmp, r, 0, 0, bmp.Width, bmp.Height, GraphicsUnit.Pixel, GetAttributes());
            }

            return newBitmap;
        }
    }

Now, in another world the output image format would be 16bpp grayscale directly, instead of being re-encoded in 24bpp RGB.  As a result, my eventual scanner will have to convert back from RGB to a grayscale value again.  Not a great start, but hey – conversion to grayscale!

And along the way learn WPF, image manipulation, video processing, LINQ, etc. etc.

"What is the c:\windows\winsxs\manifestcache\6.0.6001.18000_001c50b5_blobs.bin file and why is it taking up 156Mb on my hard drive? Do I really need a file this big?"

That file is used by the Windows Update mechanisms in Vista.  It acts like a cache and is capped at a certain size, but it's safe to delete.  The next time you turn on or off Windows optional features or take updates from Windows Update it'll reappear. The file will be recreated as necessary to help the servicing system do its work.  Maybe in the future it'll be added to the disk-cleaup wizard, but it noticably increases the performance of servicing operations while it's there.

Of course, actually deleting the file is left as an excercise to the reader.

Ok then, let's suppose you've done this and now have code that looks like "For this configuration widget, read the current value; if there is no current value, read the default; if there is no default, use <mystery value> instead."  That's three levels of decision making, three independent code paths for your test team to validate.  What if you could just cut out that middle piece and go back to two - a default in-code and a possible per-user override?

This leads me to the following broad statement - Defaults should be shipped in code, user configurations saved on the device in stable storage.  Three reasons:

1.       Setting a value during setup is a point of failure.  Yes it almost never happens.  But it happens.  The best setup you can imagine is one done by (logical) xcopy.  Imagine your app being run from a network share.  The vast majority of applications - web apps, for instance - have no "install" step.  They just start up and use default settings until overridden by a user-initiated configuration step.

2.       "Reset to known good state" should be "delete all overridden settings and start again."  Apps that have "repair" fail mightily when they try to distinguish important things to keep from unimportant things to keep.  If the app is able to start up and run correctly from a completely clean state "repair" can be "delete this key, restart the app."

3.       Servicing of user-defaults is impossible without an override model.  Imagine a default color value like "blue".  The user changes her mind and picks "orange" instead.  Later they decide they like "blue" again.  Now imagine an update coming down for your application that changes the default to "white".  A naïve updater might look at the old default (blue) and the current setting (blue) and say "aha! They're still on the default, change to white!" which is not what the customer intended.  They consciously chose "blue".  Granted, this means your settings model needs a "use default" button, but that's a small price to pay for customer sat.

Every interesting app has some form of configuration the user or the environment can supply it.  Well-designed apps work correctly even when there are no configurations provided at all.

Rude Q&A:

1.       "But I don't want to recompile to change my defaults!"  Have your default values in a text file in your app deployment unit.  Managed code provides an app configuration model based on yourexe.exe.config, which is reasonably OK.  Others use a .txt file structured like an INF.

2.       "But I can't possibly change all my code to use an override system!"  Have you checked?  I bet there's one or two interesting functions in your code that read those settings that you could change.  If there are many functions that all do configuration checks, refactor them into a single point of access where you can do this.

3.       "But having defaults in code means image bloat!" A dword in code is maximally 4 bytes in the const data section, less-so if the optimizer inlines uses of it.  A reg_dword is those four bytes plus the size of the registry value, the key that references it, the parent key of that key, and so on.  You're trading a small fixed overhead for a larger unknown overhead.

Note: this is orthogonal to registering with the system (such as creating services, registering COM goo, etc.).  Apps that integrate with the system do need an "announce" step (call it 'install' if you prefer).  The announcement-management should be owned, debugged, and tested by a central team.  Windows, CE, and others all do this wrong today for legacy reasons.  MSI tries to make this better by requiring you to register COM objects through their tables, but it's a stopgap because they still allow calling into DllRegisterServer.  One can imagine a system where a data-driven “announcement” mechanism is the only way to get integrated with the system, and the announcing application gets to run no actual code of its own.

Content is added to this directory in response to installing applications, enabling packages in the add-remove-programs UI, and installing Windows Out-of-Band releases.  Content is removed from this directory as a result of uninstall + scavenging - a topic for another time.  One important note - uninstalling your application or Windows app will not necessarily remove the physical bits from the system.  The servicing stack marks the bits as unusable and prevents their use through "normal" means.  Files and directories will be removed over time as the servicing system cleans up after itself.  Administrators should not, for any reason, take it upon themselves to clean out the directory - doing so may prevent Windows Update and MSI from functioning properly afterwards.  Preventing accidental deletion from the directory is accomplished by putting a strong security descriptor on the directory that inherits to its children.

The directory itself is marked with the SDDL:

• O:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464
• G:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464
• D:PAI
• (A;OICI;FA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)
• (A;OICI;0x1200a9;;;BA)
• (A;OICI;0x1200a9;;;SY)
• (A;OICI;0x1200a9;;;BU)"

That long SID (S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464) is the service sid for Trusted Installer.  By parts, that SDDL means "the owner and group are Trusted Installer; there is a protected and auto-inherit DACL; the ACEs of that DACL grant the trusted installer full access; the ACEs of the DACL also grant builtin-administrators, local system, and builtin users generic-read and generic-write access; each ACE is also automatically inherited by child containers and child objects."

So, the security descriptor on the object will prevent even administrators from creating or deleting objects underneath %windir%\winsxs, which is why even an elevated administrator cannot (by default) delete content.

Elevated administrators do have (by default) the SeTakeOwnership privilege enabled.  Such a token could take ownership of anything under %windir%\winsxs.  Once the owner, the administrator could then reset the SDDL on the object, granting themselves full access to the object.  Of course, the generic LUA administrator token does not allow enabling the "take ownership" privilege, so this is only possible after answering the LUA elevation prompt successfully.

I leave it to the intrepid user to figure out the correct combination of "takeown.exe", "icacls.exe", and "rmdir" to actually remove content.

// This structure is only a holder for a pointer for now.
typedef struct _ONETIME_CS {
  CRITICAL_SECTION volatile *Cs;
} ONETIME_CS, *PONETIME_CS;

BOOL InitOnetimeCs(PONETIME_CS pCs) {
  MemoryBarrier();
  if (pCs->Cs == NULL) {
    CRITICAL_SECTION *NewCs;
    NewCs = (CRITICAL_SECTION)HeapAlloc(GetProcessHeap(), 0, sizeof(*NewCs));
    if (NewCs == NULL) {
      SetLastError(ERROR_OUTOFMEMORY);
      return FALSE;
    }
    // InitCs and DeleteCs fail by raising SEH exceptions. When
    // those fly by, make sure to free the heap. The loser of
    // the race deletes the losing CS, and the __finally ensures
    // that it gets freed. The winner sees 'null' from the ICEP,
    // all others get what the winner put there.
    __try {
      PVOID OldCs;
      InitializeCriticalSection(NewCs);
      OldCs = InterlockedCompareExchangePointer(
        (volatile PVOID *)&pCs->Cs, NewCs, NULL);
      if (OldCs == NULL) {
        NewCs = NULL;
      } else {
        DeleteCriticalSection(NewCs);
      }
    } __finally {
      if (NewCs != NULL)
        HeapFree(GetProcessHeap(), 0, (PVOID)NewCs);
    }
  }
  MemoryBarrier();
  return (Guarded->Cs != NULL);
}

BOOL EnterOnetimeCs(PONETIME_CS pCs) {
  if (pCs != NULL) {
    if (!InitOnetimeCs(pCs))
      return FALSE;
  }
  EnterCriticalSection(pCs->Cs);
  return TRUE;
}

VOID LeaveOnetimeCs(PONETIME_CS pCs) {
  LeaveCriticalSection(pCs->Cs);
}

VOID DeleteOnetimeCs(PONETIME_CS pCs) {
  PVOID OldCs;
  // Delete can be multithread-aware as well, so use IEP to
  // atomically swap out the value with NULL.  The winner gets
  // a non-null value back, losers get NULL.
  OldCs = InterlockedExchangePointer(&pCs->Cs, NULL);
  if (OldCs != NULL) {
    DeleteCriticalSection((CRITICAL_SECTION*)OldCs);
    HeapFree(GetProcessHeap(), 0, OldCs);
  }
}

ONETIME_CS g_Cs = { NULL };
DWORD MyThreadProc(PVOID) {
  if (!EnterOnetimeCs(&g_Cs))
    RaiseError(ERROR_INTERNAL_ERROR, 0, 0, NULL);
  // do something
  LeaveOnetimeCs(&g_Cs);
}

This is just another example of "racy initialization" using InterlockedCompareExchangePointer. Some "racy init" patterns are dangerous - especially those that involve "read after write" of the data that's been initialized. That's what the memory barrier is there for - it guarantees (expensively) that any writes InitializeCriticalSection might have performed will be written back before the following call to EnterCriticalSection.

This method is cheap, but it does require extra heap and may create a few critical sections when there is contention. Luckily, the cost in CS creation is about zero in Vista - entering the CS when there is contention is where the real cost lies. Certain analysis methods are made harder - when the app verifier prints the address of a busted CS, "ln thataddress" won't tell you which symbol contained the critical section.

Next time, a method that avoids spurious CS creation, allows for "ln thataddress" on the CS address, and has zero heap cost!

The logic (not the implementation) looks something like the following:

1. LoadLibrary("yourdll.dll") is called by the application
2. "yourdll.dll" is found using using the current context plus the usual DLL lookup mechanisms.
3. When found, if yourdll.dll is not already loaded into this context, the DLL is mapped.
4. CreateActCtx is called using the mapped DLL's HMODULE, passing resource ID MAKEINTRESOURCE(2) as the resource number.
5. If that succeeded, the resulting context is activated.
6. The static imports of "yourdll.dll" are resolved, possibly recursively executing these operations until all the statically referenced DLLs have been loaded.
7. The DLL entrypoint for "yourdll.dll" is invoked.
8. If a context was activated above, it's deactivated.
9. Control returns to the application with an appropriate HMODULE

You can use any manifest you care to in your resource section. Visual Studio has options for embedding manifests at the right resource ID. Nikola has some tips for doing so in both makefiles and the VS IDE.

Publisher policy is of course applied, but application policy (ie: foo.exe.policy) is not. The usual "look in the app directory for private assemblies" logic applies as well, so this works even if your DLL is distributed privately with an application.  See also Using Side-By-Side Assemblies as a Resource, which covers when various resource values will be used during the loading and initialization of DLLs and executables.