Toshiba A135-S2386 for $449.99

My wife's 3 1/2 year old Compaq X1050US ( Centrino ) finally bit the bullet. Well, the LCD display did anyways... it's now been transformed `desktop` thanks to a 19" CRT that we had sitting around. We paid about $1200 for it back in the day. Last fall I purchased a Gateway MX6920 ( Core Duo T2050 w/1GB ) for $800. I was getting ready to purchase a new Gateway MT6705 ( Core Duo T2080 w/1GB ) for $600 when I noticed the Toshiba A135-S2386 ( T2080 w/512MB ) at Bestbuy for $449.99. My sister in law also needed a new laptop so I needed two.

The problem was, they are all sold out. But wait, for some reason ( as of today ) BestBuy in Killeen and Waco have dozens of these puppies. So on my way back from Dallas I picked two of them up fo less then $1000 out the door with tax. 512MB isn't nearly enough so I've given up the 2 512MB modules from my Gateway and will be getting in 2 1GB modules from NewEgg in a couple days.

Man, hardware sure does get cheap..... Anyone in Central/North Texas who needs a good solid budget laptop should really give these two stores a call while you can.

Microsoft: Make WiX a priority

I've been following the WiX-Users list where Neil Sleightholm politely started a new thread titled `How do I submit code? Do you want my changes?`:

I have tried to submit code changes to WiX but no one seems to respond. Here is what I have done:

- Applied for a “assignment agreement”, heard nothing…
- Applied for a “assignment agreement”, heard nothing…
- Applied for a “assignment agreement”, heard from Microsoft asking me to help with a new system. I helped, submitted the “assignment agreement”, heard nothing…
- Ok I thought, you guys have better things to do than paperwork, so I worked on a code change to fix a bug in the NAnt task. I submitted a bug (1715295) and followed the advice given here to email the devs list. I did this on 9 May 07 so I don’t think I am being impatient but you guessed it, heard nothing…
- Not one to give up I tried again. This time I submitted a bug (1715298) with the code to fix it. Again, heard nothing…

So what do I have to do to get code accepted? WiX has made making installs much simpler for me and I have 2 clients using it on my recommendation. I would really like to contribute to the code but don’t want to spend the time doing it if there is no way of getting the code accepted (or rejected).

Bob Arnson (MSFT) replied:

It's all a matter of time and priority. At the moment, Rob's the only person who looks at external contributions so we can't load-balance. Your fixes look fine but they have workarounds so that's pushing them down the list too.

To which Neil replied:

Bob, Thanks for your reply but it doesn’t really answer my question. Submitting code and not hearing anything for 6 weeks is a bit demoralising. Virtually every day on this list someone writes a comment along the lines of “if you can fix this please do” but it sounds like you don’t have the capacity to accept code. It would be nice if there was a process for submitting code so at least we knew that our contributions had been received. On other open source projects I have worked on it was easier to submit code.

So my question still stands, do you really want my changes? I appreciate you all have day jobs and this is part time but the same is true for us and there is little point in submitting code if you don’t have time to look at it. The longer the delay is between submitting change and the code being reviewed the harder it is for you as our changes could be based on an old code base.

To me this is a symptom of FOSS. It's a symptom of giving a fine software engineer program management responsibilities and then giving him very little time to do it all. It's a symptom of not being responsible to concrete customers and budgets. It's a symptom of combining the control freak aspects of the `Benevolent Dictator` model with the control freak aspects of super-megacorp needing all the legal I's dotted and the T's crossed with `assignment agreements`. At the end of the day you have dozens of people wanting to help, either with design suggestions or actual code merges, but so few people in the inner circle that very little actually gets done. What should have been accomplished in months takes years.

The irony is that Rob Mensching once posted this rant against InstallAware:

Yet InstallAware the company is directly benefiting from the many, many volunteer hours people in the WiX community have put in creating, discussing, debugging, and releasing the WiX toolset. Nothing wrong with that, the license is written in such a way to enable that very thing. But I think that InstallAware is missing out on a huge opportunity by choosing not to participate in the WiX community (the very people who are most likely to want such a product) until the product proves "commercially viable". There has been absolutely no discussion about WiXAware on the wix-users mailing list.

Given how Rob says he is `100% not the target ( of a GUI designer )`, and that design suggestions and code submissions go completely unnoticed, how exactly can you be upset at InstallAware for not `participating`. ( Which really isn't true.... I've seen K-Ballo (InstallAware WiXAware lead) participating on the mailing list... he just doesn't announce who he works for. )

WiX has done great things, but there is clearly a log jam here. The solution is pretty simple to me and I've rambled on about it before:

But what if Microsoft just threw a bunch of money at InstallAware and bought them? What if Microsoft was to tell Rob Mensching that he had a staff of developers and that they wanted to transform WiX into a full fledged open source enterprise installation authoring tool capable of competing with InstallShield toe to toe?

And what if all of this was to be targeted for Visual Studio Orcas so that when you bought Visual Studio you'd be completely covered for deployment?

Smarter TFS Incremental Builds

Anyone who does a search for TFS Incremental Builds is bound to stumble across this MSDN page that describes controlling TFS's CoreGet with the following properites:

<PropertyGroup>
<SkipClean>true</SkipClean>
<SkipInitializeWorkspace>true</SkipInitializeWorkspace>
<ForceGet>false</ForceGet>
</PropertyGroup>


The problem that I notice with this though is that it fails when you are running the build for the first time and the workspace has never been initialized. This is normally not a huge problem except that I recently I needed to create a BuildType that involved performing a full nightly build and on demand incremental builds. I needed a way to conditionalize the behavior.

Then I realized that I could simply have my schedule task delete the build workspace if I could get my BuildType to be smart enough to prime the pump when the build didn't exist. The result is this simple change:


<PropertyGroup Condition="Exists($(SolutionRoot))">
<SkipClean>true</SkipClean>
<SkipInitializeWorkspace>true</SkipInitializeWorkspace>
<ForceGet>false</ForceGet>
</PropertyGroup>


If the directory is missing, the BuildType defaults to performing a Full Build and if it already exists, it defaults to performing an Incremental Build.

MSI 4.5 and the `Better Together` Pattern

I once designed for a previous employer a bootstrapper that supported a very complex and seamless story for chaining together dozens of setup prerequisites in different combination to support dozens of different products. They were a Product Line Development shop ( with a whole lot of custom engineering efforts also ) that aimed to bring different assets together to create new solutions very quickly. My readers who still work at this blog know just how far we took that design.

So with Merge Modules and Concurrent Installs being officially dead and evil, and each new Microsoft product needing to integrate the experience of deploying more and more reusable components, it really comes as no sup rise to me that Microsoft is finally tackling this issue.

In the "Agility Trends in Packaged Software" white paper by Robert Flaming (MSFT Windows Installer Program Manager) one little section caught my interest:

Your tools vendor may be your first choice in your Better Together path and could even be your conduit to spectrum of software providers that want to provide you a Better Together experience on their software.

We are in a bold new world, and there is a lot to digest in the white paper, but I'm already wondering what kind of standards will be established ( ICE's, Logo Certifications ectera ) to help ISV's develop micropackages that can easily be composited into a Better Together solution. I also wonder if tools vendors like InstallShield are really the best candidates to establish these practices as it could cause problems when multiple ISV's try to integrate their packages and find out that they are somehow incompatible due to design reccomendations from their competing tools vendors.

I really don't know how this will go down yet.... there is alot of information that has been shared privatly with tools vendors yet deemed to secretive to share with actual front line setup developers. Maybe 4.5 will have a strong enough contract that this problem is mitigated and maybe it'll be too loosely defined as to have the innovation come from the tools vendors and lead to exactly this contract.

Either way, if you find yourself supporting installation stories like I described, or if you see yourself selling software that might be consumed by ISV's that support this story, you really owe it to yourself to start reading over MSI 4.5.

Google Coming to Austin, TX

I was lighting up the grill with some friends last night when my friend Ben mentioned something about Google coming to Austin, TX and that he knew that the new Engineering Director was looking for people. I recalled to him that I'd seen a job posting for an InstallShield integration position but that I had ignored it because it was in Mountain View, CA.

Later I google'd for news and I found this blog article.

<ShamelessPlug>I know from my http referer logs that Google sometimes comes by here. If so, I'd love to hear from you!</ShamelessPlug>

Bootstrapping your product with IExpress.exe

I've been following a thread over on WiX-Users entitled `msi to exe` where Afshin Sepehri ( MSFT according to his email address ) asks:

How can I convert an .msi file to .exe?

Now when I first read this I just kind of laughed to myself.... Here we go again... reinventing the wheel because WiX doesn't have a decent bootstrapper like InstallAware and InstallShield. But then the first round of answers poured in:

John Vottero:

Use IExpress.exe. You probably already have it (it’s part of IE).

Wow, my eyes popped open wide. IExpress is meant to be an administration kit for rolling out IE across an enterprise. Surely Microsoft didn't intend for it to be used as a bootstrapper by ISV's. So I had to go look at the EULA

Well again, IANAL... however this seems highly suspect. The license agreement clearly states that this product is for making customized installations of IE for internal distribution or external for companies like ISP. The concept that this would wrap up some other completely unrelated software seems to be flat out against the EULA.

So I asked the question to the group: Is this Legal? The answer surprised me.

John Vottero:

You don’t redistribute iexpress.exe, you redistribute the output of iexpress.exe. I still don’t know if that’s legal.

Wow... splitting hairs, acknowledging that the legality is uknown, yet recommending it's use for packaging an MSI. The conversation continued and it seems that IExpress.exe has leaked out of the IEAK and is now part of Windows itself.

It still seems strange, it's still not a good enough bootstrapper to support my needs, but I'm starting to feel safer about using IExpress.exe. Partly because of a TechNet article that described using IExpress.exe to compress some files and add to cmdlines.txt for a sysprep postinstall step.

I guess it's ok to use, but still a strange road to get here.

Interesting and Uninteresting Comments

I enable anonymous comments on my blog because I understand there are times that people have interesting things to add to the discussion and they either don’t want to be bothered to register an account or perhaps they just want to remain anonymous. Sadly this sometimes means I get rather uninteresting ( aka rude ) comments from anonymous users that must be moderated. Most of these negative comments seem to originate from a particularly hateful person a certain company in Bedford, MA ( remember, YOU are not really anonymous on the Internet ) but I digress. The real purpose today is to touch on an interesting question an anonymous reader asked:

Very interesting, Chris. Did the question of business ethics come up at all? InstallAware has had some really bad press recently...caught stealing other installer website designs, then using those situations to showboat, which seems a bit dirty. It would be interesting to hear what Sinan had to say about that in person that would convince you he was worth spending 5 hours with.

That's a very fair question. When Sinan first emailed me I have to admit I almost felt like turning down the invitation to get together. When I mentioned it to my wife she remembered the `oops they did it again` and `all’s fair in marketing and war` threads and got very concerned that I was meeting with Sinan and worse, was I considering working for them instead of Macrovision?

I did have a bad feeling in my stomach, after all it as InstallAware's Michael Nesmith who once accused me for being on the take with Macrovision because I've been published by Macrovision in the DevLetter series. I assure everyone, Macrovision has never given me a penny. I write for the benefit of fellow developers. I love meeting with anyone who has a love for setup. So I decided to accept the invitation and go there with two goals::

1) Keep an open mind on how InstallAware technology attempts to solve setup problems.
2) Attempt to communicate user stories that I feel today's authoring tools don’t do a very good job of supporting.

With that in mind, we had a very good back and forth technical discussion for about 5 hours. It was not until the last 20 minutes or so that we started discussing the `politics` associated with the small world of setup. I didn’t throw Sinan any softballs, but I also didn’t try to hold him to the fire. I listened to his perspective and I shared a few of my concerns. But I would not say any of this was framed as `ethics` questions or debates, but more just an exploration of the relationships between different people/groups and what could be done better to further the goals of all involved. After all we are all different. We are all trying to solve different problems with different methodologies. Some of us are trying to improve an install, some of us are trying to run a business, some of us are trying improve an installer tool, some of us are trying to improve an installer SDK for installer tools and users to use. Regardless of where we fit, we don’t always agree on how it should be done and sometimes the internet brings out the worst in us. Frankly I’d rather smooth the waters and get back to having good conversations with anyone who cares about setup.


I don’t know if that actually answers the question the anonymous commenter had so feel free to ask follow up questions. I may or not be able to answer as there were some aspects of the discussion that I'd like to keep confidential as to not stir up trouble with third parties that were mentioned.

Dealing with very large number of files

Allan Bommer recently asked on the WiX-Users list:

The one item I am worried about is managing a very large number of files. Our application’s Help directory contains about 1500 files (html, gif, etc). It seems the only way to get these files installed is to list them explicitly (with some help from Heat). It also appears that it is suggested to make each file a component.

Explicitly dealing with 1500 files and their component GUIDs seems likely to have a very low ROI for the programmer and company. I’m sure my clients would rather have me crank out a few useful features in the application than spend countless hours on all those individual entries. Perhaps if you have a million clients, then dealing with all those files individually makes sense, but with 100, 1000 or 10,000 clients, the cost-benefit ratio doesn’t look very good.

Allan hits on one of the weaknesses of the declarative design of Windows Installer. Rich metadata describing the behavior of the contents and behavior of the installer has the huge downside of having to author that metadata and keep it in sync with the ever changing world. The upgrade servicing patterns also require that you be absolutely perfect in how you do this. One component rule violation or primary key column change across dozens of builds will result in undesired servicing behavior.

Allan then asks ( in his own way ) about dynamically linking the files. Dynamically file linking will generally work but it has several downsides:

The most important downside is the possibility that a file should be in the package, but that it was not where it was supposed to be at build time. If the file was described declaratively this would be a build break. But with dynamic file linking, it simply isn't linked and now we have a potential runtime break.

The second downside is that it's very difficult to perform minor upgrades and patches due to the dynamic nature of the component authoring. Some tools like InstallShield have patterns for mitigating this, but it's still a crap shoot.

The third downside is that your build will take A LOT longer to perform since it's not only creating your package but that it's also authoring and validating your component definitions.

But I think there is a third way to go about this and I probably spent at least one of my five hours with Sinan Karaca touching on this subject: Use authoring tools with very rich component wizards. InstallShield has one, but it's not nearly good enough in my opinion. Here are a few attributes that would make it better:

`Deprecated Component` instead of Deleted Component. Minor upgrades can't remove a component and it's keyfile, so instead you take advantage of Transitive Components and NOOP conditional expressions along with a 0 Byte file in the media. This allows a developer to safely remove a component without worrying about which upgrade pattern will be used to service the installation.

Better definition and control over the concept of `Best Practices` when authoring the components. On MSDN you will find 2 very different definitions of best practices for componentizing files. The MSI team breaks things by directory and COM servers with all other files being allowed to share a component as a designated key file and companion files. The Visual Studio team takes a different approach that every file should be a key file. To be honest, I see ways in which they are both correct. A properly behaving component wizard shouldn't simply ask `do you want to follow best practices` as if it is a black and white decision. It should offer you a choice of those two best practices and a custom mode where you get to decide for yourself. The point is when I have some ASP.NET developer adding files I don't want him to have to understand the component rules. I don't want him to need to understand that default.ascx is the keyfile and background.png is the companionfile. He just needs to know that he can update either file and he can expect to see his changes on the server after the installation is executed.

Another feature that a good wizard should have is the ability to automatically detect changes between the currently authored components and the directory structure that it is syncronizing. We are talking easy button here: Rescan Components followed by "I see these 5 new files... would you like to add them?" or "These 5 files are missing, would you like me to deprecate them?"

MSI might be complex, maybe more then it needs to be, but there is value in it's patterns. It's just time that we have authoring tools that makes it a hell of a lot easier so that Allan doesn't have to be pointing out the obvious ROI problems associated with it.

Flashback: A trip down memory lane

I was reading over on Aaron Stenber's blog about Microsoft using Virtual disks to ship windows and applications and it reminded him of the old days when Microsoft would just ship preconfigured hard drives instead of installs.

I recall that at my last job that they really weren't that far removed from the practice. Going back further ( 1996 Windows 3.1 days ) I once invented a tool while I worked at Electronic Data Systems called `The Cookie Cutter`. This tool was a bootable ISO9660 ( not easily done back then.... you had to be comfortable reading the El Torrito spec and using a Hex editor ) that started up MSDOS and ran a compiled QBasic program that I wrote.

The program would present a series of configuration screens to select an image to load and needed TCP/IP settings. We could select from 18 different configurations ( Banyan, FTP PC-TCP, SmartTerm IP, Novell, MS-TCPIP ), then it would automatically fdisk / format / extract and configure all the needed INI settings to configure the machine. Funny, even back then I wasn't afraid of configuration data being a pain. The only real pain was when 10+ people lost their jobs because of the efficiency improvements in our work flow. I travelled a lot back then and this is what started me down the path of setup. It was sad that we choose to clone our workstations instead of install them because our installs were so bad back in those days.

The other funny thing is that Microsoft seems to think that virtualization is new. The fact is I used to be a rabbid Amiga addict. I actually learned how to install and configure MSDOS/Win 3.1 by using PC-Task to emulate an x86 PC. Sorry American Megatrends, please don't ask where I got a BIOS image from..... :)

Going way back, my first computer experience ever was actually quite embarrassing. My older brother had a friend who owned a Commodore Vic 20. He gave me a book to read and sent me on my way. When I returned he tested me with a simple question. You have a program in memory and you want to erase it, what do you do? The correct answer was to type NEW. I hadn't read the book so I simply reached for the power switch and toggled the power. Not too bad for a 7 year old I suppose.

Despite my less then stellar start, my parents decided to get a Commodore 64 and it all started with Microsoft Basic 2.0 & 6510 Assembler on a Commodore 64. Ahh the Commodore 64 Advanced Programmers reference manual.

It's funny to think that I've been coding for over 25 years and that Microsoft has always been there... whether I wanted them or not. How things change and yet stay the same.

Yes WiX, I really DO want to do that...

Consider this MSI fragment( created in Orca and transformed to XML by MSI2XML ):

<table name="InstallUISequence">
<col key="yes" def="s72">Action</col>
<col def="S255">Condition</col>
<col def="I2">Sequence</col>
<row>
<td>Dialog1</td>
<td/>
<td>1</td>
</row>
</table>

It's not a real installer, it's a `fake` MSI that was created just for fun and just to show what Windows Installer is capable of doing once you free yourself from coloring between the lines.

Now MSI2XML can easily round trip the table data without passing a whole lot of judgement. Just for fun I thought I'd see what it's like in WiX to do this. I take the XML and reconstitute the MSI and then use Dark to create a wxs project. Now WiX takes lot's and lot's of issues with the source even though it is a perfectly formed MSI database that will actually do what it was intended to do. Let's ignore most of this for a moment and talk about the Sequence tables.

In my XML you'll notice that only the InstallUISequence table is defined and it's pretty sparse..... it only contains a single action, a call to a UI Interface Wizard called Dialog1 (yes, unique name I know...)

Now note the XML that dark creates to represent this:

<InstallUISequence>
<Show Dialog="Dialog1" Sequence="1" />
</InstallUISequence>

This snippet sounds like what I describe, right.... a single sequence with a single action. But that's not what candle/light does with it. It automatically goes and creates:

AdminExecuteSequence ( 8 actions )
AdminUISequence ( 4 actions )
AdvtExecuteSequence ( 7 actions )
InstallUISequence ( 6 actions instead of 1 )
InstallExecuteSequence( 13 actions )
In order to get a successfully round trip'd resultant MSI ( pedantic error checks for the time being ) the XML actually needs to look like:

<AdminUISequence>
<CostInitialize Suppress="yes"/>
<FileCost Suppress="yes"/>
<CostFinalize Suppress="yes"/>
<ExecuteAction Suppress="yes"/>
</AdminUISequence>
<AdminExecuteSequence >
<CostInitialize Suppress="yes"/>
<FileCost Suppress="yes"/>
<CostFinalize Suppress="yes"/>
<InstallValidate Suppress="yes"/>
<InstallInitialize Suppress="yes"/>
<InstallAdminPackage Suppress="yes"/>
<InstallFiles Suppress="yes"/>
<InstallFinalize Suppress="yes"/>
</AdminExecuteSequence>
<AdvertiseExecuteSequence>
<CostInitialize Suppress="yes"/>
<CostFinalize Suppress="yes"/>
<InstallValidate Suppress="yes"/>
<InstallInitialize Suppress="yes"/>
<PublishFeatures Suppress="yes"/>
<PublishProduct Suppress="yes"/>
<InstallFinalize Suppress="yes"/>
</AdvertiseExecuteSequence>
<InstallUISequence>
<CostInitialize Suppress="yes"/>
<FileCost Suppress="yes"/>
<CostFinalize Suppress="yes"/>
<ValidateProductID Suppress="yes"/>
<ExecuteAction Suppress="yes"/>
<Show Dialog="Dialog1" Sequence="1"/>
</InstallUISequence>
<InstallExecuteSequence>
<CostInitialize Suppress="yes"/>
<FileCost Suppress="yes"/>
<CostFinalize Suppress="yes"/>
<ValidateProductID Suppress="yes"/>
<InstallValidate Suppress="yes"/>
<InstallInitialize Suppress="yes"/>
<InstallFinalize Suppress="yes"/>
<PublishFeatures Suppress="yes"/>
<PublishProduct Suppress="yes"/>
<ProcessComponents Suppress="yes"/>
<UnpublishFeatures Suppress="yes"/>
<RegisterUser Suppress="yes"/>
<RegisterProduct Suppress="yes"/>
</InstallExecuteSequence>

Now I can understand that for a real MSI would want all of those actions/sequences by default, and I also understand that some pople are going to want to quickly dismiss this use case as `fake` and `invalid`, but consider this prospective:

Shouldn't a successful decompiler/compiler story result in the creation of a binary that is identical ( or as close as possible ) to the original binary? To me it seems like Dark should respect ( and warn of course ) that this was the original configuration of the database and author XML to represent it. Instead dark seems to try to read between the tea leaves and say `well I know this is what you are, but I really think you should be this...`.

In the past I've worked on some pretty big, complex installer frameworks that delivered dozens of installers by consuming dozens of product assests in different configurations with different brandings. The frameworks are so big and so active that it's not practical to just dump it all at once and replace it with an entirely different system. You have to refactor individual layers and components while maintaining the existing contracts. While doing this refactoring I've attempted to incorporate WiX in my solutions, but unfortunatly it's been issues like what I just described that have forced me to use other tools like MSI2XML which are much more respectful of what I'm trying to accomplish.

Disagreeing with the Benevolent Dictator

I've been partially following the WiX-Users list recently when I noticed this question from Leo:

How do you define the InstallExecuteSequence table in WIX so that the standard actions PublishFeatures, PublishProduct, RegisterProduct and RegisterUsers won't show up? thx!

Oh my, I knew right away that this was stepping on a hornets nest. Anyone who has followed WiX / Rob Mensching / Aaron Stebner ectera for awhile knows that this group is pretty self confident that their way of doing this is the right way and everything else is wrong. However this is the WiX-Users list and I really don't want to troll for an argument. I decided to sit back and watch. Sure enough, Rob Mensching replied:

Why would you want to do that?

Ok, so maybe this is a case of email not conveying emotition, but I'm pretty sure what Rob was really saying that you have to somehow convince him that you have a valid reason for doing this. I've had several reasons in the past, but again, I don't want to go trolling... Then someone replies with an answer to the actual question of HOW you would do it, but continues to lecture about why you shouldn't do it. Then yet another person replies to lecture about how you shouldn't even use MSI if this is your need, go use NSIS. Ouch... yuck.

Now our original poster Leo comes back with a pretty good piece of logic... the MSI team specifically has a help topic on MSDN explaining how/why you might want to not register your product with these standard actions.

MSDN does not indicate any problems or recommand not doing this. As a matter of fact MSDN provided the instruction for omitting the registration of application at Exactly what kind issues I might get into if I do this. Please advise. Thx!

Now I've not waited long enough to see additional replies, but I already know from experience that this kind of questioning isn't going to go over well in the Wix-Users space because you have to keep in mind that what the Windows Installer team considers a `valid` MSI and what Rob considers a `valid` MSI are entirely different.

My opinion is as long as you understand what your doing and the related impact..... go do your thing. I follow most generally accepted best practices, but on certain issues I've had business requirements that require me to do something different. I personally won't listen to anyone try to dictate ( no matter how benevolent ) what my install should or should not do nor will I listen to complaints like `fake` or `trojan` MSI and most importantly I don't accept something as some immutable, undeniable best practice just because one person says so.

Mailbag: Have you seen this?

I guess thinly veiled ambigious references aren't enough because I keep getting emails from friends asking if I've seen the news about Macrovision. So yes, I know about the 7% RIF and I know about the director who picked up a nice $200,000 dumping 15,000 shares of MVSN stock. I also know about various people suggesting that a sale is in store for Macrovision. However, until people actually start flooding my mailbox with real inside scoop, I'm just an outsider looking in wondering what's going on. That said, here are some interesting quotes from a Yahoo! investment board:

From `candor2001us`

Why is this a good sign? you usually cut employees in bad times, when there is no work for them. This is not a sign of a growing company.

From `maxiumboostage`

exactly, with mvsn dropping safedisc , ripguard, hawkeye, the flex stuff not being developed any further i think its soon gonna be time that fred makes a move. he has been known to break companies apart and this is the first sign that vsn is being broken into nice purchasable chunks for any interested parties that want to buy the technology. i also heard on the grapevine that electronic "safediscs main customer" have dropped the product thus rendering it non profitable. well ill wait and see but i am standing by my predictions that its gonna be broken up and sold into chunks. bye bye macrovision.

From `josedelacruz150`

EA may or may not have dropped safedisc. That's an old product anyway in a market that's moved on.
Its never been a money maker, and its end of lifed already.
Macrovision doesn't have any real technology but it does have IP.
Wouldn't be surprised if he sacked them all and sold that.

From `candor2001us`

that's not necessarily true. You cut employees to strengthen the bottomline especially when the top line is remaining stable.....I think Fred just wanted to cut deadweight especially with a couple of Execs and Im pretty sure there will be another one cut soon once he proves his incompetency.....

you also start to slim down when getting ready to look for a buyer.....

It's been great working here though....

An afternoon with InstallAware's Sinan Karaca

It was a really nice father's day today: My smiling girls, the sweet cards and presents, the bacon wrapped Fillet Mignon and best of all, being given a pass to go enjoy some free time without the responsibilities of parenthood.

So what better to do on an afternoon off then to sit at a Starbucks for 5 hours chit chatting with the founder of InstallAware, Sinan Karaca. We both went into extreme detail over practically every aspect of the installation space.... way too much to write about here. I think a lot of good information flowed and I've come to realize that the two of us actually disagree on very few topics. I'm looking forward to see if InstallAware decides to implement a few of my thoughts in WiXAware and I'm equally interested in seeing if I can fit WiXAware into my installation solutions.

Either way it was a very productive session and as always, I always enjoy meeting with people who have an interest in setup. If you find yourself in Austin, feel free to look me up.

Wondering about the future

I've been wondering about the future lately... both personally and professionally. Sometimes the way things appear to be and the way things actually are can be unrelated. You often have clues to the coming changes but you either want to ignore them or just not speak of them. Maybe it's just hard to talk about something when you are only dealing with suspicions.... you just don't know the exact facts.

I know of a couple companies that are going through some pretty difficult times right now. Both have given clues that they aren't making the numbers that their investors are looking for and both have recently gone through some pretty serious layoffs and `reorganizations` as people scramble to figure out a way to make money. Both are also giving some pretty strong clues that they will be on the selling block in the near future. I don't want to name names since I don't want to hurt the innocent, but I'm guessing that by the end of the year, time will reveal all. It has been stressful lately because one of these companies I currently work for, and the other is a company that I've very recently considered working for.

Then there is the big unknown that strikes closer to home... Will my wife's cancer come back?

Burning In Hell With Heat

Ok, I really, really, really keep trying to give WiX a try but I'm not exactly sure why. I have an ASP.NET website installer that I wrote and maintain in InstallShield that I've been wanting to split out to give some of the responsibility back to the ASP.NET developer. To do this, I've moved the components/directories/files out to a Merge Module and the main InstallShield project just handles the UI, consumption of the merge module and creation of the VDIR/XML XPath resources. I want to refactor the merge module to use WiX instead of VDRPOJ.

So I decided to give Heat another try. The goal is to harvest a directory and insert into a merge module project in Votive. Now heat says it's simple, let's see if it is.

First I started by running the command:

(Foo is a directory structure with apx 200 folders and 3700 files )

heat dir Foo -out Foo.wxs

A few seconds later I have Foo.wxs and I'm thinking: Cool! It didn't throw an exception like the last time I tried this.

Then I notice two things... first all of my components ( thousands of them ) have a GUID attribute of "PUT-GUID-HERE". Oh my,that's going to be fun.

Then I notice all of my files have a absolute path for their Source attribute. Well hell, that's not going to work in a build automation environment.

For the first problem I ask the WiXUsers list and I'm told about an undocumented -GG argument to heat. It sure would have been nice if /? told me about that one. So I quickly rerun heat and problem one is gone.

Then I do a search and replace to fix the absolute path problem. Cool, that one is gone. Now it's time to go create a Merge Module project in Votive and paste my components in and build my merge module.

You guessed it... didn't work. It seems that Heat created all of these Fragment elements around the DirectoryRef/Component/File elements and WiX doesn't actually like that when I paste it in as belonging to MergeRedirectFolder Directory element.

So I run a search and replace to get rid of Fragment elements. Now I find out that DirectoryRef is incorrect also. So I perform yet another search and replace to change DirectoryRef to Directory.

Now I'm getting to a new error message:

The Class/@Server attribute was not found; it is required.

It seems Heat examined the properties of my .NET assemblies and only half authored the required attributes. For the moment I decide to just ignore the properties and treat my assemblies as XCOPY. I go through and chop off all of the offending elements.

Yup, you guessed it again... it still doesn't work. Now I'm being told that I have duplicate Directory elements. It seems that Heat didn't normalize my components by their associated directory. It just created a duplicate Directory element for each component.

Meanwhile something else is very annoying.... Ctrl+Break doesn't actually work at killing the build. I have to break out Task Manager and kill candle. Even after it's killed Visual Studio remains unresponsive as it continues to somehow process build error messages that were received from candle.

Ok, it's getting too hot in here even for this Texan. Consuming a directory structure and dropping it into a merge module really shouldn't be this freaking difficult. Even the POS VDPROJ can easily do this simple task.

Now someone can feel free to post a comment talking about how I'm being snarky or that I simply don't understand WiX enough, but it would be a lot more beneficial to actually start considering real world user stories.

I'm still waiting for the day where some tool comes by that solves all of these problems and makes real world use cases simple. Until then I'll be using InstallShield. Sure it might cost $2000 but the alternative is anything but free regardless of what the license agreement says.

Deployment Engineer Available

I would like to publically say that I'm interested in communicating with fellow Austinites ( and others from around the world if remote work is possible ) who may be aware of organizations that could benefit from my assistance in the areas of build and deployment automation. I am willing to do 50% travel is necessary. Please email me offline at chrpai@yahoo.com.

Thanks,
Christopher Painter

Austin .NET Deployment Brown Bag

I've started the processs of planning a .NET Deployment Brown Bag lunch with focus on Windows Installer / InstallShield techniques. If this interests you, please email me at chrpai@yahoo.com for more details.

Deploying a Vista SideBar Gadget

Bob Crawford recently asked on InstallShield Community:

Hi, we are developing a Vista application with a companion Sidebar gadget. We would like to install/uninstall the gadget along with the application. Does Installshield 2008 have this kind of support for Sidebar gadgets?

I havn't done this yet so I decided to start Googling. This interesting MSDN Lab came up:

Windows Vista: Creating a Simple Sidebar Gadget Virtual Lab

After registering you can download a PDF that walks through the process of creating a manifest for your gadget. From there it's a matter of giving the directory a name that ends with `.gadget` ( known as development packaging and seemingly implied not to be used for production ) or zipping / cabbing the directory and giving the compressed file a .gadget extension.

From there gadgets are deployed in true .NET ( and Java ) style.... XCOPY to C:\Program Files\Windows Sidebar\Gadgets. You simple create a component, add the .gadget file as the key file, set the directory and associate it to a feature.

So in short, yes InstallShield 2008 supports deploying SideBar gadgets.

WiX / WiXAware ... thinking about the future

I've decided to spend yet another evening looking at WiX and I really do like it conceptually. While I am still disappointed that a lot of problems that WiX and other setup tools are solving aren't being solved by the Windows Installer team instead, I am slowly coming to accept this as a fact of life.

I really like Votive's ability to integrate in a solution, support MSBuild and show the XML in your WiX project. But I dislike it's limitations in not having any kind of designer view.

I also really like the concept that WiXAware has where you can switch between a GUI and an Editor. The View Designer | View Code story is definitely the place to go. But I dislike the fact that it's waproj isn't MSBuild and it doesn't support VS integration. I also dislike the fact that it seems to throw an exception just about everywhere I click and I dislike the fact that it doesn't support fragments.

But what if Microsoft just threw a bunch of money at InstallAware and bought them? What if Microsoft was to tell Rob Mensching that he had a staff of developers and that they wanted to transform WiX into a full fledged open source enterprise installation authoring tool capable of competing with InstallShield toe to toe?

And what if all of this was to be targeted for Visual Studio Orcas so that when you bought Visual Studio you'd be completely covered for deployment?

The other day I was skimming through a Microsoft Learning Course... #4339 Upgrading from Microsoft VB 6.0: Deploying .NET Framework Applications. The course was very VDRPOJ centric and a lesson introduction claimed:

Unlike the traditional deployment which involves creating script-based setup programs, Visual Studio 2005 deployment uses Windows Installer to create installers which give you complete control over the installation process.

Wow, that's a really bold claim to say VDPROJ gives you complete control over the installation process.

But WiX meets WiXAware meets Orcas..... now that could be one hell of a system. That could really get me rethinking what tools that I use. In fact, if it wasn't for the fact that I live in Texas, that's one project that I wouldn't mind working on.

7 Months to publish 2 KB articles

Last year the Windows Installer team blogged about 4 upcoming KB articles. Now I understand why they published them as a preview, it's taken Microsoft 7 1/2 months to publish just 2 of the 4 articles.

Yes, over 7 months. Man it feels like Office Space.

What could possibly take so long to write these? The first one about DEP is only 9 sentences.

The second one caused by cached MSI's losing their digital signature is only 7 sentences and it doesn't even go into explaining why the behavior occur. It simply documents a `work around` that tells the user to click Allow.

Now I know the MSI team has some very smart and capable contributors and leaders, but I can only imagine what must be going on behind the scenes within Microsoft that it takes 7 months to publish two simple KB articles. Now imagine trying to give us something we really need like XML search/write functionality.

It's no wonder that they have seemingly abdicated the throne to WiX which can operate in the relatively unrestricted world of FOSS with nothing more then Jersey Mike's sandwichs for funding.

Working Around VDPROJ and Horrible EULAs

I recently read several blog articles and newsgroup postings of interest when put together.

The first was from Aaron Stebner ( MSFT ) talking about YEt Another Hack ( sarcasm `YEAH` /sarcasm ) describing how to do some crazy postbuild step to get a VDPROJ installer to do something as simple as set the In-Script Execution Context for a custom action. I'm sorry, but I've been down this road before. In no time at all you will have dozens of these build automation hacks just to get a tool set to do something that it specifically wasn't designed to do despite that it's painfully obvious that it should.

Then I read this posting from Phil Wilson...

The design of installer class methods does not pass the MSI handle through to managed code, mainly because the design (as a deferred custom action all) means that there's not actually much you can do with it.

Based on this and what little support for custom action attributes VDPROJ exposes, it seems pretty obvious what Microsoft ( Visual Studio Team ) wanted to design Visual Studio to support.

Finally I read a story over on SlashDot entitled Microsoft vs TestDriven.NET. It seems that the author ( Jamie Cansdale ) of TestDriven.NET royally offended Microsoft by coming up with extending Visual Studio Express editions with Unit Test Add-In's. A response from the VSE team can be read here.

So setting the threshold level to 5 on SlashDot ( as I always do ) I discovered this gem:

It seems that Microsoft is claiming a EULA violation on the basis:

...you may use the software only as expressly permitted in this agreement. In doing so you must comply with any technical limitations in the software that only allow you to use it in certain ways... You may not work around technical limitations in the software.

So I ask you, if VDPROJ specifically didn't provide for immediate context CA's, ServiceControl/ServiceInstall support and a host of other things, and assuming that Microsoft's bizarre EULA is enforceable, isn't writing articles that encourage developers to work around these ( obvious ) limitations simply an invitation to disregard their own EULA?

Just like teaching developers how to modify .NET Framework Redistributables to run silently even when their own EULA says that you may not.

BTW, did I mention that Microsoft yanked the MVP status of Jamie? Also of interest is that Jamie wrote the Installer for TestDriven.NET using all Microsoft tools including WiX.

Times like this makes me really happy that I don't owe anything to Microsoft... I prefer to have an unbiased outside opinion without worrying about things like will I get shunned from some conference, lose MVP status or worse, lose my lively hood.

Days like this, I miss my Amiga.