Hi Andreas,

>> 
>>             BTW, the rule in the makefile seems to support my 
>>             suggestion, 'sqNamedPrims.h' only depends on
>>             plugins/plugins.int (actually, it should also
>>             depend on 'Plugins.all' ;-)

> No. sqNamedPrims.h is only required for the internal plugins therefore it
> only depends on plugins.int - there is no requirement for it to depend on
> plugins.ext/all.

    Yes, you are right.
 
    
>>     3/- EXTERNAL_PLUGINS = ADPCMCodecPlugin Squeak3D [...]
>> Actually two things:
>> 
>>     4/- INTERNAL_PLUGINS = AsynchFilePlugin [...]

> What are you trying to say with the above?

    Just a note to myself what can be built as external plugins and what must be
    built as internal from your 3.5.1 release  (and I am hoping that this is just 
    because something is missing from the makefile ;-)

>>     5/- 'UUIDPlugin' unfortunately cannot enjoy the freedom 
>> of an external plugin just because of: [...]

> Have you tried it to see if it works?

    I just run a quick SUnitTest TestRunner on your 3.5.1 (with internal UUIDPlugin)
   and MobVM Mulimedia Release with Squeak 3.5, both failed on :

        TestUUIDPrimitives>>testCreationRandom

    For MobVM, if I removed the UUIDPlugin.dll, I got 9/9, no failure. no errors
    Isn't this interesting ;-)

    BTW, I just discovered that there was a bug in SqMOM.ini for MobVM
    Multimedia release, the section [UUIDPlugin] was missing:

        [UUIDPlugin]
        FileName=UUIDPlugin.dll
        RemoteFileName=UUIDPlugin.dll.gz
        Home=SmallSqueak
        Mirrors=Home2, Home3
        ;; 0: Default ; Never ; 1: Ask ; 2: ; 3: Always
        Update=0 

> Since I'm initializing COM these days directly from the main VM 
> I know this is going to work if it's builtin and the above was a reflection on the fact 
> (e.g., a deliberate decision as I wasn't sure if that's going to work or not).

    How did you test to know that it works ?


    Cheers,

    PhiHo.
     
----- Original Message ----- 
From: "Andreas Raab" <andreas.raab at gmx.de>
To: "'The general-purpose Squeak developers list'" <squeak-dev at lists.squeakfoundation.org>
Sent: Sunday, June 22, 2003 10:26 AM
Subject: RE: [ANN][WIN32] 3.5.1 VM now available


Hi PhiHo,

>         1/- Mpeg3Plugin 'makefile.win32':
>             a/- 'del' should be changed to 'rm' to work on WinXP

Ah, thanks. That's a leftover from the old days.

>             b/- The build with Mpeg3Plugin as external was stalled at:
>                 $(RM) $(LIBOBJ) $(LIB).lib $(LIB).exp $(LIB).def

I think this should be a "-$(RM)" here.

>         2/- 'Plugins.int' and 'Plugins.ext':
>             Should it be more convenient to have 'Plugins.int' and 
>             'Plugins.all' instead ? 

Well, maybe but right now we just have the two (and you can actually build
plugins both internal and external ;-) Though I have to admit the reason for
having those two was ease of use in the makefile.

>             It's less error prone to edit just 'Plugins.int' 
>             instead of both 'Plugins.int' and 'Plugins.ext' .
>             (This comment is just trying to hide how lazy I am ;-)

Use VMMaker! ;-) That's what I've been telling you all along - I am even
more lazy than you are as I cannot even remember which plugins exist and how
they are spelled! ;-)

> 
>             BTW, the rule in the makefile seems to support my 
>             suggestion, 'sqNamedPrims.h' only depends on
>             plugins/plugins.int (actually, it should also
>             depend on 'Plugins.all' ;-)

No. sqNamedPrims.h is only required for the internal plugins therefore it
only depends on plugins.int - there is no requirement for it to depend on
plugins.ext/all.

> Oh, and I forgot one thing:
>
>     3/- EXTERNAL_PLUGINS = ADPCMCodecPlugin Squeak3D [...]
> Actually two things:
> 
>     4/- INTERNAL_PLUGINS = AsynchFilePlugin [...]

What are you trying to say with the above?

>     5/- 'UUIDPlugin' unfortunately cannot enjoy the freedom 
> of an external plugin just because of: [...]

Have you tried it to see if it works? I've been uncertain about whether
CoCreateGuid() requires CoInitialize() and what effect this may have if it's
called from various different libraries under various circumstances (COM
initialization can be tricky at times). Since I'm initializing COM these
days directly from the main VM I know this is going to work if it's builtin
and the above was a reflection on the fact (e.g., a deliberate decision as I
wasn't sure if that's going to work or not).

Cheers,
  - Andreas