You've reached the internet home of Chris Sells, who has a long history as a contributing member of the Windows developer community. He enjoys long walks on the beach and various computer technologies.
Thursday, Mar 18, 2004, 3:08 PM in .NET
WinFS 101: Introducing the New Windows File System
Thomas Rizzo, Director (!) on the SQL Server Product Management team, kicks off his WinFS column with an overview of why we need it and what it is. I always love the first piece in any column, as it sets the grounding information for what readers are going to need to understand reading future pieces. I especially love them from internal folks, as it really gives a flavor of what the product team (WinFS, in this case), had in mind that drove them to build their thing the way they did. Check it out.
Thursday, Mar 18, 2004, 11:02 AM in The Spout
Quick Review of 4 California Theme Parks
Just flew in from California... and boy are my arms tired! <shot area="rim" />
We did 4 California theme parks in 4 days and here's what I thought:
- Magic Mountain: great rides, but even before spring break, the best rides had waits of 2-3 hours, so we didn't get to go on them (although Scream rocked). Also, the price gouging was gratuitous, including $3 for a soda, $.87 for a packet of ranch dressing and extra money for a bunch of the activities after paying to get into the park, e.g. virtual reality ride and rock climbing. Over all, thumbs down.
- Disney's California Adventure: Surprisingly good. The production values are high, even making the waiting as fun as possible, just like in every Disney park. The Bugs Life "it's hard to be a bug" show was hilarious and the Soarin' Over California ride took my breath away. Plus, all of the rides that had analogs in Magic Mountain were better at California Adventure. This was the winner of the trip. Thumbs up.
- San Diego Sea World: The day was a little overcast and their major ride wasn't running, but the shows were fun and it was a nice, mellow experience after two intense days. Also, the food was noticeably better than the other parks (although $50 on lunch for 4 was a bit much). More on the meal front: I called Don on the road between Sea World and the hotel in LA and he recommended In-n-Out Burger, which none of us had ever had before. My oldest son mentioned that meal more than Sea World, so both get a thumbs up.
- Disneyland: This park needs an overhaul. Their one really good ride, Indiana Jones, was closed and all of the rest of the rides were only interesting for the nostalgia factor (plus they broke down a lot). When I brought my 4-5 year olds here 4 years ago, it was really great to see the place again through their eyes. Now that they're older, the place holds no attraction for me. Thumbs down.
Over all the trip was a thumbs up if for no other reason than I was without my laptop for 4 days and didn't really miss it. Then I come home to find that you dang kids have TP'd my blog! : )
Thursday, Mar 18, 2004, 10:38 AM
Hey! You Kids Get Outta My Yard!
Here. Kids got no respect these days... : )
Sunday, Mar 14, 2004, 4:14 AM
Radio Silence
The one where the Sells brothers, the wife and I tackle 4 California theme parks in 4 days and Chris leaves his laptop behind.
Saturday, Mar 13, 2004, 7:41 AM in .NET
Chat with the VC++ Team about Longhorn on Monday
Here. If you're a C++ programmer and have questions or concerns about where C++ is going in Longhorn, you need to be at this chat on Monday, 3/15 from 11a - 12:30p PST.
Friday, Mar 12, 2004, 5:24 PM in .NET
Thumbs Up for Longhorn Security Lockdown
I'm just happy to see security + Windows = good for a change. : )
Friday, Mar 12, 2004, 5:19 PM
We're Rebuilding MSDN and We Need You!
We're busy rebuilding the MSDN infrastructure for the next decade (the one we've lived on for the last decade is getting pretty creaky) and we need a testing lead! Don't be shy! Apply today!
Friday, Mar 12, 2004, 4:57 PM in .NET
Indigo Lingo: Digging Into Channel Types
Yasser Shohoud digs into Indigo even further, this month using "channels" to build different kinds of message exchange patterns into your applications, including one-way, duplex (incoming and outgoing messages on different ports) and request/reply, as well as adding reliability.
Friday, Mar 12, 2004, 6:35 AM in .NET
What is WOW64 and How Does It Relate to .NET?
Here.
Josh Williams, an SDE on the CLR team, kicks off his 64-bit blog with an introduction to WOW64 and what it means for .NET programmers. Here's the summary:
- WOW64 isn’t the OS per se, but a subset of the Win64 OS which enables a 32bit application to run inside of a 32bit process on a 64bit OS while using 32bit system dlls and such.
- Whidbey CLR will include both 32bit and 64bit versions, both of which will be installed on 64bit machines. This allows both 32bit and 64bit managed applications to run in bitness correct native process depending on how the assemblies are tagged at compile time.
- Once a process is started up as either 32bit or 64bit all of the dlls/assemblies that are loaded into that process have to be compatible with that bitness.
- If you have a 32bit managed app which has dependencies on 32bit unmanaged code then you’ll need to either find a 64bit version of the unmanaged code or tag your managed app as x86 at compile time to make sure that you don’t float up to a native 64bit process. This will result in you having to live with your process running under the WOW64.
Thursday, Mar 11, 2004, 8:08 AM
Avoid the GAC (and Check My Reasoning)
Here.
The one where I can only come up with two reasons for using the GAC, the first being very difficult to pull off correctly and the second to happen more and more rarely as we move to SOA and .NET.
This post feels very much like "Why do we still need duals?" so if you've got a reason for using the GAC that I didn't list, by all means, let me know!
Thursday, Mar 11, 2004, 12:00 AM in The Spout
Avoid the GAC
Thursday, March 11th, 2004
The .NET Global Assembly Cache (GAC) is a misunderstood and misused beast. For all intents and purposes, it provides what COM and windows\system32 do, i.e. a machine-wide place to drop shared DLLs. Of course, the problems with sharing DLLs in a machine-wide spot is that it leads to a set of well-known problems collectively called "DLL Hell." There are many problems, but the biggest is that when a shared DLL is updated, you're really updating an unknown set of applications. If the set of applications is unknown, how can you possible test them before making this change? And if you can't test them, you're likely to break them. What this boils down to is that any of the shared spots for updates, whether it's a COM CLSID, windows\system32 or the GAC, are dangerous and should be avoided. And this is why the preferred .NET deployment scenario is "xcopy deployment," i.e. having your own private copy of each DLL that you test and deploy with the rest of your application.
"Aha!" you say. "The GAC supports multiple version of an assembly! When a foo.dll is updated to v1.1, v1.0 sits right along side of it so that your app *doesn't* break!" Of course, that's absolutely true. But if that's the case, why do you care? I mean, if there's a new assembly available but your app isn't picking it up, what difference does it make?
"Aha again!, you say. "I can put a publisher policy into the GAC along with my assembly so that apps *are* updated automatically!" That's true, too, but now, like any of the machine-wide code replacement strategies of old, you're on the hook for an awesome responsibility: making sure that as close to 0% of apps, known to you or not, don't break. This is an awesome responsibility and one that takes MS hundreds of man-years at each new release of the .NET Framework. And even with those hundreds of man-years of testing, we still don't always get it right. If this is a testing responsibility that you're willing to live with, I admire you. Personally, I don't have the moral fortitude to shoulder this burden. For example, we do sign genghis.dll when we ship it so that folks can put it into the GAC if they want, but we make no promise of backwards compatibility between versions and therefore we do not ship publisher policy DLLs. Instead, we expect folks to use xcopy deployment and catch the problems at compile-time and test-time.
So, if the GAC represents such a massive burden, why do we even have it? It's for two things that I've been able to identify:
Fixing critical bugs without touching the affected apps (and without breaking anything!)
Sharing types at run-time between assemblies deployed separately
#1 is what you get when you install Windows hot fixes and service packs via Windows Update. A ton of design, implementation and testing time is spent to make sure that existing code won't break before shipping these fixes.
#2 is needed if you're going to be sharing types between assemblies that you can't deploy as a group but absolutely must keep to the same version of things. .NET Remoting peers are in this category, but only if they're deployed in separate directories so that they won't share the same set of types available via xcopy deployment. However, if .NET Remoting peers are deployed on difference machines, the GAC won't help you anyway as you'll be manually insuring the types are the same across machines. BTW, the responsibility of keeping multiple machines to the same set of types (and the same framework for hosting those types) spawned an entirely new way to talk between machines, i.e. web services, so .NET Remoting itself is something to avoid unless you can administer both ends of the pipe for simultaneous updates.
Another scenario that fits into #2 is the Primary Interop Assembly (PIA). A PIA is a COM interop assembly that's been pre-generated and dropped into the GAC so that everyone that adds a reference in VS.NET to mso.dll (the COM library for Office) gets office.dll instead (the .NET Office PIA). That way, everyone can talk to the same set of types instead of everyone getting their own incompatible interop types generated on the fly. However, PIAs are primarily a way to make sure that VS.NET has a central place to pick up the shared types without regenerating new incompatible types.
Notice that "Saving hard drive space" wasn't on my list of reasons to use the GAC. I just purchased a 60GB, 7200RPM hard drive for my laptop for a measly coupla hundred bucks. I don't want to hear about you jeopardizing the reliability of the applications on my machine to save a tiny percentage of that space. Hell, when I buy a HD, I give 50% of it over to apps anyway, so help yourself and keep my apps running by avoiding any machine-wide space for updating shared DLLs, including the GAC! Thanks.
Discuss (did I miss any reasons to use the GAC?)
Wednesday, Mar 10, 2004, 4:57 PM in .NET
Interview: Longhorn User Experience Gurus, part 2
Paul Thurrott finishes his 2-part series of interviews of Hillel Cooperman and Tjeerd Hoek, Longhorn User Experience mavens. The interview covers just how hard it is to make an entire OS usable and just how much work MS does to get it right.
However, one thing that Hillel said struck me particularly as someone fairly new to working at MS:
"Actually, that was the shocking thing about coming here: The problems weren't simple. The number of people that I met who were humble, that cared deeply and passionately about making the user experience better for customers and weren't just saying, 'Hey, here's a new API'--not that I don't love a new API--was surprising. These people were really deeply concerned about how they could make customers' lives better and had thought a lot about this, way more than I had. I was blown away. I just couldn't believe it."
That's exactly how I felt coming to MS. We have a PR problem, but we definately do not have a care-about-the-customer problem.
Wednesday, Mar 10, 2004, 4:48 PM in .NET
Paul Thurrott's Longhorn Activity Center
Paul Thurrott is more of a user guy then a developer guy, but you have to be a user before you can be a developer, and his stuff is often interesting. Now he's created a spot on his site to gather his Longhorn content. My only question: where's the dang RSS feed?!?
Wednesday, Mar 10, 2004, 4:12 PM in .NET
Avalon vs. Quartz Extreme
If you read Ian's article on Avalon Graphics Composition before the fireworks, you missed a wonderful discussion of how Avalon compares with Apple's Quartz and Quartz Extreme. Not only does Ian respond to the ever popular "Doesn't Mac OS X already do today what Longhorn will do tomorrow?" with a resounding "No!" but he does it in such a thorough manner, that you can't help be admire it.
You go, Ian! : )
Wednesday, Mar 10, 2004, 11:24 AM in The Spout
WinForms Programming in C# 3rd Printing Ships
Here.
I find it unbelievable that after umpteen books, I finally seem to have blended quality with quantity as the C# version of my WinForms book enters it's 3rd printing after only 8 months in publication. Wahoo!