Don't you believe it.

Microsoft is still world-domination headquarters and supporting COM for Unix should be seen as nothing more than an attempt to love NT's competitors to death. Microsoft has used the same techniques with most of its competition, offering mediocre support for rivals' protocols and sometimes even offering Microsoft products for their platforms. But as any Microsoft Mail for Macintosh user can tell you, support can be, shall we say, uneven.

But Microsoft Promised Microsoft spoke at length about the advantages of COM and the shortcomings of CORBA. Given that the company sees the world this way, it makes perfect sense to port COM everywhere. After all, Microsoft can make some money by selling this superior interapplication communication mechanism on other platforms. Company execs promised me that COM development will be in lockstep on platforms, so no one should fear using it.

I just don't think it will work that way and none of you should either. Total domination of NT as a server and corporate desktop environment is the end game here, and if it furthers that goal to release COM on Unix for a few years, so be it. After that, Microsoft will cite poor sales, low profits or excessive solar flares as a reason for dropping that support, and that's exactly what it will do. Count on it.

Microsoft says it doesn't like CORBA and that it sees lots and lots of problems with it, none of which I'll get into here. Developing COM on its own platforms and touting it as the way to do interapp communication within the various incarnations of Windows is fine. If customers have bought into Windows everywhere, there is no reason not to buy into COM everywhere. However, I think reconciling the extension of that to Unix is just plain wrong.

If Microsoft wants to embrace multiplatform server environments and play within those environments, it should fully participate in CORBA and work within CORBA's committees to fix the spec where it sees deficiencies. As it stands right now, Microsoft's unwillingness to support CORBA leaves application developers with little choice other than to support both COM and CORBA, or use their own methods for communicating between servers and clients.

For in-house application development, the option of choice is simply to scale back application plans so that the COM-versus-CORBA question is a no- brainer. Either the application will deal with NT servers or it will deal with Unix servers--don't try to mix the two.

During our two days in Redmond, we heard a lot about how Microsoft wants to make NT operate on a par with other enterprise applications. Unfortunately, we saw little evidence of that in Microsoft's presentations. While the company's presenters were more polished than on our previous visit--when one product manager referred to a heterogeneous environment as one that contained NT4, NT3.5, Win95 and Win3.1--they offered little more than lip service to supporting mixed environments. Porting COM to other platforms is one of the more concrete things Microsoft has done in terms of multivendor support, but I think it's also a particularly dangerous thing on which to rely.

So what are you to do? Simply be pragmatic. Remember how Microsoft thinks about Unix: It sees it as a market to be conquered. If you see yourself becoming an all-Microsoft shop, then go ahead and use COM on Unix as a transition. But if Unix is strategic to you, stay away from COM.

Send your comments on this column to Art Wittmann at awittmann@nwc.com.