home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!olivea!apple!cambridge.apple.com!lindahl@cse.uta.edu
- From: lindahl@cse.uta.edu (Charlie Lindahl)
- Newsgroups: comp.lang.lisp.mcl
- Subject: Shared Libraries for MCL
- Message-ID: <9301112214.AA15026@cse.uta.edu>
- Date: 11 Jan 93 22:14:11 GMT
- Sender: info-mcl-request@cambridge.apple.com
- Lines: 36
- Approved: comp.lang.lisp.mcl@Cambridge.Apple.C0M
-
- I've been following this discussion with some interest, and thot I'd throw
- my $.02 in.
-
- I, too, favor a shared library approach. It has proven successful in
- UNIX environments (both for code size and for sharing of code, i.e.,
- allowing multiple MCL executables to run at once).
-
- Some precedents:
-
- 1) Visual Basic in Windows (no, I'm FAR from a big Windows fan)
- This requires a DLL (Dynamic Link Library) to run .exes generated from
- Visual Basic. However, a small-to-medium scale application (interface-
- wise) consumed only 14K of disk space (the DLL takes 360K).
-
- The VB DLL is available on public archives; therefore, I assume it is
- available from other sources, as well. This means that developers can
- distribute relatively small .exe files, and can still rely on having
- a reasonable set of functions available at all times.
-
- 2) Frontier
- Ditto with the Frontier Runtime (shareware, $25).
-
- 3) HYPERCARD
-
- I don't think that tree-shaking will work either, for the reasons given
- in previous discussions (lack of support for EVAL, READ).
-
- Later,
- Charlie
- ============================================================================
- Keep an open mind ... but not so | Charlie S. Lindahl
- open that your brain falls out. | lindahl@cse.uta.edu
- -- Gerald Coates | Electrical Engineering Dept
- | University of Texas at Arlington
- ----------------------------------------------------------------------------
- Disclaimer: #include <std/disclaimer.h>
-