[PATCH] MSVC Makefiles
Attached is a patch for the MSVC Makefiles. I have tested it with MSVC 6.0sp5 for 80x86 and MSVC 7.1 for 80x86 under Windows 2000. One change of note: I changed the Makefile to use batch rules. This significantly decreases the time required to build. It might not be supported by ancient versions of nmake.exe, I don't know. I'm hoping others can test these changes, especially with older versions of MSVC. Cheers, David Fritz 2004-02-09 David Fritz <[EMAIL PROTECTED]> * configure.bat.in: Don't clear the screen. * windows/README: Add introductory paragraph. Re-word a few sentences. Correct minor typographical errors. Use consistent capitalization of Wget, SSL, and OpenSSL. Refer to Microsoft Visual C++ as MSVC instead of VC++. Mention the --msvc option to configure.bat. Reflow paragraphs. * windows/Makefile.top: Use tabs instead of spaces. Ignore errors in clean rules. Use lowercase filenames when building distribution .zip archive. * windows/Makefile.doc: Use tabs instead of spaces. Ignore errors in clean rules. * windows/Makefile.src: Clean-up clean rules. Use tabs instead of spaces. Link against gdi32.lib. Don't define SYSTEM_WGETRC. Remove unused macros. Remove anachronistic and superfluous linker flags. Don't rename wget.exe to all upper-case. Add `preprocessor' conditionals for SSL and newer MSVC options. Use batch rules. Don't suppress all warnings. Index: configure.bat.in === RCS file: /pack/anoncvs/wget/configure.bat.in,v retrieving revision 1.4 diff -u -r1.4 configure.bat.in --- configure.bat.in2003/10/26 00:19:04 1.4 +++ configure.bat.in2004/02/09 05:29:50 @@ -26,7 +26,6 @@ rem file, but you are not obligated to do so. If you do not wish to do rem so, delete this exception statement from your version. -cls if .%1 == .--borland goto :borland if .%1 == .--mingw goto :mingw if .%1 == .--msvc goto :msvc Index: windows/Makefile.doc === RCS file: /pack/anoncvs/wget/windows/Makefile.doc,v retrieving revision 1.4 diff -u -r1.4 Makefile.doc --- windows/Makefile.doc2002/05/18 02:16:35 1.4 +++ windows/Makefile.doc2004/02/09 05:29:51 @@ -28,22 +28,22 @@ # You probably need makeinfo and perl, see the README in the main # windows directory. -RM = del -CP = copy -ATTRIB = attrib - -MAKEINFO = makeinfo.exe -TEXI2POD = texi2pod.pl -POD2MAN = pod2man - -SAMPLERCTEXI = sample.wgetrc.munged_for_texi_inclusion -WGETHLP = wget.hlp -WGETINFO = wget.info -WGETTEXI = wget.texi -WGETHTML = wget.html -WGETPOD = wget.pod -manext = 1 -MAN = wget.$(manext) +RM = -del +CP = copy +ATTRIB = attrib + +MAKEINFO = makeinfo.exe +TEXI2POD = texi2pod.pl +POD2MAN= pod2man + +SAMPLERCTEXI = sample.wgetrc.munged_for_texi_inclusion +WGETHLP= wget.hlp +WGETINFO = wget.info +WGETTEXI = wget.texi +WGETHTML = wget.html +WGETPOD= wget.pod +manext = 1 +MAN= wget.$(manext) all: $(WGETHLP) $(WGETINFO) $(WGETHTML) @@ -76,10 +76,10 @@ hcrtf -xn wget.hpj clean: -$(RM) *.bak -$(RM) *.hpj -$(RM) *.rtf -$(RM) *.ph + $(RM) *.bak + $(RM) *.hpj + $(RM) *.rtf + $(RM) *.ph $(RM) $(SAMPLERCTEXI) $(RM) $(MAN) $(RM) $(TEXI2POD) Index: windows/Makefile.src === RCS file: /pack/anoncvs/wget/windows/Makefile.src,v retrieving revision 1.21 diff -u -r1.21 Makefile.src --- windows/Makefile.src2003/11/21 08:48:45 1.21 +++ windows/Makefile.src2004/02/09 05:29:51 @@ -1,4 +1,4 @@ -# Makefile for `wget' utility for MSVC 4.0 +# Makefile for `wget' utility for MSVC # Copyright (C) 1995, 1996, 1997 Free Software Foundation, Inc. # This program is free software; you can redistribute it and/or modify @@ -25,44 +25,49 @@ # file, but you are not obligated to do so. If you do not wish to do # so, delete this exception statement from your version. -# -# Version: 1.4.4 -# - -#Comment these if you don't have openssl available - however https -#won't work. -SSLDEFS= /DHAVE_SSL -SSLLIBS= libeay32.lib ssleay32.lib -SSLSRC = gen_sslfunc.c -SSLOBJ = gen_sslfunc$o - -SHELL = command - -VPATH = . -o = .obj -OUTDIR = . - -CC = cl -LD = link - -CFLAGS = /nologo /MT /W0 /O2 -#DEBUGCF = /DENABLE_DEBUG /Zi /Od #/Fd /FR -CPPFLAGS = -DEFS = /DWINDOWS /D_CONSOLE /DHAVE_CONFIG_H /DSYSTEM_WGETRC=\"wgetrc\" -LDFLAGS = /subsystem:console /incremental:no /warn:3 -#DEBUGLF = /pdb:wget.pdb /debug /debugtype:cv /map:wget.map /opt:noref -LIBS = kernel32.lib advapi32
Re: Startup delay on Windows
Hrvoje Niksic wrote: > Does anyone have an idea what we should consider the home dir under > Windows, and how to find it? On Windows 2000 and XP, there are two environment variables that together provide the user's home directory. (It may go back further than that, but I don't have any machines running older OS versions to confirm that.) For example, on my Windows XP machine, I have to following variables: HOMEDRIVE=C: HOMEPATH=\Documents and Settings\Tony Lewis so my home directory is C:\Documents and Settings\Tony Lewis HTH, Tony
Re: Startup delay on Windows
Petr Kadlec wrote: > I have traced the problem down to search_netrc() in netrc.c, where the > program is trying to find the file using stat(). But as home_dir() > returns "C:\" on Windows, the filename constructed looks like > "C:\/.netrc", which is then probably interpreted by Windows as a name of > a remote file, so Windows are trying to look around on the network, and > continue only after some timeout. I'm curious as to what operating system and compiler you are using. I tried briefly to reproduce this under Windows 2000 with MSVC 7.1 and could not. I would regard this as a bug in the implementation of stat(), not Wget. BTW, this has come up before: http://www.mail-archive.com/[EMAIL PROTECTED]/msg04440.html Hrvoje Niksic wrote: Thanks tracing this one. It would never have occurred to me that the file name "c:\/foo" could cause such a problem. It really shouldn't; it seems perfectly valid (albeit strange) to me. Though, I guess, it behooves us to work around compiler/library bugs. I see two different bugs here: 1. The routine that "merges" the .netrc file name with the directory name should be made aware of Windows, so that it doesn't append another backslash if a backslash is already present at the end of directory name returned by home_dir. (In fact, the same logic could be applied to slashes following Unix directory names.) *AFAIK*, Window should only treat two consecutive slashes specially if they are at the beginning of a file name. (Windows might not like more than one slash between a machine and share name, but that's not really relevant.) Otherwise, they should be equivalent to a single slash. All this irrespective of whether the slashes are forward (/) or backward (\). 2. home_dir() should really be fixed to return something better than `c:\' unconditionally, as is currently the case. The comment in the source says: home = "C:\\"; /* Maybe I should grab home_dir from registry, but the best that I could get from there is user's Start menu. It sucks! */ This comment was not written by me, but by (I think) Darko Budor, who wrote the original Windows support. Under Windows 2000 and XP, there have to be better choices of home directory. For instance, Cygwin considers `c:\Documents and Settings\USERNAME' to be the home directory. From Cygwin's /etc/profile: # Here is how HOME is set, in order of priority, when starting from Windows # 1) From existing HOME in the Windows environment, translated to a Posix path # 2) from /etc/passwd, if there is an entry with a non empty directory field # 3) from HOMEDRIVE/HOMEPATH # 4) / (root) If things were installed normally, Cygwin will consider /home/username to be the users home directory. Under Cygwin / is usually mounted on C:\cygwin, or wherever Cygwin was installed. But Cygwin is very much it's own environment. Already, two of the above methods are unavailable to us (2 and 4). I wonder if that is reachable through registry... Does anyone have an idea what we should consider the home dir under Windows, and how to find it? I imagine there are a number of ways to go about this. As it stands now, if I understand correctly, Wget works like this: When processing .wgetrc under Windows, Wget does the following: If Wget was built with MSVC, it looks for a file called "wgetrc" in the current directory. This is mildly evil. A comment in init.c includes the following sentence: "SYSTEM_WGETRC should not be defined under WINDOWS." Nonetheless, the MSVC Makefile defines SYSTEM_WGETRC as "wgetrc". AFAICT, Wget won't do this if it was built with one of the other Windows Makefiles. Wget then processes the users .wgetrc. Under Windows, Wget ignores $HOME and looks for a file called wget.ini in the directory of the Wget binary. Under Windows, if $HOME is defined home_dir() will return that, otherwise it returns `C:\'. Wget uses the directory returned by home_dir() when looking for .netrc and when resolving ~. So currently Wget's behavior is inconsistent, both with its behavior on other platforms, and with itself (the handling of .wgetrc and .netrc). If we wanted to do things the NT way, we could, essentially, treat "C:\Documents and Settings\username\Application Data\Wget" as HOME and "C:\Documents and Settings\All Users\Application Data\Wget" as /etc. The above directories are just examples of typical locations; we would, of course, resolve the directories correctly. But then what would we do if $HOME *is* defined? Ignore it? That would seem the `Windows' thing to do. The directories themselves could be resolved using SHGetSpecialFolderPath() or its like. The entry points would have to resolved dynamically as they may not be available on ancient Windows installations. We could then fall-back to the registry or the environment or something else. The user could always define $WGETRC and put .wgetrc anywhere he/she pleased. But what about .netrc? And doe
Re: Startup delay on Windows
At 06:23 PM 2/8/2004, Hrvoje Niksic wrote: Does anyone have an idea what we should consider the home dir under Windows, and how to find it? In Windows 2000, if I enter "SET" at the command prompt, I get a return that is a listing of all of the environment variables that have been established (set). On my machine, part of that listing is as follows. D:\>SET HOMEDRIVE=D: HOMEPATH=\Documents and Settings\Administrator (D: is my boot drive, and therefore my home drive) (SET [variable] = [value] is the command for establishing an environment variable and its value, in Windows and DOS. SET by itself with no argument reports all of the environment variables and their values.) I'm not a "real" windows programmer, but any windows compiler should be able to get the values of these environment variables on a particular machine. The are generally/often referenced (at least in windows command prompt batch files) as %HOMEDRIVE% and %HOMEPATH%. Other flavors of Windows should be similar, if not the same, but I don't have the means to test any of them. Fred Holmes
Re: Startup delay on Windows
[...] >Cygwin considers `c:\Documents and Settings\USERNAME' to be the >home directory. I wonder if that is reachable through registry... > > Does anyone have an idea what we should consider the home dir under > Windows, and how to find it? Doesn't this depend on each user's personal preference? I think most could live with c:\Documents and Settings\all users (or whatever it is called in each language) or the cygwin approach c:\Documents and Settings\USERNAME which will be less likely to conflict with security limits on multi-user PCs I think. I personally would like to keep everything wget-ish in the directory its exe is in and treat that as its home dir. BTW: Is this bug connected to the bug under Windows, that saving into another directory than wget's starting dir by using the -P (--directory-prefix) option does not work when switching drives? wget -r -P C:\temp URL will save to .\C3A\temp\*.* wget -r -P 'C:\temp\' URL will save to .\'C3A\temp\'\*.* wget -r -P "C:\temp\" URL does not work at all ('Missing URL') error however wget -r -P ..\temp2\ URL works like a charme. CU Jens -- GMX ProMail (250 MB Mailbox, 50 FreeSMS, Virenschutz, 2,99 EUR/Monat...) jetzt 3 Monate GRATIS + 3x DER SPIEGEL +++ http://www.gmx.net/derspiegel +++
Re: skip robots
> You're close. You forgot the `-u' option to diff (very important), > and you snipped the beginning of the `patch' output (also important). Ok, I forgot the -u switch which was stupid as I actually read the command line in the patches file :( But concerning the snipping I just did diff > file.txt so I cannot have snipped anything. Is my shell (win2000) doing something wrongly or is the missing bit there now (when using the -u switch). Jens Once more: Patch sum up: a) Tell users how to --execute more than one wgetrc command b) Tell about and link to --execute when listing wgetrc commands. Reason: Better understanding and navigating the manual ChangeLog entry: Changed wget.texi concerning --execute switch to facilitate use and user navigation. Start patch: --- wget.texi Sun Nov 09 00:46:32 2003 +++ wget_mod.texi Sun Feb 08 20:46:07 2004 @@ -406,8 +406,10 @@ @itemx --execute @var{command} Execute @var{command} as if it were a part of @file{.wgetrc} (@pxref{Startup File}). A command thus invoked will be executed [EMAIL PROTECTED] the commands in @file{.wgetrc}, thus taking precedence over -them. [EMAIL PROTECTED] the commands in @file{.wgetrc}, thus taking precedence over +them. If you need to use more than one wgetrc command in your +command-line, use -e preceeding each. + @end table @node Logging and Input File Options, Download Options, Basic Startup Options, Invoking @@ -2147,8 +2149,9 @@ integer, or @samp{inf} for infinity, where appropriate. @var{string} values can be any non-empty string. -Most of these commands have command-line equivalents (@pxref{Invoking}), -though some of the more obscure or rarely used ones do not. +Most of these commands have command-line equivalents (@pxref{Invoking}). Any +wgetrc command can be used in the command-line by using the -e (--execute) (@pxref{Basic Startup Options}) switch. + @table @asis @item accept/reject = @var{string} -- GMX ProMail (250 MB Mailbox, 50 FreeSMS, Virenschutz, 2,99 EUR/Monat...) jetzt 3 Monate GRATIS + 3x DER SPIEGEL +++ http://www.gmx.net/derspiegel +++
Re: Startup delay on Windows
Thanks tracing this one. It would never have occurred to me that the file name "c:\/foo" could cause such a problem. I see two different bugs here: 1. The routine that "merges" the .netrc file name with the directory name should be made aware of Windows, so that it doesn't append another backslash if a backslash is already present at the end of directory name returned by home_dir. (In fact, the same logic could be applied to slashes following Unix directory names.) 2. home_dir() should really be fixed to return something better than `c:\' unconditionally, as is currently the case. The comment in the source says: home = "C:\\"; /* Maybe I should grab home_dir from registry, but the best that I could get from there is user's Start menu. It sucks! */ This comment was not written by me, but by (I think) Darko Budor, who wrote the original Windows support. Under Windows 2000 and XP, there have to be better choices of home directory. For instance, Cygwin considers `c:\Documents and Settings\USERNAME' to be the home directory. I wonder if that is reachable through registry... Does anyone have an idea what we should consider the home dir under Windows, and how to find it?
Re: skip robots
"Jens Rösner" <[EMAIL PROTECTED]> writes: >> distribution. See >> http://cvs.sunsite.dk/viewcvs.cgi/*checkout*/wget/PATCHES?rev=1.5 > > Thanks, I tried to understand that. Let's see if I understood it. You're close. You forgot the `-u' option to diff (very important), and you snipped the beginning of the `patch' output (also important).
Re: skip robots
Hi Hrvoje! > In other words, save a copy of wget.texi, make the change, and send the > output of `diff -u wget.texi.orig wget.texi'. That's it. Uhm, ok. I found diff for windows among other GNU utilities at http://unxutils.sourceforge.net/ if someone is interested. > distribution. See > http://cvs.sunsite.dk/viewcvs.cgi/*checkout*/wget/PATCHES?rev=1.5 Thanks, I tried to understand that. Let's see if I understood it. Sorry if I am not sending this to the patches list, the document above says that it is ok to evaluate the patch with the general list. CU Jens Patch sum up: a) Tell users how to --execute more than one wgetrc command b) Tell about and link to --execute when explaining wgetrc commands. Reason: Better understanding and navigating the manual. ChangeLog entry: Changed wget.texi concerning --execute switch to facilitate use and user navigation. Start patch: 409,410c409,412 < @emph{after} the commands in @file{.wgetrc}, thus taking precedence over < them. --- > @emph{after} the commands in @file{.wgetrc}, thus taking precedence over > them. If you need to use more than one wgetrc command in your > command-line, use -e preceeding each. > 2150,2151c2152,2154 < Most of these commands have command-line equivalents (@pxref{Invoking}), < though some of the more obscure or rarely used ones do not. --- > Most of these commands have command-line equivalents (@pxref{Invoking}). Any > wgetrc command can be used in the command-line by using the -e (--execute) (@pxref{Basic Startup Options}) switch. > -- GMX ProMail (250 MB Mailbox, 50 FreeSMS, Virenschutz, 2,99 EUR/Monat...) jetzt 3 Monate GRATIS + 3x DER SPIEGEL +++ http://www.gmx.net/derspiegel +++
Startup delay on Windows
Hi all! I have experienced delays when wget is starting. It shows what is it going to download: --16:45:37-- http://www.example.com/ => `index.html' and then freezes for about 20 seconds. I have traced the problem down to search_netrc() in netrc.c, where the program is trying to find the file using stat(). But as home_dir() returns "C:\" on Windows, the filename constructed looks like "C:\/.netrc", which is then probably interpreted by Windows as a name of a remote file, so Windows are trying to look around on the network, and continue only after some timeout. I have changed the home_dir to return "C:\windows" on my machine and it works fine; it is hard to say what solution would be good for all. With regards, Petr Kadlec -- --- When in doubt, mumble; when in trouble, delegate; when in charge, ponder. - James H. Boren
Re: skip robots
"Jens Rösner" <[EMAIL PROTECTED]> writes: > Hi Hrvoje! > >> > PS: One note to the manual editor(s?): The -e switch could be >> > (briefly?) mentioned also at the "wgetrc commands" paragraph. I >> > think it would make sense to mention it there again without >> > clustering the manual too much. Currently it is only mentioned in >> > "Basic Startup Options" (and in an example dealing with robots). >> > Opinions? >> >> Sure, why not. Have you just volunteered to write the patch? :-) >> > Touché! > ;) > Well, seriously, I don't know how to write a patch! [...] > Or someone sends me a link that explains patching so that even a Windowser > can do it ;) It's really not hard. To create a patch, you only need the `diff' utility (available precompiled for Windows). Save the original copy of the file, make your change, run `diff -u OLDFILE NEWFILE', and mail the output here. That's it. The file you need to look at to make a change in the documentation is doc/wget.texi in Wget's distribution. Although the markup might not be familiar to you, it is very easy to pick up if you're making a small change. In other words, save a copy of wget.texi, make the change, and send the output of `diff -u wget.texi.orig wget.texi'. That's it. This is explained in more detail in the PATCHES file in the Wget distribution. See http://cvs.sunsite.dk/viewcvs.cgi/*checkout*/wget/PATCHES?rev=1.5
Re: Minor typo in doc/wget.texinfo on wget 1.9.1
I've now installed this fix, thanks.