Installshield 6 (inter-proc) patches

[Dan Kegel]

Roger Fujii wrote:
> > If they are in separate files, and one calls the other via a function call
> > that crosses process boundaries (i.e. uses a remote procedure call protocol),
> > there is no linking, at least not by current standards (and I bet this
> > will not change).
> 
> so, given that linux's threading model creates a separate process per thread,

It doesn't.  It creates a new thread that happens to share address space with 
some other threads.  The scheduler schedules threads, not processes.
Perhaps it would be clearer if I said 'address space' instead of 'process'.
(IBM is working on a new threading library that will make you happy, I think;
it makes use of the "thread group" feature in the 2.4 kernel.)

> Or in wine's case,
> you're going to make a distinction between server dlls and client dlls ONLY
> because they cross a process boundary?

Yes.  A call that crosses an address space boundary by using a remote procedure
call protocol is considered remote, and is neither static nor dynamic linking.

> If you think this is ugly, try applying this to java, where the concept of "file"
> (since the classes can be in a zip file) an app (since there is no concept
> of an 'executable' - just entry points), or even a 'process space' is vague.

Replace 'file' with 'class' for java.  That takes care of it, I think.  
I don't think we need to define application.  If we did, 'hunks of
executable code in the same address space/process', or a collection thereof, might do.

> > Header files for LGPL'd works are interesting; if they contain macros
> > or inline functions, those need to be provided under a more liberal
> > license, otherwise they would fit the definition of static linking.
> 
> section 5 is SUPPOSED to address this issue, but it depends on what people
> think "small" means.

Got it.  I really should read the LGPL if I'm going to pontificate about it!

- Dan