Playing with Firefox 3 Beta 4

I've pretty much standardized on Firefox as my default browser (but not the default Windows browser).  I had been an Opera bigot for years, but the tipping point was when Google released their browser sync addin that made it easy to keep my bookmarks and other settigns in sync between work and home.

I've been hearing good things about the latest beta (beta 4) of Firefox 3, so I have decided to give it a shot.  I found a good article for running Firefox 3 in tandem with Firefox 2 on the Hack-A-Day site, so it seemed safe to run them together.  My first impression is that it's fast, much faster than Firefox 2 and probably faster than Opera.  Faster is good, I look for things to make me go and this is one of them.

Our Google Overlords have not updated the Google Browser Sync addin to work with Firefox 3.  There have been quite a few requests for Firefox 3 support, I'm surprised that company known for keeping products in beta for years isn't supporting the Firefox 3 beta.

I decided to take a look to see if anyone else had a browse sync that supported Firefox 3.  As it turns out, Foxmarks has a beta that supports the Firefox 3 beta.  I installed into my Firefox 2 and Firefox 3 installations and synced my Firefox 2 bookmarks up to the Foxmarks server.  I then tried to sync up from Firefox 3 and it repeatedly crashed.

I assumed that it was a fault of the Foxmarks plugin, so I took a look around their site.  On their wiki, I read the following:

On initial sync (or regular sync of large change sets), Firefox sometimes crashes. (We believe this is a Firefox bug; if you experience this, please make sure you allow Firefox to submit a crash report to Mozilla.) [This is an open bug in Firefox being investigated by Mozilla.]

It indicates that it's a Firefox bug and I have a work around.  Since Firefox 3 is puking on large change sets, the solution is to reduce the size of the change set.  I synced up Firefox 2 and then exported the bookmarks to a file.  I then imported that file into Firefox 3 and it was able to sync up changes after that.

Another addin that I like is GMail Manager, and it too doesn't support Firefox 3.

When will the Visual Studio IDE catchup to the Delphi IDE?

Sometimes it just the little things that annoy you.  If I add a button to a Delphi form, by default it is named Button1.  If I double click on Button1, a Click event handler is added and is named Button1Click and wires it up to the button's OnClick event.  Visual Studio does pretty much the same thing.  Where they is differ is when you edit the button's name.

If I renamed Button1 to something more meaningful like DestroyAllMonsters, the Delphi IDE will rename the event handler to DestroyAllMonstersClick.  When you rename the button in the Visual Studio IDE, it doesn't touch the event handler.  That's annoying.

Another difference is how Delphi handles event handlers when your delete the code or never add the code.  When you double click on the button and get the new event handler automagically created and wired up to the control, that event handler has no code.  If you save that file, Delphi removes the event handler.  it does under the assumption that you didn't mean to have that event handler and it will clean up the code for you.  Like wise, if you delete the code out of the handler and save the file, Delphi will remove the handler. 

This makes it easy to cleanup code when you remove a control that you didn't really want or need any more.  Visual Studio doesn't do that for you, or least not in C#.  When you spend your day working in both IDE's at the same time, those types of annoyances really can be annoying.

Miss Bimbo is not welcome in my house

There have been a few articles posted on the Internet about a web site called www.missbimbo.com.  It's supposed to be fashion game for young girls, but it sounds pretty trashy.  It's aimed at girls between the ages of 9 to 16 and it purports to be a virtual fashion games.  It's widely condemned as the users are encouraged to compete against each other to become the "hottest, coolest, most famous bimbo in the whole world." by buy chest implants.  CNN had a good write up of it and here's a direct quote:

The provocatively named "Miss Bimbo" Web site launched in the UK last month and is described as a "virtual fashion game for girls."

Girls are encouraged to compete against each other to become the "hottest, coolest, most famous bimbo in the whole world."

When a girl signs up, they are given a naked virtual character to look after and pitted against other girls to earn "bimbo" dollars so they can dress her in sexy outfits and take her clubbing.

They are told "stop at nothing," even "meds or plastic surgery," to ensure their dolls win.

Users are given missions, including securing plastic surgery at the game's clinic to give their dolls bigger breasts, and they have to keep her at her target weight with diet pills, which cost 100 bimbo dollars.

Breast implants sell at 11,500 bimbo dollars and net the buyer 2,000 bimbo attitudes, making her more popular on the site.

And bagging a billionaire boyfriend is the most desirable way to earn the all important "mula" or bimbo dollars.

As the father of two girls aged 7 and 5, I'm appalled by the site and I'm not going to let them anywhere near it.  We have a family PC that girls can use and we do let them visit certain sites on the Internet.  I've already taken steps to prevent them from seeing that site in our household.  I've been a fan of OpenDNS.org for a couple of years for their speedy DNS lookups.  OpenDNS has the ability to do some basic filtering and it's trivial to get it to block entire domains.  I just logged into my OpenDNS account and added missbimbo.com as a blocked domain. 

If you have never heard of OpenDNS, it's a free service that does speedy DNS lookups.  When you type in www.cnn.com into your web browser, a DNS server takes that domain name and converts it to the actual IP address of the site so that it can loaded into your browser.  Your Internet provider usually provides their own DNS servers, but OpenDNS has faster ones.

I'm probably overreacting and my girls will never even hear of that site, but it doesn't hurt to be safe.

Enabling users with ESX 3.5.0

I've been playing admin on our shiny new ESX server and it's been a struggle trying to get the user accounts configured.  I wanted to give our QA staff enough rights to login through the VMware Web Access portal so that they could start and stop their virtual machines.  I figured I would just set up their accounts and put them in the "Virtual Machine User" role.  No of the accounts could login in.  They kept getting the dreaded "Login failed due to a bad username or password."

I dug around a bit and started searching the VMware forums.  Apparently everyone was using AD to authenticate their user accounts.  I wasn't planning using AD because we are going to be changing domains in the near future, but I figured nothing else was working, it couldn't hurt.  This message led me to a very useful post by Geert Baeke on how to integrate Active Directory with ESX 3.   There was a lot of useful stuff in that post, but the part that I needed came down to this:

esxcfg-auth --enablead --addomain=domain.com --addc=domain.com

The VMware document uses the FQDN of a domain controller for the --addc parameter, but you can use the FQDN of the domain. That way, DNS is used to find domain controllers and use one of those. The command above modifies a few files like /etc/krb5.conf and also the system-auth file in /etc/pam.d. The ESX firewall is also automatically configured to open the needed ports for AD authentication.

Before you can logon with an AD account, you need to create a console user on the ESX box that has the same name as your AD account. For example, if you have an AD account domain\esxadmin, you need to add a user to the ESX console called esxadmin. The command to use is useradd esxadmin. You can also use VI Client to create the user. You can now logon with the account and use the AD password. I tested this with ESX 3.0.1 servers against Windows 2000 and Windows 2003 domains and it worked as advertised.

I did it and it worked like a charm.  Life is good.

Link rot and the ascendance of Wikipedia

As usual, Steve Tibbets hits the nail directly on the head with his post about link rot and Wikipedia.  I would have to say that the domain that I link to the most would have to be Wikipedia.  Most of the time I dot it because it's convenient, but link rot (there!  I just did it) happens a lot. 

Microsoft is pretty bad at this.  There have been too many times where I tried to follow a link into the MSDN, only to find that the MSDN has been reorganized and all of the links have changed.

If I link to another blog, I look for the permalink.  That usually indicates that the link will be around for a while.  I also try to find links on multiple domains.  That way, the odds are less likely that you will get the dreaded 404 page when you follow a link that has rotted away.

Steve posting his rules for linking and they just make sense:

• If what I’m linking to has a top-level domain, then I will link to it.
• If I’m linking to someone’s words (say, a blog post or magazine article), then I will link to that.
• Otherwise, I’m linking to Wikipedia.

Two of my favorite geek toys (PowerShell and VMWare) playing together

I can't wait to get the VI Toolkit for Windows.  It's PowerShell cmdlets that let you manage VMWare.  To get an idea of what you can do with PowerShell and ESX Server, check out the Automating VMware with PowerShell Lab Manual, from the VMworld Europe 2008 conference.  You will be able monitor the status of VM's on the ESX server and be able to control the VM's remotely.  I'm curious to see of you would be able to take a running VM offline and move it to a storage volume.  That would make my life easier.

The VI PowerShell Blog mentioned that the VI Toolkit will be Beta this month, I can't wait to get a hold of it.

The Lost Art of TSR Programming

Scott Allen had a amusing post, "Talks You Won’t See At the Local Code Camp", on his blog.  One of the talks was "The Lost Art of TSR Programming".   That shook some memories out of the cranial storage device.  I used to write TSR programs, more formerly known as Terminate and Stay Resident.

This takes back to the days of DOS, when giants like dBase and Lotus walked the land.  Your network was Novell and you feared the Bindery.  You could only run one program at a time and the 640K limitation was real and not just a saying commonly misattributed to Bill Gates.

When I was at Stochos, we wrote software to do statistical process control (SPC) in the manufacturing industry.  We would collect data from measurement devices or from the manufacturing hardware to monitor the process of making whatever was running.  Back in the late '80s, we had hardened PC's running DOS and our software right on the factory floor.  One of my tasks was to write the code to collect the data from the machines and get it into the PC.

Early on, I had decided that the data collection code would run separately from the SPC application.  This allowed the user to exit our app to run other apps while still collecting data.  The way I did that was to write the data collector as a TSR.

The whole TSR section of DOS programming was pretty much an accident.  The DOS print spooler gave DOS the ability to print in the background while your application was running.  The print spooler was the first TSR.  A TSR would load itself using INT 27H to make itself as a TSR type of programming.  Once loaded, the TSR would typically insert itself into the chain of the applications that would receive hardware and/or software events.  If the TSR wasn't careful, it could wreck havoc with the interrupt chain.

I would write TSR's that would hook into the serial port or parallel port events.   Some of the time, all I needed to do was to capture data as it came in and write it to a file.  Usually, the hardware would have some sort of protocol and I would have implement it in my code.  One of the odder ones was for a machine that printed foil packets, the kind used for condiments at fast food restaurants.  This machine did not support the logging of it's data.  But I found a way in.  It had a PC that functioned as operator console with a color screen and keyboard.  Usually the screen would be displaying the current process settings and readings from it's own measuring devices, but not always.  The PC was connected to the machine over the serial port and was basically being used as a terminal.

I wrote a TSR that would periodically scan the screen in memory.  Since it was running in text mode, it's fairly easy to ready the screen from memory.  If I saw a certain sequence of characters at a specific location, I knew that I had the main console screen.  I then scanned different locations on the screen and wrote out a text file, logging each set of values as an attribute for our SPC application.

The TSR would read a template file that listed what attributes to look for and at what locations on the screen to expect the attributes at.  The setup of the template was done by trial and error, but once it was set the client never had to touch it.  It even allowed for character translation.  For some odd reason, the console display didn't use the number "0", they used the letter "O".  That took more time to track down then you would have expected.

To keep the size of the TSR down, I used a library named CodeRunner with Microsoft C.  The Coderunner library had the housekeeping code for doing the INT 27h stuff and interrupt managing.  It also took many of the standard routines and replaced them with hard coded assembler optimized for space over performance.  It also had the ability to run most of the TSR out of EMS memory, greatly reducing the footprint in the lower 640K space.  This particuliar TSR took about 6000 bytes of conventional memory.  I remember talking to Ratko Tomic, the engineer who wrote the CodeRunner libraries.  He was genius at squeezing every extra byte of the TSR code.  It's a lost art.

I like having a build box

This morning I came across a blog by Landon Dyer called Dadhacker.  He got linked by BoingBoing for a entertaining post that he wrote about working on the Donkey Kong cartridge for Atari.  I started reading his other posts and it turns out that I agree with nearly all of his opinions.  Except for build boxes. He wrote:

The best thing you can do for your productivity when you’re tempted to set up that spare machine to do extra work for you is to ditch the thing.

If you are the person only using that build machine, I can see that point.  Almost.  I would argue that it's worth the time to have a 2nd machine in case the first one goes to the land whre DOS is eternally blessed.  For a team of programmers, having a dedicated build box is a must have feature.  No more guessing which program set which option to build which executable, they always get built the same way.  Plus it offloads the build process processing from your development environment and that is always a good thing.

The other advantage to having a dedicated build box is that you have have it do everything.  We use FinalBuilder and it's the kitchen sink of automated build tools.  We build about a half dozen or so shrink wrap ready applications on our build box and they all pretty much follow the same pattern:

1. Get the latest code from source control
2. Read an .ini to get the version number and other test resources, the build tool will bake the version number into the compiler and install builder.
3. Compile the application
4. Collect all of the bits and put them in a folder for the install builder
5. Authenticode anything remotely executable that we compiled
6. Create the installer from all bits that were compiled in the last step and add the necessary required bits (CaptiveX controls, Assemblies, help files, etc).
7. Copy the installer to a deployment folder for QA to test
8. Send an email to QA and other interested parties that a new build was available and include a change list in the email.

There are other minor tasks that get performed, but that's the gist of it.  And it works for for Delphi Win32 and .NET assemblies, with error handling.  The time our department saves that level of build automation clearly outweighs the the maintenance time on the build box.

Fun with changing the IP address of ESX Server 3.5

We (our IT manager and myself) have been having some fun with out shiny new VMWare ESX 3.5 server.  We have had it running for about two weeks now and we decided to change it's IP address.  The ESX server was on the same subnet as our LAN.  This meant that it the virtual machines were taking IP addresses out of a pool that was needed for our physical computers.  There were some other security issues, so we decided to put it on it's own subnet.

It was fairly easy to change the IP address address via the command line (this site helped a lot), the fun started with the NFS connection.  We are using NFS to mount a folder located on a Windows file server to add some offline storage for the ESX box.  To mount with NFS, you have to create a VMKernel in the ESX networking and the VMKernel gets it's own IP address.  That IP address must be on the same subnet as the NFS server.

When we moved the ESX to it's own subnet, we put it on it's own physical network and that broke the NFS connection.  We tried a few things and then we checked the Windows box that was running the NFS server.  It had two network cards.  The second one was not enabled, but fully functional.  We enabled it and set it's IP address to the subnet of the ESX box.  I had to drop and recreate the NFS mount, but it all worked.

While testing the networking, the IT manager was running one of the virtual machines (XP 64-bit) and set the network adapter in the VM to a static IP address.   It turned out he set it to the IP address of the ESX server.  That's when the fun started.  When you connected to the VM, ESX would lose it's connection and you lost control over ESX and the VM.  After a minute or two, you could access ESX through the VMWare Infrastructure Client, but you couldn't access the VM to change it's IP address.

We racked our brains trying to figure out how to get control of the VM to reset it's IP address.  The fix turned out to be really simple.  I powered down the VM from VIC and edited it's hardware settings.  I added a second network adapter (it's all virtual) and set the first one to be disconnected.  I powered the VM back up and the new adapter had a safe IP address.  I connected to the VM's console and opened up "Network Connections" in Windows.  The first adapter was enabled, but not connected.  I opened up it's properties and set it to grab an IP through DHCP.

I powered down the VM, removed the second adapter, and reconnected the first one.  I rebooted the VM and it had a new IP address.  Peace and harmony reigned through my virtual kingdom.

Just when I thought my SmugMug plugin was finished...

After tackling the Wix learning curve, I have an installer for my SmugMug plugin does usual things: check for .NET 2.0, install the files, add the registry key to register the plugin, and support upgrading in place.  One step closer to releasing this plugin for Windows Live Writer.

Meanwhile, over at SmugMug, a security issue of sorts popped up.  Don MacAskill, the CEO of SmugMug, blogged about it with great detail and openness and I'm not going into it here.  At any rate, in response to what was perceived to be a security, SmugMug is implementing some changes to their API.  The changes were fairly trivial to implement so it made sense to augment my plugin's code to be compliant with the updated API.

With their recent changes, I saw that my plugin was no longer displaying images for one of my test galleries, where it had worked before.  I spent a hour or so trying to track it down in my code, when the clue light finally flickered above my head.  I logged into my SmugMug account and examined the properties of that gallery. 

Sure enough, for that gallery, the "allow external links" option was set to "No".  This meant that even though my plugin would return valid URL's for the images in that gallery, SmugMug would send back a blank page for those URL's.  I augmented my call to get the gallery list to check the properties for each gallery and filter out the ones that did not allow external linking.

I thought that there would be performance hit for making a web service call for each gallery.  It wasn't really noticeable at all.  That's what I love about SmugMug, their API performance is damn fast.

At any rate, I was hoping to finally push this plugin out the door by now, but I'm going to take a few more days and beat on the code.

I hate spam that comes in under my own name

For the last few weeks, I've been getting spam email addressed to my work account with the "from:" field set to my work address.  That allows it past our companies spam filters.  The subject line is usually something liken "January 79% OFF" and the message body contains a few images, some oddly worded links, and some boiler plate text about receiving this mailing because I am "subscribed to MSN Featured Offers".

The images are blocked by our central spam filter, which means they are being hosted on a known site for spamming.  I haven't verified that with our IT manager, but it's a safe assumption. 

I'm going to block this message at my email client (Outlook 2007), but first I'm going to send a message to the ISP that is hosting the machine that sent the email.  The first thing to do is to see where the images and links are pointing to.  With Outlook, if you right click in the body of the message and select "View Source", Outlook will create a file named email.txt and launches it with the app registered to handle text files.  That's usually notepad, but YMMV.

For this message, I saw something that looked very much like the spam that was reported to the new.admin.net-abuse.sightings newsgroup in this post.

Most of the links were junk, but there was a link to "s y l l a b l e h e a v y . c o m" (I added spaces to prevent it from being a live link and inflating it's Google ranking).

A quick search in the Internic registry brings up the following results:

   Domain Name: SYLLABLEHEAVY.COM
   Registrar: XIN NET TECHNOLOGY CORPORATION
   Whois Server: whois.paycenter.com.cn
   Referral URL: http://www.xinnet.com
   Name Server: NS.XINNETDNS.COM
   Name Server: NS.XINNET.CN
   Name Server: NS2.XINNETDNS.COM
   Name Server: NS2.XINNET.CN
   Status: ok
   Updated Date: 19-feb-2008
   Creation Date: 16-jan-2008
   Expiration Date: 16-jan-2009

That tells us a couple of things.  One, the website is registered by a Chinese registrar.  Two, it was created about a month ago.  The next step is to track down the Registrar, Xin Net.  A quick search on Xin Net, gives us some more information:

Registrar Name: XIN NET TECHNOLOGY CORPORATION
   Address: 1st Floor,2nd Building Section A,BDA BeiGongD, Beijing, China 100176, CN
   Phone Number: 86.1058022118
   Email: domainadmin@xinnet.com
   Whois Server: whois.paycenter.com.cn
   Referral URL: www.xinnet.com
   Admin Contact: cody zhou
   Phone Number: +86.10.58.22266-551
   Email: tech@xinnet.com
   Admin Contact: xiaorui wang
   Phone Number: +86.1058022118-205
   Email: admin2@xinnet.com
   Admin Contact: Baosheng Jiang
   Phone Number: +86.1058022118-623
   Email: admin1@xinnet.com

 

This gives a whole bunch of email addresses to complain to.  What I did was to send a polite message to all of the addresses listed above.  I sent the following:

Hello,

Please excuse this unsolicited message, but I have been receiving numerous spam emails and they link to a site, syllableheavy.com, that you are listed as the registrar of.   This site probably violates your terms of service and I am sure that you do not want to be associated with it.    The message did not originate from that site, but it is using that site.

I then included the message header and the message source.  I doubt that they will do anything, but if they do take action, it takes a spam site offline.

The next thing to do is block additional messages like that. 

• From the Outlook menu, I selected "Tools->Rules and Alerts" to create a new junk mail filter. 


• In the "Rules and Alerts" dialog, I clicked "New Rule...". 


• Under "Start from a blank rule", I selected "Check messages when they arrive", and then clicked the "Next" button.


• Under "Which condition(s) do you want to check?", I selected "with specific words in the sender's address"


• For the "with specific words in the sender's address", I entered my address.  I rarely send myself email from my work account.  When I do, Exchange just uses my first and last name, not the SMTP address.  Then I clicked "Next"


• Under "What do you want to do with this message", I selected "move it to the specified folder" and "mark it as read".  I selected "Junk E-mail" as the selected folder.  I then clicked the "Next" button.


• I clicked the "Next" again to skip over the exceptions to this rule.


• I gave it a name and set the checkboxes to run it on messages already in the inbox and to enable the rule and clicked finish.


• Clicked "Apply" and then"OK" and we are done.

That will permanently take that style of junk mail out of my in box.  I didn't permanently delete the message.  About once a week, I take a quick peek in the junk e-mail folder just in case a false positive hit grabs a legitimate email.

Nvidia nForce network driver problem under Vista

On my home machine, I rarely reboot it. If a software update requires a reboot, then I do it. otherwise it stays running for weeks at a time. Vista (32-bit) has been stable enough for me, where I don't have to start the system or suffer system crashes.

But when I reboot, about 10% of the time (just a wildly inaccurate guess), the machine comes up without any network connectivity. In the past, I have associated it with Windows Update installing a wonky driver for the network card and I System Restore the machine back to normal. It happened today and the list of the usual suspects did not include any hardware updates. Time to dig deeper.

This machine has a NVidia nForce motherboard (Asus M2N-SLI Deluxe) and it has built-in dual Gigabit LAN controllers. I had an Ethernet cable hooked up to the first port and had disabled the 2nd one through Vista's "Network Connections" utility. My dead Windows Home Server box was next to my PC, so I unplugged it's Ethernet cable and plugged it into the second port on my machine. I enabled the network adapter and after a few seconds, it was live and had grabbed a IP address from router.

That was interesting. Since the working adapter used the same driver as the non-working one, that pretty much ruled out Windows Update nuking one of the drivers. I peeked at the driver settings for both adapter, they were both set to the defaults. I also checked the device status of the adapter, Windows reported that "This device is working properly." That was a pretty good indicator that the problem was not a fried controller on the motherboard.

The next thing to check was the ethernet cable. I swapped cables and there was no change. I decided to do the Nintendo fix. That's when you pull out the cartridge, blow on the connectors and ram it back in again. In this case, I disabled the adapter, waited 30 seconds, and re-enabled it. As Emeril says, Bam! The adapter started working. Time to start googleing and see if anyone else is having this problem.

And the number one hit for "nforce network adapter fails" in Google was a long thread in the Nvidia message forums. A sizeable number of people were having the same problem and they were all running Vista. It may be a timing issue during boot-up. Two workarounds were suggested. One was to change the duplex setting from "Full Autonegotiation" to "100 Mbps Full Duplex". The other was to change the priority order of the network adapter priority. I didn't want to mess with the driver settings, so I opted for changing the priority order. I'm not confident that it will fix the issue, but it wont hurt anything. Right now this is more of an annoyance than anything else, but I would like to resolve it permanently.

Tech Tags: nvidia nforce vista network driver

Using Wix for my Live Writer Plug-in

I finally have version 1 of my Smugmug gallery plug-in completed. The next step is to do the installer. To get a plug-in up on the Windows Live Gallery, it must have an installer that meets the requirements on the Gallery Developer Center page. A content plug-in has to meet these requirements:

1. Content Plugins must be built using either the .NET 1.1 or .NET 2.0 frameworks.
2. Content Plugins must be packaged and submitted as a Microsoft Installer (*.msi).
3. If you use the .NET 2.0 framework, the installer must link to the .NET 2.0 download site or use the Visual Studio 2005 Bootstrapper. The Bootstrapper detects and downloads the correct .NET 2.0 framework.
4. Your installer must copy the assembly to the "Plug -ins" sub-directory of the Windows Live Writer installation directory.
   

I have #1, my plug-in uses the .NET 2.0 framework. Number 2 is that it must be packaged using a Windows Installer .msi setup. I'm still figuring out the best way how to implement #3, but I'm not sweating it. With #4, I'm not doing it that way. The alternative method is to install the plug-in in your own folder and write a registry key to Software\Windows Live Writer\PluginAssemblies (HKLM or HKCU) with the name of your plugin and the path to it. That way you don't have to worry about where Live Writer was installed to. In fact that page is probably obsolete, there is an MSDN article that covers the registry method.

Let's start with the .msi requirement.

I looked that the "Setup Project" template in VS 2008. Um, no thanks. After 30 minutes of playing with it, I started getting annoyed. It felt awkward and non-intuitive. Granted, most things with Windows Installer are awkward and non-intuitive, but I couldn't get fast handle on "Setup Project" template. It was easy enough to get the files installed, but getting the registry written correctly was a task I just couldn't figure out. After two years of doing .msi with Wise For Windows and now InstallAware, I have a pretty good idea of an .msi is supposed to work.

I decided to knock out an setup with InstallAware. It took about 5 minutes and worked perfectly. But it was 1.2 MB in size. That seemed excessive to deploy 45K for two assemblies. Frankly any installer will be excessive, but I have to follow requirement #2. I have lots of love for InstallAware and it's my tool of choice for application installs, but it still bothers me to have a setup that 26 times larger than the files being deployed.

With VS's "Setup Project" and InstallAware out of the picture, I decided to check out WiX. WiX stands for WIndows Installer XML and is an open source toolkit for building .msi setups from an XML source file. The current version, 3, installs nicely into VS 2008. It installed so nicely, I didn't need to be concerned with how to run the Candle (the WiX compiler) or Light (the WiX linker). There is also a .msi decompiler, named Dark. It will emit Wix source code from a .MSI or .MSM file.

WiX source code is pretty intimidating when you first look at it. if you have no experience with authoring Windows Installer, it will be hard to grasp at first. The WiX site has a nice tutorial, but it's for version 2 and uses syntax that's deprecated in version 3. Fortunately, I was able to google the differences and I was able to get a working installer in about an hour. It's not handling step 3 completely, but it is terminating the install if .NET 2.0 is not available.

The size of the .msi is much smaller, about 220k. Still way too large, but it's as about as small as I'm going to get for a .msi file. So far, I'm very impressed with WiX. Once you start getting the hang of the syntax, it's very clear on how to setup a proper .msi file. There's even a open source editor called WixEdit. I didn't need it for this task, but I think I make take at peek at it at another timer.

Enough people are using it so that I was able to google for the bits I needed. Morten Lyhr had a great post on how to detect the .NET Framework. I figured out how to write the registry key from a post by Chris Jackson. Bonnie (one of the Live Writer developers) had a good sample WiX file for installing a plug-in. While I didn't follow her pattern, it did give me a tour of the neighborhood. Mike Stall has a good post that covers the basics. I think I need to spend some time reading the blogs of the WiX developers, they have a build a really cool tool.

Tech Tags: Windows+Live+Writer plugin installer msi Wix

When the clipboard doesn't work across Remote Desktop

Every now and then, when I have a remote desktop connection open, the clipboard fails to copy across the sessions.  It's usually the remote to local copy that's borked.  It's pretty easy to fix, but I can never remember what I need to do to fix the connection.

Fortunately the Terminal Services Team Blog has got that covered.  Just kill and restart the rdpclip process in the remote session.   There was also a part two to that post that was pretty interesting.

[Edited on 1/30/08]
There is a command line way of resetting rdpclip, so you can roll up both steps as a batch file

taskkill /IM rdpclip.exe
rdpclip.exe

Tech Tags: Terminal+Services Remote+Desktop rdp clipboard rdpclip

Copying files with VS 2008's port-build event under Vista

I'm still working on my SmugMug plugin for Windows Live Writer. I've ported it from VS 2005 to VS 2008, that was trivial. I'm at the point where I want to debug the plugin while it's being loaded from Live Writer. Normally, this is pretty straight forward. You use the post-build event to copy the plugin's files to the Live Writer plugin folder. For my plugin, I used the following build event:

xcopy /D /R /Y "$(TargetDir)s*.dll" "C:\Program Files\Windows Live\Writer\Plugins"

The next step is to go into the Debug settings for the project and set the Start Action to Start external program, setting it to the path to the Live writer executable. On my machine, that would be:

C:\Program Files\Windows Live\Writer\WindowsLiveWriter.exe

With that set, all I need to do is to press F5 and my plugin gets built, copied to the Live Writer plugin folder, then Live Writer gets launched. Sounds good, but when I did a test build to verify the files would get copied, I got the following error message:

"XCOPY /D /Y /R "C:\dev\DotNet\LiveWriter\SmugMug4WindowsLiveWiter\SmugMug4WLW\bin\Debug\s*.dll" "C:\Program Files\Windows Live\Writer\Plugins\"
" exited with code 4. SmugMug4WLWPlugin

Code 4? I had to get Mr Peabody to look that one up for me. DOS 3.2 ring a bell? At any rate, exit code 4 for xcopy is "Initialization error (not enough memory, invalid syntax, path not found)". That actually was a clue to what the problem was, I was just missing the obvious. I tried pasting that xcopy command into a Take Command shell window and it ran without errors. So the syntax was correct, something was blocking it.

D'oh! I'm doing this under Vista. Joe User can't just copy files into "program files" space, that's no longer allowed. Only administrators have write access to "program files" and I'm running VS2008 without elevation. I run my Take Command shell as admin, so of course it can write to the plugins folder.

To get around this, I decided to punch a hole through Vista's default rights for that folder and give everyone and their dog full access to it. I tried doing it through icacl, but I wasn't getting the syntax right. So I just opened up explorer, selected the plugins folder, right-clicked and selected "Properties". I then selected the "Security" tab and then selected Users under "Group or user name". Next, I clicked the edit button, to bring up the edit dialog for the access rights. I selected "Full Control" and then clicked "Ok" all the way home.

That fixed it. VS2008 was able xcopy my plugin without any errors.

Tech Tags: vs2008 post+build+event Code+4 xcopy Vista icacls

What do you mean my router has a UPnP security hole?

It's been recently made public that just about every consumer router is a security hole wide open and it's called UPnP.  That stands for Universal Plug and Play and it's a set pf protocols that allow netwrok devices to configure themselves on a network without requiring much, if any, human intervention.

The problem is that UPnP does not require any authentication and it is possible to create an Adobe Flash applet that will do nasty things to your router.  Like change the router's DNS settings so that when you visit your bank's website, you get sent to a phishing site that will take your login and password.  Or port forward to an external server, allowing your router to be used to attack other sites.  Or expose computers behind the router's firewall.

Since so many web sites use Flash to display ads, you would never see it coming.  Once you visited that page, the code would and your router is no longer solely under your comtrol.

Since many routers enable UPnP out of the box, you'll want to disable UPnP on the router.  It's usually an easy task, but you may need your router's manual to figure how to change your settings.

If you are using Windows Home Server, when you first configured it, it prompted you to allow it to turn on UPnP.  If you did that, go in and turn it off.  Right now.

How (and why) to increase the Windows Desktop heap size

Jon Galloway had a posting about issues that he came across when he opened too many tabs in IE7.  Apparently the Desktop ran out of heap space and Bad Things happened.  Jeff Atwood came across the same problem.  I remember reading Jeff's post back in October, but I didn't associate it with a problem that I was having.   

I was finding my self rebooting my XP dev box a couple of times a day.  The desktop was basically losing control and I couldn't do anything with the task bar or Start Menu.  Part of the problem was due to wonky display drivers from Nvidia.  I updated the drivers and the problem went mostly away.   But not completely.  I have a dual monitor setup, and I have a tendency to keep lots of things open on a desktop that spans both displays.

The longer I used Firefox, the less stable the system became.  I just became used to restarting Firefox.  One of the nicer things with Firefox is that you can restart it and come back to the same tabs loaded with the same pages.  BTW, Jed Brown's Restart Firefox Add-on is very helpful when you want to bounce FireFox and still have the same 12 tabs open.

At any rate, I was seeing the same symptoms that Jon reported.  There is a registry setting that you can edit that will allow you to specify the heap size reserved for the Desktop.  The default size is 3MB, everybody seems to agree that 8MB is the way to go.  The 3MB number was set for NT 3.51, back when we had a lot less memory in out machines.  This is only applicable for 32-bit versions of Windows, the 64-bit version do not have these memory limitations.

Kevin Dente documented how to bump this value.  To change this setting, you'll need to edit the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems and edit the "Windows" value.  This value is (as Kevin put it) a "big honkin' string" and you only want to edit one portion of it.  Look for the part that starts with "SharedSection".  It will have three numbers, the middle one will probably be 3072.  Change that to 8192.  On my machine, that part changed from "SharedSection=1024,3072,512" to SharedSection=1024,8192,512.  The YMMV rule is especially applicable here.  Remember to reboot after making this change.

The first number is the shared heap size common to all desktops.  The global handle table comes out of the shared heap.  The second and third numbers in SharedSection represent the size of interactive and non-interactive desktop heaps (services that interact with the desktop).  If terminal services are enabled, there may be a fourth number.  You only want to change the second number.

Tech Tags: SharedSection XP Memory Desktop Heap

What's the deal with this .rbf file?

I was updating the installer to one of our applications and every time I ran it, it wanted to reboot at the end of the install.  This installer was installing a web application with some utility apps, nothing that should have forced a reboot.  I was running the installer inside a VMWare virtual machine of Windows 2003.

I've been using InstallAware for the last 3 months to author our installations.  It was being signaled by Windows Installer that it needed to do a reboot to complete the installation.  The question was why?  After a bit of digging in the help file, I found that I could use the "/l=filename" command line parameter to have the installer write to a log file.

I ran the installer one more time and copied the log file down to my dev machine to take a look at it.  It had roughly 9400 lines of Windows Installer chattering.  I started scrolling from the end of the file until I came to the line:

Info 1903. Scheduling reboot operation: Deleting file C:\Config.Msi\3e1b7.rbf. Must reboot to complete operation.

What the frack is an RBF file?  After some googling, I learned that a file with the .rbf extension is a backup of an existing file.  I scrolled up some more and found a bunch of message like this:

Info 1603. The file C:\WINDOWS\system32\msvcr71.dll is being held in use by the following process: Name: VMwareService, Id: 1804, Window Title: '(not determined yet)'.  Close that application and retry.

The "Close that application and retry" tag means that installer would normally prompt the user to close the application that had the file in use.  If the process does not have a window title associated with it, then that prompt would be suppressed.  In my case, the processes were services and did not have window titles.  I found that documented in a few places, this post on the Windows Installer Team Blog being the most useful of them.

A few of the VMWare processes were also using msvcr71.dll and the file was in use.  OK, fine, but it was the same file.  Same bat-version, same bat-time.  Windows Installer should have had enough brains to determine that new file was the same file as current file and just skipped that step.  I don't think I ever had that problem with Wise for Windows (WFW had enough problems, but that's another story).  My guess is that it's an InstallAware issue, but I'm in the process of confirming that.

I did have a work around.  With the Install File MsiCode command, the dialog box for the command's properties has a check box labeled "Never Overwrite - do not install if another copy exists".  For msvcr71.dll, our code works pretty much each version that we have seen so far.  Setting that check box eliminated that reboot after every install.

Technorati Tags: rbf,InstallAware,Windows+Installer,reboot,msvcr71.dll

NPR broke the podcasting machinery

I like listening to podcasts on my Zen Vision:M player.  The Zen comes with a decent enough podcast tool called Zencast.  Zencast has an option to convert audio podcasts to video format.  They take the description of the podcast and display it as text in the podcast.  This makes it handy to see what is on a podcast by playing it for a few seconds.  The other advantage is that it categorizes them separately from the music, making it easier to drill down and locate the file to play.

Sometime in December, NPR made a change to their servers and is preventing the Zencast application from downloading any podcasts from NPR.  You get the message: "Unable to download due to a connection error."  It happened sometime between 12/3/07 and 12/04/07.  Other podcast sources work just fine, the problem is limited to NPR.org.   I can directly download NPR podcasts through a browser, but I lose the extra functionality provided by the Zencast application.  I'm not the only one getting this problem, I saw references to it here, here, here, and here.   The best guess is that the NPR server some setting that tells clients what functionality that they support and it's breaking the applications that actually check those settings.

Can someone from NPR please this?  I miss my Fresh Air and Car Talk shows.

Technorati Tags: NPR,Car+Talk,Fresh+Air,Zencast,podcast

Windows Live Writer change from beta to 1.0 that affects plugin development

I've been working on a SmugMug plugin for Windows Live Writer on and off for the last few months.  The code is nearly complete, some other things came up and I had to put that code a way for a while.  Now I'm back on the code and I'm almost done.  While I was off doing other things, two things changed in my development environment.

The first change was the release of VS 2008.  I moved the code from VS 2005 to VS 2008 without any issues.  The other change that Live Writer left beta and there were some folder changes.  Your plugin code needs to reference the WindowsLive.Writer.Api.dll assembly.  The beta version lived in "C:\Program Files\Windows Live Writer\WindowsLive.Writer.Api.dll" and the release version lives in "C:\Program Files\Windows Live\Writer\WindowsLive.Writer.Api.dll".  It's a subtle path change, enough where you wont catch it at first glance.

If you were using the Post-build event command line to deploy your plugin for testing, make sure that you are copying to "...Windows Live\Writer\plugins" and not "...Windows Live Writer\plugins".

The SmugMug API rocks.  Having written and consumed various web services in different incarnations, I've very impressed with the layout and functionality exposed by the SmugMug API.

Tech Tags: SmugMug API Windows+Live+Writer plugin