Previously on my blog I said
”The My namespace is really just wrappers around existing Framework classes.”

Jay Schmelzer of the VB team writes
It’s not a set of wrappers for the framework, it is a speed-dial into the framework that helps VB developers find commonly used framework classes. In many cases we will also return instances of the framework class that is initialized and ready to use. Printing is a great example of this. My.Computer.Printers.DefaultPrinter returns a System.Windows.Forms.Printing.SimplePrintDocument that is setup and ready to work with the Default Printer. You can absolutely do this directly with the framework, but to get the same functionality you need to create an instance of the System.Windows.Forms.Drawing.PrinterSettings class to determine which installed printer is the default printer and then assign it to the PrinterSettings property of the System.Windows.Forms.Printing.SimplePrintDocument you want to use. Not rocket science by any means but a few more lines of code that you don’t need to write and classes you don’t need to discover if you use the My.Computer route.

So my using “wrappers” is sloppy lingo. I guess I am just used to using that term to describe things that handle deeper levels of coding for me. At the NETDA meeting I think I compared it to the XML parser. I don't want to write my own XML parser. I want one written for me that I can Dim and then use the methods, properties and collections. I would want it to have a method called ReadXML and one called WriteXML. Happily, such a thing exists. And, happily, I can write my own if I want or need to. In my mind I see that as “wrapping“ all the plumbing code that is required to work with XML. I view My in the same vein. My.Computer.Printers.DefaultPrinter is clearly the default printer that belongs to the collection of printers that belongs to the computer that belongs to me. I don't want to necessarily have to figure out how to talk to the printer.