>>>> "Craig" == Craig Lanning
<CraigL(a)DyCon.com> writes:
Craig> At 03:40 PM 10/23/99 +0200, Adrian Aichner wrote:
>>
>>>> "Craig" == Craig
Lanning <CraigL(a)DyCon.com> writes:
>
Craig> create_child: exe=c:\BIN32\ls.exe,cmdline=c:\BIN32\ls.exe
>
Craig> create_child.CreateProcess leads child PID
-725391,
Craig> changing to PID 725391 Fatal error: assertion failed, file
Craig> sysdep.c, line 353, pid != NULL
>
>> Hi Craig,
>
>> did you ever see a message like:
>
>> Fcall_process_internal.child_setup returns
PID 725391, using PID -725391
Craig> No, I sent you all the messages that were printed.
Hmmh, beats me ...
> If not, then
> if (os_subtype == OS_WIN95)
> would not be true for Windows 98. That would be a problem!
Craig> How is os_subtype set? Maybe I can figure out what it is
Craig> for Win98.
See src/ntheap.c. It uses a SDK system information function called
GetVersion().
If this hunk against callproc.c (part of the patch I just sent) does
not produce any output (to the DOS box you started src\xemacs.exe
from), then the os_subtype test is wrong:
#ifdef WINDOWSNT
pid = child_setup (filefd, fd1, fd_error, new_argv,
(char *) XSTRING_DATA (current_dir));
+ /* OpenProcess() as soon after child_setup as possible. It's too
+ late once the process terminated. */
+ if (os_subtype == OS_WIN95)
+ {
+ stderr_out ("Fcall_process_internal.child_setup returns PID %d, using PID
%d\n", pid, -pid);
+ /* create_child() in ntproc.c hacks PIDs for OS_WIN95 to fit
+ into Lisp_Int, i.e. negates them. Hence we have to use -pid
+ to get at the real PID for OS_WIN95. */
+ pHandle = OpenProcess(PROCESS_ALL_ACCESS, 0, -pid);
+ }
+ else
I'll take out that message if all works out well.
If you have cygnus grep, please try this test-case if things work out:
(dotimes (i 200 "grep test passed")
(unless
(= 2 (apply 'call-process "grep" nil '(t nil) nil
(list "drivers" "c:\winnt\system.ini")))
(error "Incorrect call-process return value!")))
While the test is running please act unnatural. Move other
applications like a madman, start cpu-intensive processes, and the
like. This should check whether there's any danger the process goes
away before we can obtain a handle for it. I haven't seen problems
with this in recent versions of my patches on NT.
Thanks,
Adrian
>> Please let me know.
>
>> Adrian
Craig> Craig