[31599] in Perl-Users-Digest
Perl-Users Digest, Issue: 2858 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Mar 9 00:09:28 2010
Date: Mon, 8 Mar 2010 21:09:08 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 8 Mar 2010 Volume: 11 Number: 2858
Today's topics:
convert BMP 256col to raw image data ? <dam-kat-jensen@gmail-kat-.com>
Re: convert BMP 256col to raw image data ? <jl_post@hotmail.com>
Re: Detecting Bourne (or csh) shell from Perl <nospam-abuse@ilyaz.org>
Re: Detecting Bourne (or csh) shell from Perl <hjp-usenet2@hjp.at>
Re: Detecting Bourne (or csh) shell from Perl <nospam-abuse@ilyaz.org>
Re: Detecting Bourne (or csh) shell from Perl <ben@morrow.me.uk>
how to deliver a GUI app to an end user <cartercc@gmail.com>
Re: how to deliver a GUI app to an end user <hjp-usenet2@hjp.at>
Re: how to deliver a GUI app to an end user <ben@morrow.me.uk>
Re: how to deliver a GUI app to an end user <john@castleamber.com>
Re: how to deliver a GUI app to an end user <cartercc@gmail.com>
Re: how to deliver a GUI app to an end user <cartercc@gmail.com>
Re: how to deliver a GUI app to an end user <ben@morrow.me.uk>
s///gsi; with a wildcard <jwcarlton@gmail.com>
Re: Win32::AdminMisc Perl 5.10 x64: ActiveState PPD req <ben@morrow.me.uk>
Re: Win32::AdminMisc Perl 5.10 x64: ActiveState PPD req <sisyphus359@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 08 Mar 2010 21:58:09 GMT
From: Torben <dam-kat-jensen@gmail-kat-.com>
Subject: convert BMP 256col to raw image data ?
Message-Id: <Xns9D35E9A79E0Cmyicqgmxnet@130.225.254.104>
Is there a perl-ish way to strip the header off a BMP image and get only
the raw image data ?
My BMP input is 256 color, and I need to have only the image data, like
explained in
http://www.autohotkey.com/forum/topic11179.html
The forum speaks of BMP2RAW which I can call for the file from Perl, but I
would like to do it natively.
Is pack() / unpack () the solution ?
------------------------------
Date: Mon, 8 Mar 2010 14:30:00 -0800 (PST)
From: "jl_post@hotmail.com" <jl_post@hotmail.com>
Subject: Re: convert BMP 256col to raw image data ?
Message-Id: <3eddc08d-12db-469d-bb65-28d75a8d8ad0@u5g2000prd.googlegroups.com>
On Mar 8, 2:58=A0pm, Torben <dam-kat-jen...@gmail-kat-.com> wrote:
> Is there a perl-ish way to strip the header off a BMP image
> and get only the raw image data ?
Unfortunately, there a several variables for BMP files (such as
compressed/non-compressed, different number of bits per pixel), so to
do this correctly you'd have to handle them all.
Are you familiar with *.ppm files (specifically, of type "P6")?
This looks to be just about exactly what you want, where each pixel is
encoded as 24 bits (that is, one byte for RED, one byte for GREEN, and
one byte for BLUE). The only difference is that *.ppm files include a
short header to specify the width, height, and range of intensity
values.
You can read more about this file type here:
http://en.wikipedia.org/wiki/Portable_pixmap
The nice thing about this file format is that several free image
manipulator programs & libraries (such as "ImageMagick", "xv", and
"The Gimp") support this type, so converting an image of a well-known
type to a *.ppm file is very simple.
And writing to this type of file is very simple, as well. Since
there is no compression and just a very short header, all you really
need to know (aside from the width & height of the image) is the RGB
values of each pixel.
As for converting a *.bmp file to a *.ppm file, you'll have to
learn how to read a *.bmp file into an list of pixels, as well as
extract out its width & height. Since there are several variable
things you have to watch out for, it will probably just be better for
you to use a free third-party software tool to convert it to a *.ppm
file for you.
And once you have a *.ppm file, you can just read it in as a binary
file (using Perl if you want), strip off the short header, and you
have exactly what you want!
I hope this helps, Torben.
-- Jean-Luc
------------------------------
Date: Mon, 8 Mar 2010 20:53:46 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Detecting Bourne (or csh) shell from Perl
Message-Id: <slrnhpaouq.auk.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-03-08, Ben Morrow <ben@morrow.me.uk> wrote:
> then: TTBOMK there aren't any C libraries for native Win32 (without any
> sort of Unix emulation layer) which don't use cmd.exe for system(3).
This statement is IMO an oxymoron; system() is ALREADY a part of
"unix-emulation layer". Moreover, IMO any relationship of Perl's
builtins to C library APIs of the same name is at most a coincidence.
When porting, there must be not a design goal to mimic a particular
implementation chosen by a particular C library; consistency with
behaviour on other architectures is a much more important goal.
But now this discussion reduced to the mode of counting angels on the
end of a needle. As a solution to the initial problem I'm currently
testing the horrible error-prone
my $cmd = qq($^X -e "print qq(#include \\x22).shift().qq(\\x22)"
"$filename" | $Cpp->{cppstdin} $Defines $addincludes
$Cpp->{cppflags} $Cpp->{cppminus} |);
...
Ilya
------------------------------
Date: Mon, 8 Mar 2010 23:31:32 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Detecting Bourne (or csh) shell from Perl
Message-Id: <slrnhpaum4.t89.hjp-usenet2@hrunkner.hjp.at>
On 2010-03-08 20:53, Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
> On 2010-03-08, Ben Morrow <ben@morrow.me.uk> wrote:
>> then: TTBOMK there aren't any C libraries for native Win32 (without any
>> sort of Unix emulation layer) which don't use cmd.exe for system(3).
>
> This statement is IMO an oxymoron; system() is ALREADY a part of
> "unix-emulation layer".
Only if you count C itself as part of the "unix-emulation layer".
hp
------------------------------
Date: Tue, 9 Mar 2010 02:33:39 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Detecting Bourne (or csh) shell from Perl
Message-Id: <slrnhpbcs3.99d.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-03-08, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
> On 2010-03-08 20:53, Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
>> On 2010-03-08, Ben Morrow <ben@morrow.me.uk> wrote:
>>> then: TTBOMK there aren't any C libraries for native Win32 (without any
>>> sort of Unix emulation layer) which don't use cmd.exe for system(3).
>>
>> This statement is IMO an oxymoron; system() is ALREADY a part of
>> "unix-emulation layer".
>
> Only if you count C itself as part of the "unix-emulation layer".
No. system() is not a part of C.
BTW, let me clarify: I suspect what is a "Unix emulation layer" for
Ben is just "implementation of POSIX APIs on top of
`(the-given-)system'-calls" for me...
Yours,
Ilya
------------------------------
Date: Tue, 9 Mar 2010 03:35:10 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Detecting Bourne (or csh) shell from Perl
Message-Id: <e8sg67-8ob.ln1@osiris.mauzo.dyndns.org>
Quoth Ilya Zakharevich <nospam-abuse@ilyaz.org>:
> On 2010-03-08, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
> > On 2010-03-08 20:53, Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
> >> On 2010-03-08, Ben Morrow <ben@morrow.me.uk> wrote:
> >>> then: TTBOMK there aren't any C libraries for native Win32 (without any
> >>> sort of Unix emulation layer) which don't use cmd.exe for system(3).
> >>
> >> This statement is IMO an oxymoron; system() is ALREADY a part of
> >> "unix-emulation layer".
> >
> > Only if you count C itself as part of the "unix-emulation layer".
>
> No. system() is not a part of C.
It's in the standard library, so it's part of C. (Unlike, say, open(2),
which isn't.)
> BTW, let me clarify: I suspect what is a "Unix emulation layer" for
> Ben is just "implementation of POSIX APIs on top of
> `(the-given-)system'-calls" for me...
No. I consider Cygwin &c. emulation layers because they don't just
provide libc, they also remap the filesystem[0] and (attempt to) provide
Unixish kernel-level services like fork and ptys which aren't
implemented in NT. From the point of view of an application program like
perl, Cygwin behaves a lot more like a rather strange Unix than it does
like some variant of Win32, which is why $^O is different.
Ben
[0] Yes, I am aware that Win32 also remaps the filesystem relative to
the NT kernel, and that Interix is probably better described as 'a
separate OS running over the NT microkernel' than 'an emulation layer
running over Win32'.
------------------------------
Date: Mon, 8 Mar 2010 15:17:33 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: how to deliver a GUI app to an end user
Message-Id: <ba34f9b8-52ac-485c-a707-96399047ee9b@j27g2000yqn.googlegroups.com>
This has a bit of history behind it, which I won't relate at the cost
of possibly misleading you. The process is a large, critical process,
consisting of the preparation and delivery of several thousand vendor
contracts five times a year. My previous involvement has been on the
back end, furnishing the data files for the 'end user' to use for
preparation of the contracts.
Due to a number of changes, including personnel changes, major new
requirements, hiring freezes, software obsolescence, purchase order
holds, and license restrictions, we (read 'I') have a problem and it
seems beyond my ability to solve.
I had written (several years ago) three Perl scripts running on the
CLI, the first querying the database and munging the data, the second
preparing the individual contracts as PDFs, and the third delivering
the contracts to the vendors. Only the first script was used, since
the people responsible used a point and click application to prepare
and email the contracts. (Alpha 5 was the software used.)
As a result of the changes mentioned, I dusted off the scripts I had
written, revised them to meet the new requirements, and they work
flawlessly, meeting the new requirements to perfection, and (being
automated) do the job in a fraction of a second without error
(previously took a couple of days and was error prone.) It's ready to
roll.
Here's the problem: the employee charged with the contracting process
is not capable of running scripts from the CLI, but can only point and
click, and besides, cannot (due to IA policy) install Perl on her
machine. Due to policy, I'm not allowed to run end user processes,
such as the preparation of the contracts.
I've toyed with the idea of rewriting the app in Java, or perhaps
using .NET to build a graphical interface to the Perl scripts, but
this isn't my area and I really don't want to do this. I also toyed
with the idea of putting the whole thing on a web server and giving
her access through a browser, but that's probably a violation of IA
policy as well (never mind the fact that it will be on the intranet.)
Ideas?
Thanks, CC.
------------------------------
Date: Tue, 9 Mar 2010 00:41:15 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: how to deliver a GUI app to an end user
Message-Id: <slrnhpb2or.5f9.hjp-usenet2@hrunkner.hjp.at>
On 2010-03-08 23:17, ccc31807 <cartercc@gmail.com> wrote:
> Here's the problem: the employee charged with the contracting process
> is not capable of running scripts from the CLI, but can only point and
> click, and besides, cannot (due to IA policy) install Perl on her
> machine. Due to policy, I'm not allowed to run end user processes,
> such as the preparation of the contracts.
Must this program run on the user's machine?
* If not: How about running them on the server and putting a
minimalistic Web GUI in front of it?
* If yes, is there a policy against perl specifically or against
unauthorized software in general?
hp
------------------------------
Date: Tue, 9 Mar 2010 00:09:17 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: how to deliver a GUI app to an end user
Message-Id: <d6gg67-td7.ln1@osiris.mauzo.dyndns.org>
Quoth ccc31807 <cartercc@gmail.com>:
>
> Here's the problem: the employee charged with the contracting process
> is not capable of running scripts from the CLI, but can only point and
> click, and besides, cannot (due to IA policy) install Perl on her
> machine. Due to policy, I'm not allowed to run end user processes,
> such as the preparation of the contracts.
There aren't any solutions which don't violate the spirit of that
restriction: whatever reasons are given for refusing to install perl
apply just as much to any app written in Perl. However, if the
restriction is simply 'may not install perl', and you would accept a
solution that includes a perl interpreter somewhere, there are several
options.
The most obvious is PAR. This will give you a single binary which can be
deployed to the end-user. The disadvantages are that the unpacking
process can be a little slow (though with modern machines this isn't a
problem, IME) and that, particularly with toolkits like Wx that use
clever dynamic loading tricks, it can be sometimes be tricky to get the
app packed correctly. The par@perl.org list is generally helpful when
problems arise.
The next most obvious is simply to install perl on your machine, install
any required modules and a front-end script (possibly converted into an
exe with the appropriate pp invocation), and then pack the whole
directory tree up in a tarball and call it a custom app. If this is a
Win32 app (I believe it is?) it is also fairly straightforward to wrap
that tarball in a 'proper' installer, using the NSIS kit, though under
normal circumstances it won't be possible to customize the install
directory at install time and the compiled-in directory mustn't have any
spaces in its path, which may make admins nervous.
AS Perl provides a reloc_perl program which can alleviate the first
problem by allowing the installer to do a brute-force rewrite of all the
paths in all the files in the tree to point to the new location.
Needless to say this is crude and under the wrong circumstances can fail
dramatically, but AS use it in their own installer and it seems to work
well enough. Strawberry Perl provide a Portable edition, which can in
principle be moved to any directory and continue functioning, but I
can't seem to find any documentation on the limitations (if any). In
both cases I'm fairly sure directories with spaces in are still
unsupported, so an app that installs into Program Files on a normal
WinXP machine is not possible.
After that, I think at the moment you're into pay-for solutions. AS
provide various tools, some of which I think may do what you want; I've
never used any of them so I can't comment.
Of course, you could always help me finish
http://github.com/mauzo/ExtUtils-PerlToExe , but given that I haven't
worked on it for a while and there are more than a few important
unsolved problems I don't know that I'd recommend it... :)
Ben
------------------------------
Date: Mon, 08 Mar 2010 19:38:01 -0600
From: John Bokma <john@castleamber.com>
Subject: Re: how to deliver a GUI app to an end user
Message-Id: <87zl2i2s1y.fsf@castleamber.com>
Ben Morrow <ben@morrow.me.uk> writes:
> The most obvious is PAR. This will give you a single binary which can be
> deployed to the end-user. The disadvantages are that the unpacking
> process can be a little slow (though with modern machines this isn't a
> problem, IME) and that, particularly with toolkits like Wx that use
> clever dynamic loading tricks, it can be sometimes be tricky to get the
> app packed correctly. The par@perl.org list is generally helpful when
> problems arise.
For Perl programs that use Wx I use wxpar, see Wx-Perl-Packager on CPAN.
--
John Bokma j3b
Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development
------------------------------
Date: Mon, 8 Mar 2010 17:59:01 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: how to deliver a GUI app to an end user
Message-Id: <8e1c68e8-0267-402a-b5f4-b384f8ef91ab@15g2000yqi.googlegroups.com>
On Mar 8, 6:41=A0pm, "Peter J. Holzer" <hjp-usen...@hjp.at> wrote:
> Must this program run on the user's machine?
The accepted paradigm is for the Alpha 5 software to run on the
individual's machine that is responsible for sending out the
contracts. This is an entirely separate division, not IT, and the rule
for that department is only Windows apps (Office) and things
ordinarily on a users machine, such as the JVM and .NET runtimes.
>
> * If not: How about running them on the server and putting a
> =A0 minimalistic Web GUI in front of it?
> * If yes, is there a policy against perl specifically or against
> =A0 unauthorized software in general?
Both. Perl is disfavored because it is 'insecure' in the sense that
one can write programs in Perl -- it's really a situation of ignorance
on the part of the managers.
CC
------------------------------
Date: Mon, 8 Mar 2010 18:11:04 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: how to deliver a GUI app to an end user
Message-Id: <81b3503c-77de-4e0d-b80d-6f5bdd38c783@g4g2000yqa.googlegroups.com>
On Mar 8, 7:09=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> The most obvious is PAR. This will give you a single binary which can be
> deployed to the end-user. The disadvantages are that the unpacking
> process can be a little slow (though with modern machines this isn't a
> problem, IME) and that, particularly with toolkits like Wx that use
> clever dynamic loading tricks, it can be sometimes be tricky to get the
> app packed correctly. The p...@perl.org list is generally helpful when
> problems arise.
I've just toyed with PAR, it looked like too much work at the time for
the expected benefit, so I wasn't real interested.
> The next most obvious is simply to install perl on your machine, install
> any required modules and a front-end script (possibly converted into an
> exe with the appropriate pp invocation), and then pack the whole
> directory tree up in a tarball and call it a custom app. If this is a
> Win32 app (I believe it is?) it is also fairly straightforward to wrap
> that tarball in a 'proper' installer, using the NSIS kit, though under
> normal circumstances it won't be possible to customize the install
> directory at install time and the compiled-in directory mustn't have any
> spaces in its path, which may make admins nervous.
I've actually used NSIS to enable updates on non-networked machines,
and (unlike PAR) I do have an interest in learning more about NSIS.
This might be a solution.
> After that, I think at the moment you're into pay-for solutions. AS
> provide various tools, some of which I think may do what you want; I've
> never used any of them so I can't comment.
My solution was to buy the new version of Alpha 5 and continue to use
that. Unfortunately, the guy (a non-IT, professional employee) who
originally developed the process has moved beyond this, and I would be
the one to redevelop the application. The good part is that I believe
Alpha 5 to be a respectable piece of work and I would consider it a
benefit to learn more about it.
> Of course, you could always help me finishhttp://github.com/mauzo/ExtUtil=
s-PerlToExe, but given that I haven't
> worked on it for a while and there are more than a few important
> unsolved problems I don't know that I'd recommend it... :)
I've felt for a long time that the ability to easily generate machine
code from Perl would be a big benefit for the community. I've been
playing with Common Lisp for several years now (as and when I have the
spare time) and I'm really attracted by the fact that:
- you can compile CL into native machine code without having to do
memory management or deal with pointers,
- you can target your CL app to the JVM with ABCL or Clojure, and
- you can achieve very fast code without too much work.
Thanks for your suggestions, CC.
------------------------------
Date: Tue, 9 Mar 2010 02:31:40 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: how to deliver a GUI app to an end user
Message-Id: <chog67-kf8.ln1@osiris.mauzo.dyndns.org>
Quoth ccc31807 <cartercc@gmail.com>:
> On Mar 8, 7:09 pm, Ben Morrow <b...@morrow.me.uk> wrote:
> > The most obvious is PAR. This will give you a single binary which can be
> > deployed to the end-user. The disadvantages are that the unpacking
> > process can be a little slow (though with modern machines this isn't a
> > problem, IME) and that, particularly with toolkits like Wx that use
> > clever dynamic loading tricks, it can be sometimes be tricky to get the
> > app packed correctly. The p...@perl.org list is generally helpful when
> > problems arise.
>
> I've just toyed with PAR, it looked like too much work at the time for
> the expected benefit, so I wasn't real interested.
OK, but pretty much any solution which works will require that much
work. This is a tricky problem which isn't solved by any
currently-available (for free) tool.
> > The next most obvious is simply to install perl on your machine, install
> > any required modules and a front-end script (possibly converted into an
> > exe with the appropriate pp invocation), and then pack the whole
> > directory tree up in a tarball and call it a custom app. If this is a
> > Win32 app (I believe it is?) it is also fairly straightforward to wrap
> > that tarball in a 'proper' installer, using the NSIS kit, though under
> > normal circumstances it won't be possible to customize the install
> > directory at install time and the compiled-in directory mustn't have any
> > spaces in its path, which may make admins nervous.
>
> I've actually used NSIS to enable updates on non-networked machines,
> and (unlike PAR) I do have an interest in learning more about NSIS.
> This might be a solution.
If you pack your script into an exe with pp -d (which doesn't have most
of the packaging issues associated with other uses of PAR) you can
delete perl.exe and wperl.exe from the installation and leave the user
with no obvious way to execute arbitrary Perl. It's not a secure
solution, by any means, but it may be enough to mollify a sysadmin.
> > Of course, you could always help me
> finishhttp://github.com/mauzo/ExtUtils-PerlToExe, but given that I
> haven't
> > worked on it for a while and there are more than a few important
> > unsolved problems I don't know that I'd recommend it... :)
>
> I've felt for a long time that the ability to easily generate machine
> code from Perl would be a big benefit for the community.
That project doesn't attempt to do that, and, indeed, it's impossible
without changing the language in several important ways. (Perl 6 was
designed with that aim from the start, and so can easily be compiled to
a stand-alone executable.) EU::PtoE was intended to be basically 'PAR
without the unpacking', using PerlIO::gzip to read the Perl code
straight out of the executable and static linking for the extensions.
Ststic linking is not very well supported, though, so I kept running
into difficulties and moved on to work on other things. One day, for
sure... :)
Ben
------------------------------
Date: Mon, 8 Mar 2010 19:03:03 -0800 (PST)
From: Jason Carlton <jwcarlton@gmail.com>
Subject: s///gsi; with a wildcard
Message-Id: <c6854f42-0679-4051-aa4f-112ed2baf9fc@c16g2000yqd.googlegroups.com>
Every once in awhile, someone will copy and paste into my message
board from Word. After it submits through my Perl script, I'll have
something like this plugged in:
Normal 0 false false false EN-US X-NONE X-NONE
MicrosoftInternetExplorer4 /* Style Definitions */
table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-
rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-
style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-
padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin-top:0in; mso-para-
margin-right:0in; mso-para-margin-bottom:10.0pt; mso-para-margin-left:
0in; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt;
font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-
ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New
Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-
family:Calibri; mso-hansi-theme-font:minor-latin;}
The fonts and all that are different for each post; the only
consistency seems to be that it starts with "Normal 0 false false
false", and it ends with a "}".
Would something as simple as this be enough to consistently remove it?
$comment =~ s/Normal 0 false false false.*?}//gsi;
Or is there more to it than I'm thinking?
------------------------------
Date: Mon, 8 Mar 2010 19:51:44 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Win32::AdminMisc Perl 5.10 x64: ActiveState PPD required
Message-Id: <g31g67-uf5.ln1@osiris.mauzo.dyndns.org>
Quoth Dilbert <dilbert1999@gmail.com>:
> I am trying to install Win32::AdminMisc using a PPD repository for
> ActiveState Perl v 5.10 with 64 bits.
>
> I googled "Win32::AdminMisc 5.10 64 bits ppd" and I came across
> http://www.ramtek.us/downloads.html which had a PPD repository for
> Perl 5.10 at http://www.ramtek.us/cgi-bin/ppmsend.cgi?File=Win32-AdminMisc
>
> So I typed:
>
> C:\>ppm install http://www.ramtek.us/cgi-bin/ppmsend.cgi?File=Win32-AdminMisc
>
> but this failed...
>
> ppm install failed: The PPD does not provide code to install for this
> platform
>
> This is my Perl platform...
>
> C:\>perl -v
> This is perl, v5.10.1 built for MSWin32-x64-multi-thread
^^^
> (with 2 registered patches, see perl -V for more detail)
> Copyright 1987-2009, Larry Wall
> Binary build 1006 [291086] provided by ActiveState http://www.ActiveState.com
> Built Aug 24 2009 13:45:20
>
> ... and this is the content of
> http://www.ramtek.us/cgi-bin/ppmsend.cgi?File=Win32-AdminMisc
>
> <SOFTPKG NAME="Win32-AdminMisc" VERSION="0,2003,07,14">
> <TITLE>Win32::AdminMisc</TITLE>
> <ABSTRACT>The Win32::AdminMisc extension for Win32 X86</ABSTRACT>
> <AUTHOR>Roth Consulting (http://www.roth.net/)</AUTHOR>
>
> <IMPLEMENTATION>
> <OS NAME="MSWin32" />
> <ARCHITECTURE NAME="MSWin32-x86-object" />
^^^
This is a 32-bit ppd.
> Does anybody know of a PPD repository that offers Win32::AdminMisc for
> Perl 5.10 under 64 bits ?
Sorry, no. What compiler do AS use for 64-bit? Presumably not MSVC6,
since that predates Win64. Cutdown versions of MSVC7 and 8 are (or
were) freely available from Microsoft, so you might be able to compile
the extension yourself.
Alternatively, see strawberryperl.com.
Ben
------------------------------
Date: Mon, 8 Mar 2010 19:48:56 -0800 (PST)
From: sisyphus <sisyphus359@gmail.com>
Subject: Re: Win32::AdminMisc Perl 5.10 x64: ActiveState PPD required
Message-Id: <f6dc0ee0-9ed6-4832-8d01-a39527b7bd52@k36g2000prb.googlegroups.com>
On Mar 9, 6:51=A0am, Ben Morrow <b...@morrow.me.uk> wrote:
> Sorry, no. What compiler do AS use for 64-bit?
They use "Microsoft Platform SDK for Windows Server 2003 R2" - which
has a version number of 14.00.40310.41 and is therefore presumably
some sort of variant of MSVC++ 8.0 (Visual Studio 2005). It is freely
available. Afaik, it uses the msvcrt.dll runtime instead of the
msvcr80.dll that the MSVC++ 8.0 compilers use.
> Cutdown versions of MSVC7 and 8 are (or
> were) freely available from Microsoft, so you might be able to compile
> the extension yourself.
Win32::AdminMisc source is supposedly available from
ftp://www.roth.net/pub/ntperl/adminmisc/20030714/source/AdminMisc_Source.Zi=
p
but my browser has been trying unsuccessfully to get hold of it for a
good 10 minutes. (I was going to take a look inside and refresh my
memory on precisely what it contains - but I've now given up.)
If you do manage to get hold of that source you'll find that it
doesn't build in the usual way - ie it's not a normal cpan-type source
distro. From memory, it's set up more as a "Visual Studio Project", so
I'm not sure how well the free MS compilers will handle it.
Is the op aware that you can run 32-bit ActivePerl builds on Win64 ?
That would allow you to install the x86 build of Win32::AdminMisc -
which might be the simplest way to go.
Cheers,
Rob
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 2858
***************************************
