Dr. Dobb's Journal October 2001
Dear DDJ,
After reading Jonathan Erickson's "A Ringside Seat" editorial (DDJ, August 2001), it occurred to me that Microsoft will be confronted with another kind of "shared source" soon leakage. Secrets, especially explosive secrets, do not normally stay secrets. Sooner or later, they get "outed," in the fashion of Spycatcher or the Pentagon Papers. Leakage is simply the normal condition of a large organization. Auto-makers have always had access to contraband copies of each other's blueprints, but since the auto industry does not deal in pure information, this has not had any very radical consequences.
Microsoft, like most of the other firms in the mass-production merchant software industry, has hitherto been able to keep its employees in line by extremely generous stock option plans. The whole social and economic system of such companies has been premised on endless rapid growth. To take one example, Fred Moody pointed out in I Sing the Body Electric that Microsoft temporary or "contract" employees were already counting the profits they would make on shares they would buy with options they would get when they were promoted to full-time status. To take another instance, even fired Microsoft employees have been preoccupied with negotiating or litigating or legislatively lobbying their stock option claims. With the NASDAQ meltdown, such castles-in-the-air have been brutally smashed. SEC rules for stock option disclosure will inevitably become more severe, and it will become much more difficult to give junior employees "a piece of the action." I do not know how many Microsoft employee shareholders lost their stock to margin calls, but there seems to be an increasingly large alienated class among them. Even if former employees do not possess source code, they do have memories, which will substantially aid them in using reverse engineering tools on published Microsoft machine code.
The governments of many foreign countries are much more actively antagonistic to Microsoft than the government of the United States is, and on anti-trust grounds, they may provide safe-haven for reverse engineering activities. To take an analogous case, Peter Wright, the author of Spycatcher (Dell Publishing, 1988; ISBN 9991065474), had signed the British Official Secrets Act. However, laboring under a sense of ill-usage about the British secret service MI-5's failure to give him a pension, he went off to Australia to make a fresh start. The fresh start turned out to consist in writing his memoirs from memory under the protection of the Australian government and legal system. All of the developed former British colonial countries (notably Canada, Ireland, Australia, and New Zealand) tend to be extremely touchy about anything smacking of Anglo-American imperialism, whether political, economic, legal, or cultural. Thus, it came to pass that a senior British official, trying to block the publication of Spycatcher, was publicly humiliated in an Australian court, and forced to confess himself a perjurer. MI-5 would have found a pension much cheaper in the end.
What goes for MI-5 also goes for Microsoft. Since the Windows source code is inevitably going to be published, one way or another, Microsoft's only real choice is to make a virtue of necessity, and sell it, for whatever price Microsoft can get, to someone representing the public domain. That someone will probably be the United States Government.
Andrew D. Todd
Jonathan responds: Gee, Andrew, and some people call me a cynic. I'd counter by stating that most Microsoft employees, in truth, aren't motivated by money alone, and can be counted upon to do what's honorable. As an aside, the British government isn't alone in trying to suppress information. The U.S. government is currently attempting to suppress publication of Wen Ho Lee's book, My Country versus Me: The First-Hand Account by the Los Alamos Scientist Who Was Falsely Accused Being a Spy (Hyperion, 2001; ISBN 0786868031).
Dear DDJ,
Thanks to readers like Dave Methvin (dave@pcpitstop.com), it has come to my attention that my article "Is JavaScript an Object-Oriented Language" (Java Q&A, DDJ, August 2001) has some program errors. The following three lines are incorrect:
propertyR = "propertyR is read only.";
propertyA = parameterA;
propertyB = parameterB;
Instead, they should say:
var propertyR = "propertyR is read only.";
var propertyA = parameterA;
var propertyB = parameterB;
For scoping reasons, the property variables must be declared as var or else they will be global and accessible by any other function, class, or global-level code. The code fix here works with Netscape 6.x and Internet Explorer 5.x.
Nadine McKenzie
Dear DDJ,
I was pleased to see the article "Examining CORBA Interoperability," by Eric Ironside, Letha Etzkorn, and David Zajac, appear in DDJ, June 2001. I was equally pleased to see the article embrace open-source implementations of CORBA ORBs. However, I was disappointed that the authors were unable to meet their goals due to problems they encountered. I was equally disappointed to find several inaccuracies and misunderstandings in the article.
Building distributed systems even small, well-constrained ones can be hard and the details overwhelming. It's unfortunate that the authors either didn't find or didn't use the wealth of information and assistance available for the software they evaluated, because there are substantial resources "out there."
For example, for TAO there are the TAO Users mailing list (tao-users@cs.wustl.edu); OCI (http://www.theaceorb.com/); TAO Developer's Guide, also published by OCI; the cadre of research papers and articles (http://www.cs.wustl.edu/~schmidt/TAO/); taosupport@ociweb.com, seen by OCI support personnel for OCI's releases and OCI customers.
For ORBacus there are the ob-users@orbacus.com mailing list, similar to the tao-users mailing list; support@orbacus.com, reviewed by OOC engineers, usable by those who don't have licenses; the ORBacus web site (http://www.orbacus.com/services/).
For MICO there are http://www.mico.org/ and mico-devel@mico.org, the MICO developers' mailing list.
For Visibroker there are Borland's CORBA Community page (http://community.borland.com/); the VisiBroker FAQs (http://www.borland.com/devsupport/visibroker/faq/), and VisiBroker online documentation (http://www.borland.com/techpubs/visibroker/).
And for general CORBA questions, there's the newsgroup "comp.object.corba" and myriad third-party training courses similar to OCI's "CORBA Programming with C++" four-day course.
We at OCI are committed to making people successful with distributed systems, CORBA, and particularly TAO. That's why we've assembled people, authored a Developer's Guide, and work closely with TAO researchers. We would like for the authors and any readers to be successful in their CORBA endeavors, and stand ready to help.
Chris Cleeland
Dear DDJ,
The article "Selecting EJB Application Servers," by Ragae Ghaly, Krishna Kothapalli, and Uma Meyyappan (DDJ, September 2001) gave an example with three app servers. At 1 second, App Server 1 has the longest response time, as opposed to the other two at 0.673 and 0.444, respectively. I understand the need to see all the aspects of an app server including pages/sec, trans/sec, cpt, and so on. And I agree with the authors that whichever has the biggest area in the spider graph will likely out-perform the others. But I think the Response Time axis on the spider graph is incorrect. It should be the 100x at the inner-most polygraph and 0x at the outermost polygraph because the longer the response time should contribute less area to the overall performance of the app server. Right?
Richard Huang
Ragae responds: Thanks Richard, you are absolutely right. The response time of App Server 1, should be the least one (0.025 is a good number) compared to the others. We appreciate the feedback. Figure 1 is a corrected spider graph.
Correction
Due to a typographical error, an incorrect e-mail address was given for author Danny Heijl ("The Delphi XML SAX2 Component & MSXML 3.0") in our September issue. He can be contacted at danny.heijl@pandora.be.
DDJ