Compartilhar via

The History of the DCOM Remoting Addon Pack

  • Artigo

I recently wrote about the recent DCOM Remoting Addon pack being available.

Since I'm running out of things to write about, I'll explain the geeky details of how the DCOM addon pack came to be.  This post is for the very bored only or those who are intrigued by the Windows CE Build Process.  There are no profound insights on COM or any other subject, for that matter.

First we had to figure out what to do with DCOM remoting.  We had to either re-port Windows Vista COM or else remove DCOM remoting from the product.  Even though CE is componentized and we could have warned that this component was insecure & should be avoided almost always, NT4 vintage DCOM was *so* insecure that this wasn't enough.  After all, how often do you click through the obnoxious warnings that software pops up?

This was a no win situation.  Even if we wanted to spend the effort to re-port COM, the amount of time needed to do the work and then get it stable (think about how key COM is to the system) didn't allow us to go down this path.  At the same time we knew we had some OEMs who desperately needed DCOM remoting.

So the Group Program Manager, who makes a lot more money than I do for good reason, helped push through the idea of an addon pack.  DCOM remoting would be available only in CE6 if you downloaded a separate product.  The addon pack made our security people happy.  Since you have to go to a website to get the bits, you can't accidentally click on some buttons and end up with it.  It also lets us warn you point blank on the download site what you're getting into in a way less likely to be missed than warning popup box #73.

From the website:

<
"the component contains known MSRC class critical bulletins. Installing the supplemental pack ... is discouraged, and Microsoft assumes no liability if this pack is deployed."
>

How does the DCOM addon pack work?  Ironically for all the time I spent in meetings discussing various aspects of it from biz/legal/security, the actual dev work was straightforward.  On NT4, DCOM has the concept of loadable transport DLL's to actually do the heavy lifting of talking to the transport layer.  rpcltscm.dll & rpcltscm.dll. 

The way PB builds MS doesn't ship these DLL's but instead rpcltscm.lib and rpcltscm.lib, and under the covers OEMs are building the DLL themselves.  We have config files that allow us to specify which files (in this case in public\dcom\oak\lib\<CPU>\...) are shipped out to customers.  So I changed the logic in them so that rpcltscm.lib & rpcltscm.lib were no longer shipped, even though they were still building.  I also changed a few configuration files to add some comments should some geek poke around the build and try to add the DLLs manually.  Check out public\dcom\oak\lib\(dcom.reg & dcom.bib) if you want to see Spaith's warnings.

There was the extra step here of making sure that DCOM didn't have any direct calls to Winsock or other networking layer technology to do an end-round the transport DLL layer.  It doesn't.  I was impressed with the cleanliness of the design.  I anticipated whacking out winsock calls thrown all over the place and had given myself a lot more time on the schedule than I actually needed.  Of course a lot of other work that I underestimated ended up filling the free time I had!

So the addon pack is basically just an MSI installer, various EULA's (the most important piece from a biz perspective), and the libraries. 

At the time of shipping this I joked about trying to get a ship-it award, which would be riduculous given that I hardly spent a few weeks on this.  (Other ship-its have taken me +1 year of work).  The Group PM said in all seriousness he'd try to make it happen, but I think it's best to let it drop.

John

Comments