Vlad Hrybok's Tech Notes

Here's how it works: for the last two years we at UltiDev LLC work mainly on HttpVPN - our flagship product and the main reason why our company exists. Once upon a time we've decided that making a simple redistributable web server software would be a great value-added piece completing HttpVPN offering and allowing us to probe prospective market for HttpVPN, gather contact information of people who may by interested in HttpVPN and setup our QA, build and release processes along the way. The experiment turned out to be as successful and we hoped it would be. We've got about 15,000 (and counting) installed UltiDev Cassini Web Server runtimes worldwide and we are receiving overwhelmingly positive feedback from users. All this also means that about every six months we have our Cassini task tracker full enough to suspend HttpVPN work for a few weeks and do another release or UltiDev Cassini. This time was no exception.

Although we always hope to keep our Cassini mid-version upgrade development cycle limited to three weeks, it took us usual five weeks to fix, test, fix again, test again and release the latest version of UltiDev Cassini Web Server. This release had two main points of focus: to eliminate all known installation/registration hurdles and to make UltiDev Cassini compatible with all 64-bit Windows platforms. 64 bit OSes are gaining popularity very rapidly thanks to the fact that most of the recent (and even not so recent - think Pentium D) CPUs from AMD and Intel are x64-compatible. Windows Vista comes in 32- and 64-bit versions right from the start, while existing Windows XP Pro x64 and Windows 2003 Server 64-bit were somewhat obscure because they were released before 64-bit CPUs hit the mainstream. Nowadays it's pretty much impossible to buy a CPU that does not have x64 compatibility. Hoping to please Vista 32 and 64 bit users we made sure that our latest version of Cassini runs smoothly on all the latest multicore 32 and 64 bit CPUs and supports entire (reasonable) line of Windows operating systems: from Windows 2000 to Vista.

Now, whether you own an older version of our tiny but powerful UltiDev Cassini, or you never tried it - go ahead and download the latest version. If you owned old version - most of the known issues will go away (or if you had none you will be less likely to face issues in the future). If you never saw our Cassini - it's a perfect time to spend 20 minutes on something you probably will go "wow!" about. Check it out now!

All! If you use Visual Studio 2003 or 2005 to create MSI-based setup packages, here's a good one for you: if your installation uses Uninstall and Install/Commit custom actions implemented as an installer class - you are in trouble. In the process of upgrading your product MSIEXEC.exe first loads an assembly with Uninstall custom action implementation - to complete previous version uninstallation. After that it tries to load installer class of the new version to do Install and/or Commit custom actions of the new version. At this point things can get really bad. If your custom action assembly is not signed/strongly named (and in my experience sometimes even if it is signed) MSIEXEC.EXE will fail to load custom action assembly from the new version and will run Install/Commit custom steps from the old one. This means that if you added new code to your Install/Commit steps it simply won't be executed during upgrade. Even worse: Install/Commit custom actions of the old version will run instead of the new one!

This happens due to completely bizarre, to put it mildly, logic of .NET Assembly.LoadFrom() method. .NET Framework has a rule that after assembly is loaded it can't be unloaded unless it was loaded into a separate AppDomain: appdomains can be unloaded and assemblies can't. Two assemblies may end up looking the same to LoadFrom() if they have the same name even if they are located in different folders or have different versions. So what happens here is this: after MSIEXEC.exe loaded assembly named 'X' to do Uninstall custom step, the subsequent attempt to load assembly named also 'X' from another folder to do Install/Commit step does not happen. But get this: one would expect that if you asked LoadFrom() to load assembly 'X' from folder 'Y' it should either load it or tell you it can't. Instead due to some truly twisted logic, LoadFrom() won't fail if it can't load new 'X' assembly - it will simply return the reference to the one that is already loaded. So much for solving DLL hell problem!

Microsoft knows about the problem since 2004
http://support.microsoft.com/kb/555184/

It didn't, however, fix it yet:
http://support.microsoft.com/kb/906766

They recommend giving unique names to custom action assemblies for each new release. Alternatively they say signing an assembly will make problem go away. I tried signing and in my small test project it made problem go away, but not in the "real" one. I am stuck with having to rename custom action installer assemblies for each release. All Microsoft needed to do is this: force installer to create new appdomain and load old version's Uninstall custom steps assembly there and let it run. After it's done, unload the appdomain and create the new one where you load new version's custom action assembly with Install step implementation. That would make it unnecessary to give assemblies unique names - strong or physical. My understanding is that Visual Studio adds a small shim DLL to the MSI package that loads .NET installer classes from the custom action assemblies. This means they don't even need to wait for another MSI API release to fix it - every new Visual Studio or a even a Service Pack for Visual Studio could have fixed the issue that is still with us more than three years later.

In Windows XP one could just double-click an .MSI (Windows Installer) file to start package installation: MSIEXEC.exe is associated with the .MSI extension and if user had administrator rights installation would go forward. Clicking .MSI file was functionally identical to running Setup.exe bootstrapper, provided Setup.exe didn't have additional functions other than starting the installation.

In Windows Vista things are different. When Vista's User Account Control (UAC) is turned on, launching Setup.exe is not quite the same as running MSIEXEC.EXE /i mypackage.msi. The difference is that when Setup.exe is started, Vista runs it in "elevated" mode, which gives the process more privileges. MSIEXEC.EXE does not seem to run in elevated mode and therefore behavior of the installation may be different.

The issue seems to be manifesting itself most often when an MSI setup package made using Visual Studio executes custom action steps implemented as an Installer class. I am not sure what exactly happens but I noticed that MSI error 2689, which is a common result of failed custom action, will go away if installation initiated using Setup.exe instead of just clicking on .MSI file.

Bottom line: On Vista always start installations by launching Setup.exe instead of double-clicking .MSI file.

Another possibility to consider: if you were not a victim of computer virus attack in the last five years (Windows XP lifetime), then you are may want to simply turn Vista UAC off.

If it takes too long to redraw the screen when you access your remote virtual machine using VmWare Server Console or Microsoft Virtual Server admin page, consider terminaling into your virtual machines using Remote Desktop or Terminal Server client. UI works as fast as with any "real" remote PC. Entry-level Windows XP Home and Vista Home don't support Remote Desktop, but all Pro, Business, Media Center Edition and other flavors of Windows Vista, XP and 2003 work just fine. One of my co-workers told me Remote Desktop can be used for VmWare Workstation access, but I also tested VmWare Server and Microsoft Virtual Server R2, and those two also do it.

To enable Remote Desktop access a few things usually need to be done:

1. Enable RD access:

2. Ensure your user account is a member of the Administrators group.
3. The password on your user account is not blank.

The only issue I had with this setup was sometimes I couldn't ping the virtual machine due to networking issue. But when that happens all attempts to access that virtual machine over the LAN fail, including NetBIOS file shares, web access - anything.

Just-announced Windows Home Server is a good news for UltiDev LLC even though Windows Home Server currently is not much more than glorified Network Attached Storage and an automatic backup system. Windows Home Server is based on Windows 2003 Server and therefore does not have TV recording functionality for Media Center Edition one would expect from household server. But despite being driven by Windows 2003 Server, Windows Home Server does not seem to have web server and email server on it.

Our HttpVPN and Cassini Web Server products will make MCE attractive for every developer who can make a web-based application. To be truly useful household platform, all software for household servers should web-based and should accessible securely and reliably on Internet as well as and inside the home network. Good news for us is that we do it while Microsoft does not seem to.

I think people will feel much more comfortable when their data is stored on their own servers at home and being accessible everywhere using secure web connection, instead of having data stored on third party servers. Real "web 2.0" (God, I hate this marketing gimmick!) is not only user-generated content, but user-generated content stored on user's own servers and securely accessible from everywhere. This is what we are making happen with HttpVPN, which makes every programmer who can write ASP.NET, JSP, PHP, Perl, Python, ASP, Cold Fusion (or whatever else web development tool he/she is using) a potential winner in the huge but completely untapped market of home server software.

I feel good to be at the right place at the right time. You need to join in.

I need to test my software on a variety of 64-bit Windows versions. I hoped I would be able to use Microsoft Virtual Server, which I've been successfully using for a while for 32-bit tests (including German, Russian and Korean flavors of Windows - quite a feat for a Ukrainian with English as a second language), but to no avail - at this point even latest MS Virtual Server is unable to host 64-bit guest operating systems. So despite enjoying being lazy, I was forced to check out free VmWare Server. I hoped to run it on my main Vista x64 dev box, but VmWare Server did not install correctly on Vista x64. That was quite a setback for my product delivery schedule, because I realized I needed another box with 64-bit Windows 2003 Server on it to be sure I could run VmWare Server. I dug through my closet with PC parts and after combining what I had with $200 worth of parts bought from NewEgg.com I had a modest 64-bit box with Pentium D 805 and 1GB of DDR memory. VmWare has installed without a problem, but when I attempted to install Windows XP x64 VmWare Server told me that my Pentium D CPU is no good because when it comes to Intel CPUs, 64 bit guest OSes can run only on EMT64 units with Virtualization Technology (VT) support! Fortunately, my dev desktop had Core 2 Duo E6300, which does have VT support, and both Pentium D and Core 2 Duo use the same LGA 775 package, so I was able to simply swap CPUs and ta-da! - after that VmWare finally started cooperating and is installing XP x64 guest OS as I'm typing this article.

Conclusion: If you want to run 64-bit guest OS in VmWare using Intel CPU you will need a box with a processor supporting Virtualization Technology, and run Windows 2003 x64 as a host OS.

I have Cingular 3125 windows smartphone. When I bought it I also got Kingston 1GB MicroSD flash card to stash my MP3 files on it. That didn't work well. The behavior was strange: all files and folders on the storage card were accessible immediately after phone was turned on, but some time later only folders in the storage card's root were shown by the phone's file explorer or Windows Media Player library - all other files and folders seemed missing until phone was powered down and then turned back on. I replaced the card with Sandisk, which worked fine - until something happened and all files on the card got corrupted or missing. I had to re-format the Sandisk card and I formatted it as FAT, a.k.a. FAT16. To my astonishment, it has started to behave just like my old Kingston card. I reformatted it again as FAT32 and it has started working fine! So here you go: format your storage card as FAT32 for using it in your Microsoft Windows Mobile Smartphone.

After installing VmWare Server on 64-bit Windows 2003 Server R2, I was unable to access VmWare Server's web admin page due to Service Unavailable error. VmWare support forum suggests to remove .NET Framework 2.0, which seems to help some people, but I fixed the problem by repairing .NET Framework 2.0 installation after VmWare server was installed. To do that go to Control Panel -> Add/Remove Programs, select .NET Framework and hit Change/Remove button. In the dialog select repair and let it run. After that both Default Web site and VmWare web site were running fine.

It appals me beyond any limit every time I see a commodity turned into a product. Like with Mach-150 razors with 1200 blades in it, or printer ink cartridge costing more than a printer, it is a clear-cut scam every single time. Case in point: "high-end" digital A/V cables. One of my colleagues has recently bought 9ft HDMI cable for $100. It was all fancy, gold-plated, silver wrapped cable in a very pretty package. However, although HDMI is a cable used for Audio/Video purposes, it still does exactly the same stuff as your regular 1GB Cat 5 Ethernet cable or USB cable: it moves ones and zeros. Now, even in retail CAT 5 cable costs about $0.40 per foot. Look at all the USB cables around you connecting all sorts of equipment, from digital cameras and external hard drives to keyboards and printers - can you find any of them being gold-plated and costing upward of $40? All those cables are digital yet very inexpensive while moving your files and other data without any distortions.

So if one pays more than $0.40 per foot of ANY digital cable: Ethernet, DVI, HDMI - the person is a certifiable sucker and people who sold it to him/her are shameless snake oil peddlers. Go to eBay or www.AllElectronics.com and buy the cheapest cable you can find and you will be just fine.

You can bring up as many anecdotal evidence as you want about how generic cable sucked, and then monster cable made your TV picture crystal clear, but the fact remains: bits either go through or not regardless where they travel: on commodity Ethernet cable, or on the most exclusive and expensive HDMI cable. If you don't get TV picture all distorted like satellite TV signal during heavy rain, your cheap HDMI cable works perfectly fine and your TV picture CANNOT possibly be made any better by expensive "monster" cables.

I can't wait to see what will happen when all consumer electronic components will start receiving digital A/V feeds over the air using wireless connections. I think all the high-end cable manufacturers need to start diversifying now and get busy with creating gold-plated wireless antennas costing $200 and up.