I came across this link on the DOTNET-CLR mailing list today. It points to a GotDotNet workspace where Peter Hallam has posted a library containing interop declarations for many, many of the APIs from Windows.h in [DllImport] form. Handy!
Apparently, he has some sort of semiautomatic process for producing this file. If you head over and bug him, he might post the code that he used to create the declarations.
FYI, there is absolutely no point in doing this :
ReplyDelete- if you use MC++, there is no interop at all, and no marshaling, since you are doing explicitely the native calls.
- performance drop down with interop calls (COMinterop or P/Invoke) because of the marshaling and data itself being passed.
Huh? What about the 95% of people who aren't doing MC++? Maybe I'm missing something.
ReplyDeleteAlso, I don't think it's accurate to say that no marshalling is occurring. If you have a managed string, and the API you're calling expects a BSTR, then *someone* has to do the conversion. Whether that's your code or a marshalling layer, bits and cycles must be spent.
>> Huh? What about the 95% of people who aren't doing MC++? Maybe I'm missing something
ReplyDeleteYou mean those spending 2 days blindly trying to figure out a P/Invoke param signature instead of just installing MC++ and writing the call?
Come on, shops not using MC++ while doing a lot of native calls are simply unsmart, and losing money.
That's the fault of Microsoft to have promoted P/Invoke more than MC++. I believe they have been doing a lousy job here, and I hope they change ASAP.
>> Also, I don't think it's accurate to say that no marshalling is occurring. If you have a managed string
Yes and No.
There has to be a way to translate a managed string to unmanaged somehow, that's true, but that's something you do once for an entire MC++ library method. And then the method can do 100 native function calls because all it has to do is call unmanaged code with unmanaged parameters. Then at the end, you are expected to translate the unmanaged string back to managed.
The good news is that once you have done such translation once and for a few types (string, general struct), then you end up using it all the time. In fact, you are doing custom marshaling with simple CTS types. There's no issue here. Translating a string from managed to unmanaged is just one standard line of code. Many samples in many places about this.
Also, please note you do some of that trivial marshaling at the begin and at the end only, and you are not doing any marshaling in between. That's my point. The consequences on performance is obvious.
I think that I'll find this link very useful. Why? Because if I have a C# app, and I happen to need to call one random Win32 API function at some point, I'm not going to use MC++ just for that one call - it's much easier to just set up the P/Invoke, and be done with it. While it would be possible to convert the unmanaged prototype to managed code, why not make the job easier by just copying and pasting?
ReplyDelete>>why not make the job easier by just copying and pasting?
ReplyDeleteBecause it doesn't work that easy. The file was obtained by an automated process, and the result is terrible. For further details, see my comment on the Sells site :
http://www.sellsbrothers.com/news/showTopic.aspx?ixTopic=689&ixReplies=1
In short, if you are willing to use this library of preinteroped functions, please make sure you know how to premarshal unsafe pointers.
While I'm perfectly willing to grant you that the quality of the generated code might be poor (I haven't examined it in depth), I think there's a flaw in your argument. You say that people should just use MC++ because they'll have a hard time figuring out PInvoke. Well, I've taught MC++ classes, and I'm of the opinion that it's just as hard to figure out. So perhaps what we both agree on is that interop is difficult, and you have to understand what's going on. Whether you use MC++ or not.
ReplyDeleteAs far as the argument around performance, I can buy what you're saying for chatty transitions across the managed boundary, but it doesn't hold for what I think is the more common case, where I do most of my work in managed space, and once in a while have to call over to Win32 for something. In that case, the productivity benefits of working in C# (it's just easier than MC++) are going to be a major deciding factor for most projects.
But like I said, I'm willing to grant you that these particular interop declarations have some holes in them - as with any architectural decision, you have to understand what you're working with.
>> the productivity benefits of working in C# (it's just easier than MC++) are going to be a major deciding factor for most projects.
ReplyDeleteI thought .NET was about interoperable languages. I write a library with MC++ where I have all the platform specific logic.
Then I have UI, managers, and so on done in C#, VB.NET or whatever I might like. I only need to reference the MC++ library. Doing so, the languages are used for what they provide best. Yes, writing apps bottom-up using C# is faster than with C++ (MFC or the like).
While it's great that we can interoperate in .NET, I would argue that this is of primary benefit between vendors and customers, not between developers on the same time. For political and fiscal reasons, most companies (or departments) will tend to have developers standardize on a single language. They can still buy components written in any language, but there is a very real overhead for them having to maintain a source base that consists of multiple languages. And MC++ is hard for most people.
ReplyDeleteIt's certainly true that you see teams made up of a bunch of junior developers and one senior guy who handles the low level muck, in which case it might be feasible to take this approach. But that's not always the case, and even when it is, senior developers don't necessarily have the time to have to learn yet another languge, especially one as messy as MC++.
>> And MC++ is hard for most people
ReplyDeleteTell this to the Quake II .NET guy. :-)
How could he recompile the whole quake engine in a matter of days if MC++ was THAT cumbersome?
MC++ is hard for (syntaxically IMHO) for VB programmers. But please tell me what is easy for VB programmers other than drag&dropping components without being seen. :-)
I like the idea that "low-level" application logic requires senior people . What we'll be regarded (C++) as assembly language in just ten years ahead. This is kinda relief for us people in our 30s. You sure understand my point.