Archive for the ‘Windows’ Category

VirtualKD 2.8 with VirtualBox 4.2

Monday, March 11th, 2013

If you try to install VirtualKD 2.8 on VirtualBox 4.2.x, you get an error similar to this:

Unable to cast COM object of type ‘VirtualBox.VirtualBoxClass’ to interface type ‘VirtualBox.IVirtualBox’. This operation failed because the QueryInterface call on the COM component for the interface with IID ‘{…}’ failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).

It turns out it’s a pretty easy thing to fix. The Interop.VirtualBox.dll distributed with VirtualKD is built for the 4.1 VirtualBox interface, so you just have to rebuild it for your version of VirtualBox. Create a C# project, and paste the following code into the Program.cs file to build a new Interop.VirtualBox.dll for 4.2.x.

using System;
using System.Reflection;
using System.Reflection.Emit;
using System.Runtime.InteropServices;

namespace ConvertTypeLibToAssembly
    public class App
        private enum RegKind
            RegKind_Default = 0,
            RegKind_Register = 1,
            RegKind_None = 2
        [ DllImport( "oleaut32.dll", CharSet = CharSet.Unicode, PreserveSig = false )]
        private static extern void LoadTypeLibEx( String strTypeLibName, RegKind regKind, 
            [ MarshalAs( UnmanagedType.Interface )] out Object typeLib );
        public static void Main()
            Object typeLib;
            LoadTypeLibEx( @"C:\Program Files\Oracle\VirtualBox\VBoxC.dll", RegKind.RegKind_None, out typeLib ); 
            if( typeLib == null )
                Console.WriteLine( "LoadTypeLibEx failed." );
            TypeLibConverter converter = new TypeLibConverter();
            ConversionEventHandler eventHandler = new ConversionEventHandler();
            //AssemblyBuilder asm = converter.ConvertTypeLibToAssembly( typeLib, "Interop.Virtualbox.dll", 0, eventHandler, null, null, null, null );
            AssemblyBuilder asm = converter.ConvertTypeLibToAssembly(typeLib, "Interop.VirtualBox.dll", TypeLibImporterFlags.SafeArrayAsSystemArray, eventHandler, null, null, "VirtualBox", null); //using assembly name "VirtualBox" and SafeArrayAsSystemArray to be compatible to VisualStudio-Generated Interop-Assembly


    public class ConversionEventHandler : ITypeLibImporterNotifySink
        public void ReportEvent( ImporterEventKind eventKind, int eventCode, string eventMsg )
            // handle warning event here...
        public Assembly ResolveRef( object typeLib )
            // resolve reference here and return a correct assembly...
            return null; 

Some of this code was grabbed from MSDN, and a single line was grabbed from VirtualBoxService. As the latter is GPL, this code may be GPL. I don’t claim any rights to it.

Problems with file descriptors being inherited by default in Python

Wednesday, February 6th, 2013

Have you ever run into a traceback that ends with something like this?

  File "C:\Python27\lib\logging\", line 141, in doRollover
    os.rename(self.baseFilename, dfn)
WindowsError: [Error 32] The process cannot access the file because it is being used by another process

I certainly have, in a few places. The basic problem is that when python creates file objects on Windows (and I think on *nix as well), by default Python will mark the handle as being inheritable (I’m sure there’s a reason why… but, doesn’t make a whole lot of sense for this to be the default behavior to me). So if your script spawns a new process, that new process will inherit all the file handles from your script — and of course since it doesn’t realize that it even has those handles, it’ll never close them. A great example of this is launching a process, then exiting. When you launch your script again and try to open that handle… the other process still has it open, and depending on how the file was opened, you may not be able to open it due to a sharing violation.

It looks like they’re trying to provide ways to fix the problem in PEP 433 for Python 3.3, but that doesn’t help those of us still using Python 2.7. Here’s a snippet that you can put at the very beginning of your script to fix this problem on Windows:

import sys

if sys.platform == 'win32':
    from ctypes import *
    import msvcrt
    __builtins__open =
    def __open_inheritance_hack(*args, **kwargs):
        result = __builtins__open(*args, **kwargs)
        handle = msvcrt.get_osfhandle(result.fileno())
        windll.kernel32.SetHandleInformation(handle, 1, 0)
        return result
    = __open_inheritance_hack

Now, I admit, this is a bit of a hack… but it solves the problem for me. Hope you find this useful!

Screw cygwin, I’m using GNUWin32

Wednesday, April 15th, 2009

For years I’ve hated cygwin (not for any particular reason, I just don’t like it) and have generally avoided using it because of that — but I’ve finally found a good alternative if you want useful *nix tools on Windows. Its called GNUWin32 and its a bunch of GNU utilities that have been ported to windows, and they’re quite lightweight also.

Its pretty sweet, I’ve actually had grep installed on my computer for quite awhile now, and just recently started installing more of these packages as my needs have evolved. I’d highly recommend it. The key thing to do is to add the bin directory to your path, so that way its accessible from cmd by default without having to screw around with typing out the full path name or anything.

SSHFS For Windows

Wednesday, July 9th, 2008

This japanese guy apparently wrote something similar to linux’s FUSE for Windows (supporting user-mode filesystem drivers) and created a number of bindings for it. As a practical example, he’s implemented SSHFS in windows, which is awesome IMHO and exactly what I’ve been looking for.

However, this means someone can now write a filesystem driver in Visual Basic. How awesomely crazy is that?

Go to his site to download SSHFS for Windows.