Duncan Mackenzie .Net

My Grand-Boss is Blogging, oh my!

Duncan Mackenzie — Thu, 01 May 2003 02:16:00 GMT

Sara Williams, ~~overlord~~ manager of MSDN, has started her own blog. I'm sure this will be a great place for discussion around MSDN futures and features. I know that many people who read my blog use MSDN every day, so I expect to see lots of comments!

A very busy day

Duncan Mackenzie — Wed, 30 Apr 2003 00:31:00 GMT

I’m writing this from Las Vegas now, actually I’m on a plane heading to Las Vegas… but this post won’t show up until I’ve landed and found some form of connection, for a few days of the N+I conference (Networld + Interop), and it has been a fairly crazy few days. With a flight planned for 9:50 in the evening, my wife and I (and our 2 yr old son) thought we had some time to do a bit of house-hunting around 4 in the afternoon. Well, turns out we liked one of the houses a little bit more than we might have expected and it was time to make an offer. Filling out reams of paperwork is an experience all on its own, but filling it out for the first time in the US (I’ve bought a house before, but it was in Canada, and things are a little bit different) as the clock ticks towards my flight and our son tears around the Real Estate office out of boredom is a little bit too much excitement for me. In the end, we managed to get the offer in, get some food into us and get me in my car heading towards the airport with an hour to make my flight. The most interesting thing to me was that, in the end, I was able to check-in for my flight right at the parking lot where I dropped my car (checking in at an automated station isn’t new to me, but doing it at the parking lot 5 or 6 blocks from the airport was a welcome surprise)… and I even had enough time to grab a coffee in the airport before my flight. There was wireless there, and I suppose I could have at least checked my email, but I used the 20 minutes to just sip my coffee and try and calm down from the experience of (potentially) buying a house.

Now, on to Vegas!

Some "slightly less than documented" APIs

Duncan Mackenzie — Thu, 24 Apr 2003 20:36:00 GMT

I wrote an article back in August 2002 on some of the API calls that were documented as part of the Microsoft settlement agreement... but in the end, I never published it... so here it is for your viewing pleasure;

http://www.duncanmackenzie.net/writing/SettlementAPIs.htm

Associated code is also located on my site; http://www.duncanmackenzie.net/writing/newapis.exe

New Dev Centers Are Up!!!

Duncan Mackenzie — Wed, 23 Apr 2003 19:23:00 GMT

After many, many weeks of work by many, many people... the new developer centers are up on MSDN!

Feel free to check out mine http://msdn.microsoft.com/vbasic/default.aspx (mine being a vague word that suggests I had a lot to do with and will have a lot to do with it going forward!) and let me know what you think!

Exciting new Microsoft Insider Blog

Duncan Mackenzie — Fri, 18 Apr 2003 18:40:00 GMT

Check it out! http://blogs.gotdotnet.com/thayer/

Using what you write

Duncan Mackenzie — Fri, 11 Apr 2003 08:28:00 GMT

The Coding4Fun column has had some interesting side effects. I get to use the code I write, something that isn't very common when you are paid to write samples.

I wanted to pull down the new Matrix Trailer, but it is around 60mb and I often switch networks (VPN on/off to get my mail, connect to the VSS on an internal server, etc.) so I opened the Background Copy program from my second issue... off it goes, incremental background download (can't take credit for any of that, thank the team that built BITS!).. my wife has had the email checker (actually an early build without an options dialog, I just put the values right into the .config file for her) from the third issue running 24/7 and my home music system uses the code techniques from the first issue as it scans our system for music updates every few hours.

This is pretty cool so far, and right now I'm running some code, (that I hope will make it in as part of the next issue/installment), that is making my Messenger name into something ugly like "Duncan (Listening To: I Love Myself Today -- Bif Naked [3:52])"

The next thing is to make it work the other way around: instead of personally using code I wrote for publication, I want to publish code I wrote at home for use by everyone else.

Command Line Switch Parser

Duncan Mackenzie — Thu, 10 Apr 2003 22:17:00 GMT

I didn't write it (Peter Hallam did), but I was just using it and thought "wow, this is cool, it needs to be found by more people!"

If you build console apps that take multiple arguments (generate.exe /vroot:vbasic /target:c:\files\ ... etc.) then this makes it very easy. To use it, just compile the provided code into a library and reference from your own C#, VB.NET, etc. application.

From the readme;

Command Line Argument Parser
----------------------------

Author: peterhal@microsoft.com

Parsing command line arguments to a console application is a common problem.
This library handles the common task of reading arguments from a command line
and filling in the values in a type.

To use this library, define a class whose fields represent the data that your
application wants to receive from arguments on the command line. Then call
Utilities.Utility.ParseCommandLineArguments() to fill the object with the data
from the command line. Each field in the class defines a command line argument.
The type of the field is used to validate the data read from the command line.
The name of the field defines the name of the command line option.

The parser can handle fields of the following types:

- string
- int
- uint
- bool
- enum
- array of the above type

Managed Wrapper for BITS

Duncan Mackenzie — Tue, 08 Apr 2003 05:46:00 GMT

Wow, people pick this stuff up quick... that was just an updated version of my BITS wrapper that I posted TODAY... Appreciate the link from ScottW and Chris Kinsman, but I'd rather people read the associated article (at http://msdn.microsoft.com/library/en-us/dnwxp/html/WinXP_BITS.asp ) instead of just pulling down the code... or at least the column I wrote that uses the same managed wrapper ( http://msdn.microsoft.com/library/en-us/dncodefun/html/code4fun02282003.asp ). Code is cool, code with some explanation can be cooler!

Full MusicXP Source Posted to GDN

Duncan Mackenzie — Mon, 07 Apr 2003 23:10:00 GMT

The full source for the MusicXP application, without the database (which is up in the GDN Workspace as a release) is now available as a User Sample on GDN...

Enjoy

MSDN TV now available offline!

Duncan Mackenzie — Mon, 07 Apr 2003 21:29:00 GMT

From: Erica Wiechers
Sent: Monday, April 07, 2003 12:51 PM

Due to huge customer demand we now offer each MSDN TV as a download as well as a live stream. See http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20030403XMLGB/manifest.xml for an example.

Certification doesn't prove you know everything, but it certainly helps....

Duncan Mackenzie — Mon, 07 Apr 2003 09:09:00 GMT

My name is Julie and I am not certified.

I stress out about it because I feel that it might garner me some peer recognition that I do not have after almost 20 years of programming. I don't need it for my clients or my business.

[Julie Lerman]

Get certified.. it is cool to have the option to use the letters, but more importantly it can (1) give a little bit of reassurance to someone who is a 1st time client of yours... how could that be bad? and (2) it reassures you that "yep, I do know at least that much...". Sometimes I've thought... "Maybe my programming assignments have all been easy, and I'm not actually even in the league of person x" ... at least with an MCSD I felt that I must have some idea what I'm doing :)

I passed those WOSA tests, which I thought were useful tests to a certain degree (developers should have a good knowledge of the underlying OS and hardware... maybe not those specific details Keith mentioned, but the intent of the exams was valid) .. and received my MCSD in 1996. Big deal at the time, but I'm still proud of it. I kept it up to date and added a MCSE (NT4) and MCT ... but recently I've realized that I'll likely be certificationless soon (NT4 MCSE... MCT expired because I don't teach anymore, MCSD is for VB6...) if I don't get back on the exam taking track. Why bother? At this point, with a job that doesn't require it of me, I want to do it to help out the certification itself by pointing out that I am proud to have it. If I ever manage to get my certifications up-to-date, I'd like to list them in that little bio they put at the end of my columns.

I actually suggested (when I first arrived at MSDN) that we list certifications after the names of all our writers, to show the developer community that our 'experts' valued their certifications... but not all of us had our MCSD so we decided it wouldn't have the desired effect. I had just come to Redmond from a position out "in the field" working for Microsoft Consulting Services and the customers I worked with were (and still are) of the opinion that certification was very valuable. Anyways, in the end my general answer to anyone who says that they don't need to be certified is "why not, how can it hurt?"

Sure you don't need it, but then it should be easy for you to blow through the exams... I'd hate to have a customer ask me if I was an MCSD and have to say no... "I don't need it" might not cut it with them. Does having a MCSE/D prove you are an expert? Of course not, but it proves a certain level of basic knowledge... you can prove the rest through your references and your work.

A little 'bit' more on Int32 vs Integer

Duncan Mackenzie — Sun, 06 Apr 2003 08:57:00 GMT

Darren's comments on my previous post:

I certainly don't want to get into a debate over this but, shouldn't the question be: "what is it best to use?".

I'm probably biased because I never really programmed in any typed languages before .NET, but, to me at least, being as explicit as possible is always a good thing.

I know that Int32 will map to System.Int32 even in version 30 of the Framework. God knows what Integer or int will map to by then.

Instead of replying back to him directly or in the comments, I thought I would try replying in another blog entry (there certainly are some issues to be worked out regarding the best way to comment/discuss)..

Good point Darren, thanks. The problem I see is that the question of "best" isn't an easy one to answer. If you are writing your code to be dependent on the size of the underlying data type, then the desire to be explicit is certainly understandable, but when programming in C# or VB.NET you do not always need to be aware of this implementation detail. (that hurt to even type, I'm a big fan of always knowing about the details... but my point is that you shouldn't have to know about them in this case). In fact, I think you should try to avoid being implementation dependent as a general rule.

As I mentioned in my last post, if I'm working in a situation, such as a Win32 API call, where the exact size of the integer, the number of bits involved, is relevant then I use it. In all other situations, I need to know that my data type (Integer) is big enough to hold the range of values I want to work with. Personally, I noticed and even wrote about the fact that Integers and Longs have changed from VB6 to VB.NET, but that change has had almost no effect on most VB6 code upgraded to VB.NET, except when calling out to external libraries. So, if in future implementations of the VB.NET compiler, they decide that (for efficiency on the standard processors of the day, perhaps) Integer should map to Int64, then I would hope that wouldn't cause me much of a problem... if they decided, and I don't think they would, to change the mapping to Int16, then I think I would be screwed.

Right after the PDC in 2000, I had just installed the .NET Framework "alpha" onto a machine and was busily writing a book on VB.NET... I decided that I should always use fully qualified types (System.Text.StringBuilder, instead of using an Imports and then just StringBuilder)... .NET was so new to many people that I wanted to err on the side of clarity. I also decided that I shouldn't use things like Integer or MsgBox and that I should instead use System.Int32 and System.Windows.Forms.MessageBox.Show()... in time though I realized that I prefer to work with the terms/keywords that I am familiar with, and that even with Intellisense, I prefer to work with relatively short and easy to remember terms as well. So, now I use Imports for common namespaces (on a code file by code file basis, I really find the "default" Imports in VS.NET confusing) and I use language specific data types. I think that this is natural for people, and I wouldn't want to try and change developers to Int32 or to change VB6 developers so that they stop using MsgBox("Test"). Developers have habits; for example, I still use hungarian notation in lots of my own code (sorry Brad, I did read the design guidelines, I really did... I even use FxCop... my public members are generally ok, I just can't stop using hungarian in my private variables!) even though it is no longer recommended.

I am still undecided about using fully qualified types in samples, sometimes people copy/paste a snippet of code from one of my articles that it is not a complete class or code file (and therefore does not include any Imports statements) and get quite confused when it doesn't compile and they have all of these squigglies under the class names. When I can write code samples in such a way that the required Imports are automatically attached (even to a single code snippet) then I won't have to use fully qualified class names, but for now I think I will have to change my coding style for snippets.

Darren, you said you didn't want a debate and here I am replying with such a long post... but there really is no debate, at least not from me. I don't know what the "best" way is, I just hope that some of my comments help explain why I have chosen a certain set of coding rules.

Int32 or Integer/int?

Duncan Mackenzie — Sun, 06 Apr 2003 08:50:00 GMT

Brad Abrams posted about the use BCL types vs. language specific type names (in sample code) today, which just happens to be a topic I've had to think about myself when writing sample code for my own articles, so I thought I would make a comment.

I'm with Morty on this one... I have the general rule that sample code should be written following the style and convention guidelines for the language. I'm a VB guy, so this usually takes the form of "Write VB code the VB way", but there are exceptions.... For example, I use Integer in my Visual Basic .NET code, not Int32, but I like to use Int32 in Win32 API declarations; the specific size of integer is pretty important at that point so I like to make it clear... Beyond types it gets a little murky... I always use the System.IO classes for File access; VB.NET still has the Open/Put commands but I truly believe that those "legacy" statements are not as good/clear as the new System.IO classes... whereas in the case of Int32 vs. Integer (or MsgBox vs. MessageBox.Show()) it is merely a syntax/style difference.

I think using Int32 in a VB.NET/C# code sample makes it slightly less familar to a C++ developer (in the case of C#) or a VB6 developer (in the case of VB6)... and that makes the developer a little less comfortable, and therefore a little less likely to understand what they've been shown. The purpose of a sample is to explain the concept in terms of code. The purpose of doing in more than one language is to explain the concept in terms that the developer is already familiar with... well, following that same guideline and knowing that a VB.NET developer is more familar with Integer than Int32, they will benefit more from seeing the sample written using the VB data type names.

Of course, all of this can be ignored if Int32 was the class being demonstrated :)

It is a gradual process...

Duncan Mackenzie — Tue, 01 Apr 2003 23:29:00 GMT

As per my previous post , I'm slowly uploading bits and pieces of " MusicXP " to a GotDotNet Workspace . The Music Scanner utility went up today, a messy sprawl of console application code that scans your system for .wma and .mp3 files and ~~sends them to me~~ puts their meta data into the MusicXP database.

I hate to get involved at all, but...

Duncan Mackenzie — Tue, 01 Apr 2003 19:28:00 GMT

There have been a few VB vs C# debates flying around... I'll refrain from linking to them all, as they aren’t really saying anything new. One comment in particular caught my eye though, and I have to respond.

Jesse Ezell's post includes a quote that says "Microsoft is standardizing on C#" and then goes on to use that quote as a reason to suggest you shouldn't use VB.NET... well, I work for Microsoft and I am in discussions with the .NET groups every day and I know exactly what we are working on and working with, and I can tell you that Microsoft is not “standardizing” on anything. Yes, much of our internal .NET development is done with C#, and why not? We are a huge campus full of C++ developers. If we did standardize on anything, I would expect it to be Managed C++. Also, it’s worth pointing out that we do development in VB as well, including some of our internal business applications.

Before .NET, Microsoft used C++ almost exclusively (and we still do almost everything in C++) but that doesn't mean that everyone should use C++ to build their line of business applications. People also point out that much of the Framework was written in C#, but remember, it was written by C++ developers. There isn’t a single class, method, property, or event, anywhere in the Framework, that you can’t use from VB.NET. If someone builds a library in C# that you can't use from VB.NET, (and vice versa) they probably did it wrong...

C# is the flashy new language that has arrived with .NET so it gets a lot of attention (which led to more samples being written in C#, etc...), but Visual Basic is by far the more popular language and I don't expect that to change. I write code in Visual Basic everyday and nothing in the Framework is being "hidden" from me, I have full access to the Framework in all its glory. I don't think there is any need to ignore C#, but you certainly don't have to learn it to work in .NET...

Stop debating this issue; pick a language and build something... you'll feel better.