Long story in a short version – I wasn’t satisfy not knowing – neither was I after being reading the following article:
(That I actually think isn’t that bad – but is also probably the most detailed public available information on the subject)
[1] http://technet.microsoft.com/en-us/library/cc772829(WS.10).aspx

So I decided with a very good friend of mine Christoffer Andersson (long-time Microsoft MVP in AD) to go ahead and build a tool that could read NTDS.dit and decode its internals, and then we started a journey that has given us invaluable knowledge at this part of Active Directory, this is the first article in a series of articles that will describe what’s really inside NTDS.dit and how Active Directory works on the database layer.

The illustration below has been presented in various documentations since Active Directory was initially released over 10 years ago; a similar illustration is also available in (However after this research project it’s actually turning out to be inaccurate in some aspects – in the way the DRA/REPL communicates with the DBLayer) [1]

Table 1: DSA Components (Simplified for the DBLayer)

Data Store Physical Structure / Inside NTDS.dit - Tables

Finally we can start looking into the content/internal structure of NTDS.dit – but first let’s take a look on what has been reveled before, the illustration below is from [1] and is accurate as far as outside the white box that represent the tables within the database, the tables do exist (Except for * “sd_table” on Windows 2000 DSAs) – but there is more tables that isn’t mentioned in this example.

So it’s about time to reveal the real table structure of an NTDS.dit database file – It’s time to use the tool we produced to first discover this:

Table 2: NTDS.DIT - Tables

In the next article – we will take a deep-dive into the content and the structure of the “datatable” also known as the object-store.

You can find the full instructions  at http://www.mvps.org/winhelp2002/hosts.htm. I personally have been using this list for almost two years now (it is frequently updated).

Because I have IIS set-up on my main machine I decided to change the redirect IP address to 0.0.0.0 instead of 127.0.0.1, so that IIS is not “bothered” with the failed requests.

P.S. This list also blocks the YouTube commercials, which is a nice touch!

A thread executes code synchronously—a set of instructions processed by the CPU “first in first out”. This can include virtually any kind of code, be it updating of the GUI, processing calculations, or waiting for user input.

Windows Forms is arguably one of the most used aspects of .NET Framework. GUI programs typically rely on two layers:

• Processing stack, which includes any code or task executed in the background, and
• User interface, which is supposed to give the user a means for instructing the program to execute tasks, and receiving timely “updates” or indications of progress.

Multithreading

Multithreading is a programming paradigm, which has become popular during the past decade. In a nutshell, the CPU can switch between two or more thread contexts so two tasks (e.g. calculation, and GUI update) can be executed in parallel—or asynchronously.

For example, a program can make full use of a multi-core processor by instructing each core to process a separate task, or a chunk of the whole task. This results in improved performance.

In the case with Windows Forms, a separate thread can be used to process a task while allowing the main thread (GUI) to provide timely information about the progress, or to let the user continue their work during the lengthy task.

“BackgroundWorker”

In the example below, we are going to use the BackgroundWorker component. Common uses for it include any possibly lengthy operations such as:

• downloading images or information from the Internet
• assembling a list of files from various directories
• computing CPU-heavy results

A good practice with GUI programs is to keep the user informed of the process and results of such tasks, or to let them continue using the program while the task is executed.

Assume we have a ProgressBar control to show the task’s progress, and a ListView in details mode to show the results.

Start by adding a handler to the DoWork event of the worker. This handler will contain any code executed in the separate thread—it will calculate the first 90 Fibonacci numbers, with a delay between every iteration to slow down the operation. This delay will be natural in other cases, such as waiting for information to be fetched, or for a more serious calculation to be processed.

When the RunWorkerAsync method is called, the worker creates a separate thread, in which all of its code is executed. Despite the valid calls, a quick test reveals that updating the progress bar or list view from this thread results in an exception—most cross-thread operations with Windows Forms controls are invalid.

A solution is to move the UI update code to a separate “proxy” subroutine: the InvokeRequired property and Invoke method are used in combination to enter the necessary context. A delegate declaration with an identical method signature has to be written so that the Common Language Runtine can execute the code in the UI context.

Tip: The worker.IsBusy property can be used to prevent multiple operations from being started. Also, the RunWorkerCompleted event handler is useful for showing. A similar “proxy” method should be used when updating the UI in this case, too.

Download the source code here.

Също така поздравления на Miguel Hernandez (@migue333) и Kim Nilsson (@no_substitute), които бяха избрани посредством случаен жребий от Bryant Zadegan и мен, за да получат по един подарък-карта за абонамент MSDN Ultimate.

Честито!Благодарности на Microsoft за подкрепата.

A quick introduction

ImageX is a command-line tool that enables original equipment manufacturers (OEMs) and corporations to capture, to modify, and to apply file-based disk images (.wim files) for rapid deployment.

WIM files can capture disk or directory snapshots in such a that identical files are only stored once in the internal structure of the image. In addition to this, compression can be used to minimize the size of the final data.

These are some of the reasons I have been using ImageX to take full “snapshots” of all of my code, private files, etc. from time to time, for backup  and archiving purposes. When needed, I can extract different revisions of the same file, or restore a whole image/snapshot in case of disk damage or data loss.

The graph on the left visualizes the changes to my projects backup file spread across 16 months. The last image’s actual data weighs at 64GB, while the whole WIM is 59GB—and it contains all file changes, directory structures, even information that has long been deleted from my working copy.

Requirements

• The scripts package. Download and extract to a folder of your choice.
• ImageX.
1. Download and install the Windows Automated Installation Kit (WAIK).
2. Copy the ImageX binaries (both amd64 and x86 folders), located in \Program files\Windows AIK\Tools\ to the backup\app\imagex folder.

The scripts

Capturing, mounting, or unmounting images requires administrative privileges, so you can either right-click the scripts and select Run as Administrator, or create a shortcut to the script and change its Compatibility options to always require elevation.

The script defaults are below. These can changed (in all four scripts, where used) as needed:

• C:\projects The folder to back up
• projects.wim (created and updated in the root backup folder) The Windows image to be used
• projects.YYMMDD-HHMM The image name template; it is dynamically updated based on the time when the capturing process is started
• mount (folder; located in the root folder) The mount folder to use

Mounting Windows images is only possible after installing the driver by right-clicking wimmount.inf (in the respective ImageX folder), and selecting Install.

Using the solution

Testing and using the backup solution is quite easy. After preparing the ImageX binaries and editing the script defaults as needed:

1. Simply run the capture.cmd script to take the initial snapshot of the target directory.
2. To verify that the new image is processed, you can run the info.cmd script. The command-line output will show information about all images, including the new one.
3. Repeat when a backup is needed.

Of course, the process can be fully automated, by just referencing the capture.cmd in the scheduling program of your choice.

Just wanted to post a quick update:

Thanks to the MVP Program I have received two MSDN Ultimate Subscription gift cards, worth $11,899 each.

These are going to be given away soon as I am working with Bryant on the giveaway details. Stay tuned.

As a follow-up to my previous article on FLAC and encoding uncompressed audio, I have further developed the Wav2Flac library and added FLAC decoding to the WAVE container. Some key points of this aspect of the WavFlacTest library are:

• Support for 16- and 24-bit audio streams
• Support for virtually all FLAC channel mappings: mono, stereo, 5.1, 7.1, etc.
• The resulting file is a bit-for-bit copy of the original audio stream

All source code and the compiled 32-bit FLAC library can be downloaded from here.

Known limitations

• Due to the wave format used being 32-bit, uncompressed files greater than 2GB in size might not play in full in some players.
• Even though FlacReader can receive metadata callbacks, the data is not interpreted. This can be further developed using the FLAC API documentation.

One thing that popped in my mind yesterday after having a conversation over twitter (admittedly, a service I had rarely used until recently), is that the more followers you have, the higher the odds you would have to use other languages in addition to a lingua franca. This ‘leaves out’ other friends who could have limited knowledge of foreign languages.

This is how the idea for the Tweet Balloon Translator was born. It’s a Greasemonkey script for Firefox, which uses the balloon/hover feature recently introduced in twitter plus the Google Translate service to translate tweets quickly and inline.

You can install the script from userscripts.org or the local copy here.

Development notes

The key phases I outlined for the script were as follows:

1. Establish a working translation block of code using the Google Translate JSON API
2. Research the possibilities of inserting a Translate link in such aspects of twitter as the profile page, direct messages, retweets. The Guest/logged out user scenario also had to be taken into account as twitter serves the pages in a different manner.
3. Figure out a way to use the twitter internal API for the HoverCard balloon feature. This was probably the hardest of all three because of the way these are created and populated.
4. Integrate 1 through 3 in a single script.

Needless to say, the script employs asynchronous requests to Google via the HTTPXMLRequest model so as to not break the UI thread, as well as exception handling.

Please feel free to try out, review, or contribute to the script at userscripts.org. I feel both international and English-speaking users could benefit from this by being able to communicate with more people on twitter, and understand international tweets.

What’s needed is for the window function to be overriden (WndProc) and pre-process the target window rectangle used by the WM_SIZING message.

The new destination rectangle is calculated by taking into account the resizing handle and the window chrome size (title height, border width, etc.).

protected override void WndProc(ref Message m)
{
    if (m.Msg == WM_SIZING)
    {
        RECT rc = (RECT)Marshal.PtrToStructure(m.LParam, typeof(RECT));

        int w = rc.Right - rc.Left - chromeWidth;
        int h = rc.Bottom - rc.Top - chromeHeight;

        switch (m.WParam.ToInt32()) // Resize handle
        {

           // …

        }

        Marshal.StructureToPtr(rc, m.LParam, true);
    }

    base.WndProc(ref m);
}

You can find the full C# source code here, including a test program. The aspect ratio and initial client size is set to 16:9.

Lossless audio is used on various media, including studio masters, CD, DVD-Audio (via MLP) and Blu-ray (via Dolby TrueHD, which is technically a rebrand of and an extension to MLP, and DTS-HD Master Audio). All of these, when decoded, will result in a pulse-code modulated signal identical to the source, unlike the popular MP3 format. MP3 performs a quality-file size trade-off by discarding or reducing frequencies less audible to human hearing.

PCM by design uses a constant bitrate, which is proportional to the sample rate, bit depth and number of audio channels, which results in very large file sizes with the increasing of each parameter, and/or duration of the audio track.

Solutions such as FLAC, TrueHD and DTS-HD MA are used to losslessly compress the source audio so that the rest of the medium (for example, a Blu-ray disc) can be used for more audio tracks, higher-bandwidth video or extras.

Out of the aforementioned, only FLAC is free to use—both TrueHD and DTS-HD MA encoders and decoders have to be licensed.

The first part of the series will explore the processing of uncompressed audio data with the FLAC API in C#. In case you prefer to use Visual Basic .NET, you can use this online converter.

Anatomy of a WAVE file

In order to process a digital audio signal, we have to know three key parameters:

• The frequency, at which the signal was sampled. Usual sample rates are 44,100 Hz; 48,000 Hz, 96,000 Hz and rarely 192,000 Hz.
• The “depth” of each sample, measured in bits. The FLAC encoder supports up to 24 bits. Our C# WAVE reader will support 16 and 24 bits of audio data.
• The number of channels, which the recording consists of. This is usually mono, stereo (CD), 5.1 (DVD-Audio, Blu-ray) or 7.1 (Blu-ray).

The most common container for PCM audio data is the WAVE file format. As noted above, PCM has a constant bitrate of

SampleRate * BitDepth * Channels,

which makes it very easy to predict the size of each block of audio samples—a single second of audio data would be Bitrate / 8 bytes (8 bits in a byte)—e.g. 176.4KB for a second of CD-quality audio.

We can create the initialization method of the WavReader class by starting with an input Stream object. We have to ensure that there is enough available data for the wave format header, and check that the file is indeed a RIFF/WAVE file to avoid unnecessary reading and processing.

uRiffHeader = reader.ReadInt32();
uRiffHeaderSize = reader.ReadInt32();
uWaveHeader = reader.ReadInt32();

if (uRiffHeader != 0×46464952 /* RIFF */ ||
    uWaveHeader != 0×45564157 /* WAVE */)
    throw new Exception(”Invalid WAVE header!”);

Right after the RIFF chunk there can be a number of JUNK (padding) chunks, which we can skip and data and fmt chunks, whose data we need.

// Read all WAVE chunks
while (reader.BaseStream.Position < reader.BaseStream.Length)
{
    int type = reader.ReadInt32();
    int size = reader.ReadInt32();

    long last = reader.BaseStream.Position;

    switch (type)
    {
        case 0×61746164: /* data */
            uDataHeader = type;
            nTotalAudioBytes = size;
            break;

        case 0×20746d66: /* fmt  */
            uFmtHeader = type;
            uFmtHeaderSize = size;

            format.wFormatTag = reader.ReadInt16();
            format.nChannels = reader.ReadInt16();
            format.nSamplesPerSec = reader.ReadInt32();
            format.nAvgBytesPerSec = reader.ReadInt32();
            format.nBlockAlign = reader.ReadInt16();
            format.wBitsPerSample = reader.ReadInt16();
            format.cbSize = reader.ReadInt16();
            break;
    }

    if (uDataHeader == 0) // Do not skip the ‘data’ chunk size
        reader.BaseStream.Position = last + size;
    else
        break;
}

Our WavReader class only supports 16 and 24-bit PCM samples, so we have to ensure that format format.wFormatTag is 1 (PCM) and format.wBitsPerSample ple is either 16 or 24. These limitations can be further removed by implementing sample rate conversion on-the-fly.

After all headers are read, nTotalAudioBytes will contain the total count of audio data bytes in the WAVE file. To determine the duration of the audio file, we can simply divide it by the block size (Bitrate / 8 bytes).

The input stream will now be at the start of the audio samples. Every 16th or 24th bit (respectively, 2nd or 3rd byte) will mark the beginning of each sample. All audio samples are interleaved so the stream consists of:

channel 0, sample 0

channel 1, sample 0

…

channel n, sample 0

channel 0, sample 1

…

Now that we have reached the audio samples, we can start feeding them to FLAC.

Free Lossless Audio Codec

The FLAC encoder is an open-source C/C++ project. In order to use it in a C# application we have to use PInvoke to call its application programming interface—LibFlac.dll. The latest version of LibFlac can be found at http://sourceforge.net/projects/flac/files/flac-win/.

1. Create a new encoder instance.
2. Set the three key parameters (sample rate, bits per sample,
3. number of channels).
4. Optionally set a compression level (default is 5).
5. Initialize the encoder by passing references to the callback functions (Write, Tell and Seek).
6. Pass all (desired) audio samples to the encoder, which will return their compressed counterpart.
7. Finalize and delete the encoder instance. This will release all memory allocated by FLAC.

// Callbacks
[UnmanagedFunctionPointer(CallingConvention.Cdecl)]
delegate int WriteCallback(IntPtr context, IntPtr buffer, int bytes, uint samples, uint current_frame, IntPtr userData);

[UnmanagedFunctionPointer(CallingConvention.Cdecl)]
delegate int SeekCallback(IntPtr context, long absoluteOffset, IntPtr userData);

[UnmanagedFunctionPointer(CallingConvention.Cdecl)]
delegate int TellCallback(IntPtr context, out long absoluteOffset, IntPtr userData);