Vlad Hrybok's Tech Notes

Think what would happen if Microsoft was giving away Windows for free to everyone, and would also be giving away Visual Studio to developers, but taking %% of every sale of every program ever made for MS Windows. Think of how much more money would they would have made? Could Bill Gates have become  a first trillionaire?

First of all, no worries, I am not a nut who writes another OS. Creating a new operating system is WAY too complicated, costly and most importantly financially risky: OSes are commodity - it's impossible to change the world by creating another OS now.  Instead, I am creating a new platform. What is platform? To give a definition, platform is an operating environment for programs, and a user interface conduit for users. To give a few examples: Internet is platform: back-end web server is an operating environment for programs and browser is a conduit for the UI; every operating system is a platform: Windows, Linux, MacOS – their APIs and drivers form an operating environment and OS desktop and windows is a UI conduit; web browser is a platform too, albeit a limited one – it can run client scripts and therefore it’s an operating environment and a UI conduit at the same time. You get the idea…

Platforms differ in reach and complexity. Operating systems make a somewhat mediocre platform: they have limited reach – contained by the hardware they designed for, by how incredibly expensive it is to make an OS, and by how hard it's to learn to develop applications for a new OS. Adoption threshold for a new OS is very high. Web, on the other hand, is a very good platform: HTTP protocol is insanely simple, web development is relative simple and mastered by ever-growing legions of developers, web is not constrained by hardware, and finally web has a virtually unlimited reach. Curiously, web as a platform is built on top of other platforms - underlying disparate OSes running web server back-end software and user browsers. it’s a platform layered on top of other platforms – OSes.

The drawbacks of the Web as a platform include:

1. Deploying and operating web apps is complex and costly. It is very hard to make an application accessible on the web: all the routers, firewalls, networking, DNS servers, domain names leases, IP addresses -  everything involved in deployment of a web application is much more complex from user’s standpoint compared to regular program with a "pop-in a CD and have it installed" type of deployment;
   
   
2. Web applications are hard to market. From developers’ perspective business models for selling web app is limited to big-ticket sales to businesses who have budget and skills necessary to run web-facing infrastructure.

Now, imagine World Wide Web with above-mentioned problems removed. That is what I am doing: a new web-based platform that has user reach as wide as current Internet, but removes application deployment and marketing hurdles that are limiting web application usage right now. That’s a unique innovation right there. “But hey, there’s more!” Another unique innovation is the business model: I am not going to sell this platform to users, or development tools to developers. All will get it for free. The catch? All software that uses our platform can only be sold and bought using channels belonging and controlled by UltiDev, and like eBay we are going to take %% of every application sale.

You may have some concerns, like will developers find this new platform attractive enough to spend effort learning it and making programs for it? The answer is no, they won’t. Because they won’t need to. The beauty of it is that application developers can take their existing skills and even their already-built applications and simply package them together with our new platform components and ship it to users. Every member of millions-strong army of web developers worldwide is ready to take advantage of this new platform.

You may also wonder how complex is this new platform? Will it take billions of dollars an decades to create it? Well, it’s complex enough to take two years to develop, but the good news is that it’s virtually finished and working pre-alpha releases are deployed. 

Small detail: the platform described above is called HttpVPN™ and some additional technical information is available at http://ultidev.com/Products/httpVPN/.

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.