Tasks which are executed under Windows95/98/NT are
time sliced which means that when a given task has exhausted
its allocated execution time slice then that task is
automatically suspended while another task is executed. All
of this is controlled by things which we all probably should
learn but we don't have enough time. This includes ME! The
fact that the CPU usage shows a usage value does not mean
that the system is out of a resource. It means that the system is
David Gabler is correct in that PLBWIN is event driven
which means that when Windows has something for the
runtime to do, then an event is queued for the runtime to
process. This includes the keyboard keyed actions.
The PLB386 runtime being a DOS based executable has to
continually loop while executing a DOS API to determine if
something has been keyed at the keyboard. This action is then
causing the PLB386 runtime to use as much of its allocated
execution time slice as it can. Notice, that while PLB386 is
looping, it is also trying to determine when and if a timeout
*T=nnn operation has expired.
Now, that we know why the PLB386 runtime is looping, I need to tell you that the looping action is an indirect reason for the high CPU percent usage. It turns out that PLB386 is generated to be executed by a DOS Extender named DOS4GW. The PLB386 runtime is actually a Linear Executable (LE) file format that gets executed by the DOS4GW DOS Extender. As the PLB386 runtime is looping to fetch current keyboard keyed actions, the DOS4GW has to page the PLB386 runtime code into memory space to be executed. This is causing the high CPU percent usage to appear.
All of this can be expected in that DOS is a single tasking OS environment and there are certain limitations we must live with. However, I can help this situation for a KEYIN only, where I will consider putting a keyword into the runtime which will execute a different DOS API which will cause the PLB386 runtime to stop looping while waiting for a KEYIN. This will reduce the CPU usage because the PLB386 runtime will be idle while waiting for the OS to fetch a character. This can only apply to a KEYIN without an *T=nnn control.
The last thing to consider here under DOS is that you can change the Windows PROPERTIES for the MSDOS command.com shell such that any program executing in that shell would be automatically suspended when that Window becomes inactive or is placed into the background. The PLB386 runtime continues to try to fetch keyed characters even while in the background because it does not know that it is being executed under Windows. This would cause the PLB386 runtime or any other task running in the MSDOS shell to be suspended thus creating more idle time to be used by other active tasks. Note that this may not apply to your application if you are expecting execution to continue even when outside the scope of a KEYIN statement.
The PLBCON runtime is somewhere between PLBWIN
and PLB386 in its operations. PLBCON is created using the
MAKECON utility for those unfamiliar with its usage.
PLBCON is a 32 bit application just like PLBWIN except it
uses the Windows CONSOLE for all KEYIN and DISPLAY
statement operations. PLBCON CANNOT be purely event
driven like PLBWIN because the keyboard keyed actions for
the CONSOLE are processed differently by Windows. This
difference makes it such that PLBCON must also loop, first
looking at the Windows queue and second looking for
CONSOLE keyboard keyed actions. Therefore, PLBCON
cannot be a purely event driven task.
Now what this means is that PLBOCN will have less idle time than PLBWIN and would require more system resource usage. You will also see an increased CPU useage in this case. However, I will consider causing the PLBCON runtime to waste ( go to sleep ) some number of MS which will reduce the CPU usage while in a KEYIN statement.hat PLBCON must also loop, first looking at the Windows queue and second looking for CONS