Install the Surface SDK SP1 Workstation Edition on x64

Posted May 14, 2009 2:28 AM Categories: .NET | Surface | x64

image_thumb

Update 11/20/09: The Surface SDK is now available to everyone at the new Surface website!  The instructions below should continue to work just fine…let me know if they don’t.

Update 10/29/09: It appears that the version of the SDK available from the Microsoft Partner site comes as a straight .exe file.  To extract this back into the MSI file to follow the instructions below, execute the following command:

"Microsoft Surface SDK 1.0 SP1, Workstation Edition.exe" /extract c:\surface

This should spit out a MSI file to the c:\surface directory and you can continue on with the instructions below.  Thanks to Tim Hurst for the info!


The Surface SDK SP1 Workstation Edition was released this week and while it will install (but is still unsupported) on Windows 7, it will not install on a 64-bit machine.  The installer has changed a bit, so my previous instructions will not work with this installer, but I have managed to get the new package to install and run.  And here’s how…

As before, this is a totally unsupported setup, so if official support from Microsoft is required, this is not for you.

Please note that you will still need to meet the other hardware and software requirements of the SDK.

To perform the actions in this guide you will need to install Orca, a tool for editing MSI files, included with the Windows SDK.  Unfortunately, this utility isn’t available separately and will require you to download the full SDK to get it.  You can download the Windows Vista or Windows 7 SDK here.

1) Extract the MSI to its individual files

This can be done with the following command performed in an elevated cmd window:

msiexec /a SurfaceSDKWE.msi /qb TARGETDIR=c:\surface (or some other TARGETDIR of your choosing)

When complete, you will have a new directory at TARGETDIR filled with a smaller MSI and all the files contained within the original MSI.

2) Remove the platform check from the MSI

Open the newly extracted SurfaceSDKWE.msi file in Orca.  Select LaunchCondition from the left pane.  In the right pane, select the row labeled Installed OR NOT VersionNT64, right-click, and select Drop Row.  This will remove the check for a 64-bit OS.

5-14-2009 5-52-27 AM

After the rows are dropped, save the MSI using the standard File –> Save menu option.

3) Patch the setupcustomaction.exe file

This executable is called during the SDK installation process.  Because the installer will launch as a 64-bit application, so will this executable, which will force it to write some registry values into the wrong location.  Therefore we have to patch this file using the corflags.exe utility included in Visual Studio and the .NET SDK. 

If you have the full Visual Studio installed, simply open an elevated Visual Studio Command Prompt from the Start Menu and the path to corflags.exe will automatically be loaded.  Otherwise, you should find this in the C:\Program Files\Microsoft SDKs\Windows\v6.1\Bin directory and you can set your PATH environment variable appropriately.

With the path to corflags.exe in your PATH environment variable, change to the following directory:

<TARGETDIR from above>\Microsoft Surface\v1.0

Inside this directory, run the following command:

corflags setupcustomaction.exe /32bit+ /force

You will get a warning that the file is strong named signed.  You can safely ignore this.

Administrator Visual Studio 2008 Command Prompt (2)

4) Install the SDK

Now that the MSI and setupcustomaction.exe have been patched, run the extracted and patched SurfaceSDKWE.msi file from the TARGETDIR location, not the original MSI file.  As long as you have the other prerequisites installed, the SDK will install without issue.

5) Patch the executables / Build and fix the samples

These steps are identical to last time, so I will just link to the original blog post here.

And there we have it.  A patched and working Surface SDK SP1 running under Vista/Windows 7 x64.  As always, run this at your own risk, but let me know how it works out for you if you give it a try.

Install the Surface SDK on Windows 7 and/or x64

Posted March 10, 2009 1:31 AM Categories: .NET | x64 | Surface

image

Update: Running Surface SDK SP1?  See my other post on how to install it on a 64-bit machine...

The Microsoft Surface SDK was given out to some folks at PDC 2008.  I know the SDK is not out to the masses yet, however one of the questions/requests posted most frequently in the Surface forums is the ability to install the SDK on a 64-bit machine, and/or on Windows 7.  I’ve put together a quick guide that will show how to accomplish this.  But be warned…by doing this you are throwing away support from Microsoft.  This is an entirely unsupported setup and the Microsoft Surface folks won’t be able to help you.  So, if official support is important to you, this guide isn’t for you.  With that said, let’s continue…

Please note that you will still need to have Visual Studio 2008 Express or greater installed, and you will need to have the XNA 2.0 Framework runtime installed.

To perform the actions in this guide you will need to install Orca, a tool for editing MSI files, included with the Windows SDK.  Unfortunately, this utility isn’t available separately and will require you to download the full SDK to get it.  You can download the Windows Vista or Windows 7 SDK here.

1) Remove the platform checks from the MSI

Open the SurfaceSDKWE.msi file in Orca.  Select LaunchCondition from the left pane.  In the right pane, individually select the rows highlighted in the screenshot below, right-click, and select Drop Row.  This will remove the checks for 64-bit, Windows Vista, and Windows Vista SP1.  The rows are:

  • Installed OR (VersionNT=600 AND ServicePackLevel>=1)
  • Installed OR NOT VersionNT64
  • Installed OR VISTASKU="Business" OR VISTASKU="Ultimate" OR VISTASKU="Enterprise"

3-10-2009 4-40-54 AM

After the rows are dropped, save the MSI using the standard File –> Save menu option.

2) Install the SDK

Now that the MSI has been edited to remove the checks, install the SDK normally.

If you are using Windows 7 x86, you are done!  If you are running on an 64-bit OS, please continue…

3) Patch the executables

Now that the SDK is installed, several executables need to be patched to be forced to run inside the 32-bit CLR instead of the 64-bit CLR.  This will be done using the corflags.exe utility.  If you have the full Visual Studio installed, simply open an elevated Visual Studio Command Prompt from the Start Menu and the path to corflags.exe will automatically be loaded.  Otherwise, you should find this in the C:\Program Files\Microsoft SDKs\Windows\v6.1\Bin directory and you can set your PATH environment variable appropriately.

With the path to corflags.exe in your PATH environment variable, change to the following directory:

C:\Program Files (x86)\Microsoft SDKs\Surface\v1.0\Tools\Simulator

Inside this directory, run the following command:

corflags SurfaceSimulator.exe /32bit+ /force

You will get a warning that the file is strong named signed.  You can safely ignore this.

3-10-2009 4-57-13 AM

Next, change to the following directory:

C:\Program Files (x86)\Microsoft Surface\v1.0

There are several executable to be patched in this directory.  You can easily do this from a single command as follows:

for %i in (*.exe) do corflags %i /32bit+ /force

This will enumerate all .exe files and patch them as done above.  You will again see the warning, and again, it can be safely ignored.

3-10-2009 5-05-50 AM

Update 12/4/09: If you have problem with the Identity Tag printer not bringing up the printer dialog box, modify the above command to add the /UpgradeCLRHeader switch.  Thanks to Klaus Amtoft for this tip!

If you don’t care about running the sample applications, you are finished.  If you want to install and run the samples in the simulator, continue.

4) Build and fix the samples

The samples, by default, are setup to build as “Any CPU” executables.  This means they will always run under the 64-bit CLR, which is a problem.  They need to be built to run in the 32-bit CLR.  There are two ways to handle this: 1) you can edit each .csproj file to create an x86 build type and build the project, or 2) you can build the projects as-is, and patch them later.  I find option 2 to be easiest, so that’s what will be described here.  Note that you won’t be able to run and debug these samples via Visual Studio by doing this…if this is required, please go with option 1.

Unzip the Surface Code Samples.zip file from the C:\Program Files (x86)\Microsoft SDKs\Surface\v1.0\Samples directory.  This should output a SDKSamples directory.  In this directory, open the InstallSamples.bat file in Notepad.  You will see several lines that check the registry for various things.  Each one of these will path the registry in a way similar to the following:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Surface\v1.0 /v IsLogicalSurfaceUnit

Modify each of these to add the Wow6432Node key, which is part of the 64-bit registry that 32-bit applications access:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Surface\v1.0 /v IsLogicalSurfaceUnit

It’s probably easiest to do a find and replace, finding SOFTWARE\Microsoft and replacing with SOFTWARE\Wow6432Node\Microsoft.

Next, run the InstallSamples.bat file.  This will build each sample and deploy them to the Microsoft Surface Simulator.

Now we need to patch the built executables.  Back in the elevated Visual Studio Command Prompt, change to the directory where you unzipped the sample SDKs.  For me, this path is:

C:\Program Files (x86)\Microsoft SDKs\Surface\v1.0\Samples\SDKSamples

Run the following command to enumerate all directories and patch the executables:

for /r %i in (*.exe) do corflags “%i” /32bit+ /force

3-10-2009 5-17-51 AM

Each file will be patched to run in the 32-bit CLR only.

That’s it!  You should now be able to build, run and debug applications using Visual Studio and the Microsoft Surface SDK on Windows 7 and Windows Vista, either x86 or x64.

Just remember…this is a totally unsupported scenario, so run at your own risk!

64-bit Development Discussion on .NET Rocks

Posted May 13, 2008 11:03 AM Categories: Personal | .NET | x64

I did an episode of the .NET Rocks show last month which debuted today on the site.  Now, instead of only reading my idiotic ramblings, you can actually listen to my idiotic ramblings.  Lucky you!

Anyway, the show is a discussion on 64-bit development with .NET and all the fun that comes with it.  Have a listen...

x64 Development with .NET

Posted November 13, 2007 1:01 AM Categories: .NET | x64

Earlier this year I made the switch to a 64-bit operating system - Vista Ultimate x64 to be exact.  For the most part, this process has been relatively painless, but there have been a few hiccups along the way (x64 compatible drivers, mainly, but that's not the point of this discussion).

In the world of x64 development, there have been a few struggling points that I thought I'd outline here.  This list will likely grow, so expect future posts on the matter.

In the wonderful world of .NET development, applications and assemblies can be compiled to target various platforms.  By default, applications and assemblies are compiled as Any CPU in Visual Studio.  In this scenario, the CLR will load the assembly as whatever the default target is for the machine it is being executed on.  For example, when running an executable on an x64 machine, it will be run as a 64-bit process.

Visual Studio also provides for 3 specific platform targets:  x86, x64 and Itanium (IA-64).  When building an executable as a specific target, it will be loaded as a process of that type.  For example, an x86-targeted executable run on an x64 machine will run as a 32-bit process using the 32-bit CLR and WOW64 layer.  When assemblies are loaded at runtime, they can only be loaded by a process if their target matches that of the hosting process, or it is compiled as Any CPU.  For example, if x64 were set as the target for an assembly, it can only be loaded by an x64 process.

This has come into play in a few scenarios for me:

  • XNA - XNA is available as a set of 32-bit assemblies only.  Therefore, when referencing the XNA assemblies, the executable/assembly using them must be targeted to the x86 platform.  If it is targeted as x64 (or as Any CPU and run on a 64-bit machine), an error will be thrown when trying to load the XNA assemblies.
  • Microsoft Robotics Studio - The XInputGamepadService uses XNA internally to talk to the Xbox 360 controller.  See above.
  • Managed DirectX - While this is already deprecated and being replaced with XNA, it still has its uses.  The assemblies are not marked for a specific target, however I had difficulty with memory exceptions, especially with the Microsoft.DirectX.AudioVideoPlayback assembly.
  • Phidgets - Depending on what library you download and when, it may or may not be marked as 32-bit only.  The current version (11/8/07) is marked as such, and so requires a 32-bit process to host it.

The easiest way to determine if an executable or assembly is targeted to a specific platform is to use the corflags application.  To use this, open a Visual Studio Command Prompt from your Start menu and run it against the assembly you wish to check.

image

Here's a handy table to decode the resulting information:

CLR Header NOT the version of the CLR the file is compiled for
2.0 = .NET 1.0 or 1.1
2.5 = .NET 2.0
PE PE header type
PE32 = 32-bit
PE32+ = 64-bit
CorFlags Various flags for endian type, ILONLY, etc.
ILONLY The file contains IL only (i.e. no unsafe code)
32BIT 1 = x86 target
0 = Any CPU target
Signed 1 = Assembly signed
0 = Assembly not signed

And here is a second table showing the mapping from target to flags:

Any CPU PE32 with 32BIT = 0
x86 PE32 with 32BIT = 1
x64/Itanium (IA-64) PE32+ with 32BIT = 0

So how do you work around using 32-bit assemblies on a 64-bit platform?  There are two answers to this.

Use corflags against the file with the /32BIT- switch to remove the x86 restriction.  This will make the assembly look like an "Any CPU" compilation.  Note that this will only work on unsigned assemblies.  If the assembly is signed, you can use the /Force switch to make the change, but this will likely just break the assembly and make it unusable.  I don't personally recommend using corflags since it's likely that if an assembly is distributed with this flag set, it's probably done that way for a reason.  So, let's look at method two.

Create a new configuration which targets x86 and everything should work.  With the host process being forced to run as a 32-bit application, any 32-bit specific libraries will work just fine.  Here's how:

  1. From the Build menu, select Configuration Manager
  2. In the Active solution platform: drop down, select <New...>
    image
  3. In the Type or select new platform drop down, select x86
    image
  4. Click OK to get back to the main Visual Studio window and ensure the x86 configuration is selected in the build bar or in the Platform drop down in the project settings.
    image
  5. Rebuild the project

Your output will now be located in the bin\x86 directory.

In the next installment, I'll discuss some of the issues with using P/Invoke in .NET from the 64-bit world.

My Info

  • View Brian Peek's profile on LinkedIn

Sponsored Ad

My Book

Sponsored Ad