OS: Windows 7 Ultimate

With fossil.exe installed in "fossil ui" and "fossil server" fail to start the web server. On each attempted access to , the command prompt outputs:

<pre>'"fossil"' is not recognized as an internal or external command,
operable program or batch file.</pre>

Windows Firewall is off and there are no other firewalls installed.

Are you able to edit your PATH variable and add another folder (e.g., where you can transfer fossil.exe instead? Fossil probably does not understand %SystemRoot%\system32, which is what's on PATH for that folder.

This is not a problem of fossil.

The mentioned error message is a MS Windows message, documenting, that the requested command is not found in the path.

So you should check:
  *  is the path really correct
  *  how do you call fossil, MS Windows doesn't use the path variables in all call variants

>Fossil probably does not understand %SystemRoot%\system32, which is what's on PATH for that folder.

I think you've hit on the problem here. It works perfectly well on XP though, which is why I'm puzzled. I will try your suggestion but ultimately will end up with Fossil back in system32, where (IMO) it belongs.

>This is not a problem of fossil.

I believe it is. Please see below for my reasons.

>The mentioned error message is a MS Windows message, documenting, that the requested command is not found in the path.<br>
><br>
>So you should check:<br>
><br>
>is the path really correct<br>
>how do you call fossil, MS Windows doesn't use the path variables in all call variants<br>

Looks like you didn't read my ticket. I'll explain again:

At the command prompt, I'm running "fossil ui". ("fossil server" does the exact same thing.) There is a known good, open fossil in the working directory. Fossil opens a web browser (Firefox in this case) and gives it the path "localhost:8080" as expected.

The problem occurs when Firefox accesses localhost:8080. Fossil is definitely listening on 8080/tcp because it reacts to connections on localhost:8080. The way it reacts is to output this error on stdout:

'"fossil"' is not recognized as an internal or external command, operable program or batch file.

instead of returning a web page to the browser.

You're right that this error is generated by the OS, but I believe the flaw is in Fossil. IMO Arnel's suggestion is correct, that Fossil is not interpreting %SystemRoot%\system32 properly. I will now attempt to prove it.


I mean, I will attempt to prove it in 8 hours or so, when I get home from work and have access to my Windows 7 box.


I can confirm "fossil server" works with fossil.exe inside the %SystemRoot%\system32 folder from a Windows 7 box I'm using.

With "fossil ui" I'm getting the "'http:' is not recognized...batch file" message. Which is odd, considering I can run "start from within the folder.

Sorry, I forgot to add: "fossil ui" does provide the error message I described earlier when I ran it from the command-line, *BUT* if I open a browser and go to it opens the web UI for Fossil.

I think the problem comes about because Fossil tries to run a copy of
itself by calling system() with argv[0] being used as the command name.
Apparently on windows, argv[0] is not a reliable name for the program
that is being run.

Does anybody have any suggestions for an alternative way to get a
windows program to run a copy of itself?

is this recently introduced?  i've been using fossil on windows 7 64 bit since it was released with no problems (not counting a few hiccups along the way in the win32 build).  i haven't updated my build for about six weeks, so i'm not experiencing this issue (Fossil version [7aae4ef068] 2010-09-03 01:57:41).

Nothing has changed in this area recently.  I think the people that are
having problems simply have an unusual windows configuration.

For my XP machine, argv[0] is correctly filled with the complete path. A windows 7 Home Premium machine shows only the filename(fossil.exe), not the complete path. Both tests used a standard cmd.exe console starting fossil with <kbd>fossil help ver</kbd> and fossils install directory in environemt variable PATH. =>
  *  on XP argv[0] seems to be filled with the complete path, so that the environment is not used
  *  on Win 7 is only the filename stored in argv[0]. This way it depends on the environment/registry settings, whether fossil is found or not.

The contents of argv[0] can be tested with

fossil help ver

The name of the binary, displayed in the output is replaced with argv[0].

Windows uses diffent ways to find a binary (calling via cmd.exe or calling by explorer,..). So if argv[0] doesn't contain a full path, the error  may appear.

I've found a link to some information, how to get the application location:


<pre>
DWORD WINAPI GetModuleFileName(
  __in_opt  HMODULE hModule,
  __out     LPTSTR lpFilename,
  __in      DWORD nSize
);
</pre>

I think, using <code>pgmptr</code> doesn't really solve the problem. Reading the microsoft msdn pages, i see:

<blockquote>
When a program is run from the command interpreter (Cmd.exe), _pgmptr is automatically initialized to the full path of the executable file. For example, if Hello.exe is in C:\BIN and C:\BIN is in the path, _pgmptr is set to when you execute:
Copy

C> hello

When a program is not run from the command line, _pgmptr might be initialized to the program name (the file's base name without the file name extension) or to a file name, relative path, or full path.
</blockquote>
If the fossil.exe is called by tools like the value of pgmptr may be a relative or absolute path or only the filename.


>Nothing has changed in this area recently. I think the people that are having problems simply have an unusual windows configuration.

Could you narrow this down a bit? Tricky I know, but did you have something particular in mind? It's a standard Windows 7 Ultimate install. I haven't applied vLite or anything, all the usual parts seem to be there.


Richard, perhaps you refer to this? have since set a HOMEPATH (which, OT, I think might be an artifact of AD, which would explain why I've never seen it as I've never had an AD domain at home).


The original poster uses windir/system32. I think it's not a good idea, to use such an special OS folder for a user installed executable. Especially Vista/Win7 haves special mechanismns to protect this folder. In addition to this: windows uses differrent ways to expand paths while searching executables(see above).

I don't think, that we should try to handle these MS-Windows specific problems.

Many of us do not have any problems with a win7 fossil install. For me the following works pretty good (on different windows versions (XP Home, XP Prof., Win7 HP):

  1  install fossil into a fodler in the data area, including executable and repositories (this makes it easy to copy the installation between different computers)
  2  add the install directory to the PATH environment variable
  3  install a using the complete path, so the OS path search is deactivated

The problem of the original poster should be solved, if the service uses a fully qualified path instead of giving only fossil (and letting the OS search for the path).

In my opinion, this isn't a problem, which should/can be solved in fossil => Close ticket?

> starting fossil with "fossil help ver"

I'm not sure this test does what you think it does. It didn't work on my Ubuntu workstation:

fossil help ver
Usage: fossil version

Print the source code version number for the fossil executable.</pre>

When I used the full path, though, it did work...

`which fossil` help ver
Usage: version

Print the source code version number for the fossil executable.</pre>

... but using the full path defeats the point, I think. This is on a 32-bit Linux. I do have a 64-bit Linux somewhere but that test will have to wait.

Windows XP (32-bit), same result:

Resource Kits\Tools>fossil help ver
Usage: fossil version

Print the source code version number for the fossil executable.

Resource help ver
Usage: version

Print the source code version number for the fossil executable.

Resource Kits\Tools></pre>

I really must change the starting dir. My projects folder would be much more handy.

My 64-bit Windows system is at home and offline, so that test will also have to wait.

>The original poster uses windir/system32. I think it's not a good idea, to use such an special OS folder for a user installed executable.

I can't agree with that. The executable should absolutely not care where it's installed. Why should it stop working in some magic location? If the OS wants to prevent the installation, fine, if group policy wants to prevent it, also fine, but otherwise the executable should work as expected.

I have installed many programs in %windir%\system32 in the past and this is the first time there's ever been a problem.

>Especially Vista/Win7 haves special mechanismns to protect this folder.

The only "special mechanism" is a dialog box saying "you want to do this? really?" and me saying "yes".

>In addition to this: windows uses differrent ways to expand paths while searching executables(see above).

As far as I can see this is the only valid argument against fixing this, that it would require OS-specific code in a "#ifdef _WIN32" block. I hate that kind of thing normally.


>Does anybody have any suggestions for an alternative way to get a windows program to run a copy of itself?

Thinking about it, is this the best way to do it? Could we not just call the cgi function instead of launching a separate instance of Fossil?


Here's another unfinished patch (for src/winhttp.c) to implement the internal call.


It doesn't trigger the error any more, but neither does it return anything to the browser.

It <i>almost</i> works, now if only I could figure out how to call into main.c from winhttp.c! I'd prefer to do that than separate out the required functions into their own .c file.


Thanks for the patch, Fatman, but a solution that runs each HTTP request in
a thread will be unacceptable.  Fossil is designed around processes, not
threads.  The amount of work required to make Fossil threadsafe would be prohibitive.

See also,

I need a way to start a new process (not a thread) running the same binary in Windows 7.  Apparently the technique of calling system() on <nowiki>argv[0]</nowiki> or on _pgmptr works for all prior versions of Windows does not work in Windows 7.  Nobody has yet explained to me why it doesn't work, and I do not have access to Windows 7 to test it for myself, but apparently it does not.  I would prefer to fix the problem, rather than rearchitect all of Fossil.


>a solution that runs each HTTP request in a thread will be unacceptable

Fair enough. I saw "_beginthread" in winhttp.c and assumed it would be ok to use it. I'll think some more.


> Nobody has yet explained to me why it doesn't work

I'd like to know that too. It will affect my work in future.

> I do not have access to Windows 7 to test it for myself

Would it be useful if I set up a Windows 7 VM and you could fiddle with it remotely? My internet connection is fast enough for that, I think, and my server should be able to cope with a small VM. Just an idea there.


I wonder, could this be a related issue?


Maybe system() does a GetModuleFileName() call internally. I <i>have</i> been using the 32-bit version of Fossil on my 64-bit OS. If Win7 64-bit screws with 32-bit GetModuleFileName() calls, a simple recompile with MinGW-w64 might fix the problem.

Well, probably not. But I'm hoping for an easy fix. :P

i keep seeing people (including drh) in this thread saying that fossil doesn't work in windows 7.  again, it's working for me on windows 7 64 bit, and has always worked.  i have it installed in which is different than the OP, but i agree it shouldn't make a difference.  you can see my easyunit mirror at so what is different about the OP's configuration?