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.
Friday, Jan 9, 2004, 9:16 PM
Pentium Run at Over 5GHz
Here.
Tom's Hardware is hosting a video of a guy moving heaven, earth and liquid nitrogen to get his PC over 5GHz. I don't know the right term, but the arrangement of the shots and the music made me laugh all the way through. And the ending is worth sticking around for. : )
BTW, I'm sure I overhyped this so you won't enjoy it like I did, but that's OK; I'm posting this with a smile. : )
Friday, Jan 9, 2004, 4:54 PM in .NET
MSDN TV: Introducing ClickOnce
ClickOnce is the install-on-demand technology for Longhorn, but makes it's debut in the next version of the .NET Framework, codename "Whidbey." Hear Jamie Cool from the Windows Forms team introduce the technology he first built in prototype form as the AppUpdater Component.
Friday, Jan 9, 2004, 3:57 PM in Tools
My First .NET Tool Gets An Update
Here.
Given Aaron's wonderful set of .NET XML tools, I don't know why Tony Malandain found my little xmlValid tool for checking XML well-formedness and schema validness, but he did and then added the ability to take XML input from stdin (he apparently uses it to check compressed SVG files).
What makes this kind of unusual is that I built this tool almost 2.5 years ago. In fact, it was the first .NET tool I posted on my site. Before that, it was all C++ and COM, although almost none of that has gone up since. It was kind of fun digging into that code again. I spent a bunch of time rearranging it to map more closely to my current .NET coding style not because it added any more functionality but because I couldn't stand not to. This developer thing is just a sickness, isn't it? : )
Friday, Jan 9, 2004, 3:43 PM in The Spout
Surprised by Microsoft's Openness
Here. The one where even I'm surprised at how open Microsoft is willing to be.
Friday, Jan 9, 2004, 11:24 AM
New Home for Many MS Bloggers
Don't have enough bloggers to listen to? Can't find your favorite MS blogger? Chances are that you'll find a bunch of interesting tidbits at the new MSDN blogger site.
Friday, Jan 9, 2004, 10:35 AM in .NET
Developers Shrug Off Longhorn Delay Rumors
Here.
<whew> : )
Friday, Jan 9, 2004, 12:00 AM in The Spout
Surprised by Microsoft's Openness
Friday, January 9th, 2004
I get a lot of emails from folks surprised about how open Microsoft is being lately, mostly due to all of the blogging we've been doing lately (some of us started long before we ever became employees). However, even I was surprised in an internal blogging meeting today filled with a bunch of MS bloggers. During the meeting, we talked about a bunch of the benefits to MS and to our customers. Sara talked about how blogs are driving more traffic to MSDN than our own headlines. Robert described his "green, yellow, red" scale for determining whether to blog about something (believe it or not, he does decide not to sometimes : ).
And then Adam Sohn from marketing talked about the need to police ourselves, describing some of the downsides in regards to blowing some group's launch plans or unconstructively criticizing another group. He preached caution when approaching the line between what was good for the customer and what was good for Microsoft. After listening to what I began to interpret as a message of self-censorship, I asked Adam a warm up, "Isn't it true that a lot of the stuff close to the 'line' is what our customers find most valuable?" He agreed that it was. And then I asked Adam my real question, "So, when we get close to that line, do we err on the side of our customer or ourselves?"
Now, you have to remember that I've been a contributing member of the Windows development community for a lot of years. I've seen how aggressive Microsoft is in everything it does to always be on top. So when I asked on what side of the line I should come down, I fully expected to be told to keep the shareholders in mind.
Of course, you know what his answer was or this story wouldn't have made it into my blog until after my tenure at MS was complete (or just before : ). He said, without hesitation, "Err on the side of the customer."
That blew me away. Of course, I've been doing just that since before I became an MS employee and Robert rides the ragged edge all day long, but it was *very* nice to hear that guy with the PR and legal battle scars tell me to keep the customer first and foremost in my mind.
Thanks, Adam. You've confirmed my decision to work at Microsoft.
Wednesday, Jan 7, 2004, 10:50 AM in .NET
Vector Graphics & Declarative Animation w/ Avalon
Don "XML" shows how to use graphic primitives and animation declaratively in Avalon, building an analog clock in the process. Cool!
Wednesday, Jan 7, 2004, 10:37 AM
Stereolize Pumps Up Presentations
Not only does Longhorn intimidate me by removing my safe, comfortable barriers to building difficult applications, Stereolize does the same for presentations, but seems to require a music composer as well as a graphic designer. Yikes!
Tuesday, Jan 6, 2004, 8:33 AM in .NET
Breaking the Mental Logjam
Here.
As I've mentioned, one of the biggest problems I see with Longhorn is deciding exactly what to do with all of the new capabilities. So, when Carter Maslan showed me some internal training videos showing off some uses of Longhorn in potential real-world applications, I just knew we had to get them out to the world.
The first such "concept video" is centered around commercial real estate (available at 320x240 and 640x480) and Carter's got more planned in other industries, including manufacturing, telecom, financial services and more. The goal is to help break the mental logjam around how we build Windows and web applications today to get folks thinking about the possibilities that Longhorn provides. Enjoy.
Monday, Jan 5, 2004, 11:13 AM in .NET
Don Box on .NET Rocks!
Here. I haven't heard this yet, but I just know it'll be fun. Once you get Don started talking, it's hard for me to stop and interesting things almost always pop out. : )
Saturday, Jan 3, 2004, 4:23 PM in .NET
On Genghis, WinForms and Moving Towards Avalon
Here. Inspired by my pending interview of Don Box, Paolo Severini sent along an interview for me on Genghis, WinForms and how to move towards Avalon (although not in that order). The questions were so good, I thought I'd share them. Thanks, Paola!
Saturday, Jan 3, 2004, 3:20 PM in .NET
WinFS: Stamping out the Roach Motel
For those of you unfamiliar with Don's reference, a "roach motel" lets roaches in, but never lets them out. That's exactly what most apps do today, i.e. take data in from users or import routines, but never let it out again. As Don states, one of the chief benefits of WinFS is that data that apps store in it will be available to other apps, thereby letting the roaches out of the hotel. Where Don's analogy breaks down is that in the case of application data, letting the roaches back out of the hotel is actually a good thing. : )
Saturday, Jan 3, 2004, 12:00 AM in The Spout
On Genghis, WinForms and How to Move Towards Avalon
Saturday, January 3rd, 2004
Inspired by my pending interview of Don Box, Paolo Severini sent along an interview for me.
Paul: Being a faithful reader of your books, articles and of your blog, I'd like to ask you a few questions about LH, Avalon and the future of WinForms. Before all, let me say that I'm really fascinated by Longhorn, and especially by Avalon. I installed the PDC stuff as soon as I received it through my MSDN subscription and I've begun exploring it with "pure geek" enthusiasm. Everything is extremely interesting, but I'm now not sure what to do with it.
Chris: I know what you mean, Paul. I'm going through that myself. Suddenly having so many fewer barriers tends to throw off the engineer in me. I'm working through it by begging the Longhorn User Experience team for guidance, learning Adobe Illustrator, reading graphic design books and trying to open my mind to the graphic designer inside us all (I hope : ).
Paul: Paraphrasing one of the questions you proposed to Don Box: what should a WinForms programmer *really* do today to prepare for Avalon?
Chris: If you want to write code today
that'll work well on Longhorn tomorrow, write WinForms today. WinForms in
Whidbey gets tons more features and I expect they'll be some cool new
Longhorn-specific stuff when the time is right. If, when you're preparing a
Longhorn version of your application, you'd like to host Avalon controls from
your WinForms app or even build Avalon apps that host your WinForms controls,
you'll be able to do that in Longhorn via WinForms/Avalon interop.
For
maximum flexibility in the code you write now, be very thorough about separating
the data from the view of the data so that you can write a 100% Avalon front end
to replace your WinForms front end if such is your need. Likewise, be very
thorough about separating the data from the storage of the data is that you can
take advantage of WinFS.
Paul: I'm very grateful to MS for having
disclosed their future technologies so soon, and more generally, to have become
so "opened" to outsider's eyes, with so many devs and PMs now blogging about
their work.
Chris: Me, too. Without this openness, I'd get into lots more trouble. : )
Paul: But I somehow also think that maybe LH was presented a bit too soon. Since it's not planned to be released before 2006, chances are that the shipped version could be significantly different. (Will it? Is it already? Can you write anything about that? :-).
Chris: I used
to think that we were unveiling Longhorn too soon, too. However, the later in
the development process we get it out to reviewers, the fewer major changes
we'll be able to make based of your feedback. What that means, of course, is
that some major things are going to change between now and release, but those
changes will be based on decisions that include feedback from you. The downside
is that you'll have to relearn some of the things you learn with these bits.
Hopefully, the upside is that most of what you have to unlearn will be replaced
with something significantly better.
Paul: Furthermore, even when the
new presentation subsystem will ship, it seems like it won't be easy to write
code that supports both the new and the old platforms, being they so different,
and that could slow down its widespread acceptance even more. So I'm afraid that
we'll all have a difficult time writing user interfaces, having to decide
whether to take advantage of the new features or simply stay with the old
portable libraries. After all, there are today still (too many) people running
Windows 9x. And Windows XP is such a great OS that won't universally be replaced
so soon.
Chris: I've already mentioned how well WinForms will work under Longhorn, so I think I've answered part of your question. However, you're asking something deeper here, i.e. when do I give up the old "way" that has more ubiquitous support for the new "way?" In this case, you're talking about .NET and Longhorn, but you could as easily be talking about DOS and Windows or Win32 and .NET. This is the eternal struggle and the reason that we need software engineers in the first place. As with all such questions, the answer is "it depends."
My general purpose answer is to always pick the newest thing that meets my requirements. The newer the technology you pick, the longer the shelf life. Can I build cool, scalable apps that take advantage of the high resolution monitors and GPUs of tomorrow in DOS? Absolutely. Do I want to? Hell no. Can I do it in WinForms? Yes, although it'll still be harder than doing it on Avalon. Will I increase my available market by targeting DOS today? The answer used to be "yes," but for a while now it's been "no." What about WinForms? The answer is definitely "yes" today and will be for a while yet, even after Longhorn ships.
The answer to the question of when to adopt new
technology has too many variables for me to provide any general advice better
than "as soon as possible." Of course, Microsoft wants the answer to that
question to be "sooner rather than later," and we're working to make Longhorn
kick-ass for developers, business users and consumers so that ubiquity is taken
out of the equation as soon as possible. Please use all channels of
communication you have into the company to help us make sure we're doing that.
The WinFX newsgroups are one good place for such feedback. They are heavily
monitored by all of the WinFX teams and the Longhorn User Experience (Aero)
Team.
Paul: I found out that the PDC build of Avalon doesn't really
work in kernel mode but simply uses two (unmanaged) DLLs, milcore and milrender
built upon the old GDI APIs (to the point that it is actually possible to run
Avalon on XP). Of course, that's bound to change, as Chris Anderson wrote, with
the new video driver model and when the desktop composition stuff will get
turned on. But wouldn't it be nice if a subset of Avalon ran on XP? After all,
not every app will take advantage of its more advanced features.
Chris: Before I answer this question, I just wanted to point out that GDI is not part of the Avalon rendering path. Instead, Avalon is built on DirectX, which is built directly on the drivers. GDI is still supported, of course, but it's a parallel rending path to Avalon's.
The answer to the core question, i.e. why not ship Avalon on XP, is one of resources. Chris Anderson once told me that something like a man millennia has gone into the development of Avalon thus far. Even if Chris was exaggerating for effect, that's still one hell of a lot of work. That work has gone into building an architecture that allows application developers to take advantage of features present all the way down to the hardware level, including changes at every point in the presentation stack. What kind of work do you think it would take to make a subset of that available under Windows XP? Or Windows 2000? Or Windows 98? What kind of work do you think it would take to support those features on those down-level operating systems in their subsetted states? If we're looking at a release years into the future already, how many more years are we willing to wait to release Avalon in a form that works in a subsetted form on those OSes? And what will we ship to our customers expected a new OS in the meantime?
It may be that you could come up with answers that you love to these questions. Would our other customers answer them the same way? Would our shareholders answer them the same way? Would your answers best position us against our competitors?
Even if you got a subset of Avalon that works across .NET platforms today, would it really enable you to be more successful at your business or is it an engineering "gosh that'd be neat?"
I know that our product teams really listen to our customers these days, so if you've got specific scenarios that you need enabled to be successful, please let them know.
Paul: Furthermore, if XAML is, in the end, only a way to glue together a graph of CLR objects, why don't use it also to build WinForms UI? Both these options would make the transition much easier.
Now that's a question I can provide a more satisfactory answer to, I think
(sorry about that last answer : ). In the Longhorn PDC bits today,
you can generate WinForms apps using XAML for the very reason you state.
Likewise, if you'd like to try a subset of XAML in today's version of the .NET
Framework, there are not one,
but two 3rd parties providing
early access to projects to allow this to happen. Given the amount of work that
has gone into, and will go into, getting Avalon out the door, I doubt very much
that their versions of XAML will be full-featured, but it may help ease the
transition, as you say.
Paul: That brings me to ask you about the
future of WinForms (about which I'm now reading your book and really enjoying
it). In the near future I will surely have to write WinForms code. But is it
still worthwhile to spend time studying and trying to improve it? (I personally
think so). Or should I rather concentrate my interest learning everything about
the new LH technologies? So I'm back on the question about how to prepare for
Avalon...
Chris: I'd say that it absolutely makes sense to continue to
write WinForms applications for years to come. Not only in WinForms a great
platform for client applications today, but in Whidbey, it about doubles in size
and capability. Plus, WinForms applications will continue to work great under
Longhorn and will form the core of an application that needs to take advantage
of Longhorn features under Longhorn but continue to work on the rest of the .NET
platform. Unless you are planning to target only Longhorn, WinForms is
absolutely where you should be spending your client development effort today
and for years to come.
Paul: Speaking of WinForms, one of the things
I've never liked is the absence of windowless controls. It has been said that
windowed and windowless controls are difficult to make live together, and that's
true. But windowless controls are sometimes very useful (and cool! just think to
the Windows Media Player UI). I found in your Genghis page that the "Windowless
control architecture" feature is still "opened" and I'd like to try to work on
it. (In the past, I wrote an ActiveX control container that supported windowless
controls, so I wouldn't start from zero).
Chris: Windowless controls
were meant mostly as an optimization when creating thousands of Window handles
brought the platform to its knees. Some folks also used windowless controls as a
good way to fake non-rectangular controls. In modern implementations of User32,
neither is much of an issue, so windowless controls provide a service that is no
longer required in most cases. In the specialized cases where it is still
necessary, I find that building an aggregate control that does the drawing of
multiple controls that you would have made windowless in the past solves most of
my needs in this area, although your mileage may vary. Given that Genghis has
most of the rest of the features that I wanted for it, but no windowless control
architecture, I'd say that folks seem to agree with me that windowless controls
are no longer as important as they once were.
Paul: But I also noticed
that the Genghis project has been still for a few months, so I'm now wondering
if it is still alive and if my project still makes sense now that Avalon is on
its way. May you give me an advice?
Chris: I was waiting for a wizard that would generate MDI, SDI and multi-SDI applications before shipping the next drop of Genghis, but there are enough new things and fixes that we should have another version of Genghis out in a week or so. If you or anyone would like to build the wizard (or just send Scott Densmore email begging him to finish the one he already started and has promised to me several times) that'd be great.
Thanks for your wonderful job and for the time you dedicated to this mail. I just hope my English was understandable... :-)
Best regards from Italy,
Have
a wonderful new year!
--Paolo Severini
Friday, Jan 2, 2004, 1:20 PM in Tools
ImCli Classes Updated for MSNP8
Here.
Plenty of folks have asked for updates to my IM client classes to support the new MSNP8 protocol, but only Robert M. Wagner Jr. made the changes and sent them to me. Thanks, Robert!