The "fork-to-background" on Windows is just a joke (as the comment
in config.h.mingw says). Is anybody using it? It could be a useful feature 
if we attach to the console of calling process (the shell in most cases) 
at startup. Then when ^Break is pressed (or '-b' specified), we free
that console and continue running in the background. That way we will
get the shell prompt back (and not as it is know with Wget seemingly 
hanging idle until finished).

A brief description of how I did accomplish this:

* In makefiles, add
  "CFLAGS += -Dmain=wget_main" and
  link wget as a GUI app ("-Wl,--subsystem,windows" or
  "/subsystem:windows")

* In mswindows.c, add a WinMain() function that sets up a detached
  console (or for Win-9x/ME/NT allocates one). Reopen stdin, stdout 
  and stderr using "$CONIN" etc. Call wget_main(). 
  BTW. We could do the Winsock init stuf here too to avoid cluttering
    main.c

* In fork_to_background(), free the attached or allocated console
  seemingly continuing in background.

This actually works fine, but redirection (e.g. wget -h > foo) doesn't 
work.I don't know any way to get at the redirected stdout/stderr handles 
from Wget. But then you're not supposed to do that from a "GUI" app.

I've not tested on anything but Win-XP. I've attached the modfied 
mswindows.c if anybody could try it on other Win OS'es.
(define 'CTRLBREAK_BACKGND' in config.* or makefiles).

Anybody see other ways to run detached or in background. I haven't 
checked how Cygwin's fork() does it, but hear it is pretty slow. 
And can we live without redirection?

Gisle V.

Attachment: mswindows.c
Description: Binary data

Reply via email to