Tuesday, October 18, 2005

Things that won't run on my x64 machine...

I have had very few programs refuse to install. Most just run as 32 bit without issue.

These programs will not install...

  1. Daemon Tools - new release (v4) that will support x64 expected soon.
  2. Virtual Server - R2 version update will support x64. Currently in beta.
  3. MSN Desktop Search - no update expected that I could find
  4. Google Desktop Search - no update expected that I could find.
  5. Printer driver for Dell Inkjet 720 - presumably all Dell inkjets?
  6. cvsnt - at least it won't run. Not sure of the actual issue. Does great in win32.

This one requires a simple workaround...

  1. x64 Flash plug-in (and all other plug-ins as far as I can tell) - no mention of an update coming that I have found. 32-bit explorer works just fine though.

Submit this story to DotNetKicks

Insights on x64 v. x86

In my last post, it was certainly clear that I needed to do some lernin'. A very helpful fellow at MS pointed me to the following blog entries:


First, it is worthwhile to read the related articles referenced in the 10/15 post. You should also realize that during these posts, the handling of x64 targeted assemblies was in flux, and later articles contradict the earlier ones. However, the overall picture is more clear when you read them all.

The one thing I was right about in my last post was that basically these issues do arise from the program saying "I am not going to run in this environment". Whether or not they *could* run is a decision the developer has made, and is trying to enforce. In the .net world this safety mainly revolves around the use of Interop, PInvoke, and unsafe code blocks.

Version 1.1 of the framework (and strangely v. 2.0 of CLR Header- 2.0 framework produces v2.5 headers) did not have a concept of targeting processor architectures - this targeting is done in the assembly manifest. That basically means all 1.1 assemblies are agnostic. I ran a few simple tests, and here is what I found:

1. The main problem I was having when I wrote my last post was because I am an idiot, and was getting a Bad Image Format Exception (BIFE) because I was trying to load a 2.0 assembly into a 1.1 executable. Don't try that, and don't try to debug x64 issues when it happens.

2. The tool called corflags is a great help mainly as a quick assembly header reader (use it with assembly name only and it will display the target info - both 2.0 and 1.1).

3. When a 1.1 executable is loaded on an x64 machine it is run in the WOW64 as a 32-bit process and utilizes the 32-bit framework.

4. When a 2.0 executable is loaded, it runs according to how the configuration targets the architecture. If this 2.0 executable is loaded and references a 1.1 assembly, there is no problem on load. However, if the 1.1 assembly utilizes PInvoke, Interop, or unsafe code there could be runtime problems. For this reason, you should probably target x86 when compiling a 2.0 executable that utilizes these operations, or if you don't know what it does.

5. If you compile your application to "Any CPU" and the assemblies you use specifically target x86, you will BIFE it at load time. You can do two things here - compile yours to target x86 and forgo the wonder of 64-bit computing, or force a header change with corflags. The second option just seemed to break things for me.
Submit this story to DotNetKicks

Friday, October 14, 2005

x64 v.x86

I just got a new machine recently that has a Xeon proc with x64 architecture. I figured I should be forward looking. I also didn't really know what I would be getting into with program compatibility - especially with my own programs.

1. Most programs will run just fine in WOW64. Actually, why they don't all run is a mystery to me, but I bet sometimes its overactive processor architecture checking as I get stopped by the installer which tells me the program just won't run on my machine, or the program stops itself as it runs the first time. I have yet to see the program that has some fatal error when it tries to run. Since I can run programs that are easily 5 years old, I would guess any program would run. Obviously, if a program is dealing directly with the processor, or something in the 32 bit WinAPI I suppose there could be problems. But, again I don't really *get* the whole issue.

2. Developing in the .net framework held a few mysteries as well. When I installed I got the 64 bit version of the framework, and the x86 version. The 64 is my default framework and unless pointed to the 32-bit, everything runs as 64. This makes app-dev straightforward as things are marked "agnostic" or "Any CPU" in the MSIL and the proper framework is loaded when the program is run - no matter if my compiled programs are moved to a 32-bit machine.

The problem comes in when a program I compile agnostically calls on assemblies which are compiled to target the x86 framework. My program starts up a 64-bit process, and then calls on an assembly to load in that process. It is strictly x86 and fails to load with System.BadImageFormatException. So, I have to compile to an x86 config so my process gets loaded in wow, and targets the x86 framework. There seems to be more to it than this, and you can still get f'd by other people's .net stuff that has been compiled agnostically. I am looking into what to do about this. Probably some config file settings.
Submit this story to DotNetKicks

Monday, October 03, 2005

Team Foundation Beta 3

Let the fun begin! - I now have the latest RC's and now the beta 3 of the TFS. I installed the RC's the day after they came out, and have been waiting on the beta. Downloaded it last Friday, but ran into an issue rather quickly with the SharePoint Services configuration. I was able to quickly isolate the cause of this annoying error because the docs clearly state you need to install in Server Farm mode. However, no such choice is presented. Thanks to the following post:


...the answer is provided.

Moving beyond that however, I ran into an issue with the web service validators. Strangely, all this required was that I go to the services myself and run the registration service from the browser. Then, a 'retry' made it go.

That being solved, we get to our next issue: cannot connect to the Analysis server! Opening my Management Studio, I try to connect to the server and get a more helpful error. This error indicates that "under default settings SQL Server does not allow remote connections". The error indicates it is trying named pipes. I check with my Sql Server Configuration Manager, and sure enough named pipes is disabled. I enable, restart and try again. No help. I can connect in the studio, but setup still complains. After some time installing over and over again, it looks like this one is a sticky domain security issue. I tabled it for now, and just installed TeamServer on a single box.

It runs very slowly on this underpowered machine.
Submit this story to DotNetKicks