DVD Ripping and Nero Recode

Steve Makofsky turned me on to some software I already use: Nero Burning ROM, but more specifically, Nero Recode 2, which is a part of their expanded "ultra" Nero suite. I've long considered Nero the definitive DVD and CD burning software; I had no idea they also offered a DVD ripping solution.

Quick clarification: by DVD rip, I mean re-encoding a MPEG2 DVD using some variant of the MPEG4 video and audio codecs. The goal is to reduce the file size without losing (too much) quality. For example, you may start with ~9gb of raw, decrypted DVD data, and end up with a 700mb .avi file that has DVD-like video and sound quality. I know it sounds implausible, but I can tell you from personal experience that it works, because MPEG4 is a more modern and efficient codec than MPEG2. The tradeoff is higher CPU decoding requirements (rarely an issue on any remotely modern PC), and a lot of re-encoding time.

I've used XMPEG (freeware) and Dr. DivX (payware) to rip DVDs before with somewhat.. unreliable results. Both apps crashed on me fairly regularly, and both apps required too many tedious, trial-and-error trips into obscure options and settings dialogs. In comparison, I just ripped about 10 different DVDs with Nero Recode and it's been a painless point and click operation every single time-- without a single crash! And my god, the speed! Recode produces encoding framerates of nearly 90fps*; the peak encodng rate of Dr. Divx or XMPEG was ~50fps. This is a huge time savings when you're encoding a 2 hour movie!

But don't take my word for it. The experts at CDFreaks loved Nero Recode. When compared to the DivX and XVid encoders, Nero Recode was..

• by far the easiest and most automatic encoder to use
• 5x faster (single pass)
• delivered superior video quality

Ripping to MPEG4 is what I'm most interested in, but Recode can do much more. If you want a fuller overview of the Nero Recode software, there's a good review at CDRInfo.

Now, there is one thing you should know about Nero Recode: it produces somewhat.. unusual.. MPEG4 video files, with a *.mp4 extension. All of the above packages technically produce MPEG4 output, but no DivX compatible decoder I found-- and I tried many-- could deal with the Nero Recode file format. Nero calls their format "Nero Digital", but it's really just advanced MPEG4. It defaults to multi-channel AAC encoded sound instead of your typical (less sophisticated) Dolby Digital or MP3 encoded sound. AAC is a part of the MPEG4 spec, but it's not widely used. Anyway, the upshot of all this is that you're forced to install the annoying Nero Showtime application on any PC you want to watch your *.mp4 files from. Not acceptable. We should be able to download a small set of decoders and watch our *.mp4 files in any application we want.

Unfortunately, Nero hasn't seen fit to distribute a standalone "Nero Digital" decoder, which is not exactly a great way to promote a new file format. As Steve helpfully pointed out, you can pay $7 for the 3ivx decoder which-- with a small registry modification-- enables playback of *.mp4 files in good old Windows Media Player:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\.mp4]
"PerceivedType"="video"
@="3ivx.mp4"
"Content Type"="video/mp4"

Paying $7 for a decoder irks me. As an alternative, you can download the full version of the K-Lite Codec Pack. No need to install every codec under the sun, unless you want to; just deselect everything except for the 3ivx video and sound decoders. That enables Nero Digital playback in WMP on my box.

Like Steve, I can't recommend the Nero Ultra suite highly enough. It truly is best of breed. The only reason to go with DivX is if you have a standalone device that understands the DivX MPEG4 format.

* On my Athlon FX-53. If you plan to encode video a lot, either be very patient, or buy the fastest P4 or Athlon system you can afford. Video encoding is one of the last great frontiers where PCs can never be fast enough.

Threading, Concurrency, and the Most Powerful Psychokinetic Explosive in the Universe

Back when I was writing for Tech Report, I had an epiphany: the future of CPU development had to be multiple cores on the same die. Even in 2001, a simple extrapolation of transistor counts versus time bore this out: what the heck are they going to do with those millions of transistors they can add to chips every year? Increase level two cache to twenty megabytes? Add to that the well known heat and scaling problems of Intel's "more Ghz, less work per Mhz" Pentium 4 architecture and you've got a recipe for both lower clocks and lots of transistors. When you can't go forward, go sideways: more CPUs on the same die.

Unfortunately, as Chris Sells points out, our current languages are extremely poorly suited for the kind of development necessary in a world where CPUs don't get faster:

Because CPU speeds have topped off recently even though I/O speeds continue to increase, Herb Sutter posits that the Moore's Law free performance lunch is over, i.e. no more getting faster software by waiting for the next gen of faster hardware. Instead, we'll have to write our apps to be a lot more concurrent to take advantage of hyper-threading, multi-core CPUs and multi-CPU machines if we want our apps to continue to run faster.

What this means to me is that we'll have to have much better language-level support for concurrent programming. What we have now sucks. Rocks. Hard.

Does it suck rocks? Hard? Rick Brewster recently wrote this about the threading code in Paint.NET:

[Algorithms for splitting rendering work between processors], as well as the thread synchronization that goes with the progressive effect rendering, is easily the most complex code in Paint.NET. It's worth it though because this gives us a huge performance boost when rendering effects.

You can make a very strong case that, as developers, we're pretty screwed if the only way to get more performance out of our apps is to make them heavily multithreaded. Writing software is hard enough as-is without adding a pinch of "the most complex code in our app" throughout.. your app. The best treatment of the perils of threading I've found is in Dan Appleman's book Moving to VB.NET: Strategies, Concepts, and Code:

In his classic science fiction novel The Stars My Destination, Alfred Bester describes a psychokinetic explosive called PyrE -- so powerful that a single grain of it can blow up a house. And all that is needed for it to blow up is for anyone to just think at it and want it to explode. The hero of the story has to decide whether to keep it locked up and secret or to spread it around the planet leaving the fate of the world in the hands and thoughts of every single person on earth.

Which brings us to multithreading.

It's a useful technology -- one that has the potential to improve your application's real (or perceived) performance. But it is the software equivalent of a nuclear device because if it is used incorrectly, it can blow up in your face. No -- worse than that -- used incorrectly, it can destroy your reputation and your business because it has nearly infinite potential to increase your testing and debugging costs.

Multithreading in VB.NET scares me more than any other new feature. And as is the case with a number of new .NET technologies, the reason for this has to do with human factors as much as with technology.

Several months before the .NET PDC preview,' I was doing a session with Bill Storage at a VBits conference. I asked the audience, which consisted of fairly experienced Visual Basic programmers, whether they wanted free threading in the next version of Visual Basic. Almost without exception, their hands quickly went up. I then asked how many of them actually understood what they were asking for. Only a few hands were raised and there were knowing smiles on the faces of those individuals.

I'm afraid of multithreading in VB.NET because Visual Basic programmers have little in their experience to prepare them for designing and debugging free-threaded applications VB6 provides enormous protection (along with severe limits) in its implementation of multithreading. The only way to use free threading safely is to understand it and to design your applications correctly.

Again, I stress, design your applications correctly. If your design is incorrect, it will be virtually impossible to patch up the problems later. And again, the potential cost to fix threading problems has no upper limit.

I've always felt that it's my responsibility as an author to not only teach technology but to put it into context and help readers choose the right technology to solve their problems. Because multithreading is such a serious issue, I've decided to take a somewhat unusual approach in teaching it. Instead of focusing on the benefits of multithreading and why you would want to use it, I'm going to start by doing my best to help you gain a healthy respect for the technology and the kinds of problems you will run into. Only towards the end of this chapter, once you understand how to use multithreading, will I discuss scenarios where it is advisable to use it.

This book is written for VB developers, however, I believe Dan's cautionary tale applies to virtually all developers currently working in Windows. Programming with threads is hard because:

• our current programming models don't deal with concurrency well
• most of the programming we do is linear in nature
• programmers have a hard time thinking in terms of events than can interrupt each other at any time

While threading can-- and should-- be made easier in .NET 2.0, I seriously doubt programmers can adapt to a concurrent world without deeper, more radical changes.

Spurious Pundit

Brad Wilson pointed out a new, interesting blog yesterday: Spurious Pundit.

On managing developers:

It's like you're asking them to hang a picture for you, but they've never done it before. You understand what you need done - the trick is getting them to do it. In fact, it's so obvious to you that there are constraints and expectations that you don't even think to explain. So you've got some junior guy working for you, and you say, "Go hang this picture over there. Let me know when you're done." It's obvious, right? How could he screw that up? Truth is, there are a whole lot of things he doesn't know that he'll need to learn before he can hang that picture. There are also a surprising number of things that you can overlook.

One way I've found effective is to start it together, pair programming style. This also implies the people managing the developers actually are developers themselves-- and that's the way it should be.

On bargaining:

Allow me a brief digression here. Technical staff actually operate in a different universe from the business side of the house. They're "reality-based" in the disparaging way that our current administration uses the term. Put simply, shit will either work or fail based on the properties of the observable universe. No amount of personal motivation or focus-group work will let a spare, obsolete PC handle a million page hits a day. There's math there. You can prove things.

On the business side of the house, to an alarming extent, believing things makes them true. If the sales guys are confident and self-assured, if they really believe that they're great salesmen and they have a great product, people will trust them and buy stuff from them. If the managers believe that the current project is destined for success, and can keep everyone enthusiastic and focused, it's much more likely to be successful. By contrast, once people start believing it's doomed, they don't work as effectively, maybe they leave, and the project fails. (This is that morale thing I mentioned earlier.) It's all unsettlingly self-referential.

These traits which managers and sales people need to be effective are actually bad for technical folks. Arrogance means you overlook things. You miss subtleties that you'd catch if you were more cautious. Two heads are always better than one; three or four better still. (Okay, yes, there's a limit to this.) But any technical solution will be better if you can put your ego aside and plunk your idea down in front of some other folks for a good, harsh critical review. Being able to sell them on it by force of personality doesn't make it better. Being aware of your own failings and limitations makes it better. Being able to let go of your proprietary defensiveness makes it better. Learning to value the people who will poke holes in your designs - the ones who are "not team players" - makes it better. A considerable amount of humility is called for here.

Only three posts so far, but excellent insights in each one. I'm looking forward to more punditry.

It Came From Planet Architecture

Coming from humble Visual Basic 3.0 beginnings, by way of AmigaBasic, AppleSoft Basic, and Coleco Adam SmartBasic, I didn't get a lot of exposure to formal programming practice.

One of the primary benefits of .NET is that it brings VB programmers into the fold-- we're now real programmers writing in a real language, using the same IDE as the C# and C++ guys. And like other real programmers, we are expected to use proper development patterns and practices, many of which were absorbed from the Java world. It's a great opportunity for the masses of VB.NET developers to improve their skills and become more productive. However, there is a dark, non-productive side to the patterns and practices brigade: something Joel Spolsky calls architecture astronauts.

It's a phenomenon I strongly associate with the Java world:

When you go too far up, abstraction-wise, you run out of oxygen. Sometimes smart thinkers just don't know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don't actually mean anything at all.

These are the people I call Architecture Astronauts. It's very hard to get them to write code or design programs, because they won't stop thinking about Architecture. They're astronauts because they are above the oxygen level, I don't know how they're breathing. They tend to work for really big companies that can afford to have lots of unproductive people with really advanced degrees that don't contribute to the bottom line.

Here's the key distinction between an architecture astronaut and a practical developer: when you're in the trenches proving your ideas by implementing them in real applications. The kind used by actual users. Christopher Baus articulates this best in doers vs. talkers:

Software isn't about methodologies, languages, or even operating systems. It is about working applications. At Adobe I would have learned the art of building massive applications that generate millions of dollars in revenue. Sure, PostScript wasn't the sexiest application, and it was written in old school C, but it performed a significant and useful task that thousands (if not millions) of people relied on to do their job. There could hardly be a better place to learn the skills of building commercial applications, no matter the tools that were employed at the time. I did learn an important lesson at ObjectSpace. A UML diagram can't push 500 pages per minute through a RIP.

There are two types of people in this industry. Talkers and Doers. ObjectSpace was a company of talkers. Adobe is a company of doers. Adobe took in $430 million in revenue last quarter. ObjectSpace is long bankrupt.

Patterns and practices are certainly good things, but they should always be framed in the context of a problem you're solving for the users. Don't succumb to the dark side.

Reducing Useless Clutter on Websites

From the Articles That Unintentionally Parody Themselves department:

In the last article we listed some of the seemingly good but superfluous elements with which Web designers clutter their sites. We covered:

• Counters
• Close, Bookmark and Print this Window links
• Flashy menus that don't help the user
• Right-click protection scripts
• Animations
• Tunnel pages
• Background music

This time we will wrap up with some more examples and a list of ideas for how to spot cluttering knick knack.

Road Warrior, Beyond Lapdom

For all their cool teeny-tiny productiveness, I've never been able to effectively use a laptop on.. my lap. It's just not possible, except for brief sessions to check email or the like. To do real work, I have to find a desk or desk-like surface. This can be tough unless I'm in a hotel room.

I recently blogged about the three essential travel accessories for my laptop. Well, I am tentatively adding a fourth item to that list: the portable laptop stand. My mom picked this laptop stand thing up at a yard sale for a few bucks. She thought I might like it.* Initially I was quite skeptical-- how can something this ridiculous looking actually work? But it does! I can finally sit on the couch and work with my laptop at nearly full desktop speed, with a real mouse.

I didn't get any documentation with the laptop stand, so I did some research and found out it's a PC Table Tote. Unfortunately, it's a bit expensive at $49.99. But it works unbelievably well, and folds up into a neat little package. I particularly like the way the opposite side mounts on the top to double the surface area, so you have a generous area for both laptop and mouse.

I'm no expert on devices like this, so there might be laptop stand alternatives that work just as well. All I can tell you is, it looks ridiculous, and it's a bit expensive, but this PC Table Tote thing really works.

* Thanks, mom. You rock.

Emulating Passion

When it comes to gifts for geeks, you can't go wrong with the plug-and-go classic home videogame emulators. Relative obscurities two years ago, they seem to be wildly popular now. Many of the most influential home console videogame systems are now represented at Wal-Mart and Target:

• Commodore 64
• Intellivision
• Atari Flashback 2 console
• Atari 2600 joystick with Atari games
• Atari 2600 joystick with Activision games
• Atari 2600 paddle
• Sega Genesis Madden NFL/NHL
• Sega Genesis (and Volume 2)
• Nintendo NES (not licensed, pirate)

There's something more to these devices than mere nostalgia, though. Many of us can trace our current careers all the way back to a childhood spent fascinated with these primitive home videogames. It was a small step, at that time, from player to creator. There was a kernel of possibility that you could somehow convince your parents to buy you a home computer and become The Next Great Videogame Programmer. Of course, this is less likely in the current era of multi-million dollar game budgets, but that do-it-yourself spirit lives on in these devices.

Nowhere is that better illustrated than in the odd history of the Commodore 64 Classic Plug & Play:

There is a story behind every electronic gadget sold on the QVC shopping channel. This one leads to a ramshackle farmhouse in rural Oregon, which is the home and circuit design lab of Jeri Ellsworth, a 30-year-old high school dropout and self-taught computer chip designer.

Ellsworth has squeezed the entire circuitry of a two-decade-old Commodore 64 home computer onto a single chip, which she has tucked neatly into a joystick that connects by a cable to a TV set. Called the Commodore 64--the same as the computer system--her device can run 30 video games, mostly sports, racing and puzzles games from the early 1980s, all without the hassle of changing game cartridges. She has also included five hidden games and other features--not found on the original Commodore computer--that only a fellow hobbyist would be likely to appreciate. For instance, someone who wanted to turn the device into an improved version of the original machine could modify it to add a keyboard, monitor and disk drive.

Sold by Mammoth Toys, based in New York, for $30, the Commodore 64 joystick has been a hot item on QVC this Christmas season, selling 70,000 units in one day when it was introduced on the shopping channel last month; since then it has been sold through QVC's Web site. Frank Landi, president of Mammoth, said he expected the joystick would be distributed next year by bigger toy and electronics retailers like Radio Shack, Best Buy, Sears and Toys "R" Us. "To me, any toy that sells 70,000 in a day on QVC is a good indication of the kind of reception we can expect," he said.

Ellworth's first venture into toy making has not yet brought her great wealth--she said she is paid on a consulting basis at a rate that is competitive for her industry--"but I'm having fun," she said, and she continues with other projects in circuit design as a consultant.

Her efforts in reverse-engineering old computers and giving them new life inside modern custom chips has already earned her a cult following among small groups of "retro" personal computer enthusiasts, as well as broad respect among the insular world of the original computer hackers who created the first personal computers three decades ago. (The term "hacker" first referred to people who liked to design and create machines, and only later began to be applied to people who broke into them.)

More significant, perhaps, is that in an era of immensely complicated computer systems, huge factories and design teams that stretch across continents, Ellsworth is demonstrating that the spirit that once led from Silicon Valley garages to companies like Hewlett-Packard and Apple Computer can still thrive. "She's a pure example of following your interests and someone who won't accept that you can't do it," said Lee Felsenstein, the designer of the first portable PC and an original member of the Homebrew Computer Club. "She is someone who can do it and do it brilliantly."

It's an inspiring story. All the great developers I know are passionate about their work and have that same do-it-yourself approach to solving problems. It's not even work; it's fun to solve problems and build things.

When the C64, as the joystick is called informally, appeared on QVC last month, Ellsworth watched with obvious pride. "It was one of one of the best projects I've ever done in my life," she said. "It was a tribute back to the computer that started it all for me."

If you're lucky, the result of your passion will be used and enjoyed by thousands of people. That's the ultimate compliment. If you're curious about Jeri, here's a brief biography with photo.

I prefer the classic home videogame emulators, but there are similar devices for classic arcade videogames, too:

• Pac Man, Bosconian, Rally-X, Dig Dug, Galaxian
• Ms. Pac Man, Galaga, Pole Position, Xevious, Mappy
• Mortal Kombat
• Space Invaders, Phoenix, Lunar Rescue, Qix, Colony 7
• Tetris (full arcade version with 2 player mode)
• Frogger, Rush n' Attack, Time Pilot, Scramble, Gyruss, Yie Ar Kung Fu
• Street Fighter 2

As for me, all I want for Christmas is a freakin' superyacht. Is that so much to ask?

Happy Talk Must Die

Per Steve Krug's excellent book, Don't Make Me Think:

We all know happy talk when we see it: it's the introductory text that's supposed to welcome us to the site and tell us how great it is, or to tell us what we're about to see in the section we just entered.

If you're not sure whether something is happy talk, there's one sure-fire test: if you listen very closely while you're reading it, you can actually hear a tiny voice in the back of your head saying "Blah blah blah blah blah...."

A lot of happy talk is the kind of self-congratulatory promotional writing that you find in badly written brochures. Unlike good promotional copy, it conveys no useful information, and focuses on saying how great we are, as opposed to delineating what makes us great.

Although happy talk is sometimes found on Home pages-- usually in paragraphs that start with the words "Welcome to..."-- its favored habitat is the front pages of the section of a site ("section fronts"). Since these pages are often just a table of contents with no real content of their own, there's a temptation to fill them with happy talk. Unfortunately, the effect is as if a book publisher felt obligated to add a paragraph to the table of contents page saying, "This book contains many interesting chapters about _____, _____, and _____. We hope you enjoy them."

Happy talk is like small talk-- content free, basically just a way to be sociable. But most web users don't have time for small talk; they want to get right to the beef. You can-- and should-- eliminate as much happy talk as possible.

Although Steve is referring to a web page here, this phenomenon is not limited to websites. Don't put happy talk anywhere in your application-- interface, dialogs, documentation, or even comments. Happy Talk Must Die. Happy Talk is just a pathological case of Omit Needless Words. The less text you have in your app, the better, because users won't read it anyway.

Also, if you don't own a copy of Don't Make Me Think, treat yourself this Christmas and get one. It's the single best book on usability I've ever read. If I had my way, it'd be required reading for every developer in the world.

Task Manager Extreme

If Task Manager Extension is Task Manager on steroids, then Mark Russinovich's Process Explorer is Task Manager in a ripped anabolic fury, fueled by high octane rage. In other words, it's extreme:

Although it can be a little overwhelming-- I think it just kicked sand in my face-- it does have some features that I prefer over Task Manager Extension, namely:

• A menu item to enable/disable replacing Task Manager
• Drag and drop spy icon button to visually identify windows and their corresponding processes
• Real-time, color-coded highlighting of changes
• Native support of .NET processes
• Shows TCP/IP connections for a given process
• Lists all strings found in a given process

.. among many, many other things. And of course it duplicates all the functionality of Task Manager Extension. If you've outgrown Task Manager completely, this is definitely the tool for you.

The Last Configuration Section Handler..

I stumbled across the Craig Andera post The Last Configuration Section Handler I'll Ever Need a few months ago, but I didn't really understand the implications until I started writing a bunch of configuration section handlers. His approach is very clever; instead of writing a bunch of tedious code to read settings from a .config file, you deserialize an instance of the class using the .config file XML as the input!

Here's the VB.NET version of the necessary ConfigurationSectionHandler:

Imports System.Xml
Imports System.Xml.Xpath
Imports System.Xml.Serialization
Imports System.Configuration

Public Class XmlSerializerSectionHandler
    Implements IConfigurationSectionHandler

    Public Function Create(ByVal parent As Object, ByVal configContext As Object, _
        ByVal section As System.Xml.XmlNode) As Object _
        Implements System.Configuration.IConfigurationSectionHandler.Create

        Dim xpn As XPathNavigator = section.CreateNavigator
        Dim TypeName As String = xpn.Evaluate("string(@type)").ToString
        Dim t as Type = Type.GetType(TypeName)
        Dim xs as XmlSerializer = New XmlSerializer(t)

        Return xs.Deserialize(New XmlNodeReader(section))
    End Function

End Class

And here's an example of what your *.config file would look like:

<configuration>
  <configSections>
    <section name="MyStuff" 
      type="MyClass.XmlSerializerSectionHandler, MyClass" />
  </configSections>

  <MyStuff type="MyClass.MyStuff">
    <Foo>234</Foo>
    <Bar>A bunch of information</Bar>
  </MyStuff> 
</configuration>

Note the type= attrib on the MyStuff element. With the type information in that attribute, the <MyStuff> config section can be deserialized to an instance of the MyStuff object:

Class MyStuff
    Public foo As Integer
    Public bar As String
End Class

.. in a single call!

Dim ms As MyStuff 
ms = CType(ConfigurationSettings.GetConfig("MyStuff"), MyClass.MyStuff)

Before going this route, make sure your class serializes to the same XML format exactly-- otherwise you'll get a bunch of non-intuitive deserialization error messages. Here's a quick way to serialize a class to the console and view the correct XML that is expected for deserialization:

Dim o as New MyStuff
o.foo = 3
o.bar = "stuff"

Dim sb As New Text.StringBuilder
Dim sw As New IO.StringWriter(sb)
Dim xs As XmlSerializer = New XmlSerializer(o.GetType)
Dim xsn As New XmlSerializerNamespaces
xsn.Add("", "")

Dim xtw As New Xml.XmlTextWriter(sw)
xtw.Formatting = Xml.Formatting.Indented
xtw.WriteRaw("")

xs.Serialize(xtw, o, xsn)
Dim s As String = sb.ToString
s = Regex.Replace(s, "(<" & o.GetType.Name & ")(>)", "$1 type=""" & o.GetType.FullName & """$2")
Console.WriteLine(s)

Note that some of the contortions in the above code are necessary to get a "clean" set of XML output, free of namespaces, encoding, and the like. This code was borrowed from Mark Allanson's blog.

It really could be The Last Configuration Section You'll Ever Need.

However, troubleshooting XML that won't deserialize can be.. difficult. Here's an improved, more robust XmlSerializerSectionHandler that provides much better feedback when things go wrong.

''' <summary>
''' Configuration section handler that deserializes configuration settings to an object.
''' </summary>
''' <remarks>The root node must have a type attribute defining the type to deserialize to.</remarks>
Public Class XmlSerializerSectionHandler
    Implements IConfigurationSectionHandler

    Public Function Create(ByVal parent As Object, ByVal configContext As Object, ByVal section As System.Xml.XmlNode) As Object _
        Implements System.Configuration.IConfigurationSectionHandler.Create

        '-- get the name of the type from the type= attribute on the root node
        Dim xpn As XPathNavigator = section.CreateNavigator
        Dim TypeName As String = xpn.Evaluate("string(@type)").ToString
        If TypeName = "" Then
            Throw New ConfigurationException( _
                "The type attribute is not present on the root node of " & _
                "the <" & section.Name & "> configuration section ", _
                section)
        End If

        '-- make sure this string evaluates to a valid type
        Dim t As Type = Type.GetType(TypeName)
        If t Is Nothing Then
            Throw New ConfigurationException( _
                "The type attribute '" & TypeName & "' specified in the root node of the " & _
                "the <" & section.Name & "> configuration section " & _
                "is not a valid type.", section)
        End If
        Dim xs As XmlSerializer = New XmlSerializer(t)

        '-- attempt to deserialize an object of this type from the provided XML section
        Dim xnr As New XmlNodeReader(section)
        Try
            Return xs.Deserialize(xnr)
        Catch ex As Exception
            Dim s As String = ex.Message
            Dim innerException As Exception = ex.InnerException
            Do While Not innerException Is Nothing
                s &= " " & innerException.Message
                innerException = innerException.InnerException
            Loop
            Throw New ConfigurationException( _
                "Unable to deserialize an object of type '" & TypeName & "' from " & _
                "the <" & section.Name & "> configuration section: " & s, _
                ex, section)
        End Try
    End Function

End Class