|
Post by steve on Jan 16, 2019 12:14:22 GMT 1
I am trying to streamline the vDos startup and have come across some strange behaviour.
When I start vDos with the autoexec.txt file of
@echo OFF
USE C: C:\VDOS\
USE O: O:\
CD C:\OPS
the vDos window is ‘instantly’ displayed. When I then type “OPS LON-1” at the C:\> prompt my program ’instantly’ loads and runs. The time OPS takes to load the database and display the first input field is about 6 seconds.
However if I run vDos with the autoexec.txt file of
@echo OFF
USE C: C:\VDOS\
USE O: O:\
CD C:\OPS
OPS LON-1
there is a 2.5 second pause before the screen is updated and the vDos window is displayed and a further 3.5 seconds before the first OPS input field is displayed.
In other words the overall time to display the first input field is about the same, just nothing happens on the screen for 2.5 seconds when OPS is invoked from the autoexec.txt file! This pause may cause the operator to assume that nothing is happening and then click on the Windows shortcut several times!
In both cases the config.txt file is
MOUSE = ON
WINDOW = 100
Any ideas, please?
Many thanks,
Steve
PS: I think the problem may be being exaggerated because OPS is accessing a database on a USB stick (during testing) rather than a remote disk on the network.
|
|
|
Post by Jos on Jan 16, 2019 12:32:04 GMT 1
This ‘strange’ behavior is intended.
vDos won’t show anything until the DOS program is inquiring the keyboard (ready for input). This to hide an initial black window with (for the user meaningless) commands being echoed, the DOS program displaying an intro screen, logo… Could be the DOS program for instance doesn’t require input, so after 2.5 seconds vDos still displays its window. If you don’t want to wait that long, you could add a PAUSE command to autoexec.txt, or execute some little program that inquires the keyboard.
Jos
|
|
|
Post by steve on Jan 17, 2019 10:58:29 GMT 1
Thanks Jos, I shall have an experiment.
May I suggest that in the next release you make this an option in config.txt.
Cheers, Steve
|
|
|
Post by Jos on Jan 17, 2019 12:04:20 GMT 1
My goal is to minimize the number of options in config.txt. So I don’t intend to add any that are useful to only one (or a few) and what can be achieved alternatively, sorry.
Jos
|
|
|
Post by steve on Jan 18, 2019 11:16:03 GMT 1
Hi Jos,
I fully understand.
As you suggested I tried Pause - that works but requires the operator to enter return. I have altered the OPS program to stuff a character into the keyboard buffer, then reading back from it - that didn't seem to work.
Is there any way you can think of that will work transparently, i.e. without Operator intervention?
Steve
|
|
|
Post by Jos on Jan 18, 2019 15:22:00 GMT 1
OK, attached a 9 byte program that just does a simple keyboard request. I haven't tested it, no DOS program around that takes more than 2,5 second to start... Jos Attachments:INT1601.COM (9 B)
|
|
|
Post by steve on Jan 19, 2019 12:39:55 GMT 1
Hi Jos,
I have inserted an invocation to INTO1601 into autoexec.txt and it did not seem to have any effect. Unfortunately the screen still 'freezes' for 2.5 seconds.
Steve
|
|
|
Post by Jos on Jan 19, 2019 15:24:35 GMT 1
I didn’t test INT1601. The problem is that vDos doesn’t initialize the window the first 0.2 seconds. That was once added when 4DOS was embedded as the default command line processor and messed up the 2.5 second max delay by inquiring the keyboard (I’ll remove that in the next version).
You’ll have to add something before starting INT1601 that eats some 0.15 seconds processor time. Or add an initial loop to INT1601 that let the system timer do 8 ticks or so.
Jos
|
|
|
Post by steve on Jan 20, 2019 20:13:25 GMT 1
Hi Jos,
Following your suggestions I wrote a 3 line C program
main() { ungetch(26); // Stuff EOF into keyboard buffer delay(200); // Wait 200ms getch(); // Read EOF from keyboard to stop vDos 2.5sec screen hold-off.. }
not very elegant but it seems to work. Thanks for your help.
Steve.
|
|