Closed boeckmann closed 3 months ago
This also occurs with a kernel from May, before the JWasm conversion. And this also occurs with EDR-DOS 7.01.7.
Problem is most serve with 4DOS, occasionally with SvarCOM, and with EDR command it seems to work best (everytime?).
I can get this to work under 4DOS better by changing the following config.sys line:
SHELL=C:\4DOS\4DOS.COM /P
to
SHELL=C:\4DOS\4DOS.COM C:\4DOS /P
Since then I did not notice a failure. HOWEVER: When I temporarly switched the kernel to FreeDOS, the 4dos setup was spawned on boot. I am wondering why this did not occur when starting 4dos under the EDR kernel.
This issue, and the one about the CTRL+C handler being unable to spawn a new process, makes me think that it would be useful to have a tool that intercepts and logs all INT 21h requests and their results to help understand who is at fault and why. Andrew Schulman used such a contraption when writing Undocumented DOS, it is named INTRSPY and was apparently written by Dave Maxey, an experienced QA specialist. https://www.pcjs.org/software/pcx86/sw/books/undocumented_dos/ -- might be worth giving this a try, or looking for similar options..
https://pushbx.org/ecm/download/interc3.zip is one such tool.
https://pushbx.org/ecm/download/interc3.zip is one such tool.
Very cool! 1987, wow. I did not find any mention of licensing by glancing inside the zip file. Any idea if it would be okay to distribute this software as a SvarDOS package?
The licensing is given in https://hg.pushbx.org/ecm/interc3/file/418bdbad4ee0/intercep.asm#l10 and lists public domain, no copyright is claimed, and Paul Vojta's and my copyright under the Fair License as parts of lDebug were used.
thanks, I've added intercep to the SvarDOS repository of packages. unfortunately it seems to be unsuitable for SvarCOM testing because it needs to execute the monitored program itself, but still a very nice tool for monitoring "normal" programs (like wmake).
//edit: I did not find any clear version so I used "2021" as the package version
the error message suggests that when wmake executes a shell command for "cd", the cd "program" itself isn't found - one would think it's a shell builtin, but maybe it's an external program for 4dos and somehow the PATH is messed up? i suspect the source of wmake dealing with shell command spawning could give some clues as to what happens.
I also thought that CD is a wmake internal, but have to look up in the source to be sure. I will deal with this on weekend, when I have a little more time...
I have the impression that the latest SvarCOM modifications fixed this!
Looks like finally the pieces come together :)
That's odd since the SvarCOM changes were only about handling ctrl+c situations and COMSPEC lookups while respawning. Only explanation I can think of is that wmake is treating 'CD' like a normal program and executes it through COMMAND/C. In such case maybe the previous SvarCOM had issues with spawning such child process and wmake failed on that. But you said the issue was also present with 4dos, so it's still strange.
4DOS runs everytime since the options exe was run which changed the config.sys SHELL line for 4DOS to contain its directory. It seems to run with every shell now, every single tiime :)
While trying to build the kernel on an EDR installation I noticed that somewhat randomly WMake can not CD into a directory after boot. This happens on FAT32 and FAT16 volumes and with OpenWatcom 1.9 and v2 wmake. Other programms can access the directory fine. I sometimes can get it to work by starting a program or changing directories. And if it starts to work it stays so until reboot. I can then build the kernel perfectly fine.
Minimal Makefile to reproduce: