A lot of people have signed up since I sent this message, so I'm sending
it again.  If you have any kind of feedback, please let us know.

If you think everything is fine, and we should just ship it, let us know
as well! :)

Cheers,
-Jan

-----Original Message-----
From: Of Jan Dubois
Sent: October 6, 2004 9:17 AM
To: PDK-Beta@[...].com
Subject: [PDK-Beta] If you want some ideas for testing...

Here are some areas that we are especially interested in receiving
feedback on:

* Side by side installation

PDK 6.0 can be installed alongside earlier versions. It should work
with the Perl that is either first on the PATH or that is specified in
the --perl commandline option. We are aware of the PerlNET syntax
checking problem.

Are there any other scenarios where this new installation outside the
Perl\bin directory fails?

* Dynamic DLL Loader

PerlApp, PerlSvc and PerlTray on Windows use by default a new DLL loader
that bypasses the operating system. This allows us to load DLLs directly
from memory without ever having to write them to disk, so no temp
directory needs to be created. There are some modules, most notably the
Tk module, that still require additional files to be loaded from disk,
but the PDK 6.0 should detect this automatically.

It would be very helpful to us if you could rebuild your existing
PerlApp, PerlSvc or PerlTray applications with PDK 6.0 Beta and test if
they still work. Please report if there are any modules that don't work
properly with the new loader. You can get back to the PDK 5 behavior
using the --nodyndll option.

* Shared library generation

You can now bundle Perl modules into a shared library that can be used
by multiple applications generated by the PDK. For example:

  perlapp --scan myapp1.pl --scan myapp2.pl --shared private --script mylib.pl
  perlapp --use mylib.exe --shared private --xclude --script myapp1.pl
  perlapp --use mylib.exe --shared private --xclude --script myapp2.pl

The mylib.pl file can be either empty or just print a warning that it is
a library and not an application. Please look up --scan, --use and --
shared in the documentation.

This will generate myapp1.exe, myapp2.exe and mylib.exe. You can deploy
these 3 files together with perl58.dll.

You should also look into the --runlib option, which allows you to put
your mylib.exe as well as perl58.dll and other files into a different
directory, e.g.

  perlapp --use mylib.exe --shared private --xclude --runlib lib --script myapp1.pl
  perlapp --use mylib.exe --shared private --xclude --runlib lib --script myapp2.pl

Now you can deploy your code like this

  mydir/myapp1.exe
  mydir/myapp2.exe
  mydir/lib/mylib.exe
  mydir/lib/perl58.dll

This has the advantage that by putting mydir on the PATH you don't put
another copy of perl58.dll on the PATH, which would be a problem if your
user is also having Perl on the PATH, and their Perl is a different
version of Perl than the perl58.dll you are shipping.

* Please try the new GUI interface to the deployment tools

Of course we are also very interested in feedback on the new GUI
interface for PerlApp etc.

The GUI for the deployment tools lets you save your settings in a
project file. You can then later use this project file from the
commandline or a Makefile or build script:

    perlapp myapp.perlapp

* Check out VBSPerl and Filter Builder

Do you find them useful? What would you use them for? What functionality
is missing?

Cheers,
-Jan


_______________________________________________
PDK-Beta@[...].com
http://listserv.ActiveState.com/mailman/listinfo/pdk-beta