Installshield 6 (inter-proc) patches

Dan Kegel dank at kegel.com
Wed Dec 19 11:12:10 CST 2001


Roger Fujii wrote:
> 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.

Yes.

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

An interesting thought.  I'd better sleep on that before commenting.

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

Most windows DLLs are pure userspace and execute in-process, so that's
dynamic linking.  But a windows DLL that implements an operating system
service is explicitly ok to link to, even for (non-L)GPL apps.
How that OS linkage is done is moot, as long as it's not static, I think.

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

That's ok, I think.  The .class files are all related only by dynamic linking.

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

I believe that every interface provided by the Java spec
and implemented by the JDK is a platform/os interface, and thus 
GPL and LGPL apps are specifically allowed to link to it by the GPL/LPGL
os linkage exception.

- Dan




More information about the wine-devel mailing list