On Sat, 13 Dec 2008, Brian H. Oak wrote:
>  Thank you for all of your help so far. Per your suggestion I
>  uninstalled 5.8 and loaded 5.10 64-bit, and was quite pleased with the
>  PPM coverage. Unfortunately, I have found two deal-breakers:
>  Win32::API and Win32::API::Prototype. There are some others missing,
>  but only these two will break my mainline software.
> 
>  Would some kind soul, pretty please, (1) build these packages manually
>  and post them on the ActiveState repository, (2) suggest alternate
>  packages or a workaround that would obviate my need for these, or (3)
>  point me to the resources and instructions necessary for me to build
>  these packages manually on my own?

Win32::API and Win32::API::Prototype actually need to be "ported" to
64-bit Windows as they deal with calling arbitrary functions in DLLs,
and the current code assumes 32-bitness, calling conventions, etc. It
also contains inline assembly code, IIRC, which isn't supported by the
64-bit compilers.  I believe Cosimo is interested in porting the code
to work under 64-bit Windows, but hasn't actually done any work on it
so far.

It is not really possible to suggest alternatives to these modules
without knowing what you are using them for, as they are only
providing the glue to calling arbitrary code in other DLLs.

If you cannot live without Win32::API then you'll need to run
32-bit Perl for now.

Note also that even with a 64-bit version of Win32::API you won't
be able to call code in 32-bit DLLs; you can only call 64-bit code
inside a 64-bit process, so whatever you are accessing needs to
provide 64-bit DLLs as well.

>  I believe that I don't even have a Win32 C compiler lying around
>  anymore. I remember from a few years ago (the last time I actually
>  rolled my own PPM packages) that I compiled my packages using v7 of
>  Microsoft's compiler, while ActiveState was using the v6 compiler.
>  This slight difference sometimes made it iffy to mix my packages with
>  theirs. If I have to start making my own packages again, I would like
>  all the details on how to do it right from the beginning....

ActivePerl is still compiled with VC6 for various reasons; the
recommended compilers for building extensions are VC6 and MinGW. For
most extensions there should be no problem if you build them with a
later VC version. If you use these modules with PerlApp/Perl2exe/PAR
then you will need to package and auto-extract the additional runtime
libraries for those compilers too (which is one of the reason for
sticking with VC6 or GCC).

I plan to build a PPM package for MinGW by the end of the year, so that
you can install GCC with just `ppm install MinGW` or similar.

All the above is for the 32-bit builds. 64-bit ActivePerl is built with
the VC compiler from the Windows 2003 Platform SDK, and extensions
should be built using the same compiler to make sure they reference the
64-bit version of MSVCRT.dll that is part of all 64-bit Windows releases
and not a compiler specific runtime.

>  One last question, almost totally off-topic: should I have any
>  problems getting PerlApps built on a Windows 64-bit system to run on a
>  32-bit system?

Assuming you use the 32-bit ActivePerl and 32-bit PerlApp there should
be no problems. The 64-bit executables generated by the 64-bit PerlApp
will not run on 32-bit Windows; it only works the other way around
(32-bit code can be executed on 64-bit Windows using the WOW64
subsystem).

Cheers,
-Jan

_______________________________________________
PPM mailing list
PPM@[...].com
http://listserv.ActiveState.com/mailman/listinfo/ppm