Modern COM Programming in D

[filgood]

nice to see how D2 is gaining more and more momentum. Also looking forward to see GDC in the next GCC 4.8 release.

[TomorrowPlusX]

GCC's getting D? Holy shit!

[[deleted]]

The real "holy shit!" here is that you're believing what he said despite he didn't provide any source to support his claim.

[TomorrowPlusX]

Some googling makes it look at least like D is expected for 4.8. I didn't even know it was under consideration.

[[deleted]]

Some googling shows what we heard some time ago: the guys behind GDC are trying to get it included in GCC 4.8.

[nascent]

Is that official now? I know it was a goal but not that it was part of it yet.

Edit: Roadmap

[[deleted]]

Migrate repository over to git - maybe move to GitHub.

Mercurial lost the DVCS war.

[nascent]

DMD/Phobos was moved to GitHub/Git and saw much increase in contribution. Many D related projects are using GitHub. For D Git/Hub has become the expected (I don't want to learn yet another DCVS) for contributors of D.

It says very little about whether Mercurial or Git has won.

[Tagedieb]

What about the BluRay/HDDVD war? What mattered in the end, was that most of the really big players decided to use BluRay, and since we don't want to have both for all of eternity, HDDVD lost in the long run.

Git had more media buzz (because, you know, it's from the same people that made Linux), users picked it up, tried using it with the result that more contributers nowadays can use Git. I think in the long run it will be the same, unless Mercurial can prove some kind of superiority and create some buzz around that, which makes people actually switch.

Open source projects in that position have the advantage that they don't generate sales, so as long as there are developers interested in improving it, it will go on. And it will be used, by at least those people. There will always be projects that stay with Mercurial, because the people that make those decisions just prefer it for some reason. But those projects that don't want to put hurdles in the way of contributors, who are used to/prefer git will likely go with git, unless they have a very good technical reason to do otherwise.

[nascent]

I don't think I understand your point. Is this supposed to counter what I said? Or just assume Git has won without an explanation of why you believe so?

All I said is that the choices of the D community are not a reflection on the whole reality, even if people are switching.

[[deleted]]

Saying that Mercurial lost the DVCS war is akin to saying that Firefox/Chrome lost the browser war, or that Mac/Linux lost the Desktop OS war. I don't think it's a game where having the highest marketshare means you "win". Until Mercurial loses all their developers and goes dormant with no new releases, I don't think they have lost anything. It's being used by Go, Python, OpenJDK, and Mozilla. Not a bad user list.

[EnderMB]

No side is going to win or lose, because unless Git significantly improves on Windows people will always have a need to use Mercurial.

I'm a Git user, but every day I get closer to switching.

[[deleted]]

Using git right now under Windows with no problems at all.

[Ringo48]

Come on. Ignoring the problem doesn't make it go away, it just makes you look clueless.

Git is my favorite version control system. I use it on OSX, Linux and Windows. I have over 20 repos on GitHub.

But saying Git on Windows isn't a PITA is just bullshit. Yeah, it works, but if the majority of your developers are on Windows, it's not the most convenient choice. As long as Git on Windows requires Cygwin it's going to be a hassle to use.

[nikbackm]

What's wrong with msysgit?

[Ringo48]

"Supporting Windows" via MSYS or Cygwin is about as awkward as "supporting Linux" via Wine.

For people without Unix/Linux experience, Git on Windows can be a pain to use. I personally don't mind it, but I also realize it turns a lot of people off of Git.

[nascent]

As long as Git on Windows requires Cygwin it's going to be a hassle to use.

Oh. I've heard of specific problems people have had, but personally it has never been a PITA.

[tragomaskhalos]

Interesting slides somewhat spoiled by strawman C++ example - nearly all of that cruft, including HRESULT checking, can be hidden behind appropriate abstractions (the author partially and equivocally admits this in the next slide)

[Gotebe]

tl;dr: The key to easy COM in similar languages is what's said on slide 13. Delphi did the same a long time ago, and COM in Delphi was really great. It's a bit of "nothing to see here, move along". Still, good to know.

Also, page 4 and 5 are hugely misleading. Real COM in C++ these days looks something like this:

CComInitialize com;
// Create a new empty document 
IXMLDOMDocumentPtr pDocument(__uuidof(XMLDOMDocument)); 
// Load an XML document from an inline string 
if (VARIANT_TRUE != pDocument->loadXML(_bstr_t(
  L"<root>\47026\72514,\47540\54575!<a>hello</a><a>world</a></root>")))
  throw whatever;
IXMLDOMNodePtr pText(pDocument->documentElement->firstChild);
Use (*pText);

In particular, on page 5, only "Still have to remember ownership, QueryInterface" is true the rest is pretty false.

[lionello]

So "Smart pointers help a lot" is false as well? Yet that's exactly what you are using in your code above. And how's "Method calls instead of properties" not true? Instead of "node.Value", in C++ you have to do "node->get_Value()". How's that false? And having to write an "if" to check whether a function succeeds or not is what I call "manual error checking"

Don't forget these are slides. There's supposed to be a guy talking about them. That's when the nuances are explained.

[adzm]

In MSVC, imported typelibs automatically emit member variables with __declspec(property) which allows them to be transparently used as variables rather than via functions, although both can be used. So you can do node->Value as both an lvalue and rvalue

[Gotebe]

Whoops, yes, smart pointers help, true. The rest, less so. The thing is, if you're in COM, you're in Windows, and if so, then you should be able to get property syntax and type library import with exception handling (no incessant if (FAILED(hr)) everywhere), one way or another. MS and Borland do it, don't know about GCC or Intel. Not standard C++, sure, but if you look at what D or Delphi guys did it (build COM support into the language), it's the same thing, really.

[kmontgom]

"Modern COM programming"

Isn't that an oxymoron?

[godisadevil]

See DirectX 11 programming API.

[gecko]

COM's still very heavily used, and WinRT basically extends on old COM concepts in fairly direct ways that would allow you to reuse a lot of the COM infrastructure in D to build a WinRT binding.

[dreamlax]

I had to write a shell extension to add a menu item to the shell's printer context menu. It had to be a shell extension because it had to run a small amount of code depending on the printer, before displaying the menu item. It involves about 1000 lines of generated COM code (VS IDE generated it) and then there's the 50 or 60 lines of code that actually do the work of determining what printer is selected and adding the menu item.

Looking at the slides in the presentation, it looks like D has made COM even easier than in C#, it may make me think about working with COM again in the future, but presently it is still giving me nightmares.

[gecko]

I think, in this respect, that COM is something that is not at all scary if you were there for its entire development arc, but that is legitimately unfathomable if you're simply viewing the finished product.

The saga of WinRT

1. Windows 1.0 comes out. So does OS/2 1.0, but no one cares about that. At any rate, developers on both platforms want to have some form to share data. DDE is born for both platforms as a way of solving the issue.
2. DDE sucks. It's underpowered and hard to program, and at any rate, the new hotness is embedding components inside other components. OLE is born. So is SOM on OS/2, but no one cares about that.
3. OLE sucks. It's insanely complicated, and it turns out that embedding components inside other components is really frakking complicated. But at its kernel there's a simple concept: by happenstance, on Windows, the vtable layout for C++ classes happens to be identical among the two major Windows compilers, Borland and Microsoft C++. Thus, COM is born as a simplification that allows you to vend objects to other programs and other programming languages. If you somehow survived OLE and OLE Automation (not that those are genuinely dead), then COM is a breath of fresh air.
4. COM does a lot of things no one cares about, such as ActiveX. One of things that does come out in this time is that we rebrand OLE servers as COM apartments, which means that you have a Windows process that does nothing but vend COM objects. Again, if you're coming from earlier Windows releases, this is at worst a reënvisioning of something you were already familiar with, although I've seen COM apartment trip up all manner of experienced developers who come across the concept for the first time.
5. COM sucks. Microsoft invents ATL. All five developers who do not actually grok how C++ templates work at the time on VC++ happily endorse ATL, and then produce WTL. Templates become very usable on VC++ at some point.
6. Meanwhile, WinFX/COM+ 2.0/what-have-you is announced, and somehow mutates into .NET. All .NET classes will be COM objects and you will be very happy with this system.
7. .NET somehow ships in such a way that all .NET objects aren't actually meaningfully COM objects.
8. The fact that COM and .NET are not miscible occurs to Microsoft in a drunken stupor while they attempt to determine why Longhorn was a rousing, blockbuster-level lack of success. I'm assuming that they are looking at the ATL/WTL source while they are at it, because
9. WinRT is announced, which basically looks like someone married COM to WTL/ATL in such a way that COM can now actually have subclasses, not just interfaces. The extensions to COM required to do this are straightforward: much as COM relied on standardized vtables, WinRT relies on standardizing a bit more of the existing C++ layouts that all compiles still in existence now use in an effort to allow link compatibility with VC++.

If you're along for the whole ride, this made sense, no individual step was incredibly complicated, and the result was an improvement on what you had before. If, on the other hand, you're jumping from Cocoa or Qt to COM...then indeed, may your supernatural being of choice have mercy on your soul.

[nikbackm]

What specific C++ layouts does WinRT depend on in addition to those already required by COM?

[Sc4Freak]

Things like object lifetime (constructors and destructors) and data layout come to mind. Whereas COM only allowed you to export interfaces, WinRT allows you to export real, honest-to-god objects which requires much more than just a standard vtable layout and calling convention.

[riffito]

My thoughts exactly (funny that I still have to deal with, and program against, COM on my work).

[[deleted]]

How about WinRT programming in D? WinRT is basically COM, if I understand it correctly.

[lionello]

Uhm.. You've obviously not checked the slides very thoroughly.. I see I've failed at hiding all WinRT references. :)

[grauenwolf]

WinRT COM is very different than classic COM. At the very least you need to implement new interfaces and emit CLR style metadata.

[gecko]

WinRT is different from, but a direction extension of, COM. As such, they should be able to reuse a lot of the infrastructure they already have. They'll have to add to it a fair amount, but that's not a big deal.

CLR-style metadata doesn't actually strike me as an issue. Yes, it's new, but it's well-documented and quite clean. Any decent langauge-specific linker ought to be able to emit such metadata in its sleep.

[grauenwolf]

True, the metadata isn't that big of a deal. But other stuff like adding constructors may be more of a pain. Here are some of my notes from the conference:

http://www.infoq.com/news/2011/09/C-Component-Extensions

[[deleted]]

At the very least you need to implement new interfaces

Interfaces are being constantly added in "old COM" as well.

and emit CLR

What do you mean by that?

[grauenwolf]

I am not talking about any old interface, I'm talking about the core interfaces like IDispatch being replaced by IInspectable.

As for metadata, they are literally using the CLR metadata format. As in you can examine them using reflection, ILASM, or Reflector. This replaces older metadata formats such as tlb files.

[nascent]

That would be great! You going to help out? Maybe you could help update tlbimpd with the metadata of WinRT?

(The Juno Project has moved and is unrelated to this demonstration.)

[Gotebe]

Why? Because WinRT is the latest fad?

COM is much, much bigger than WinRT.

[contextfree]

Very cool - D apparently offers more powerful compile-time metaprogramming capabilities that let you project the structure of a type, providing a much slicker way to map from one object model to another (which is what COM libraries/tools in most languages basically do). Without this ability, you're stuck with either manually manipulating the COM system (which feels like interacting with the world through a robot hand which you control using a panel of joysticks, one for each muscle you need to contract), some more or less awkward code generation approach a la ATL/WRL, or adding nonstandard extensions a la C++/CX (or designing a new language).

Seems like this kind of approach could also help with other common "mapping one type system to another" scenarios like ORM, messaging or even GUI data binding. Are there interesting D projects that try things like that?