Screen freeze on startup.

[steve]

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.

[Jos]

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

[steve]

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

[Jos]

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

[steve]

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

[Jos]

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)

[steve]

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

[Jos]

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

[steve]

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.