Ben Wing wrote:
1.It must be tested and shown to work on all of Windows 95, Windows
98, NT 3.5, NT 4.0. If it absolutely will not work on NT 3.51, this
must be noted when you run the installer.
I have access to Win95, 98 and NT4.0. I routinely test the installer
on all of these. I do not have access to NT3.51, so I have no way to
test. It seems pretty clear from the reports coming in that it simply
won't work on 3.51. I will add an OS-version check to the installer
and bail out if OS == NT && version < 4.0, unless somebody can tell
me what needs to be done to make it work on WinNT.
2.The installer should be mentioned in the same place as the other
binary distributions, and its operation needs to be documented
somewhere on the XEmacs web site in addtion to being mentioned in
the INSTALL file.
3.This installer needs to be available on the ftp site in the same
place as the other binary distributions.
I have stuck the installer in my personal little bit of web-space, but
have always hoped that somebody would pick it up and put it on the
main XEmacs site.
Subprocesses on Windows:
1.Must work at least somewhat (as well as possible) on Win95 and Win98.
2.What works and what doesn't should be clearly documented.
I submitted a patch that fixed a bunch of the Win95/98 subprocess
brokenness, but it was rejected for (at least) two reasons: (A)it was
a bit kludgey, and (B) there is some disagreement about the need for
"cmdproxy" and the ability of the existing XEmacs subprocess code to
spawn 16-bit subprocesses.
The kludge was there because I didn't understand why the variable
"win32_quote_process_args" didn't work as advertised, and I introduced
another variable to do the same thing. The problem was
"vars_of_ntproc" not getting called from emacs.c.
On the other issue, I am fairly certain that "cmdproxy" is *not*
necessary; "command.com" should do just fine. "ntproc.c" checks
whether the process being spawned is "16-bit" (if it has the ".com"
extension it is considered 16-bit) and if so uses cmdproxy to spawn
it. However when I simply took this piece of code out I found that
XEmacs can apparently spawn "command.com" just fine.
It's perhaps a bit confusing to follow the code, the "spawnve" that is
called at line 734 in "callproc.c" is *not* the Win32 spawnve
function, but the spawnve function in "ntproc.c", which is capable of
spawning a 16-bit subprocess. (Try it and see....)
Anyhow, I'm glad you consider the broken subprocesses on 95/98 as a
problem worth fixing.
I will clean up my rejected patch to make it less kludgey and resubmit
it; maybe it can still make it into 21.0.
1.Complete, well-defined, well-tested and properly integrated.
I'll leave these to somebody else!