Re: [Bug-wget] wget for windows - current build?

[Tim Rühsen]

On Sonntag, 2. Oktober 2016 10:11:33 CEST Eli Zaretskii wrote:
> > From: Tim Rühsen 
> > Cc: ge...@mweb.co.za
> > Date: Sat, 01 Oct 2016 20:12:28 +0200
> > 
> > If you like to create a README.windows maybe with (basic) explanations on
> > how to build wget on Windows plus pointers to your port(s), we include it
> > into the project.
> 
> That's okay (will do when I have time), but I think it would be more
> useful to have a link on the Wget Web page to the places where Windows
> binaries can be found.

Basically we only provide source code plus recipes how to build binaries.
IMO, it is ok to link to places where one can download ready-to-go binaries - 
as long there is also a recipe for users to (re-)generate these binaries on 
their own.

Regards, Tim


signature.asc
Description: This is a digitally signed message part.

Re: [Bug-wget] wget for windows - current build?

[Doug Kaufman]

On Fri, 30 Sep 2016, ge...@mweb.co.za wrote:

> So, is there a "secret" new place hosting a newer version for Windows?
> Or is the 1.11 on sourceforge actually okay? And - while I am already

In addition to the Windows port Eli makes available, there are also
32 bit and 64 bit Windows binaries available from Jernej Simoncic at
"https://eternallybored.org/misc/wget/;. The latest version there is
1.18.

Doug

-- 
Doug Kaufman
Internet: dkauf...@rahul.net

Re: [Bug-wget] wget for windows - current build?

[Eli Zaretskii]

> From: Tim Rühsen 
> Cc: ge...@mweb.co.za
> Date: Sat, 01 Oct 2016 20:12:28 +0200
> 
> If you like to create a README.windows maybe with (basic) explanations on how 
> to build wget on Windows plus pointers to your port(s), we include it into 
> the 
> project.

That's okay (will do when I have time), but I think it would be more
useful to have a link on the Wget Web page to the places where Windows
binaries can be found.

> BTW, meanwhile libidn fixed several security issues, as well as gnutls, 
> libpsl 
> and wget itself ;-)

Duly noted.

Re: [Bug-wget] wget for windows - current build?

[Tim Rühsen]

On Samstag, 1. Oktober 2016 20:27:47 CEST Eli Zaretskii wrote:
> > From: Tim Rühsen 
> > Cc: ge...@mweb.co.za
> > Date: Sat, 01 Oct 2016 18:10:26 +0200
> > 
> > > > It shouldn't be too hard to write a script that cross-compiles wget
> > > > and
> > > > some dependencies via mingw. But would such an .exe really work on a
> > > > real
> > > > Windows machine ?
> > > 
> > > I'm not sure I understand the question.  If cross-compiling works,
> > > then why won't the result run as expected?
> > 
> > Well, some years ago I copied cross compiled executables (32bit) onto a
> > WinXP machine. Executing these didn't error, but they immediately
> > returned without doing anything. Even the first printf() line didn't do
> > anything.
> > While executing the same executables with wine on the machine that I used
> > for compilation, they worked fine.
> 
> Sounds like some incompatibility between the import libraries you had
> in that cross-environment and the corresponding DLLs on the target
> Windows XP machine.
> 
> > While it seems pretty easy to generate a wget.exe on Linux and even run it
> > through wine, it seems not to work out that easily on a real Windows. At
> > least these questions for a recent Windows executable are pretty common -
> > and the Windows affine users here do not have a easy solution as it
> > seems.
> Building Wget on Windows is easy if you have an operational
> development environment.  What's not easy is running the test suite
> and figuring out what each failure means, then fixing the sources as
> needed.
> 
> Anyway, in addition to my site, which offers a 32-bit build, the MSYS2
> project offers both 32-bit and 64-bit builds (although I cannot vouch
> for their thoroughness in running the test suite -- not that I know
> they didn't, mind you).  People who ask about that must be doing that
> out of ignorance; perhaps we should include pointers to those places
> in the distribution.

Sounds good :-)

If you like to create a README.windows maybe with (basic) explanations on how 
to build wget on Windows plus pointers to your port(s), we include it into the 
project.

BTW, meanwhile libidn fixed several security issues, as well as gnutls, libpsl 
and wget itself ;-)

Regards, Tim


signature.asc
Description: This is a digitally signed message part.

Re: [Bug-wget] wget for windows - current build?

[Eli Zaretskii]

> From: Tim Rühsen 
> Cc: ge...@mweb.co.za
> Date: Sat, 01 Oct 2016 18:10:26 +0200
> 
> > > It shouldn't be too hard to write a script that cross-compiles wget and
> > > some dependencies via mingw. But would such an .exe really work on a real
> > > Windows machine ?
> > 
> > I'm not sure I understand the question.  If cross-compiling works,
> > then why won't the result run as expected?
> 
> Well, some years ago I copied cross compiled executables (32bit) onto a WinXP 
> machine. Executing these didn't error, but they immediately returned without 
> doing anything. Even the first printf() line didn't do anything.
> While executing the same executables with wine on the machine that I used for 
> compilation, they worked fine.

Sounds like some incompatibility between the import libraries you had
in that cross-environment and the corresponding DLLs on the target
Windows XP machine.

> While it seems pretty easy to generate a wget.exe on Linux and even run it 
> through wine, it seems not to work out that easily on a real Windows. At 
> least 
> these questions for a recent Windows executable are pretty common - and the 
> Windows affine users here do not have a easy solution as it seems.

Building Wget on Windows is easy if you have an operational
development environment.  What's not easy is running the test suite
and figuring out what each failure means, then fixing the sources as
needed.

Anyway, in addition to my site, which offers a 32-bit build, the MSYS2
project offers both 32-bit and 64-bit builds (although I cannot vouch
for their thoroughness in running the test suite -- not that I know
they didn't, mind you).  People who ask about that must be doing that
out of ignorance; perhaps we should include pointers to those places
in the distribution.

Re: [Bug-wget] wget for windows - current build?

[Tim Rühsen]

On Samstag, 1. Oktober 2016 18:29:30 CEST Eli Zaretskii wrote:
> > From: Tim Rühsen 
> > Cc: "ge...@mweb.co.za" 
> > Date: Sat, 01 Oct 2016 13:04:25 +0200
> > 
> > It shouldn't be too hard to write a script that cross-compiles wget and
> > some dependencies via mingw. But would such an .exe really work on a real
> > Windows machine ?
> 
> I'm not sure I understand the question.  If cross-compiling works,
> then why won't the result run as expected?

Well, some years ago I copied cross compiled executables (32bit) onto a WinXP 
machine. Executing these didn't error, but they immediately returned without 
doing anything. Even the first printf() line didn't do anything.
While executing the same executables with wine on the machine that I used for 
compilation, they worked fine.

I didn't have any time to investigate - but since then I remember cross-
compilation as a theoretical thing without any practical use :-)

While it seems pretty easy to generate a wget.exe on Linux and even run it 
through wine, it seems not to work out that easily on a real Windows. At least 
these questions for a recent Windows executable are pretty common - and the 
Windows affine users here do not have a easy solution as it seems.

Regards, Tim


signature.asc
Description: This is a digitally signed message part.

Re: [Bug-wget] wget for windows - current build?

[Eli Zaretskii]

> From: Tim Rühsen 
> Cc: "ge...@mweb.co.za" 
> Date: Sat, 01 Oct 2016 13:04:25 +0200
> 
> It shouldn't be too hard to write a script that cross-compiles wget and some 
> dependencies via mingw. But would such an .exe really work on a real Windows 
> machine ?

I'm not sure I understand the question.  If cross-compiling works,
then why won't the result run as expected?

Re: [Bug-wget] wget for windows - current build?

[Tim Rühsen]

On Freitag, 30. September 2016 19:17:42 CEST Eli Zaretskii wrote:
> > Date: Fri, 30 Sep 2016 16:52:55 +0200 (SAST)
> > From: "ge...@mweb.co.za" 
> > 
> > So, is there a "secret" new place hosting a newer version for Windows? Or
> > is the 1.11 on sourceforge actually okay? And - while I am already asking
> > all these stupid questions - would that version actually handle larger
> > file sizes already?
> You can find a 32-bit Windows port of 1.16.1 here:
> 
>   https://sourceforge.net/projects/ezwinports/files/?source=navbar

It shouldn't be too hard to write a script that cross-compiles wget and some 
dependencies via mingw. But would such an .exe really work on a real Windows 
machine ?

Tim


signature.asc
Description: This is a digitally signed message part.

Re: [Bug-wget] wget for windows - current build?

[Eli Zaretskii]

> Date: Fri, 30 Sep 2016 16:52:55 +0200 (SAST)
> From: "ge...@mweb.co.za" 
> 
> So, is there a "secret" new place hosting a newer version for Windows? Or is 
> the 1.11 on sourceforge actually okay? And - while I am already asking all 
> these stupid questions - would that version actually handle larger file sizes 
> already? 

You can find a 32-bit Windows port of 1.16.1 here:

  https://sourceforge.net/projects/ezwinports/files/?source=navbar

[Bug-wget] wget for windows - current build?

[ge...@mweb.co.za]

Hi guys, 

I just checked, I believe the version of wget I am running is from 2003 (and I 
have been using it for much mich longer than that ...) At some point I even 
wrote scripts around wget batch jobs I used to run ... 

But I am kind of stuck in Windows. And things happen on a different time line 
there. 

Just the other day I noticed that I was getting no joy downloading certain 
files and only after that had happened a few times did I realize that the file 
size was shown as negative. That is something that I have seen when the number 
is too big as an unsigned integer to also be interpreted as a 2's complement 
integer in the available number of bits. And then it dawned on me that my old 
wget may not be up to files greater than, say, 2GB. 

Time for a new download. 

I am being pointed at sourceforge, even by the German c't magazine, which is 
usually pretty clued up. But I remember having heard bad things about 
sourceforge. And the version they offer is 1.11.4, whereas your version on 
gnu.org is 1.18 or so. 

So, is there a "secret" new place hosting a newer version for Windows? Or is 
the 1.11 on sourceforge actually okay? And - while I am already asking all 
these stupid questions - would that version actually handle larger file sizes 
already? 

Thanks, guys, 

Gerd 

(and I mustn't forget to send a note to c't as well ...)