Letters

First: We are not a native VB shop. We prefer to deal in real languages.

Second: We partnered with a shop that was a native VB shop.

Third: We constructed scriptable COM+ objects that could be used by the VB shop to do the work that we find essential. These objects will work in anything at all: at least, according to the popular wisdom. These objects were written in C++.

Fourth: As a matter of simple testing, I wrote a simple VB app that would test our COM object in the environment for which it was intended.

Fifth: The object did not work as expected. Review the following code:

Dim oObject

Dim nValue As Long

nValue = 2

Set oObject = (a scriptable COM object)

oObject.nLongParameter1 = 1

oObject.nLongParameter2 = nValue

What can you see in that code that is wrong? Assume, for the sake of argument, that nLongParameter1 and nLongParameter2 are explicitly declared in the scriptable COM object to be a C++ long value, which is always a 32-bit integer. It looks like a slam-dunk, doesn't it? The code must work. It doesn't. The correct syntax is as follows:

Dim oObject

Dim nValue As Long

nValue = 2

Set oObject = (a scriptable COM object) oObject.nLongParameter1 = 1

oObject.nLongParameter2 = CLong( nValue )

Are you confused by that explicit cast in the last statement? According to the documentation, VB can implicitly cast any type to any other type, except for Variant types, which can only be implicitly cast to String or Variant.

There's the rub. VB will take your nValue and explicitly cast it to a Variant before it is passed to the function that accepts nLongParameter2. Since nLongParameter2 is a long, assigning it a Variant value will fail because you are attempting to implicitly cast a Variant to a Long, which is not allowed—that is a "Type Mismatch Error." By including the explicit cast to a Long in the function call, you explicitly cast the Variant type back to a Long, and avoid the Type Mismatch Error that otherwise occurs. Yes, that means that it casts your declared Long to a Variant, and you have to explicitly cast it back.

Why it works with a manifest constant, I cannot say. That has to be a bug. The nearest approximation I can come up with is that if a manifest constant appears in the parameter stream, it is cast to the nearest appropriate type, which is an integer in this test case.

Now, I will struggle to recover my brain from the hell that is VB. Only Bill Gates could have devised this. That is his genius: To make brilliant people go to bed because they have a severe headache.

David Wright

[email protected]

Dear DDJ,

Business Process Outsourcing

Dear DDJ,

In regards to Jonathan Erickson's March 2003 "Editorial" about business process outsourcing, it is important to keep in mind that corporations are required by law to seek the highest return on their investor's capital. If it is economically favorable for them to outsource labor to India, they will do so. It is not useful to think of this as Good or Bad.

It is also unreasonable to deny the social impact of corporate actions, or to ignore the increasing power wielded by corporations. Corporate power was not an issue when the Constitution was framed, and so our government doesn't protect us from it very well. While we can hope for good laws to protect us, we should not bet anything as valuable as our paychecks on it.

We do have other choices; choices overlooked by IT workers in the past when the labor market was tight and we were riding high. We can form labor cartels (that is to say "unions") to counter powerful employers with comparably powerful entities. We can stop work at employers who displace too many domestic workers with H-1B visa workers or outsourcing. We can negotiate contracts that transfer more money from shareholders and CEOs to productive workers.

I've never been a union man. I don't like adversarial contract negotiations, strikes, and lockouts. But I'm also unused to being outsourced like a clerk or laborer. And I'm sickened by the unchecked excesses of corporate greed I'm currently seeing. Somebody needs to field a counterforce against corporate power. The government isn't a good bet. So it's up to us, the people, again.

Kurt Guntheroth

[email protected]

Copy Protection

Dear DDJ,

Bully for Michael Swaine for raising the issue of mathematics regarding copy protection! Shannon's "A Mathematical Theory of Communication" (http://cm.bell-labs.com/cm/ms/what/shannonday/paper.html) firmly staked out the ground: The amount of noise required to swamp out a copy protection mechanism is exactly and irreducibly the amount of information the copy protection introduces to the channel. You can do low-order-bit steganography, but that can be defeated by precisely that amount of low-order noise in the channel. This is why in-media steganography is fundamentally limited (digital-analog-digital transformation is just an introduction of noise into the channel; you're exactly right to elevate the issue from "But I can record my speakers" to its mathematical fundamentals). The strategy of companies like Macrovision is to introduce signals (that is, copy protection) into the channel, not in the media, but into bits that are high-order for the correct functioning of the system (where "functioning of the system" == the complete set of software and hardware infrastructure associated with media play == a Shannon "information channel"). Layers and layers and layers and layers, but the fundamental issue is the signal:noise ratio. It's so simple, I bet you could fit a humorous discussion into a single page essay! :-)

Larry O'Brien

http://www.ThinkingIn.NET/

DDJ