Paul,

The question of whether or not redistributing separate shared libraries on
various platforms is a good idea was one of the major points of discussions
when we reworked the entire plugin stuff. You can trivially avoid the
binding problem if you just generate all the plugins as 'builtins' - that is
every plugin is contained in the VM and no platform specific code will ever
be used therefore avoiding any such problems.

   - Andreas

> -----Original Message-----
> From: Paul Fernhout [mailto:pdfernhout at kurtz-fernhout.com]
> Sent: Sunday, June 25, 2000 11:48 AM
> To: squeak at cs.uiuc.edu
> Cc: recipient list not shown
> Subject: Re: How to create a windows pluggable primitive?
> 
> 
> Tim Rowledge wrote:
> > I don't think any thought was given to having multiple 
> users of the same
> > plugin. Certainly can't remember it coming up in 
> discussions. I imagine
> > it might be a problem in some cases; we need to get some info from
> > various OS experts I guess. I don't think I need to worry for Acorn,
> > since the plugin is bound into the vm executable address space.
> 
> Good for the Acorn!  I wonder if the same is true for the Mac 
> and Unix?
> 
> The reason why I care about this issue with Squeak/Windows 
> plugins is if
> I were to ship a Squeak based application using plugins and 
> the user was
> to open two copies of it, then at least one would crash 
> mysteriously. It
> is not that unreasonable to open several copies for a 
> utility, as it is
> common two have several file editors open at once for example. 
> 
> I've always disliked the DLL architecture since I first read 
> about it in
> OS/2 1.0. I believe there are other absurdities intended as features,
> like not loading your DLL is there is one already loaded with the same
> eight (six?) byte internal signature (which may be different from the
> DLL file name). This is one reason why Microsoft recommended 
> putting all
> DLLs in the Windows directory with the file name reflecting the
> signature -- so conflicts might be detected at installation. This (and
> the lack of true backward compatitiblity of most DLLs with 
> the same name
> which is a requirement to make the system work) has led to the
> (rutheless) policy of some vendors of installing over 
> existing DLLs with
> the same name regardless of timestamp to ensure their application runs
> -- even if some other vendor's app gets broken.  This is why you often
> have to reinstall other Windows packages that mysteriously break after
> installing a new Windows application (also breaking other 
> things in the
> process).
> 
> I hope Squeak pluggable primitives (for Windows) can avoid this
> situation. I'd still like to see an approach for loading native code
> that gets linked into the Squeak VM dynamically -- sort of like Forth
> words. (And I've thought some on this.) 
> 
> -Paul Fernhout
> Kurtz-Fernhout Software 
> =========================================================
> Developers of custom software and educational simulations
> Creators of the Garden with Insight(TM) garden simulator
> http://www.kurtz-fernhout.com
>