Re: Re: *more* relocatable perl

--0000000000002825cd06572f229c
Content-Type: text/plain; charset="UTF-8"

On Wed, 22 Jul 2026 at 10:31, Vadim V Konovalov <
[email protected]> wrote:

> Hi Yves,
>
> > FWIW: Back in the day on
> > Win32 Activestate had a relocatable perls, in the sense that they would
> > distribute prebuilt executables, but they had to go through an install
> step to
> > be usable (a win32 style installer). One trick I remember they used (and
> the
> > main reason I'm writing this email: to get this concept on record in this
> > thread), was to prefill certain fields in the binary with a long series
> of
> > nulls (or some other specialy crafted string). They would then overwrite
> those
> > fields in the binary during install.
>
> It was surprise for me and initially I doubted that null-padded string,
> but chat with AI made me think that your statement is ok.
>

I think if you look for mails from Jan Dubois you will find him discussing
this at some point.


> However the picture is different: the trick was to adopt binaries during
> install process so to allow people without C compiler to feel good.
>

Yes, that is what I meant by distributing pre-built-executables.


> Still, without this trick - there are some limitations, but:
> - if perl fails to find path on those craft-edited strings
> - also it checks registry for those paths
> - also it checks PERL5LIB paths
> After (and if) all this fails, it checks DLLs nearby (relatively) and - if
> succeeds - it just works
>
> This resulted in me executing unzipped perl binaries from random path to
> just work.
>
> The relocation on 5.004_02 (pre-Activestate) and then
> 5.6.x-and-above(Activestate) was just working.
> Not only relocated perl worked well, but also any perl-as-a-library binary
> just worked.
>
>
> TL;DR.
> this string-editing trick was not necessary, everything worked well
> without it starting from 1997 up to nowadays.
>

If you say so. I remember Jan discussing this much later than that. IN
response to this email I did some more digging and i found this:

https://groups.google.com/g/perl.perl5.porters/c/7CSaoDYd6nU

which I am pretty sure is the conversation I remember. Specifically this
mail fragment:

Randal Asks:
>>Is the process to make a binary run anywhere proprietary to
>>Activestate, or did I just miss that the sources were out there?

Jan replies:
>The script that does the relocation is in perl/bin/reloc_perl in the
>ActivePerl distribution. ActivePerl is built with a long silly pathname
>(not with embedded NULs), and that path is being replaced during
i>nstallation with the actual install path.

cheers,
Yves


-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

--0000000000002825cd06572f229c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><span style=3D"background-color:transpare=
nt">On Wed, 22 Jul 2026 at 10:31, Vadim V Konovalov &lt;<a href=3D"mailto:v=
[email protected]">[email protected]</a>&gt; wrote=
:</span></div><div class=3D"gmail_quote gmail_quote_container"><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex">Hi Yves,<br>
<br>
&gt; FWIW: Back in the day on<br>
&gt; Win32 Activestate had a relocatable perls, in the sense that they woul=
d<br>
&gt; distribute prebuilt executables, but they had to go through an install=
 step to<br>
&gt; be usable (a win32 style installer). One trick I remember they used (a=
nd the<br>
&gt; main reason I&#39;m writing this email: to get this concept on record =
in this<br>
&gt; thread), was to prefill certain fields in the binary with a long serie=
s of<br>
&gt; nulls (or some other specialy crafted string). They would then overwri=
te those<br>
&gt; fields in the binary during install. <br>
<br>
It was surprise for me and initially I doubted that null-padded string, but=
 chat with AI made me think that your statement is ok.<br></blockquote><div=
><br></div><div>I think if you look for mails from Jan Dubois you will find=
 him discussing this at some point.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
However the picture is different: the trick was to adopt binaries during in=
stall process so to allow people without C compiler to feel good.<br></bloc=
kquote><div><br></div><div>Yes, that is what I meant by distributing pre-bu=
ilt-executables.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">
Still, without this trick - there are some limitations, but:<br>
- if perl fails to find path on those craft-edited strings<br>
- also it checks registry for those paths<br>
- also it checks PERL5LIB paths<br>
After (and if) all this fails, it checks DLLs nearby (relatively) and - if =
succeeds - it just works<br>
<br>
This resulted in me executing unzipped perl binaries from random path to ju=
st work.<br>
<br>
The relocation on 5.004_02 (pre-Activestate) and then 5.6.x-and-above(Activ=
estate) was just working.<br>
Not only relocated perl worked well, but also any perl-as-a-library binary =
just worked.<br>
<br>
<br>
TL;DR.<br>
this string-editing trick was not necessary, everything worked well without=
 it starting from 1997 up to nowadays.<br></blockquote><div><br></div><div>=
If you say so. I remember Jan discussing this much later than that. IN resp=
onse to this email I did some more digging and i found this:<br><br><a href=
=3D"https://groups.google.com/g/perl.perl5.porters/c/7CSaoDYd6nU">https://g=
roups.google.com/g/perl.perl5.porters/c/7CSaoDYd6nU</a><br><br>which I am p=
retty sure is the conversation I remember. Specifically this mail fragment:=
<br><br>Randal Asks:<br>&gt;&gt;Is the process to make a binary run anywher=
e proprietary to<br>&gt;&gt;Activestate, or did I just miss that the source=
s were out there?<br><br>Jan replies:<br>&gt;The script that does the reloc=
ation is in perl/bin/reloc_perl in the<br>&gt;ActivePerl distribution. Acti=
vePerl is built with a long silly pathname<br>&gt;(not with embedded NULs),=
 and that path is being replaced during<br>i&gt;nstallation with the actual=
 install path.<br>=C2=A0</div><div>cheers,</div><div>Yves=C2=A0</div></div>=
<div><br clear=3D"all"></div><div><br></div><span class=3D"gmail_signature_=
prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature">perl -Mre=
=3Ddebug -e &quot;/just|another|perl|hacker/&quot;</div></div>

--0000000000002825cd06572f229c--