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, Aug 22, 2003, 4:28 PM
Managed Version of Microsoft's Solitaire
Here. Christine Morin, a fellow Microsoft employee, came to my rescue when I went looking for a sol.exe implementation (I love working at Microsoft...). I found the original C implementation (which can still compile for 16 or 32 bits!) and hers, the very nicely done WinForms version (from scratch!). Christine's implementation is not quite perfect yet, but it's very, very close. I did some coding on it and then talked her into opening the source up in a GotDotNet Workspace. The project has two goals: 1. Perfectly recreating sol.exe in managed code 2. Separating the UI completely from the data The 1st goal is to provide homage to the world's most popular Windows application (!), although I've already violated it while keeping to the spirit (Undo needs a Ctrl+Z mapping!). The 2nd goal is to enable other UIs to be placed on top of the sol.exe data model for future versions of Windows which may or may not have amazing new UI capabilities (and which may or may not be discussed in glowing details at the PDC [1]) and about which I may or may not be writing about in the future (vague enough? : ). Got some time? Instead of firing up the existing sol.exe, help us finish our .NET version! [1] http://msdn.com/pdc
Friday, Aug 22, 2003, 12:09 PM
The Coolest Web Site I've Ever Seen
Here. I love the mix of media on this site. It's what the web should be.
Thursday, Aug 21, 2003, 3:51 PM in The Spout
The .NET Show: Managed Code
Here. "Joining us in this episode will be Brad Abrams and Anders Hejlsberg to discuss the overall architectural issues involved with Managed Code, as well as Nick Hoddap and Chris Sells to show us some of the programming benefits that are gained by using Managed Code."
Thursday, Aug 21, 2003, 3:36 PM in The Spout
VS.NET 2003 + Mastering VS.NET
Here. Buy VS.NET 2003 on Amazon.com and get a special deal on Mastering Visual Studio .NET by Ian Griffiths, Jon Flanders and some other guy...
Wednesday, Aug 20, 2003, 2:03 PM in .NET
Permutations in .NET
Here. Dr. James McCaffrey provides a nice introduction to "permutations" along with some .NET to generate them. He further goes on to use permutations for security purposes, but that's not all they're good for.
Wednesday, Aug 20, 2003, 11:11 AM
More Fun With CodeDOM
Here. In a recent debate over writing the n very similar algorithms by hand (one for each number of inputs) vs. writing a data-driven algorithm to handle any number of inputs, Peter takes the middle route using the .NET CodeDOM to generate the simple algorithm for the required number of inputs at run-time. What makes this interesting isn't the result, which didn't turn out to be the most efficient, but the approach itself, which is unique to metadata-enabled systems and something I completely forgot even existed. Thanks for the reminder, Peter!
Wednesday, Aug 20, 2003, 10:31 AM
Startup, Shutdown & related matters
Here. Apparently cbrumme was backed up after two weeks fighting the blaster virus internally, because he lets loose with a tour de force of details about managed and unmanaged startup and shutdown as well as a trailer on writing secure code in general. Fun to read if you like this level of detail (and the part about secure code at the end should be read by everyone).
Wednesday, Aug 20, 2003, 8:45 AM
PowerPoint Is Evil (Not!)
Here. I've seen this kind of argument before, blaming presentation software (or PowerPoint specifically) for making people stupid. If PPT didn't allow you to make intelligent presentations, then I'd be all for panning it, but that's not true. PowerPoint can be used for good or for evil, but it's only a tool; it's the presenter that decides the use to which the tool is put.
Wednesday, Aug 20, 2003, 8:40 AM
How much is your brain worth?
Here. ShawnMor documents his hangover from a hd crash w/o a recent backup, collecting backup schemes from contributors to avoid this problem in the future. I wonder how users that don't program computers for a living deal with this problem if we have trouble?
Tuesday, Aug 19, 2003, 2:28 PM
Career Calculus
Here. There's just so much good advise in this post and it covers so much ground that I can't even think of a clever summary. Just go read it.
Tuesday, Aug 19, 2003, 1:37 PM in .NET
Buffering .NET Console Output
Here. The one where I can't believe that .NET Console output isn't buffered by default, then come to appreciate why they did it that way and finally figure out how to turn buffering back on at will, keeping the best of all worlds.
Tuesday, Aug 19, 2003, 11:49 AM
Not Missing Duff's Device
Here. This isn't new, but the wacky C/C++ Duff's Device came up again in my circles. I really don't miss using a language that allows such things. Thank you for C#, Anders.
Tuesday, Aug 19, 2003, 12:00 AM in The Spout
Buffering .NET Console Output
Doing some ad hoc benchmarks, I found that my compute/IO intensive program was significantly slower in .NET than in native C++ (here's a more rigorous test showing the same thing). However, when the IO was taken out (Console.Write), the test showed that the computation in .NET and in native C++ was nearly the same (with C++ still having a slight edge).
My .NET IO code looked like this:
static
void OutputIt(int[] vect) {
for (int i = 0; i < vect.Length; ++i) {
if( i > 0 ) Console.Write(",");
Console.Write(vect[i]);
}
Console.WriteLine();
}
In tracking down this disparity, Courteney van den Berg noticed that, unlike STL IO streams in native C++, .NET Console output is not buffered. A simple manual buffering using a StringBuilder brings the performance of .NET back in line with native C++:
static
void OutputIt(int[] vect) {
StringBuilder sb = new StringBuilder();
for (int i = 0; i < vect.Length; ++i) {
if( i > 0 ) sb.Append(",");
sb.Append(vect[i]);
}
Console.WriteLine(sb);
}
Instead of buffering manually, I could have turned on buffered console IO by reopening console output with a buffer size:
static
void Main(string[] args) {
using( StreamWriter bufferOutput = new
StreamWriter(Console.OpenStandardOutput(1024)) ) {
Console.SetOut(bufferOutput);
//
Use Console.Write (via OutputIt)...
}
// Remaining buffered Console output flushed
}
//
Console output now buffered
static
void OutputIt(int[] vect) {
for (int i = 0; i < vect.Length; ++i) {
if( i > 0 ) Console.Write(",");
Console.Write(vect[i]);
}
Console.WriteLine();
}
Why isn't Console output buffered by default? Unlike in C++, which has deterministic finalization, in .NET, console output would have to be manually flushed or closed (closing causes a flush). Failure to do so can cause console output to be incomplete at the end of a program. Notice our careful use of the "using" block in the code above, causing the output stream to be closed at the end of the block and the remaining buffered output to be flushed, even in the face of exceptions. Forgetting to use the "using" block or forgetting to manually flush or close in a finally block, can cause console output to be lost. Rather than imposing the new burden of manually closing the console output, .NET architects opted to turn off buffering by default, while still letting you turn it on at will.
Monday, Aug 18, 2003, 10:15 PM
Protect Your Friends' & Families' PCs
Here. Nobody reading this site needs any help protecting themselves from the blaster virus or any other kind, but those of you with families and friends having trouble, point them at Microsoft's Protect your PC site.
Monday, Aug 18, 2003, 3:24 PM
Microsoft Programming Languages
Here. Prashant Sridharan, a Senior Product Manager at Microsoft, details the uniqueness of VB.NET, C#, C++ and J# to help you pick the right tool for the right job.