From owner-freebsd-hackers Tue Apr 22 13:40:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA02518 for hackers-outgoing; Tue, 22 Apr 1997 13:40:10 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA02491 for ; Tue, 22 Apr 1997 13:40:06 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA27003; Tue, 22 Apr 1997 13:34:20 -0700 From: Terry Lambert Message-Id: <199704222034.NAA27003@phaeton.artisoft.com> Subject: Re: Dynamic linking libraries [Q] To: rssh@cki.ipri.kiev.ua Date: Tue, 22 Apr 1997 13:34:20 -0700 (MST) Cc: gurney_j@resnet.uoregon.edu, freebsd-hackers@freebsd.org In-Reply-To: <335CD2F6.1429@cki.ipri.kiev.ua> from "Ruslan Shevchenko" at Apr 22, 97 06:02:10 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > Are anybody thinking about implementation of stuff ? > > > (not .so, simular to win DLL) > > > > they already exist as shared libs... then if you want something more > > like DLL... take a look at dlopen... you can use that to load shared > > libs into memory and make calls into the library... > > > > Problem: I can't share *one* copy of shared library > by different programs This is false. There is only one instance of the vnode in vore, and there is only one list of page buffers hung off the vnode representing the in disk file data contained in the shared object. What *is* different is: 1) User processes operate in seperate address spaces; the pages associated with the vnode are mapped into each processes address space. This is no different from how Win95 handles DLL's. 2) The static data in the shared object is statically linked into the process image instead of being instantiated each time. The reasons for this are: A) The MS vtable is slightly different from the less correct GCC vtable implementation. FreeBSD does not do fixups (this means the FreeBSD vtable is shared between processes and the MS vtable is not). B) There is no section attribution available in a.out shared object format, so the section information can not be used to distinguish global data. C) UNIX (and clone) system processes can not share address space in this way; MS uses user space mappings, which violate the protection between processes interfering with each other. Effectively, this is the same as if you had placed the data in the "LIB" proxy stub instead of the DLL under MS. So most of what you want is already there. The data stuff is desirable, if only to get around the LGPL "included code" (virtual base classes) and "relink" (data and code associated with a library not part of the image) clauses, but is not necessary... you can either write dataless functions, or create the data via constructor (assuming C++) or via ctor/dtor linker sets (assuming C or some other language). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.