This year we FINALLY get a PDC. I have been looking forward to it for a long time, but booked my attendance and my flights during one of this year’s blogging hiatuses (hiati?). If you are responsible for any kind of strategy or planning, if you are starting a project that will take several years to finish and you want to use the latest technology while you’re building it, or if you just love making software and can’t wait to see what’s next, then the PDC is for you.

It’s the last week of October, in Los Angeles (the only thing about it I don’t really like) and it will just cram your brain with information you actually can’t use to write code quite yet -- but that you really need to plan your own roadmap over the next few years. If you want to know something about a product that is already shipped (say, Visual Studio 2008) then this is not the conference for you. Even if your area of interest is software that is mostly written, maybe has a CTP out already, and will be released during 2008, then again, PDC is not really going to help you. PDC is about stuff that is just starting now. PDC is about getting a big headstart on those who waited till a product was released or a public beta was available. Here’s the list using their own keywords (the numbers are how many sessions are on that topic)

I also chose a random session so you could get an idea of the level of conversation PDC is for:

Unified Communications: Futures

Kyle Marsh, Chris Mayo

In this session we unveil the future of Microsoft Unified Communications (UC) technologies. Be among the first to see the UC roadmap, watch the new features in action, and walk though the code that makes it all possible. Come see how you can deliver breakthrough applications by embedding rich presence, build click-to-call features including voice and video, create communication workflows using speech and IM, and integrate Microsoft Exchange 2007 features and data.

Tags: Advanced, Unified Communications

This is one of the few conferences in the world that I get myself to (that's right, my own money) as an attendee. I'm not there to speak, work a booth, or be on a panel. I'm there to learn, and you should be too. See you there!

Or put another way, is VB just C# without semi colons? Well, yes and no. If you work in the big wide world of many different programming languages, frameworks, libraries, and operating systems then C# and VB are so close as to be almost indistinguishable. They both have great support from Visual Studio, they both produce managed code that runs on the CLR, they call the same framework functions, they have keywords for the same CLR concepts, and they both have a community of support, sample code, tutorials and the like. But those communities aren’t twinned – some samples are available only in VB, and others only in C#. For historical reasons there are a lot of C# programmers inside Microsoft, and perhaps that’s why VB samples can be a bit thin on the ground.

This less-than-100%-overlap between the samples, tutorials, and so on for the two languages results in people who are proficient in one language trying to read (or worse, write) in the other. Sometimes a great C# developer will be asked "where’s your VB sample? Quick, translate your C# one right away!". Other times a great VB developer will be trying to write their own VB code while reading samples or tutorials written in C#. It can go in the other directions, too.

But although these two languages have a great deal in common, they are different, and in more than just syntax. There are features in each that aren’t in the other. There are natural idioms, too. Idioms are a way of writing things that are natural to one language or identifiably belong to one language. Choosing an example not from the VB/C# world, but from C++ or C, it used to be just so normal to write

if (p=SomeFuncThatMightReturnNull())
{
//do something that relies on p not being null
}

That’s C++, and a deliberate single equals sign. I am assigning p the return value from the function. Then I am testing that value. (Quibble: I am testing what the = operator returns, which is the value just assigned for all well written = operators.) If it’s not null, we’ll do the stuff in the braces. Sometimes I used to come across this instead:

p=SomeFuncThatMightReturnNull();
if (p)
{
//do something that relies on p not being null
}

Or even

p=SomeFuncThatMightReturnNull();
if (p != null)
{
//do something that relies on p not being null
}

Now these other ways of doing it aren’t wrong, they will compile and work, but they demonstrate a lack of familiarity with C++ idioms, with a C++ way of thinking. They are usually written by people who aren’t very comfortable with pointers.

Again, that’s not wrong exactly, but it’s not what I like to write. I prefer just:

Return (x > y)

Sometimes people say I write C++ in VB, because that's a very C++ way of writing things. But I find it not just easier to read -- it's less bug-prone. (Copy and paste errors like having True in both clauses, for example, will make you crazy.) I know that it’s kind of a C++-ish way to express myself, but it feels natural to me and it works. People who are less comfortable working with Booleans tend to prefer the first, more verbose way. They can see the whole thing laid out for them. It’s not wrong, just different.

Well, it turns out those who try to write VB when they’re proficient in C# are likely to run into a lot of differences in thinking and expression when they take on that task. It might be syntax tripups, missing the use of a helpful VB feature that isn’t in C#, or just writing code that doesn’t use the VB idioms. Kathleen Dollard has amassed a huge list (77 at the moment) of things you should know if you want to write VB code. Required reading for C# people who have to write VB, entertaining for those who like VB, and what's more, plenty of experienced VB developers could learn a thing or two from it (I did.)

Vista gets a lot of bad press it doesn’t really deserve. For example, it crashes way less than XP for me. Some applications behaved oddly at first (primarily because of UAC and Virtualization) but I have either learned workarounds, such as running the app elevated, or upgraded or replaced the apps that were causing trouble. The slow file copy thing drove me insane, but SP1 took care of that. I really have very few complaints left about my computer, and the ones I have are aimed at specific applications (yeah, Outlook 2007, I am looking at you when I say that, and Adobe, don’t think not meeting my eyes will keep you out of my bad books) rather than the operating system.

Still, who wouldn’t want to make their operating system run faster and smoother? Here are some helpful thoughts and guides:

Windows Vista Performance and Tuning. A downloadable paper from Microsoft. Simple stuff here like choosing the right power management plan, using ReadyBoost, tweaking your search settings, and so on. Worth a read.

Vista Annoyances Resolved. Despite being annoyingly spread over 9 pages (see what taking ads does to you?) it has some good stuff. You’ll see explanations of SuperFetch, ReadyBoost, restore points, and more.

I wonder if this shows some sort of era-of-adoption effect, where folks in the US had widespread Internet access so they got started with AIM and never switched, then Canada and Australia picked up Messenger, and other places see a popularity of even more recent clients? Or perhaps it’s an artefact involving what kind of people use a messenging-interop solution? Whatever the mechanism, I’m a typical Canadian I guess since I use Messenger.

Whenever an application blows up and offers to send information to Microsoft, please please say yes. On Vista it’s described as “checking for a solution” to make it more obvious what’s in it for you.

Sometimes, when you send this information to the giant Windows Error Reporting mother ship, you get a response that your blowup was caused by a known problem, and a link you can click for more information. That doesn’t happen to me very often, which I guess means I am among the first to find problems in shipping software. But that doesn’t mean you can’t benefit from the fix when the developers finally get around to acting on the reports they get from the WinQual program. Here is something you should do every month or so if you can remember.

First, bring up Problem Reports and Solutions. It’s on the control panel, or just click Start and type Problem, then press enter. You’ll see something like this:

Click View Problem History on the side. You will see a list of stuff that has blown up on your computer over the months.

Interesting, isn’t it? Click the Select all box at the top, and also Check Again For Solutions to Other Problems. Now click the Check for Solutions button. It will go and have a think:

It might also ask you if it can send extra info for some blowups, I always say yes. In for a penny in for a pound eh?

Then, the cool part. New solutions!

Click a link and you’ll get some more info with a link straight to the page that lets you get the update or latest version or whatever that specifically fixes the problem you had on your computer.

You can clear your problem history, but I am not sure why you would. You never know when a fix will show up for a problem you already had.

Check out http://www.easyduplicatefinder.com/ - it has tracked down all the identical demos, powerpoints etc all over my C drive in quite a short time. I haven’t let it do the deleting yet, but the finding is worth a lot to me (I can delete for myself once they’re found.) Three gig of duplicates and that’s without looking on the networked shares where I store things when I’m done!

The guys call me a regular now, and I suppose I am. Here’s another hour of rambling and fun covering Vista (especially the Vista Bridge) the Vista things you’re not allowed to implement in managed code, C++, the MFC update, concurrency, and whatever else popped into my head while we were talking.