Virtual Server being accessed by a 32-bit or 64-bit binary

8. February 2007 07:07 by Csaborio in General  //  Tags: ,   //   Comments (0)
Yesterday, one of the attendees from the Virtualization events asked this question which I though would be worthwhile to share:

For a simple .NET application like this, would we need different applications when running on 64 vs. 32 bit hosts?

Before answering, please allow me to elaborate more on where the question is going.  Virtual Server has a COM API that allows it to be managed by applications and scripts.  Virtual Server R2 SP1 Beta 2 (phew) comes in two flavors: 32-bit and 64-bit.  The owner of the question wondered if you could manipulate a 64-bit instance of Virtual Server using a 32-bit application (or vice-versa).

Ok, now that the question is (hopefully) a bit clearer, the answer to the question is no, you do not need to have a different version for accessing Virtual Server from an application regardless of its bit-architecture.  Why?  Virtual Server's COM API is accessed by an out-of-process COM library, which means that everything is done by means of RPC.  When two applications are communicating with each other by means of RPC, the 1st commandment of 64-bit is not broken (thou shall not run 32-bit and 64-bit code within the same process space). 

Optimizing Multi-Threaded Applications on the Itanium 2 (Part 1)

22. January 2007 12:59 by Csaborio in General  //  Tags:   //   Comments (0)

If the tasks that your application carries out are independent of each other, a way to optimize things is to create threads for various tasks.  There are many ways to thread applications including Pthreads, windows threading, and recently OpenMP.  OpenMP excels in the sense that it can make your application multi-threaded by just writing a few pragmas here and there.

Once you multi-thread your application, many things can go astray.  For instance, different threads can access variables at different intervals in a loop, which can only lead to disastrous results in your calculations.  You can break your head and lose some of your sanity by manually debugging what is going wrong with your application or you can use Intel's thread checker to find out what is going on.  For instance, the following sceenshot shows you the output of all the problems (referred to as data races) when various threads were accessing variables and changing them on each loop:



Furthermore, your application's threads might starve waiting for a particular resource to be freed, which can only make the whole multi-threading effort futile.  Tools like Intel's thread profiler can help you find this info.  For example, after data collection, based on the following screenshot, you can pretty much tell that due to locks in the code, the threads are pretty much stalling the application:



Now that you know what these two tools are and what they do, what I wanted to show you was how to get around the fact that none of these tools can be installed on a Itanium box.  That is, now that the Itanium is dual-core, how do you go about optimizing multi-threaded apps using these tools?   The solution to this problem will be included in the second part of this post, stay tuned!

An Error with the Intel C++ Compiler 9.1.028

9. January 2007 12:16 by Csaborio in General  //  Tags:   //   Comments (0)

These days I have been testing all of our 64-bit labs on a Montecito (Itanium) box that was lent to use by HP.  The newest feature of this new chip is the fact that it has two cores, which should make multi-threaded applications perform a lot faster.  I have not developed in a while for the Itanium, and one of the first things that struck me was the fact that there is no "Intel Compiler Installer" available for download.  As of version 9.1.028, the compiler installer includes compilers for x86, x64, and IA64 - sweet.

While following my usual install procedure (click next until the installer finishes) I noticed that my IA64 compiler was completely broken - even when compiling a Hello World.  The error I got was the following:

icl: internal error: Assertion failed (shared/driver/drvutils.c, line 535)

After reading some forums which did not hint me at all what the problem was, I decided to re-install but this time around reading the installer screens.   It happens that one of the requirements for this compiler to work is that it needs the PSDK from Microsoft installed, something that I had completely forgotten to do.  Once I installed the PSDK, the IA64 compiler was a happy camper and everything worked OK.  Hopefully, some desperate soul will be able to find this info if they ever face that dreaded message.

How to run Visual C++ Binaries in a 64-bit Machine without Visual Studio installed

11. September 2006 06:28 by Csaborio in General  //  Tags:   //   Comments (0)
Fact: You cannot install Visual Studio on an Itanium box - this is a "by design" issue and the installer will not budge regardless of what you try.

So if you are building binaries from Visual C++, how do you manage to make them run given that most of the libraries they need will not be found on the Itanium box?

One workaround is to statically link your binaries - which oftentimes lead to bloated sizes and defies the whole purpose of using dynamically linked libraries.

Another one is to install the Visual C++ Runtime libraries for Itanium and x64:
Install these on your 64-bit server and C++ binaries will run in all of their glory.  With Remote Debugging and these utilities installed, you won't even need a RDC to the 64-bit box to run your code.  Happy coding!

Sending Mail via MAPI using Outlook Office in 64-bits

23. July 2006 17:05 by Csaborio in General  //  Tags:   //   Comments (0)
We recently received an interesting mail detailing the problems faced when using MAPI to send mail via Office Outlook Express. Here are the symptoms (try and see if you can figure it out by the end of the post):

1. When using MAPI calls in a 32-bit application when Outlook Express is the default e-mail handler, the application creates a blank message (success)
2. When using MAPI calls in a 64-bit application when Outlook Express is the default e-mail handler, the application creates a blank message (success)
3. When using MAPI calls in a 32-bit application when Office Outlook is the default e-mail handler, the application creates a blank message (success)
4. When using MAPI calls in a 64-bit application when Outlook Express is the default e-mail handler, the application does not create a blank message (failure). When the program ran and tried to create an e-mail, the Outlook Express connection wizard showed up.

After comparing registry entries for hours trying to find why Office Outlook was not being recognized as the default e-mail client and why Outlook Express was, it then hit me. There is a 64-bit version of Outlook Express on every 64-bit Windows install, that is why scenarios 1 & 2 above were working! There is some MAPI calls via DLLs, and since there is a 64-bit version of Outlook Express, everything works fine when it is the default e-mail client.

The story with Office Outlook is different. Since it is only 32-bit, when it is registered as the default e-mail client, only the 32-bit section of the registry is affected. That is why when the 64-bit MAPI program tries to send mail, it only sees Outlook Express. This makes sense as the MAPI functionality to work with Office Outlook is a 32-bit DLL, which would not work when called from a 64-bit binary.

As far as what can be done to overcome this problem, you ask? I have not tested this, but if you could build yourself an out-of-process 32-bit COM LocalServer that was responsible for invoking the MAPI functionality of sending mails, you could (in theory) invoke it from a 64-bit application and be done with your bit-dependencies problem.

This link is a great place to start. I will be busy at an event here in Redmond, but if I have some free time I will try to come up with the solution and post it here,

Itanium with VT support thoughts and questions

20. July 2006 09:25 by Csaborio in General  //  Tags: ,   //   Comments (0)

After reading Jose's blog entry, I immediately had some questions about virtualization on the new dual-core Itanium architecture.  First and foremost, which software vendor out there has a Virtualization solution that supports the Itanium?  As far as I know, the roadmap for Virtual Server 2005 R2 SP1 does not include support for the Itanium.  Longhorn's roadmap does not include any foreseen support for the hypervisor on the Itanium either, so no luck in there as well.

Secondly, if some company indeed supported VT on the Itanium and allowed you to say, run Windows XP 32-bit on a virtual machine, would  that be faster than running the a 32-bit application directly on Windows Server for the Itanium?  Also, how would the WoW64’s performance (which IMHO is the Itanium's Achilles’ heel) be affected by the fact that there is VT support? 

These are many, many questions for which I have no answer for and hopefully will be addressed soon enough.

New Series of 64-bit Related Web Casts

28. June 2006 04:14 by Csaborio in General  //  Tags:   //   Comments (0)
Starting today (like in 30 minutes ;) ), we will start the first webcast in a series of three.  These revolve around most of the things we have discussed in the labs plus some new ones such as issues with 64-bit installers, setting up VS for 64-bit deployment, and multi-threading your application using OpenMP standards.

You can find the whole list here.  Tomorrow, Thursday 29th, I will be presenting a webcast that has many, many demos on how to preserve dependencies in 64-bit.  Feel free to stop by and let me know your comments once the session is over.

If you really have no idea on what to expect when moving to 64-bit, then these webcasts are definitely worth listening to.