Tag Archives: x64

NTFS Links: x64 build

Posted by on October 12, 2011 No comments

Per user request, here goes 64-bit version of NTFS Links utility, which provides shell UI for NTFS Junction Points.

As 64-bit version of Windows operating systems provide two versions of shell explorer, and support both Win32 and x64 platform applications, it is typical to install both 32-bit and 64-bit versions of the utility to cover/extend applications of both platforms. Note that 32-bit (Win32) applications can only load and directly interact with 32-bit builds of libraries (DLLs), so 64-bit (x64) applications need a corresponding matching version of the shell extension available.

As the utility provides a shell extension for directory property pages, here comes a curiosity exercise: how Windows 7 uses junction points to cross-map directories under user profile directory, e.g. C:\Users\<username>\Local Settings directory is actually a shortcut to C:\Users\<username>\AppData\Local.

Current version of Alax.Info NTFS Links can be downloaded from:

Resource Tools: 64-bit build

Posted by on August 30, 2011 No comments

I rebuilt the Resource Tools utility in 64-bits to, supposedly, be able to be good with resources on 64-bit binaries (actually 32-bit code might be dealing with those fine also?). Anyway, the build is here and the tool available in both 32-bit and 64-bit versions.

In particular, both 32-bit and 64-bit JavaScript scripts hosted by Windows Scripting Host (respectively, 32-bit from C:\Windows\syswow64 or 64-bit from C:\Windows\system32 – in 64-bit Windows) can leverage the tool in file manipulation.

This utility is specifically helpful in automating steps which involve resource updates, such as to apply OEM branding, or resource-based file operations. The code snippet below archives a copy of DLL and PDB files for published release into a .7z archive named using current file version of the DLL itself (that is, it created a ResourceTools.dll-1.0.6.296.7z archive file out of ResourceTools.dll and corresponding ResourceTools.pdb files):

image = new ActiveXObject("AlaxInfo.ResourceTools.Image");
image.Initialize(inputDirectory + fileName);
productVersion = image.VersionInfo.ProductVersionString;
fileVersion = image.VersionInfo.FileVersionString;
WScript.Echo(" Product Version: " + productVersion);
WScript.Echo(" File Version: " + fileVersion);
shell = WScript.CreateObject("WScript.Shell");
currentDirectory = shell.CurrentDirectory;
shell.CurrentDirectory = currentDirectory + "\\" + inputDirectory;
try {
    shellExec = shell.Exec(
        "\"" + toolDirectory + "7z" + "\" " +
        "a -t7z " +
        "\"" + currentDirectory + "\\" + outputDirectory + "ResourceTools.dll-" + fileVersion + ".7z" + "\" " +
        "ResourceTools.dll" + " " +
        "ResourceTools.pdb" + " " +
        "");
    while (shellExec.Status == 0)
        WScript.Sleep(100);
    if (shellExec.ExitCode != 0)
        throw new Error("7-Zip Exec failed, .ExitCode " + shellExec.ExitCode.toString());
    WScript.Echo(" Output File: " + "ResourceTools-" + fileVersion + ".7z");
}
finally {
    shell.CurrentDirectory = currentDirectory;
}

Title: Alax.Info Resource Tools
Version: 1.0.6
Download Links: ResourceToolsSetup.msi (Win32, 32-bit) and ResourceToolsSetup-x64.msi (x64, 64-bit)

Obtaining number of thread context switches programmatically

Posted by on March 20, 2011 No comments

Previous post on thread synchronization and context switches used number of thread context switches as one of the performance indicators. One might have hard times getting the number from operating system though.

The only well documented access to amount of context switches seems to be accessing corresponding performance counters. Thread performance counter will list available thread instances and counters “Thread(<process-name>/<thread-number>)/Context Switches/sec” will provide context switch rate per second.

While access to performance counters is far not the most convenient API, to access data programmatically one would really prefer absolute number of switches rather than rate per second (which is still good for interactive monitoring).

A gate into kernel world to grab the data of interest is provided with NtQuerySystemInformation function. Although mentioned in documentation, it is marked as unreliable for use, and Windows SDK static library is missing it so one has to obtain it using GetModuleHandle/GetProcAddress it explicity.

typedef NTSTATUS (WINAPI *NTQUERYSYSTEMINFORMATION)(SYSTEM_INFORMATION_CLASS SystemInformationClass, PVOID SystemInformation, ULONG SystemInformationLength, PULONG ReturnLength);
NTQUERYSYSTEMINFORMATION NtQuerySystemInformation = (NTQUERYSYSTEMINFORMATION) GetProcAddress(GetModuleHandle(_T("ntdll.dll")), "NtQuerySystemInformation");
ATLASSERT(NtQuerySystemInformation);
ATLVERIFY(NtQuerySystemInformation(...) == 0);

Having this done, the function is capable of providing SystemProcessInformation/SYSTEM_PROCESS_INFORMATION data about running processes.

Read more »

DirectShow Filter Graph Spy: 64-bit version and hook API

Posted by on November 1, 2009 1 comment

Today’s update for DirectShow Filter Graph Spy introduces 64-bit version (mind the beta state) and a mini-API for an external module to be involved into graph building process.

Filter Graph Spy is offering three new interfaces that provide extensibility of the spy:

  • IFilterGraphAddRemoveHook
  • IFilterGraphConnectHook
  • IFilterGraphStateControlHook

The interfaces are contained in the type library and can be imported using #import directive. An implementation of one or more of these interfaces will receive hook style calls corresponding to respective Filter Graph Manager calls, system wide including in context of other applications.

A COM object may be registered as a hook object with Spy and NoThreadSpy COM classes under predefined registry keys:

Registering a DirectShow Filter Graph Spy Hook

Spy will instantiate the registered hook objects and forward them the calls it receive, before passing them to system Filter Graph Manager object. A hook object has an option to override default processing, including, for example, inserting its own filter in between. For example, IFilterGraph::Reconnect call is implemented the following way:

STDMETHOD(Reconnect)(IPin* pPin) throw()
{
    _Z4(atlTraceCOM, 4, _T("...\n"));
    HOOK_PROLOG(CFilterGraphConnectHookHost)
        OnReconnect(pT, pPin, &bDefault);
    HOOK_EPILOG()
    return m_pInnerFilterGraph2->Reconnect(pPin);
}

Before passing the call to original Reconnect method, spy is iterating through associated hooks, passing them IFilterGraphConnectHook::OnReconnect call. Setting bDefault parameter to FALSE will prevent spy from passing the call to original method.

Included BdaHooks project shows a sample implementation of the hooking COM classes (note .rgs registration).

Filter Graph Spy is compatible with all current Windows operating systems, 32-bit and 64-bit (x64), in particular including:

  • Windows 7
  • Windows Server 2008
  • Windows Vista
  • Windows Server 2003
  • Windows XP
  • Windows 2000

NOTE: DirectShow Filter Graph Spy is NOT suitable for production environment, it is NOT licensed to be redistributed to be a part of production state software item.

Partial Visual C++ .NET 2008 source code is available from SVN, release binary included (Win32, x64); installation instructions are in another post.