On Sun, 26 Apr 2020 23:16:57 +0200, Oliver Betz wrote:
> Are you running under real Windows or Wine? This doesn't sound like a
> Windows issue.
I've unzipped the files under Linux on a disk shared with Windows.
On Linux, files like perl.exe and perl530.dll have permissions 0664
(rw-r--r--).
Hi Johan,
I unpacked the zip and tried to run.
First problem: the .exe files are not executable:
Are you running under real Windows or Wine? This doesn't sound like a
Windows issue.
[...]
While looking at the (modified) source: what is the purpose of
unshift @INC,
On Sun, 26 Apr 2020 17:57:23 +0200, Oliver Betz wrote:
> it was not so difficult as I thought initially so I compiled a 64 bit
> wrapper including the icon:
Great!
I unpacked the zip and tried to run.
First problem: the .exe files are not executable:
H:\cp> wxchordpro_console.exe
Access
[...]
If you want to use my wrapper with 64 Bit Perl, you need to compile it
yourself. If you switch to 32 bit Perl, I can support you with special
it was not so difficult as I thought initially so I compiled a 64 bit
wrapper including the icon:
Hi Johan,
I've uploaded a perl GUI program:
https://www.squirrel.nl/pub/xfer/uploads/3C6TeP1OMnL8q7ciPFkyneaA.exe
I managed to run this application from the pp created archive contents
after applying a few modifications you might want to revise:
In wxchordpro.pl, I replaced lines 10..12 with
Hi Johan,
I've uploaded a perl GUI program:
https://www.squirrel.nl/pub/xfer/uploads/3C6TeP1OMnL8q7ciPFkyneaA.exe
this is made with 64 bit Perl. My launcher currently supports only 32
bit Perl because the 64 bit version was even slower running ExifTool.
It is not exactly a trivial program,
Hi Oliver,
On Sat, 25 Apr 2020 12:08:31 +0200, Oliver Betz wrote:
> An easy approach is to continue using pp to build the required
> environment. Extract it immediately afterwards. Look at my ugly hack
> "unpar.cmd" to see one way to do it.
I've uploaded a perl GUI program:
Hi Oliver,
On Sat, 25 Apr 2020 00:07:35 +0200, Oliver Betz wrote:
> Seemingly I'm not recognizing the advantage in using pp *in addition* to
> InnoSetup.
>
> What is the point to use InnoSetup just to transport *one single exe*?
The point is that typical Windows users can download and click a
Hi Johan,
I, too, have been using pp + innosetup for many years, so that is not the
problem. BTW my apps are Perl/Wx based.
Seemingly I'm not recognizing the advantage in using pp *in addition* to
InnoSetup.
What is the point to use InnoSetup just to transport *one single exe*?
If you work
Hi Welle,
Thanks for your reply.
I, too, have been using pp + innosetup for many years, so that is not the
problem. BTW my apps are Perl/Wx based.
I was responding to Olivers suggestions to have par handle the file
selection and bundling, and innoset doing the unpacking. I wondered if
anyone
Hi Johan,
no, you are not the only one. I have a fairly complex GUI application for
Windows and macOS written in Perl and Tcl/Tk (I switched away from Perl/Tk
a couple of months ago). For Windows, I have been using the combination
pp+Innosetup for years now, and I am very happy with it (for what
Hi Oliver,
Thanks for all suggestions.
A bit of background: I am 100% linux user/developer. Since Windows people
want to run some of my applications and since most Windows users are not
capable of installing perl and modules and so on I figured out how to use
PAR (pp) and InnoSetup to produce
On Fri, 24 Apr 2020 20:21:22 +0200, Kenneth Ölwing
wrote:
> What do you mean by 'lack of symlinks'?
I must admit I haven't really kept up with Windows lately (and I don't plan
to).
Anyway, the symbolic links are of no real importance to this discussion.
Reducing installer size. Not 'installed size' since the binary needs to be
copied under two names due to the lack of symlinks.
What do you mean by 'lack of symlinks'?
Hi Johan,
What would be the drawback of using a (subset of a) portable Perl
distribution together with your Perl code, IOW just a bunch of files,
and run it directly?
It seems non-trivial to put the bunch of files together, distribute
par is good in doing this selection.
them and have the
On Fri, 24 Apr 2020 19:40:58 +0200, Oliver Betz wrote:
> Which kind of complexity and overhead do you mean?
Having multiple copies of the same code installed may sooner or later cause
confusion.
> What would be the drawback of using a (subset of a) portable Perl
> distribution together with
Hi Johan,
which benefit do you expect from packing:
Avoiding "installation", reducing size, or something else?
Mostly avoiding complexity and unnecessary overhead. The cli version is
fully contained in the gui version.
Which kind of complexity and overhead do you mean?
What would be the
Hi Oliver,
On Fri, 24 Apr 2020 17:16:37 +0200, Oliver Betz wrote:
> which benefit do you expect from packing:
>
> Avoiding "installation", reducing size, or something else?
Mostly avoiding complexity and unnecessary overhead. The cli version is
fully contained in the gui version.
Reducing
Hi Johan,
I have an application that comes in two forms: as a command line tool, and
as a GUI tool. I want to package these in a single binary, using pp
which benefit do you expect from packing:
Avoiding "installation", reducing size, or something else?
multi-script feature. So far, so
On Fri, Apr 24, 2020 at 2:36 PM Johan Vromans wrote:
> But on Windows it matters whether the program is built with --gui or not.
> If I build with --gui invoking the command line version will make all
> terminal output disappear. If built without --gui the GUI invokation will
> show a nasty
20 matches
Mail list logo
