Re: [Firebird-devel] 64/32 bit handle compatibility

[James K. L. <jkl...@sc...>]

On Thu, 15 Apr 2004, Jim Starkey <ja...@ne...> wrote:
> >Can a 32 bit (compiled) application running on a 64 bit system connect
> >to 64 Firebird ?
> >
> Yes and no.   A 32 bit client can call a 32 bit remote interface that 
> talks to a 64 bit server.  It can't link directly to a 64 bit database 
> engine for embedded use.  In theory it could with a "thunking" library, 
> but I don't think any of the hybrid 32/64 bit systems actually support
> this.
> 
> Vulcan is designed to support simultaneous 32 and 64 processes on a 
> hybrid platform for central server and embedded use with a single 
> install and combined configuration files.

Finally, it's clear to me.  Some newer (not Alpha or Sparc) 64-bit
architectures support 32- and 64-bit addressing modes in a single process.
 On such a chip, a 32-bit clients won't be able to link safely to an
embedded 64-bit server, because their definitions of void* differ.  Is
that it?  

If I understand you correctly, a 32-bit executable could link to a 64-bit
shared object, blithely unaware that their pointers are different sizes. 
It that really true?  Because, if so, it would be a much bigger problem
than our one little handle.  How, for instance, would such a pair exchange
file handles, which POSIX defines as a pointer to a "structure containing
information about a file"?[1]  

Why would anyone choose to run this kind of mixed model, when he could
just recompile one or the other module?  

If it's advantageous to run a 32-bit client and a 64-bit server on the
same machine, would it be just as well to force them to use a remote
interface instead?

--jkl

[1] http://www.opengroup.org/onlinepubs/007904975/basedefs/stdio.h.html