Re: [DotGNU]Framework Interop on Mac OS/X & platform issues

[Oscar Papel]

See inline

> LD_LIBRARY_PATH is the usual environment variable.  If MacOS X has its own
> pre-existing environment variable for this, then you might consider adding
it
> to the "LoadSystemPath" function in "pnet/image/link.c".  And send me a
> patch.

The frameworks are all located in /System/Library/Framework and
/Library/Framework.
However, since each is located in it's own subdirectory off of these main
paths, I would have to add each framework individually to the
LD_LIBRARY_PATH environment.  Ideally, it would be good if pnet/image/link.c
searched each path in LD_LIBRARY_PATH (including subdirectories) for the
file.  This might not be desirable, however, since dotNET doesn't do this.
I'm not sure if there is a good solution to this problem that will please
all parties.

> Using platform identifiers is a bad way to do this, because some features
are
> common across many platforms and others aren't.  The reason why
> "Platform.Unix" exists is that sometimes it was necessary to know "we are
not
> running on a Windows system".  "NonWindows" might have been a better name,
> but the name "Unix" was chosen for backwards-compatibility with Mono.

I agree with you in general.  Using platform identifers reduce portability
and complicate code and one of  the goals of managed code should be
portabililty and simplicity.

However, I think that they are needed when using Interop.  With interop, you
have specifically "stepped out of the box" and in that case you need as much
information as possible about the platform just as you would in C.  This
type of code is inherently platform specific.  I'm currently coding separate
platform specific interop classes (each implementing a common interface) and
choosing the correct one at runtime, failing gracefully if the current
platform isn't supported.  The alternative is to call each interop class in
turn and wait for an exception to be thrown.  It is a time consuming
operation as each causes a directory search and also does not adequately
solve all problems.

Consider the case of the same library (with the same name) on two different
platforms that need to use a different calling convention or have their
parameters marshalled differently (string is especially platform specific)
This already exists in the Windows world which is why the Platform
enumeration has separate definitions for Win98 and WinNT.  And don't get me
started on the A/W mechanism in Windows. There is currently no way to handle
this problem in general without using platform identifiers.

Also, this does not lend itself to user friendliness.  Let's say I receive a
DLLNotFoundException.  That could mean that this platform doesn't have this
functionality or it could mean that the user is simply missing this file.
If I put up a dialog box telling the user to find and install a particular
file it could cause them to install a file that is not intended for this
platform.  It would lead the user on a wild goose chase.  Or it could
destabilize their system.

I guess the thrust of my rant is that Interop code is never going to be
cross-platform in general and you can't rely on exception handling since it
is expensive, error prone and potentially dangerous.

Oscar.