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:
Ahh the beauty of overloading or versioning, why bother with flat C and so on with all these problems, flat C and C++ is NOT an APPLICATION language and never was designed to be such. ITs a system language. You chose the wrong language if you use it as an app language.
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!
# Nobody on 6 Dec 2004 12:46 AM:
# James Risto on 6 Dec 2004 8:17 AM:
# michkap on 8 Dec 2004 1:19 AM:
# michkap on 8 Dec 2004 1:23 AM:
# anonymous on 12 Dec 2004 3:07 PM:
# michkap on 12 Dec 2004 4:46 PM:
2004/12/11 I guess BIOS.NET may be on the way?
go to newer or older post, or back to index or month or day