There is a danger here that I remember from the win95 Local Interbase.
On most systems, there is only one C library. If there can
be more than one, there is some chance that an application and
a shared library that it links to use different RTLs. The danger
is that the program (or actually, the programmer ;-) may blindly assume
that the internal structures of one are compatible with the other.

On win95, we had the following situation:
Client library, built with MSVC, uses msvcrt.dll to fopen.
Client tool, (wisql), built with borland C uses the borland RTL.

There was a function in the client library which opened a file and
passed a FILE * back to the client app. The client appt then
used the FILE * in a printf or something like that...
Of course a Borland FILE * (as expected by wisql) and Microsoft
FILE * are not the same thing, so GPFs resulted.

The the function in question did something silly like creating
a temporary file, and so we worked around it by returning
a file name or something instead.

Of course your sitiuation is a little different, but I thought it
might be worth mentioning.

Regards.

PS: Thanks for sharing this process with us.

Ann Harrison wrote:

>
> I'd like to describe a late change that is being introduced
> into V6 and the way decisions were made about the necessity
> and the architecture of the change. This time, the discussion
> was face-to-face in the InterBase engineering group. When
> InterBase is open source, this process will occur on the
> developers' list.
>

[...]
--
Reed Mideke
rfm(at)collectivecomputing.com