Re: Revised installer for XyWin

["Wengier W" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "wengierwu" for DMARC)]

Hi Carl,

In my previous message I said the following:

2) "start.exe dir" (or "start.exe dir x*") will pop up a a dialog asking "How do you want to open this file?", only if there is a file named "dir" (without extension) in the current directory.

The above sentence should be changed as follows:

2) "start.exe dir" (or "start.exe dir x*") will pop up a a dialog asking "How do you want to open this file?", if there is a file named "dir" (without extension) in the current directory or in the search path.

Clearly, if there is a file named "dir" in your search path, even if it is not the current directory, the dialog will show up too. If there is no such file in the current directory nor in the search path, then the command will open a cmd.exe window, which quickly closes, at least in my computers.

Wengier

On Wednesday, January 29, 2020, 12:36:05 a.m. EST, Wengier W <dmarc-noreply@xxxxxxxxxxxxx> wrote:

Hi Carl,

Thanks for your feedback! I have made further testing about this, so let's suppose the file CMDS.LST does not exist, then I will get the following results on my computer:

1) "start.exe dir" (or "start.exe dir x*") will open a cmd.exe window, which quickly closes, if there is no file named "dir" in the current directory;

2) "start.exe dir" (or "start.exe dir x*") will pop up a a dialog asking "How do you want to open this file?", only if there is a file named "dir" (without extension) in the current directory.

Since you get a dialog when you run the above command, I think there is likely a file named "dir" in your current directory, so that Windows will ask you how to open this file.

On the other hand, when you run "start.exe dir/p" nothing happens because "dir/p" is considered to be a whole command in such case instead of "dir /p" (with a space in the middle). I believe you will get the same dialog as "start.exe dir" when you run "start.exe dir /p" (within a space between "dir" and "/p").

When you run "start.exe attrib", the cmd.exe window opens and closes quickly when there is no file named "attrib" in the currently directory. This should also apply to other commands if there is no file with the same name as the command in the currently directory.

In any case, I think it will be a nice feature for start.exe to automatically separate the command and argument(s) in case there is no space between them, like "dir/p" you mentioned. So I have updated start.exe again, which will see "start.exe dir/p" as "start.exe dir /p" instead of treating "dir/p" as a whole command, and the new files are still downloadable from:

http://vdosplus.org/files/start.zip

Wengier

On Tuesday, January 28, 2020, 10:57:12 p.m. EST, Carl Distefano <cld@xxxxxxxxxx> wrote:

Reply to note from Edward Mendelson <em36@xxxxxxxxxxxx> Tue, 28 Jan 2020
20:54:54 -0500

> This is really brilliant programming. It makes it possible to
> shell to DOS in the same way that WordPerfect and other programs
> did back in the DOS era. Thank you for it.
>
> Kari, assuming that it's all right with Wengier, I hope you might
> consider replacing the old start.exe with Wengier's new version in
> the vDos-Xy installer.

I agree, Edward, but think we may want to allow a little more time to
shake out the wrinkles before adding the new start.exe to the standard
vDosPlus package or the Xy installer. In my early testing, I'm getting
some odd results, depending on the argument I supply. For example -- and
in all of these examples CMDS.LST does *not* exist -- when I command

start.exe dir

  or

start.exe dir x*

I get a dialog that asks "How do you want to open this file?" and lists
possible Windows programs.

But if I command

start.exe dir/p

nothing happens; same result with start.exe xcopy and start.exe xcopy /?.
And if I command

start.exe attrib

the output of the attrib command quickly scrolls by in a cmd.exe window,
which then closes.

The inconsistent behavior when the argument string is identical to a
built-in or external Windows command is a bit unsettling. For myself, I
would expect start.exe arg to behave just like cmd.exe /c start. With no
argument, cmd.exe /c start opens a new cmd.exe window, so that's good.
With cmd.exe /c start arg, if arg is a Windows command, it executes the
command, and if arg is a filename, (a) if the file exists, it either
opens the file in its associated Windows application or displays the
dialog that asks "How do you want to open this file?", or (b) if the file
does not exist, throws up the Windows error message box that says,
"Windows cannot find [filename]. Make sure you typed the name correctly,"
etc.

And, lest anyone forget, we need start.exe because cmd.exe /c start, when
executed from a DOS program, causes a cmd.exe window to flash by, whereas
start.exe does the job cleanly.

I think start.exe is very close to perfect, and hope that Wengier will
weigh in on the above.

--
Carl Distefano
cld@xxxxxxxxxx