On 11/26/12 21:06, Richard Hipp wrote: >> fossil uses fork() quite enough, and its memory management depends on >> that, for >> what I understand. > > The "fossil ui" and "fossil server" commands use fork() on unix. But > fork() is not available on windows so we have the winhttp.c source file to > work around that limitation. > > So Fossil does not depend on fork(). But the implementation of Fossil > would be simplified if fork() were universally available.
Oh, thanks for reminding me of something. When I downloaded the win32 fossil binary and installed it on a 64-bit windows, I noticed that the fossil ui won't work properly due to that it fails to launch new processes. Running command line fossil works, but starting new fossil processes from fossil appears to fail. My gut feeling is that there's a simple solution for this (other programs must be launching new 32-bit processes from 32-bit processes in win64, but I'm not well versed in windows, so I don't know exactly where to look. Fixing it by building a 64-bit binary was trivial enough, but if we could make the distributed binary play nice on 64-bit Windows it would be great. Anyone know if there's a trivial fix? -- Kind regards, Jan Danielsson _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
