Posts Tagged ‘win32’

Playing a CD with the Win32 Media Control Interface

A long time ago I wrote some code to play CD audio tracks for a game engine I was writing. CD audio (via mixed mode CDs) was popular for video game music at the time because it allowed for high quality music without having to deal with large un-compressed audio files (e.g. uncompressed WAV) or relatively expensive decompression algorithms with compressed files (e.g. MP3).

I cleaned up the code a bit and decided to post it here. It’s surprising simple code as it uses the very high-level Media Control Interface (MCI).

Compiling and Linking

You must link with winmm.lib

cdaudio.h

#ifndef __CDAUDIO__H__
#define __CDAUDIO__H__

bool cdaudio_open(void);
void cdaudio_play(int track);
void cdaudio_stop(void);
void cdaudio_close(void);

#endif

cdaudio.cpp

#ifndef WIN32_LEAN_AND_MEAN
#define WIN32_LEAN_AND_MEAN
#endif

#include
<windows.h>
#include <stdio.h>
#include <stdarg.h>
#include <mmsystem.h>

bool cdaudio_open(void)
{
    DWORD ret = mciSendString(L
"open cdaudio",NULL,NULL,NULL);
    mciSendString(L
"set cdaudio time format tmsf",NULL,NULL,NULL);

    
if (ret != 0) {
        
return false;
    }

    
return true;
}

void cdaudio_play(int track)
{
    
wchar_t tk_string[32];
    wsprintf(tk_string, L
"play cdaudio from %i to %i", track, track+1);
    mciSendString(tk_string,NULL,NULL,NULL);
}


void cdaudio_stop(void)
{
    mciSendString(L
"stop cdaudio",NULL,NULL,NULL);

}

void cdaudio_close(void)
{
    mciSendString(L
"stop cdaudio",NULL,NULL,NULL);
    mciSendString(L
"close cdaudio",NULL,NULL,NULL);
}

main.cpp (example showing how to use cdaudio functions to play track)

#include <stdio.h>
#include "cdaudio.h"

int main(int argc, char *argv[])
{
    
// setup MCI for CD audio
    
cdaudio_open();

    
// play track 8 on CD
    
cdaudio_play(8);

    wprintf(L
"Press any key to stop playing track...");
    getchar();
// wait for keypress

    // cleanup
    
cdaudio_close();


    
return 0;
}

Querying the Windows Registry

I’ve always considered the Windows Registry to be a pretty awful piece of technology and a terrible way to store system and application settings. That said, if you’re doing Windows development, you’re probably going to have to touch it at some point. I was digging through some old C++ code, and came across some code to get the current version of Flash installed on the system (I can’t remember why I need to do this at all), which I think serves a good example of how to query the registry.

#include <iostream>
#include <windows.h>

int main()
{
    LONG ret;
    HKEY result;
    
    
// open the key "HKEY_LOCAL_MACHINE\SOFTWARE\Macromedia\FlashPlayerPlugin"
    
ret = RegOpenKeyExW(HKEY_LOCAL_MACHINE, L"SOFTWARE\\Macromedia\\FlashPlayerPlugin", 0, KEY_QUERY_VALUE, &result);
    
if(ret != ERROR_SUCCESS)
        
return 1;

    
// allocate 64 wide chars to hold value
    
DWORD dataLen = 64;
    
wchar_t* data = new wchar_t[dataLen];

    
// query the value of "Version" for the key we opened
    
ret = RegQueryValueExW(result, L"Version", NULL, NULL, (LPBYTE)data, &dataLen);
    RegCloseKey(result);
    
if(ret != ERROR_SUCCESS)
        
return 2;

    
// put the value in a wide string and output it
    
std::wstring versionStr(data);
    std::wcout << versionStr.c_str();

    
// memory cleanup
    
delete [] data;

    
return 0;
}

The code required some modification as the name name of the key and value has since changed (FlashPlayerPlugin was previously FlashPlayer, Version was previous CurrentVersion).

No shell extensions with .NET 4?

Shell extensions (at least in Windows, I can’t speak to other platforms) are not easy to write and require some pretty ugly native code, requiring Win32 and COM code. For most applications, the .NET Framework can usually provide a nice wrapper for such code, but not for shell extensions. Prior to .NET 4, using the .NET Framework was dangerous because, as explained in this forum post, an extension would attempt to inject a version of the .NET Framework (the version the shell extension was written in) into every application affected by the extension (i.e. every application making use of the shell component extended), but only one version of the .NET Framework can be loaded in a process, potentially creating conflicts with other applications using different versions of .NET.

.NET 4 can be loaded side-by-side with other versions of the framework, so shell extensions are technically possible, and I was happy to find an article + code sample detailing how to write an extension as part of Microsoft’s All-In-One Code Framework. Unfortunately, the code sample has since disappeared and, regarding .NET 4 shell extensions, Jialiang Ge of the All-In-One Code Framework team explains:

In .NET 4, with the ability to have multiple runtimes in process with any other runtime. However, writing managed shell extensions is still not supported. Microsoft recommends against writing them.

No much of an explanation, to say the least.

Managed wrapper for the BTObex library

More open-source goodness. A managed wrapper for the BTObex library. The source includes the BTObexWrapper.h header file which contains the wrapper code (shown below) and a compiled managed DLL, for those who just want to include it into their projects and use it ASAP.

// Managed C++/CLI wrapper for the BTObex Library
// Include the BTObex library files into the project (BTOBEX sub-directory) and compile as a managed DLL

/*
    Copyright (c) 2010, Avishkar Autar
    All rights reserved.

    Redistribution and use in source and binary forms, with or without
    modification, are permitted provided that the following conditions are met:
        * Redistributions of source code must retain the above copyright
         notice, this list of conditions and the following disclaimer.
        * Redistributions in binary form must reproduce the above copyright
         notice, this list of conditions and the following disclaimer in the
         documentation and/or other materials provided with the distribution.
        * Neither the name of the <organization> nor the
         names of its contributors may be used to endorse or promote products
         derived from this software without specific prior written permission.

    THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
    ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
    WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
    DISCLAIMED. IN NO EVENT SHALL <COPYRIGHT HOLDER> BE LIABLE FOR ANY
    DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
    (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
    LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
    ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
    (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
    SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

*/



#pragma once

#pragma
unmanaged
    #ifndef WIN32_LEAN_AND_MEAN
    
#define WIN32_LEAN_AND_MEAN
    
#endif

    #include <winsock2.h>
    #include <Ws2bth.h>
    #include <BluetoothAPIs.h>

    #pragma comment(lib, "ws2_32.lib")

    
#include <windows.h>
    #include <cguid.h>

    #include "BTOBEX/BTSock.h"
    #include "BTOBEX/OBEX.h"
    #include "BTOBEX/BTOBEX.h"

#pragma managed

using
namespace System;
using namespace System::Runtime::InteropServices;

namespace BTObex
{
    
public ref class BluetoothDeviceProfile
    {
        
public:
            System::String^        name;
            System::String^        address;
// (address):port, typically repeat of device address
            int                    port;
    };

    
public ref class BluetoothDevice
    {
        
public:
            System::String^                            name;
            System::String^                            localAddress;
            System::String^                            deviceAddress;
            System::Collections::ArrayList^         supportedProfiles;

            
virtual System::String^ ToString() override
            {
                
return name;
            }
    };

    
public ref class Progress
    {
        
public:
            System::IntPtr^        current;
            System::IntPtr^        total;
    };

    
public ref class BTObexFileIO
    {
        
protected:
            BTOBEX::Session* btSession;
            BTOBEX::Progress* opProgress;

            
wchar_t* MarshalStringToCStr(System::String^ str)
            {
                
wchar_t* ret = new wchar_t[str->Length+1];

                
for(int i=0; i<str->Length; i++)
                    ret[i] = str[i];

                ret[str->Length] = 0;

                
return ret;
            }

            
void DeleteMarshaledCStr(wchar_t* str)
            {
                
delete [] str;
                str = 0;
            }

        
public:
            BTObexFileIO() : btSession(0)
            {
                opProgress =
new BTOBEX::Progress();
            }

            ~BTObexFileIO()
            {
                
delete opProgress;
            }

            
void QueryDevices(System::Collections::ArrayList^ devices, bool queryOnlyOBEXFileTransferProfiles)
            {
                BTSock::Session* btSession =
new BTSock::Session();

                std::vector<BTSock::Device*> btDevices;
                
if(queryOnlyOBEXFileTransferProfiles)
                {
                    btSession->DeviceQueryObject()->PerformQuery(btDevices, OBEXFileTransferServiceClass_UUID);
                }
                
else
                {
                    btSession->DeviceQueryObject()->PerformQuery(btDevices);
                }

                
for(int i=0; i<(int)btDevices.size(); i++)
                {
                    BluetoothDevice^ dev =
gcnew BluetoothDevice();
                    dev->name =
gcnew System::String( btDevices[i]->name.c_str() );
                    dev->localAddress =
gcnew System::String( btDevices[i]->localAddress.c_str() );
                    dev->deviceAddress =
gcnew System::String( btDevices[i]->deviceAddress.c_str() );
                    dev->supportedProfiles =
gcnew System::Collections::ArrayList();

                    
for(int j=0; j<(int)btDevices[i]->supportedProfiles.size(); j++)
                    {
                        BluetoothDeviceProfile^ profile =
gcnew BluetoothDeviceProfile();
                        profile->name =
gcnew System::String( btDevices[i]->supportedProfiles[j]->name.c_str() );
                        profile->address =
gcnew System::String( btDevices[i]->supportedProfiles[j]->address.c_str() );
                        profile->port = btDevices[i]->supportedProfiles[j]->port;

                        dev->supportedProfiles->Add(profile);
                    }

                    devices->Add(dev);
                }

                
delete btSession;
            }
                

            
bool Connect(System::String^ address, int port, int packetSize)
            {
                
wchar_t* addr = MarshalStringToCStr(address);

                btSession =
new BTOBEX::Session();
                
bool connOk = btSession->Connect(addr, port, packetSize);

                DeleteMarshaledCStr(addr);

                
return connOk;
            }

            
void Disconnect()
            {
                btSession->Disconnect();
                
delete btSession;
            }

            
bool SetPathBackward()
            {
                
return btSession->SetPathBackward();
            }

            
bool SetPathForward(System::String^ folderName)
            {
                
wchar_t* folderNameCStr = MarshalStringToCStr(folderName);

                
bool setOk = btSession->SetPathForward(folderNameCStr);

                DeleteMarshaledCStr(folderNameCStr);

                
return setOk;
            }

            
bool GetFolderListing(System::Collections::ArrayList^ result)
            {
                OBEX::NakedVector<OBEX::byte> utf8Bytes;
                
bool getOk = btSession->GetFolderListing(utf8Bytes);

                
if(getOk)
                {
                    
for(int i=0; i<utf8Bytes.Count(); i++)
                    {
                        result->Add(
gcnew System::Byte(utf8Bytes[i]) );
                    }
                }

                
return getOk;
            }

            
bool DeleteObject(System::String^ objName)
            {
                
wchar_t* objNameCStr = MarshalStringToCStr(objName);

                
bool delOk = btSession->DeleteObject(objNameCStr);

                DeleteMarshaledCStr(objNameCStr);

                
return delOk;
            }

            
bool PutFile(System::String^ remoteFileName, System::String^ localFilePath, Progress^ progress)
            {
                progress->current =
gcnew System::IntPtr( &opProgress->current );
                progress->total =
gcnew System::IntPtr( &opProgress->total );

                
wchar_t* remoteFileNameCStr = MarshalStringToCStr(remoteFileName);
                
wchar_t* localFilePathCStr = MarshalStringToCStr(localFilePath);

                
bool putOk = btSession->PutFile(remoteFileNameCStr, localFilePathCStr, opProgress);

                DeleteMarshaledCStr(remoteFileNameCStr);
                DeleteMarshaledCStr(localFilePathCStr);

                
return putOk;
            }

            
bool GetFile(System::String^ remoteFileName, System::String^ localFilePath, Progress^ progress)
            {
                progress->current =
gcnew System::IntPtr( &opProgress->current );
                progress->total =
gcnew System::IntPtr( &opProgress->total );
                
                
wchar_t* remoteFileNameCStr = MarshalStringToCStr(remoteFileName);
                
wchar_t* localFilePathCStr = MarshalStringToCStr(localFilePath);

                
bool getOk = btSession->GetFile(remoteFileNameCStr, localFilePathCStr, opProgress);

                DeleteMarshaledCStr(remoteFileNameCStr);
                DeleteMarshaledCStr(localFilePathCStr);

                
return getOk;
            }
    };
}

BTObex Library

I’ve released the BTObex library (I’m playing around with using bitbucket for hosting the code) I wrote a few months ago which is a Win32 bluetooth library that allows for file transfers with devices that support the Bluetooth File Transfer Profile. This library uses the MS Bluetooth stack (included w/ Win XP SP2 and later).

For those wondering what OBEX is and what Bluetooth has to do with it: Bluetooth devices support a set of profiles, one of which is the File Transfer Profile. However, the FTP itself doesn’t really take care of anything much, once the connection is established, actual file transfers are handled by the OBEX protocol.

Bluetooth FTP stack

OBEX was originally designed for transfers across infrared devices and is not handled by the Bluetooth SIG, its specs are controlled by the IrDA. Now, aside from being a useless bit of trivia, this is important because while the Bluetooth SIG publishes a ton of documentation, the IrDA does not. The documentation on the specs for OBEX requires signing up for IrDA membership and paying some hefty membership fees. That said I was able to get my hands on a copy of the OBEX documentation here. How long that remains up and the legality of me reading it is up in the air. Charging for documentation is a shitty practice by the IrDA and I can only hope that the Bluetooth SIG ditches OBEX for something better in the future.

There’s little-to-no documentation for the library, so I’m going to use this blog post to provide some examples.

Link with necessary libraries

#pragma comment(lib, "ws2_32.lib")
#pragma comment(lib, "irprops.lib")

Include header file

#include "BTOBEX.h"

The entire library simply consists of a bunch of header files. BTOBEX.h will include everything else.

Query all Bluetooth devices

std::vector<BTSock::Device*> btDevices;
BTSock::Session* btSession =
new BTSock::Session();
btSession->DeviceQueryObject()->PerformQuery(btDevices);
delete btSession;

The vector btDevices will contain an entry for each device paired with the system. Look at BTSockDevice.h to see the structure of the BTSock::Device class.

Make a connection

BTOBEX::Session* btObexSession = new BTOBEX::Session();
bool connOk = btObexSession->Connect(devAddress, port, 8192);

devAddress is the deviceAddress member of a BTSock::Device object.
port is the port number for a given profile, for the file transfer profile it’s 5. If you can’t connect on the port, it likely means that the profile is not support by the device.

Set the current directory on the device

bool setPathOk = btObexSession->SetPathForward(L"my_picture");

OBEX only allows you to move forward into a subdirectory (SetPathForward) or jump back to a parent directory (SetPathForward).

Get a directory listing

OBEX::NakedVector<OBEX::byte> xmlBytes;
btObexSession->GetFolderListing(xmlBytes);

The bytes are UTF-8 bytes that form a XML document (an XML parser is not part of the library). The XML doc will have folder and/or file elements, each with a required name attribute. Directory listings are one of the dumbest aspects of the OBEX protocol; whereas everything else is binary and well-defined, directory listings are verbose and text-based (remember, this is a low bandwidth connection) and have no required attribute aside from name. Other attributes (e.g. size) may be present, but they’re optional, meaning, in general, you’ll likely avoid them in order to develop for the lowest common denominator.

Get a file from the device

bool getOk = btObexSession->GetFile(L"remote.jpg", L"local.jpg", new BTOBEX::Progress());

The last parameter is optional, you can pass a BTOBEX::Progress object if you wish to poll the progress of the transfer from another thread.

Put a file on the device

bool putOk = btObexSession->PutFile(L"remote.jpg", L"local.jpg", new BTOBEX::Progress());

The last parameter is optional, you can pass a BTOBEX::Progress object if you wish to poll the progress of the transfer from another thread.

Disconnect and clean up

btObexSession->Disconnect();
delete btObexSession;

Have fun! The code is released under the BSD license. Any comments or bug reports are greatly appreciated.

Edit (11/22/2020): Update link to point to GitHub repo.

User objects

A while back I wrote about 2 applications, The KMPlayer and JCreator not behaving well when attempting to run both concurrently (see post).

Now, I have an incredibly weird situation on my system. KMPlayer and JCreator don’t play nice together. If they’re both open, some JCreator panels and menus are suddenly blank and don’t refresh and the side tabs panel is transparent, showing thru to the desktop. As for KMPlayer, I can’t open anything, clicking play (which plays the last file opened when nothing else has been loaded) does nothing, and certain items are mysteriously missing from the context menu. This hasn’t been a big deal for me, and I still use both JCreator and KMPlayer, but it would be nice if they worked together. Also, I have to wonder, what is the common component causing the conflict here, what would a media player and a java IDE both be using or trying to access concurrently? (assuming there is a conflict for a common component, which I suspect might be the issue here)

My suspicion was wrong, it was not a conflict between the applications or a common component, it was the system running out of User objects. In Winforms (and I suspect most other GUI toolkits as well) any GUI control or window will consume at least 1 user object (more complex controls, with multiple sub-components will consume more User objects), and when the system or process hits the limit (65,536 for the user session, 200 – 18,000 per-process; default is 10,000 on Windows XP), creation of new User objects will fail, even if the system has enough memory to support whatever it is that’s being created. On the .NET Framework, you’ll notice this if you get an exception that looks similar to the following,

System.ComponentModel.Win32Exception: Error creating window handle. at System.Windows.Forms.NativeWindow.CreateHandle(CreateParams cp) at System.Windows.Forms.Control.CreateHandle() at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible) at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible) at System.Windows.Forms.Control.CreateControl()

I’m still puzzled as to why there simply isn’t a limit based on available memory, but I haven’t been able to find a whole lot written on User objects in general much less details on why they exist.

Counting the number of files/folders in a directory

I was looking for a fast way to get the number of folders in a directory. I didn’t need anything else, just the number of folders – this was for a folder tree, and to determine whether or not to display an expansion arrow that would pull and list the subfolders when clicked. The brute-force (read: slow) way to accomplish this is just to get an array of folders and get its length. I thought such information would exist within the directory metadata, but it turns out it doesn’t, and the brute-force way is the only way.

folder tree

Quicker (quickest?) way to get number of files in a directory with over 200,000 files

How do I find out how many files are in a directory?

The stackoverflow questions refer to files, but files and folders are seen/enumerated the same way by Windows (FindFirstFile, FindNextFile), so the same limitation exists.

This post on The Old New Thing explains the reason for the lack of such metadata.

The file system doesn’t care how many files there are in the directory. It also doesn’t care how many bytes of disk space are consumed by the files in the directory (and its subdirectories). Since it doesn’t care, it doesn’t bother maintaining that information, and consequently it avoids all the annoying problems that come with attempting to maintain the information.

Another issue most people ignored was security. … If a user does not have permission to see the files in a particular directory, you’d better not include the sizes of those files in the “recursive directory size” value when that user goes asking for it. That would be an information disclosure security vulnerability.

Yet another cost many people failed to take into account is just the amount of disk I/O, particular writes, that would be required. Generating additional write I/O is a bad idea in general…

Completely understandable… but it still sucks on the application developer’s end. One solution I toyed around with is using the folder info to make a cache, instead of just getting the count and tossing the array to the garbage collector. This means, everytime a folder is expanded, the subfolders within the subfolders of the directory being expanded would be pulled and the necessary UI widgets would be created. However, this isn’t always ideal, especially as you go deeper into a folder tree, as you can end us wasting time pulling and creating UI widgets for a lot of folders which will never be seen by the user.

Let your app talk about itself

Fragment Sync has an automated update system called autobot. The system is used both for development and public releases (I should mentioned that automated updates to development copies of a networking app is a beautifully amazing thing). Updates are published to the autobot server using a simple publisher app, which puts the update package on the server and calls a server-side script to enter the patch details into a database. One annoyance with the publisher is that I would have to enter details (version, whether or not update is public, etc.) manually. This isn’t too bad, but on more than one occasion I’ve screwed things up by accidentally entering the wrong version or packaging an old executable.

I finally decided that the best way forward was to have the publisher automatically query the executable for information. You can embed this sort of information via. the application manifest, but using the manifest really didn’t cross my mind and I’m not a big fan of manifest files in general. In any case, what I did was have the executable take arguments and output the queried data to the console. This is a bit trickier than it sounds because, for whatever reason, a GUI app can’t send messages to a console without some hackery with the AttachConsole() Win32 function. (I’m dealing with C# and WinForms, but native Win32 GUI apps don’t have a default console either, so this isn’t a WinForms specific thing). The publisher redirected the standard output stream and read in the data that was pushed out.

This seems to have worked out nicely and has pushed me to think about other information an app can output about itself, lending to better communication between related apps.

Handle leaks and CreateProcess

I finally nailed down an annoying little bug tonight. In a certain app, I’ve been calling CreateProcess() to periodically spawn a process, do some work, and shut down. Unfortunately after running several hours, the app would fail with an exception saying: insufficient quota to complete the requested service. After a fair bit of monitoring the app’s activity, I notice that the handle count of the main process, slowly and surely, kept going up. After a bit of trial-and-error, disabling modules systematically, I finally noticed that this was occurring when I spawned off the child process I mentioned.

Reading the MSDN docs for CreateProcess(), I finally got to the root of the issue; the handles returned in the PROCESS_INFORMATION struct must be closed via. CloseHandle() or the handles are kept open, even though the child process has terminated.

If the function succeeds, be sure to call the CloseHandle function to close the hProcess and hThread handles when you are finished with them. Otherwise, when the child process exits, the system cannot clean up the process structures for the child process because the parent process still has open handles to the child process.

This oversight was probably due to the fact that I was working in C# (I was P/Invoking this stuff) and lulled into a false sense of safety, thinking the garbage collector would take care of stuff like this, but from working with files, various streams, sockets, etc. I realized that C# doesn’t really close handles automatically. Now that has me thinking, why not? Wouldn’t handle management be very similar to memory management?

Child process inheritance

So, a little story. I was working on some code that periodically spawns off a child process to do its thing, then read the results in the output stream from the parent process. Now, this periodic spawning was being done asynchronously in the parent process via. a thread. All was well and good, but there was also another thread in the parent process which created a file with a temporary name, downloaded and wrote a bunch of bytes into it, then renamed the file to a proper name. Unfortunately, I began to notice that the rename operation was failing as the parent process couldn’t get access rights to the file that needed to be renamed due to a sharing violation. I checked, double checked, and triple checked that I was closing the file, and everything looked perfect. After a bit of headbanging, I figured I should probably check to verify that another process is not holding the file handle. I then ran a wonderful utility called Handle to see exactly what processes had the file handle and, to my surprise, it was a child process that was spawned. Now, this was weird as hell as the child process did nothing with this file or directory or any file i/o whatsoever. After a bit more headbanging, I made the unpleasant discovery of child process inheritance. This forum thread, discussing a similar issue with a .NET’s TcpListener, actually pointed me to the issue.

Now most of this was in C#. One tricky aspect of this issue is that the file i/o mentioned was done in a bit of native code using fopen/fclose. I never encountered the issue with similar code using a C# FileStream. My assumption is that the file handles from the C# functions were explicitly not inheritable, while those created by fopen were. The underlying Win32 CreateFile API function does provide for this feature, but it’s not exposed via. fopen.

If this parameter is NULL, the handle returned by CreateFile cannot be inherited by any child processes the application may create and the file or device associated with the returned handle gets a default security descriptor.

CreateFile ignores the lpSecurityDescriptor member when opening an existing file or device, but continues to use the bInheritHandle member.

The bInheritHandle member of the structure specifies whether the returned handle can be inherited.

Now it was time for the really tricky part, fixing this. I didn’t want to change the native code (which in retrospect may have been an appropriate course of action and much easier to do), so instead I tried to see if I could prevent the process from inheriting the handle. The Win32 CreateProcess function has a bInheritHandles argument that can be set to false to prevent child processes from inheriting handles. Unfortunately, I was using the C# Process class and it provides no means to set such a flag. I eventually P/Invoked the CreateProcess function (this blog entry helped a great deal), but faced disappointment as I discovered that I can’t redirect standard output from the child process without bInheritHandles being set to true. I eventually altered the child process’ code to write its output to a file (which was actually better behavior for the app) and finally closed the door on this issue.