| |
 |
Sunday, December 08, 2002 |
ILLINK Microsoft (R) .NET Framework IL Linker
The ILLINK utility is intended for linking multiple managed modules or assemblies into a single module or assembly... [Adrian Bateman (VisionTech)]
Nice little tool from Serge Lidin. It works by running ILDASM, doing some string grinding, and then running ILDASM on the result. The program is about 500 lines of raw C++ - it would be interesting to rewrite it in C# or VB.NET. Even cooler - write it using Jim Miller's PEWriter libraries and dispense with ILASM / ILDASM altogether...
9:45:12 PM 
|
|
Effective C# tip #17
I listened to most of Chris Sells on .NET Rocks this morning. It was mostly just interesting chat but the one thing I did pick up that I hadn't considered before was the idea of putting System.Diagnostics.Debug.Assert(false) in the finaliser for your IDisposable classes. This means that if you're using a debug build and you forget to call Dispose, you'll ultimately get an assertion failure to remind you when the GC cleans up. I think this is helpful when moving to the GC paradigm.[Adrian Bateman (VisionTech)]
This is such a great idea, and so obvious in retrospect. Be careful though - As long as finalized thread is busy showing that modal assertion dialog it's not running object finalizers. In an unattended scenario this could lead to crashing the process if nobody is around to press "OK" as the finalizer queue just starts backing up. Easy enough to fix - run the dialog asynchronously, or route the output to the event log instead. Still, a very cool tip.
6:23:46 PM
|
|
How to Evolve a language...evolves
Hee hee, since Sam works on MC++ I knew he'd jump all over me, and that he did (in record time too :).
The point of my post was not to slam MC++. Au contraire - I think it's a stupendous piece of engineering - perhaps the most impressive compiler achievement ever (I mean really. C++ compilers are hard to being with. The MC++ compiler handles that plus all kinds of extensions to generate code various ways with different outputs. There are operating systems that are less complex than that compiler). No, my point was simply that you have to make choices when you evolve a language, and the choices aren't always easy. MC++ and VB.NET both offer different lessons here as legions of developers look at the options and decide what to do.
Sam perfectly illustrated the main dilemma the MC++ team faced, which is the same one that every C++ vendor faced. Every vendor toyed with nonstandard extensions at some point to enable their own pet features. The only legal way to add new features and conform to the C++ ISO standard is via the use of __keywords. In years past MS might have just added new features anyway and standards be damned. In fact they did exactly this in the first MC++ compiler with the attributed syntax for COM that lets me say:
[coclass,threading("apartment"),
vi_progid("atl.MCPPATL"),
progid("atl.MCPPATL.1"),
version(1.0),
uuid("EFF2FDB5-ADD6-41D9-AA3D-56925F56273C"),
helpstring("MCPPATL Class"),
support_error_info(IMCPPATL),
registration_script("control.rgs")]
class ATL_NO_VTABLE CMCPPATL : blah blah blah
This is way easier to use than the RGS model of ATL past, but I don't see "attributed compilation" in any part of the ISO spec. So why did Microsoft do this? Becuase developers hated RGS files - they're hard to write and easy to break. At the same time a lot of developers I know were bewildered by MS putting the engineering effort into this instead of working to come into ISO compliance. Choices, choices.
So! I'm very happy to see Microsoft [finally!] place standards conformance high in their list of priorities, because there were some libraries that never worked will with Microsoft C++ in the past. Even the STL implementation wasn't too hot in VS6. The fact that adherence is correct does not necessarily make it popular, though. I worked for years with ATL which was [is!] a fantastically good use of C++ templates (though a bit hobbled by lack of support for partial templates at the time), and completely within the C++ standard. However ATL really only appealed to the rare COM/C++ wonk - it never achieved much penetration despite my own proselytizing for two years :). Those of use that loved it, loved it, but most developers didn't want to spend the time to appreciate it. What was very popular was #import which of course was nonstandard. Convenience versus Conformance, either has its cost.
Sam even says:
I will never argue that C# doesn't make the *general* developer more productive than MC++. [Sam Gentile's Radio Weblog]
It's those *general* developers that drive market share. If the MC++ team had made different choices that made MC++ magically easy to use (but were highly nonstandard) then MC++ might have more market share / visibility among the general population (but at the same time would be reviled by the more purist C++ wonks). Personally I'm happy that MC++ decided to go for a purist approach but that doesn't mean it will gain lots of mindshare. I don't blame the MC++ team for this. C++ is a language of a different time, before components, and frankly I think its day in the sun is fading for mainstream development. Even if the MC++ compiler is the bitchingest C++ compiler ever (and the Everett compiler may very well be) I don't think hordes of developers will rush to use it.
The real question I'm asking is - what happens when C# starts to evolve? Missteps there (or elswhere in the platform) might get developers not just switching languages but switching platforms...
4:39:42 PM
|
|
ECMA, SCHMECMA
get it? I said "schmeck" - heh-heh, heh, heh...
Keep an eye on http://msdn.microsoft.com/net/ecma/ - A little birdy told me there should be a pretty significant announcement on Monday about 8am.
Update: And so there is. The CLI is headed for ISO approval as ISO 23271, and the final ECMA specs are online. Work on the "next version" will begin in January - I wonder if I should try to get in on it?
2:21:37 PM
|
|
What's really in that assembly?
System.Reflection is great, but sometimes you wanna know more. Ever notice that you can't see (say) the IL of a method given a MethodInfo? Jim Miller [who was one of the main forces behind ECMA-335 (soon be an ISO standard as well!)] just posted two PERreaderWriter packages up on gotdotnet for working with PE files in the raw from managed space. (similar to cisterni's library at the University of Pisa) Looks way more convenient than the unmanaged API's (ICorMetaData and friends). Jim showed his own language agnosticism by posting two versions - one written in C# and one written VB.NET.
These libraries are probably most interesting to people writing compilers and related tools (I may use them myself for this soon) but there's good stuff here even for general development, including this snazzy class:
[Serializable]
public class MMFStream : Stream, IDisposable
{
private OSMappedViewOfFile mappedViewOfFile;
private Int64 position = 0;
private Int64 fileLength;
...
}
Yes! Everybody needs one of those in their toolbox!
2:04:29 PM
|
|
How to evolve a language?
In response to a thread over on Lambda the Ultimate, Sam writes:
...VB is in a tough position: either adopt the same model and semantics of the other CLR languages closely (like C#) and alienate the group of productive developers who want to stay with what they know or give up and stop. To be in the .NET world, forces them to change.
This reminds me of a conversation I had with John Lam about Managed C++. Both VB and C++ obviously pre-dated .NET and when their respective teams decided to make the port they faced a common choice - backward compatibility or slick new features. What John pointed out was that the VB and the C++ teams made basically opposite choices here.
The VB.NET team ignored backward compatibility in favor of new features. VB.NET is a very nice language for doing things in .NET, but of course it bears little resembles to VB past. Given the amount of marketing behind C# (and the curly-brace envy manifest in a lot of VB developers) a lot of VB developers decided that it would be just as easy to learn C# for new work as it would be to learn VB.NET. And so VB.NET isn't seeing the desired penetration.
The MC++ team made the opposite choice - the MC++ compiler bends over backwards to allow you to take that weird mix ofC++, STL,MFC, and inline ASM code that comprises most real world C++ programs and compile it somehow into a .NET assembly. It's an incredible feat of engineering. BUT for *new* projects MC++ is rarely very pleasant. C++ code tends to be complex as it is - introduce managed extensions and MC++ projects can become a morass (A good friend of mine who is an accomplished C++ developer once called MC++ a "landmine with 400 pins sticking out that can blow off your foot").
The result? The same as the VB camp. Developers by and large (including myself) tend to look at MC++ and said "thanks, but no thanks" for new projects. MC++ is great when you have 99% legacy code and 1% that needs to access .NET functionality, but any more split than that and it's often easier to just factor new functionality into C# and leave the old stuff largely intact.
The interesting thing is that developers in both camps defected to C#, but for opposite reasons. VB.NET is a great environment, but doesn't respect work you did previously. MC++ respects the work you did previously, but is somewhat painful for new projects. In C# of course there was no legacy code. There is now though, and more of it every day, so hopefully the C# team will tread a little more carefully as they start trying to evolve C#.
1:35:34 PM
|
|
© Copyright 2003 Jason Whittington.
|
|
