If a program doesn’t signal it’s actually idle, idle detection is mostly based on the absence of user interaction or file access for a given time (number of CPU instructions). With keypresses and mouse actions this time should be around 6 seconds, for file access some 60 seconds. A low-end real CPU will result in more time, a high-end one in less.
This delay before going idle is to ensure a program isn’t doing some time-consuming calculations, vDos going to idle premature, the calculations taking forever.
Since the program quickly consumed less CPU time with NTVDM, I guess FoxProX will first establish if it’s running in Windows, and only if so signal Windows to go idle on the program. I’ll have a look at that.
FoxPro indeed inquires if it is running under Windows/NTVDM, vDos reports just DOS. It then seemingly doesn’t call INT 2F/1680 - MS Windows, DPMI, various - RELEASE CURRENT VIRTUAL MACHINE TIME-SLICE (supported by vDos). Doesn’t call functions to wait for keypresses, but checks one is eventually available. And doesn’t fall back itself to call DOS INT 28 - DOS IDLE INTERRUPT.
So you just have to live with vDos maxing at 100% of its designated core for some time. The alternative to go idle sooner is no practical option.
With me in dBase 5 are the same things regarding high CPU usage. When I have started my application and it is standing still in a selection menu, then my cpu usage is around 33% constantly in vDos 01-03-2020 Do I understand that this will be improved in an upcoming version?