If you program doesn’t use [Ctrl]+V, you can still use that.
You could start vDos with the log option (….vDos.exe /log). Then look in the generated vDos.log file where the "No such file." comes from.
Thank you, Jos, for the fast and informative reply.
Yes, [Ctrl]+V works in True Basic 3.00 with vDos 2020.03.01. Being able to access the Windows clipboard from within the DOS program is immensely helpful.
The values returned by True BASIC's "GET KEY" statement -- and my customizations of the key bindings that are possible in version 3.00's editor (which I find to be much more user friendly and interactive than the editor in any of their Windows versions I have used) -- are affected by the "no extended keyboard" mode.
I had not used the log option before. The resulting file is attached.
The "hello.exe" program (to start the True BASIC editor, with on-demand interactive program execution) is expecting "noxkb" to be a True BASIC program file (noxkb.tru) that is to be run immediately (instead of opening the editor) upon startup of the language system.
For some reason, the '/noxkb' command line switch will be recognized only if there are no spaces between the program name and the slash for the switch.
I don't recall using any other program that disallowed a space before a command line switch.
vDos 2015.10.1 accommodated this quirky behavior. It seems that vDos 2020.03.01 does not.
The line "OpenFile failed: NOXKB.TRU(2) => c:\a\b\NOXKB.TRU(2)" states there's no NOXKB.TRU file in the current DOS working directory (no path supplied), resolving to Windows c:\a\b\NOXKB.TRU. NOXKB.TRU is located somewhere else?
There is no intention for there to be a NOXKB.TRU file in any location.
"/noxkb" is a command line switch so the language system will report the same key codes from corresponding keys in an "extended" keyboard, wherever they are located: 1) the numeric key pad (number, arrows, etc.) 2) the QWERTY/navigation sections of the keyboard.
The slash seems to be getting converted to (or prefaced with) a space, so the IDE (integrated development environment) in the hello.exe program is seeing noxkb as a file name (with an implied .tru extension), not as a command line switch.
Sorry, didn’t read your message that good. That extra space is added by vDos. The only versions that didn’t do that were 2015.10.01 – 2016.10.01. Seemingly that gave problems with other programs, so it was reinstated. Perhaps that space should not be added if the first character is a '/' or '-'?
When the vDos command line interpreter parses a line, that is split into two parts: The command (internal or an external program) to be executed. The remainder (passed on to the internal command or external program).
That remainder is then eventually prefixed by a space. To comply to the behavior of NTVDM or some program(s) expecting that (don’t recall). What I intended was to check that remainder for a leading '/' or '-', then skip adding a space.
It seems I don't understand how the vDos command line interpreter parses a 'prog-1' line in a context where both 'prog-1.exe' and 'prog.exe' are valid external programs. And you have been more than gracious in your attention to my posts.
Basically the command line is split at the first space, tab, '/' or '=' character. The first part is evaluated as an internal or external command. The second part is passed on to that command.
So "prog-1 -more" would become "prog-1" and " -more". If "prog-1" with a ".com", ".exe" or ".bat" extension is found (w/o a path, eventually in the PATH environment variable), that program is started with " -more" as its command line.
I’ll remove adding a space if the command line (the mentioned second part) doesn’t start with one.