Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re: Running compiled Perl script on different Windows Server versions

by sundialsvc4 (Abbot)
on Sep 25, 2019 at 01:59 UTC ( #11106663=note: print w/replies, xml ) Need Help??


in reply to Running compiled Perl script on different Windows Server versions

I suggest that you should carefully explore and then address these client objections, such as "But he wants to avoid third party installations." And then, in turn, to address the subsequent objections that he might presume to be the case: "would not allow the installation of the Perl interpreter under a privileged account."

The client's justifiable concerns for security could in fact be addressed by implementing, within that "privileged account," an entirely self-contained and isolated Perl installation which could, nonetheless, "avail itself of libraries in the conventional way" because the search-scope could be constrained and predicted.

I would argue that it isn't actually necessary to "build an EXE," and, given the client's expressed concern for adequately covering seven years' worth of Windows versions, you probably couldn't cover the requirement that way if you tried. Your solution, when deployed into any of the client's various target environments, needs to be provably adaptable to each and every one of them.

Therefore: "perhaps, a custom-compiled Perl executable, with a strictly-specified default library search path." Then, an execution environment sufficiently regulated to guarantee that this perl-command will be the one that is selected. Beyond this, absolute control over PERL5LIB at runtime, and the cpan library search paths for any updates.

In short, "to my way of thinking, the existing features of Perl should be able to serve both you and your client very well, in his privileged environment, so long as you are able to guarantee Ц as you can do Ц what it "sees." Importantly, you should be able to devise a situation that is fully and automatically adaptable between Windows versions. (Which a rigid, EXE-based strategy probably could not do.)

  • Comment on Re: Running compiled Perl script on different Windows Server versions

Replies are listed 'Best First'.
Re^2: Running compiled Perl script on different Windows Server versions
by marto (Archbishop) on Sep 25, 2019 at 03:09 UTC

    "given the client's expressed concern for adequately covering seven years' worth of Windows versions, you probably couldn't cover the requirement that way if you tried"

    What evidence do you have to backup any of these claims?

Re^2: Running compiled Perl script on different Windows Server versions
by Anonymous Monk on Sep 26, 2019 at 16:28 UTC

      Firstly; thanks for all the answers.

      @ sundialsvc4

      Re: The client's justifiable concerns for security could in fact be addressed by implementing, within that "privileged account," an entirely self-contained and isolated Perl installation ...

      Maybe a naive question, but why should address this the clients security concerns? Could You please elaborate this remark a bit?

      Anyway, I think my client and me are beyond this discussion already. He just would not understand and allow such a scenario.

      From my point of view my client and me should come to a solution which is as independent as possible from the Windows version, just to keep the maintenance effort low.нннннн But since we cannot exclude in advance differences in the dependencies from (windows) version to version, I am afraid we cannot avoid holding three (virtual) machines available for development with the corresponding windows versions installed.

      Unfortunately, there is only scarce information on the compatibility of the Perl interpreter with the windows versions, but from my research it seems that there will be no single Perl version which will work with all windows versions, which makes things more complicated.

      Since the situation is like this, my approach would be to develop and compile script(s) into executables on those three different machines, but NOT including the Perl interpreter (the tool will be transferred to the production system prior to each deployment, so the file should be small).

      Does this make sense?

      And: is it worth to TRY to run the executable generated on the newest Windows version (2019) on the other two versions? (hoping their will be backwards compatibility)

        "from my research it seems that there will be no single Perl version which will work with all windows versions, which makes things more complicated."

        What makes you think this? Using Strawberry perl, packaging to exe with pp I've not experienced issues using the same exe on several different versions of windows. The user you addressed is unlikely to elaborate on what they suggested, at least not in any logical or meaningful way.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://11106663]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (8)
As of 2019-12-12 19:34 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?