Folks:

If I do a darcs put to a local directory on win32, a process named  
ntvdm.exe starts hammering the CPU and keeps going for many minutes.

If I do a pull, the process appears, but then it disappears again  
shortly.

ntvdm.exe is apparently a 16-bit (!!) emulation module.

There are two likely culprits here:

1.  cygwin is using some crazy 16-bit something to launch/load bash  
scripts (there is a bash script wrapper around my darcs executable)

2.  haskell is using some crazy 16-bit something for some reason

Does anyone out there know?

Regards,

Zooko

This was my mistake.  I had renamed my cygwin bash wrapper script from "darcs"
to "darcs.exe".  That causes this behavior.  Fixed.

On Mon, Oct 08, 2007 at 05:28:29PM -0000, Zooko wrote:
> Folks:
> 
> If I do a darcs put to a local directory on win32, a process named  
> ntvdm.exe starts hammering the CPU and keeps going for many minutes.
> 
> If I do a pull, the process appears, but then it disappears again  
> shortly.
> 
> ntvdm.exe is apparently a 16-bit (!!) emulation module.
> 
> There are two likely culprits here:
> 
> 1.  cygwin is using some crazy 16-bit something to launch/load bash  
> scripts (there is a bash script wrapper around my darcs executable)

Could you try doing the same action without cygwin? It would seem that this
could eliminate this as a possibility.

> 2.  haskell is using some crazy 16-bit something for some reason

This sounds very weird.  If it's the case, it'd either be because (a) darcs
calls a Haskell library function that does something weird, or (b) a
Haskell library calls some windows function that itself is implemented
with 16-bit code.

There's an outside chance that we directly call some weird windows
function to deal with the filesystem.

> Does anyone out there know?

I don't.  :( I'm sorry to so often be so unhelpful on windows problems...
-- 
David Roundy
Department of Physics
Oregon State University

Sorry about the noise...