"<i>My</i> language is better than yours!" he said. He was wrong....

by Michael S. Kaplan, published on 2004/12/06 02:14 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2004/12/06/275506.aspx

An anonymous person was posting about my suggestion yesterday that maybe a GetKeyboardLayoutNameEx API should be added to extend the existing GetKeyboardLayoutName, and they suggested:

Ignoring for a moment the fact that I was talking about APIs (and the fact that even one of those "application languages" would likely use such an API if it were added), and talking about the wider issue of what is the right language to use....

I couldn't help but be reminded of a conversation I was having less than two months ago. I was at a party being thrown by my officemate and her boyfriend. He works in DevDiv so there were a lot of DevDiv people there, and although I had managed to avoid work talk all night, toward 2am I got into a conversation with several developers who were very opinionated. After we got by the positional jockeying (e.g. "you're a technical lead? Oh, so in other words you are a PM!"), they were very interested about the fact that I owned code both in kernel32.dll in Windows and in the Base Class Library of the .NET Framework.

They were curious how I could stand to do all that C code and why I wasn't trying to move to do managed code all of the time. They spent a little longer slamming on "unmanaged" code and how awful and pointless it was. How terrible unsafe code was with all the issues regarding memory allocation, buffer overruns, and everything else. They went on and on for what seemed like an hour but was probably less than 10 minutes.

On the one hand I wish I had been drinking more so I could speak my mind, but on the other was glad I had not had more to drink, so I was able to keep from speaking my mind -- if you know what I mean.

I realized of course that it was dumb to get mad, so I didn't. After a brief pause (I assume they were waiting for agreement!), I asked them whether they aware that there are nearly 400 API calls between mscorwks.dll (managed C++ dll that handles lots of BCL stuff) and mccoree.dll (the "execution engine" that starts off managed processes)? That mscorlib.dll (the written-in-C# piece of the BCL) has almost 250 p/invokes to Win32 APIs? That it has close to 1200 uses of the unsafe keyword?

(Note: if you are from Microsoft and worried that I am spilling out secret information, everything in the previous paragraph can be obtained by any customer with publicly available tools that ship with Visual Studio -- no secret squirrel stuff!)

Clearly it takes a lot of that unsafe stuff underneath it all to enable customers to do things in the cool new environment.

I told them that the reason I enjoyed working in the two different environments (well, three if you count the stuff we look at in kernel mode!) is that I did not see any one programming language as better than any other. And it was by working in kernel mode, in Win32 kernel32, in managed C++ in mscorwks, C# in the BCL, and C# in various out-of-band tools like MSKLC, that I am able to be reminded of that fact on a regular basis. Its all important, and it all has its place.

It defused the situation nicely, and none of them were unhappy (I suspect in part because I pointed out how everyone was important!).

But it was not just a line to get a bunch of devs who had too much drink to back off a bit. I get the converse attitude from people on the Windows side all the time, people who like to slam on what they hate about managed code. Its an identical problem, with people not wanting to see that there is a purpose to all of it -- maybe different purposes for each, but everything has as point. No exceptions!

No purpose to real mode code you say, since we have have been running in virtual for over a decade? Well I have had to look over code the in the NT boot loader a few months ago that loads the NLS casing tables, the very same ones that are later used by kernel32.dll. This data gets used so early in the boot cycle that it has to be loaded in real mode; the disk is not even available yet in virtual mode.

Perhaps that provides the answer to the original anonymous poster. When talking about system APIs, overloading is not really an option. And I'll bet you that if the API I suggested ever was added that the .NET Framework would be calling it within a version or two to get rid the hoops they have jump through to support the LayoutName property on InputLanguage today.

Maybe one day it will all be managed, and we will have BIOS.NET. Then everyone but the C# and VB.NET developers can go fishing. But I wouldn't suggest anyone hold their breath waiting for it -- everyone is still going to be important for some time to come....

Minor correction 6 Dec 2004 10:46pm: I am not sure why I keep making this mistake, but mscorwks.dll is not managed C++. It is regular unmanaged C++. This is still different the code in kernel32.dll, which is mostly regular C. Sorry for the mistake on this, I have no idea why I keep making it. I am still a huge fan of BIOS.NET, though!

... that sure, MS has to do stuff in system DLL's to make .Net talk to the OS. But at the app level, the idea is to use managed code whenever we can so that we are protected from buffer overflow and stuff (as well as tons of other reasons, of course). And, preach it to newer programmers so they are "safer" right out of the box. Plus, MS has a huge text matrix, and us plebes in the field are too rushed, so avoiding string hell saves time.

James, I cannot disagree with what you are saying. But I was suggesting that an API be added to the operasting system, so not sure where app level stuff came into the conversation of either the original article or this one. :-)

I have actually seen the code that the .Net framework uses to support the InputLanguage.LayoutName property, and not only is it not trivial, but it will also not always work (bug reported to the right people!). Its a hard problem from the outside, but not quite as hard from the inside of the operating system.

My main point in this second article was that everyone has room to respect both the power of their preferred language and the power of the other languages as well.

And I say this as a user of all of them....

Everyone calls it the Whidbey release.... developers who write the code, testers to find the bugs in it, PMs who write the specs, product managers and marketing folks who call it Whidbey for the public.

I call it Whidbey because I have never heard anyone else call it that, public or private. I doubt they will ship with that name, but I know lots of people who still call Windows, SQL Server, and Access releases by their code names, even after release.

you hit the nail on the head, the same language debate goes on between folks at my work and I difuse it the same way as you....as long as I haven't had too many beers first, of course.

Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.

"My language is better than yours!" he said. He was wrong....