[Mono-list] Couple of questions

[Jonathan Pryor]

On Mon, 2007-04-16 at 10:04 -0600, Eric Morgan wrote:
> 1.)  Our licensing system does not offer a 64bit library for linux.
> The company says that it should be "backwards compatible", but every
> time we try to P/Invoke into that library on 64bit, it comes back that
> the library is either missing or corrupted.  It's not missing, and
> I've double checked the config file dllmaps, I've pasted the thing
> everywhere.  It sees it, so I think it's saying it's corrupted.  Is
> this expected?  Is there any way to get this 32bit library that we
> currently us (and works) to work on our 64bit machine? 

There are two answers to this question.

1. It's possible to run a 32-bit executable on a 64-bit OS.
2. It's NOT (easily) possible to run a 32-bit library within a 64-bit OS
process.

The problem with (2) is pointer sizes -- a 32-bit pointer can't store
all values that a 64-bit pointer can, so if malloc(3) returns a 64-bit
value (high 32-bits are non-zero), then this pointer address cannot be
used within a 32-bit library.  You might be able to work around this
somehow -- iirc there is an adapter to run the 32-bit Flash plugin
within a 64-bit Firefox process -- but these are going to be special
purpose "hacks."  AFAIK, Win64 has the same limitation.

Which leaves (1) -- running a 32-bit mono on a 64-bit Linux distro,
which is possible and is supported, and will easily permit loading
32-bit libraries, since the pointer sizes do not differ.

> 2.)  We've been thinking about moving our codebase over to linux, but
> the thought of trying to re-set up such a big pile of spaghetti and
> compile it all on linux scares me.  What are the benefits of actually
> compiling our .NET code on linux, vs compiling it in visual studio and
> copying it over?  I've seen so many screenshots of good looking Mono
> apps, and our app just seems to fall short in reponsiveness and crisp
> looks.  Will it look better compiling it natively?  Will our
> underlying algorithms run faster from optimization or something? 

The benefit is that you can more easily know which APIs exist vs. which
don't.  In general, if an API doesn't exist within Mono, we try NOT to
provide the method within the assembly (with a default version throwing
NotImplemetedException()), so that you can use a mcs/gmcs compile to
determine if all the APIs you use actually exist.

(This isn't always possible, so there are several instances where a
NotImplementedException is thrown, but when a NIE can be avoided by
omitting the member, the member is omitted.)

The alternative is to build under .NET and run under Mono, which leaves
you (more) at the mercy of NotImplementedException's or
MissingMememberException.  A decent regression test platform should find
these issues, so this might not be an actual problem.

 - Jon