views:

130

answers:

2

Well, to begin with, I'm using Visual Studio 2008 on a 32-bits Windows XP system. I have a second 32-bits Vista system but that's not used for development. I just ordered a new development computer which will use 64-bits Vista. (Don't want Windows 7 just yet, but will probably upgrade to Windows 7 in two years from now if it has a good market value.) (Btw, Intel Xeon Quadcore, 12 GB RAM, 1.3 TB diskspace over 2 disks.) I know that most 32-bits applications will work just fine, including VS and several others. I'm not too worried about this anyways. I also do development with Delphi 2007 but am not worried about this either. But I do want to take this in consideration:

On this new 64-bits system I can start developing 64-bits applications. This is new for me, so what are the most common pitfalls that I need to avoid when I start to develop new 64-bits applications? For example, datatypes that are of a different size, a file system that might be different, special 64-bits functions that I need to be aware of, possible conflict when I have to combine my 64-bits code with 32-bits assemblies, etc.

(I know one already: when developing web applications, I need to make sure my webhost is supporting 64-bits applications, else it's no use... Apparently, IIS doesn't seem to be able to support both 64-bits and 32-bits applications, so that's one pitfall.)

I'm not going to port 32-bits applications to 64-bits applications. I just want to create new 64-bits applications. From scratch! So without any 32-bits history. I've also read about this unanswered Caveat question but that's more about migrating. I won't migrate anything.

+1  A: 

I've been using a 64-bit Vista system since November, with very few problems. The worst so far is that in Visual Studio, to debug a Script Task in SSIS, you have to tell it not to use the 64-bit runtime.

John Saunders
+1  A: 

Deployment headaches at least for desktop applications.

Special Folders are different for some reason.

Edit and Continue in Visual Studio only works when compiling to 32bit.

You could find some obscure issues which could take forever to work around.

eschneider