This just in... Static Control Corp (SCC) has essentially won its appeal against Lexmark. Lexmark was attempting to use the DMCA (Digital Millenium Copyright Act) to claim that Static was overriding its “digital locks” which prevented printer users from using printer ink cartridges from other manufacturers.

One court had issues an injunction against SCC, but the appeals court dropped the injunction, finding that it is not clear that Lexmark will win its case. If you read the appeals court ruling, you'll see that 2 of the 3 judges came out pretty strongly against what Lexmark was claiming and the 3rd judge agreed but for different reasons...

As the kids say, w00t!

You'll recall a few days ago I was complaining about this printer ink cartridge scam:

And what about this anti-competitive technology? Inkjet cartridges these days have little computer chips, and the printers have little chip readers. The cartridge keeps track of ink levels, and is hard-coded to go down, never up. The printer will stop working when it thinks the ink is too low - even if there is still ink left in the container. And try using a no-name or third-party ink cartridge, and your printer will not work at all.

He he... I'm feeling a little better. The law does (sometimes) step in and protect the little guy from being bullied by the big guys. Sometimes.

Update: Oooooh. SCC is counter-suing Lexmark under the Antitrust law. You know, the price of ink jet printers may rise by a few dollars after this, but the cost of ink jet cartridges will fall drastically.

Long-time readers will recall that I often post here how much I love .NET. You can go back in the posting archives of this site and see how it thrills me when things that I want to do are made simpler with .NET (compared with other programming environments I am used to).

Today was not a good day in that regard.

Where do I begin? Well, first of all, I was writing a simple Windows Forms program to call a stored procedure and write the dataset returned out to a text file. Should be simple to do.

Well, I tried to be a bit fancy right off the bat. I don't know why I did it, but I lost a couple of hours of productivity and I still don't understand what the big deal is.

Here's what I tried to do: I wanted execution time to be displayed on screen as the program ran. You know, every second the text will update to say “1 second”, “2 seconds”, “3 seconds”, etc. Easy right? I just add a timer component to the form and have the Tick event update the text in a label.

Well, I tried to run the program in debug mode, by stepping through it line by line. When I happened upon my SqlConnection.Open() statement, the debugger froze. “There is no source code for the current location.” Hmm. I was using Step Over, not Step Into, so it should not be trying to go into the SqlConnection object code. Is my SQL connection setup OK? Check my connection string. Database is running. Add a generic exception handler to the catch statement. Tried commenting a bunch of stuff out. Moved things around. Nothing worked. The program always froze on the SqlConnection.Open() statement.

I called a friend over, and showed the problem to him. We both spent 20 minutes trying different ways of doing the same thing, to no avail.

Finally, I checked Google. It led me right away to this MSDN Knowledge base article. Ah, you cannot access the SqlConnection from inside a timer event in Debug mode. But the article suggested a work around. Instead of using a Timer component, I could use the System.Timers.Timer class.

So I reworked my code to use that class instead. The method and property names are slightly different, so it wasn't just one-line change. Ran it again.

This time it worked. But... the program continued to act strangely in Debug mode. When I tried to read the dataset using a SystemDataReader.Read() call, it froze again.

So finally, I pulled out all the timer events. Not the best solution, but it worked fine after that.

Anyways, .NET's flakiness with Timer events cost me a couple of hours today. While most of the time it is fun to be a programmer in this tool, today it was not fun.

What if I told you there was an industry that sold 10 cents worth of product for $50 at retail stores? And that consumers were usually forced to buy it every few months at those inflated prices?

And they intentiionally made each version of their product incompatible with previous versions to make life more difficult for both consumers and competitors? And they came out with new versions of their product almost every month?

And that they developed technology so that their product would stop working when a competitor's product was used with it?

Some of you may have already guessed what industry I am talking about. Others may think I am dealing with something only Tony Soprano and the mafia could dream up -- a racket to ensure you make tons of money and everyone else gets screwed, especially the consumer.

Well, the industry is computer printers. The scam is that they sell the printer to you for $89 or so. And that printer comes with very little ink - the minimum required by law. Then they got you to the tune of $100 every few months as you replace your ink cartridges ($40 for black, and $20 each for three color modules). But what's so special about their ink? A cartridge of ink costs only a few cents. Even with all the fancy packaging, it's only $1 or so. Why do they jack up the price to $20-$40 per cartridge?

And what about this anti-competitive technology? Inkjet cartridges these days have little computer chips, and the printers have little chip readers. The cartridge keeps track of ink levels, and is hard-coded to go down, never up. The printer will stop working when it thinks the ink is too low - even if there is still ink left in the container. And try using a no-name or third-party ink cartridge, and your printer will not work at all.

The other thing that kills me is that there are, like, 100 different models of inkjet printers by each company. And each printer takes a different size and model of ink cartridge. That is why the computer stores contain aisles and aisles of inkjet cartridges. There is NO GOOD REASON why each printer requires a different model cartridge besides to make life more difficult for competitors and by extension consumers. If Epson makes 100 different inkjet models, then anyone who wants to make a cheaper ink cartridge needs to make 100 as well, which raises costs.

It's a big scam. Governments should step in. If the Department of Justice wants to stop anti-competitive behavior, this is a PRIME EXAMPLE. Do you think companies can get by with having two or three model printers, and keep selling them for a year or two? Do you think companies can get together and settle on a standard inkjet cartridge size? Yes. Of course they could. But then, they would be forced to compete, and that would be bad for business.

Tonight I didn't break any laws, but was made to feel like I did. I refilled my own inkjet cartridge. After a few minutes trying to get it to work, it did. I don't feel so bad though - these companies have been ripping me off for years.

This series of blog entries is running 2 or 3 longer than I had expected at the start. I'm sorry if this saga is getting old from the reader's perspective. How do you think I feel, trying to install this thing 10 times at least?

Finally, I have some good news to report.

I reinstalled the database and application servers from scratch. Reinstalled Windows Server 2003, and did everything in the proper order. I made sure the TFSIdentity user had admin permissions on the database, and did a few tests to ensure the permissions were properly set. And I hit the install button again...

And it failed. Again.

So, I deleted the databases that were created. I noticed it was the C:\VSTS folder that was not created this time, so I tried something different when installing the second time. I hit the install button...

And it succeeded. Yay!

What did I do differently between the two attempts? Well, during the install it asks you for four things:

• database server name
• TFS domain user name
• TFS domain
• TFS domain user password

During my first attempt, I used “vsts.x4.ca” as my domain name. Because that is the domain I created on the application server. The second attempt, I only used “vsts” as the domain name. And voila!

I really wish the install program would be smart enough to tell me “vsts.x4.ca” is not in the proper format. That would have saved me a TON of time. Heck, if they just had an example there (or in the documentation) that showed what a valid domain looked like, I would have known what to use and some of this mess would have been avoided.

Lessons learned:

* Follow the directions from the start. Once you've discovered you've skipped a step (by not installing all the options at the database tier, or by having disjointed domain server names), realize that you might have to start over. Try the install first, but be prepared to start over.

* This domain name requirement is a pain in the neck. If you understand Active Directory and domains, no problems for you I guess. But if you're like me and don't, be prepared to learn some new things.

* The install instructions may not be enough. Find someone who has installed it already and written about it on their blog. Blogs make good adjuncts to the official documentation.

Whew! You should see the relief on my face today.

That's it. I'm starting over.

I could not convince the application server install to finish completely. Add to this the fact that I was now getting an error when trying to shutdown the database server, and an error when starting the application server. Time to start over.

This time, I am following the install instructions to the letter right from the start. That was my big mistake last time. I was forced to install certain things out of order. It possible that since I installed SQL Server 2005 before installing IIS, something just wasn't right.

So, I've now reinstalled the database server. Windows Server 2003, IIS, all critical Windows Updates, and SQL Server 2005. Easy as punch.

I am in the process of reinstalling the application server. I'll get the domain controller thing right from the start this time, so that might go a lot smoother.

Installing VSTS has not been easy. But at least progress is being made.

My first big hurdle was getting past the problem where the instructions said to configure ADAM using one set of port numbers, while my computer refused to do so. I solved that in my last VSTS post, by accepting my computers defaults and ignoring the instructions.

My second big hurdle came during the install of the application server (Team Foundation). If you'll recall, I am installing the application tier in a Virtual PC 2004 instance. I tried installing VSTF directly from the DVD. I tried it a couple of times, but each time it failed reading one of the files from the DVD. I tried accessing that file directly from Windows Explorer inside Virtual PC, and no luck.

My first suspect was the DVD (media) itself. I tried that DVD in a different computer and it worked. So it appears the DVD is fine.

So of course I then suspected the external DVD player I was using. So I downloaded and installed the latest firmware upgrades from the manufacturer and retried the install. No luck.

Now I realize that you can “Capture an ISO” and use it as a drive image. So I tried buring this DVD to ISO. No luck - Virtual PC did not recognize it as a valid ISO.

Finally, I just XCOPY'ed the files into a shared folder. That worked.

It turns out, from this Ask Burton blog entry, that Virtual PC does not support DVD's over 2GB. What? Well, several hours of my life lost for nothing.

That problem solved, I am now facing my third major hurdle. This time, I am really getting frustrated. The install goes all the way to the end, apparently creates a bunch of databases, and then dies with a mysterious 26201 and 26204 errors. Ask Burton again has some hints.

My problem is that the database tier almost completely installs. So I know we have connectivity, the database is running, app server has rights to the database, etc. Ugh. I am painstakingly cleaning the DB server up after each attempt.

I think I might finally worked past the SQL DB issues, but I am not sure. The last time I ran the install, it completed everything and then did a rollback on its own. I'll give it one last try tonight.