Installshield 6 (inter-proc) patches

[Roger Fujii]

Dan Kegel wrote:
> 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.

yes, but threads and processes are not independent.  Look at this:
  http://www.samag.com/documents/s=1148/sam0107a/0107a_s1.htm
It *appears* like a process to the user in the ui (ps has separate PIDs).
The problem is that words like "process" and "linking" really require some
context around them and it's hard to codify that in a document.

> 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.)

Don't think it would change all the much.  Think what 'address space' means
in a NUMA model.  2 threads running in the same address space MAY be running 
on separate processors with a copy of the address space..
 
> > 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.

So, a windows DLL under windows is neither static nor dynamically linked since
the DLLs live in a funky state that is in the 'kernel' process space and not
with the app (at least, this is what I remember).
 
> > 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.

uh, nope.  As java source files can compile into MANY .class files (inner classes).  

> 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.

but this would include everything that that particular jvm is running at the time,
including the "libraries" like swing, and other java.* stuff.

It really is pretty ugly trying to apply *gpl to java.....

-r
-- 
Roger Fujii <rmf at lookhere.com>
Underemployed, and trying to keep it that way....