Andreas -

Thanks for the suggestion. 

For a major application under Windows then I guess that is the way to go
-- use builtins instead of DLLs if you think people might run your
application twice. It's still fairly modular, so that is good. Of
course, this means doing some compiling and then redoing Q&A relative to
the base VM distribution. :-(  But that is probably better than worrying
about what might happen if users really love your program.  Also, it
seems overkill for a small Squeak-based utility, but then again, a
utility probably won't need a plugin.

Perhaps a solution that might be easy to add for Windows if this becomes
an issue in practice is to optionally pass the VM as a parameter if the
DLL requests it or optionally call the setVM function before each VM
call. Of course, this may create confusion with setting flags correctly
and having compatible versions of VMs/DLLs and such.

Alternatively, maybe there should be (or is?) some easy way for a
windows Squeak App using plugins to prevent a second similar app from
running. You can do this in a windows EXE by checking various things.
Sometimes this is done by checking the Windows list for similarly named
apps. Normally though, I would want to run two or more Squeak images for
various apps if I could.

In any case, I think Squeak is just getting better and better -- and in
general, I really like what is happening with pluggable VM components.
And it's unfair of me to come in after a lot of hard work and complain.
In part I was making this comment on Windows DLLs so when months from
now someone asks "Why does my Squeak Windows App crash when I have two
copies open at once", they can find the answer. I've spent a lot of time
learning about windows DLLs -- that's why I avoid them when possible.
Unfortunately, they are pretty much the only game in Windows-town. :-( 
[Maybe we can figure out a way to dynamically load static Windows libs
into Squeak VM memory? ;-) Probably too hard and Windows OS
(95/98/NT/200) version specific though.]

-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

"Raab, Andreas" wrote:
> 
> 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
> >