Hi Cordata,
> So is the problem simply eating up processor time?
Note that this is probably not VM specific and would
also happen on real hardware. Why not run DOS on your
real 64 bit CPU? At boot, it is in 16 bit addr space
anyway, allowing the usual DOS 16/32 bit calculations.
You would waste the extra CPU cores and ability to do
things with more than 4 GB RAM or 64 bit calculations
(unless using the FPU) but running DOS inside a VM in
another OS will have the same problem. Of course it is
good to run DOS inside a VM if you want to use a host
OS (Linux, Windows) while just ALSO running some DOS
things in the VM. Also, the VM can help by behaving as
if it had classic sound / graphics / network cards, so
DOS does not have to use HDA / accel graphics / Wifi /
USB / other drivers itself :-)
> But the real problem is the applications. For example FreeDOS
> EDIT.EXE is a terrible offender. I modified it for my own use to
> throw in a few HLTs and now it works great. People will talk about
> making applications "FDAPM aware" and...
Note that EDIT already WAS working great with FDAPM for
example in version 0.7d, but something in some of the
newer versions broke that :-( Applications which just
use blocking keyboard reads are already fine anyway, so
only applications like EDIT or SSH2DOS which do other
things in the background need to explicitly take care
to have FDAPM-detectable idle states.
Here is the relevant code from EDIT 0.7d to help FDAPM:
BOOL dispatch_message(void)
{
...
/* only message.c can fill the event queue, but all components */
/* can fill the message queue. Events come from user or clock. */
if ( (EventQueueCtr == 0) && (MsgQueueCtr == 0) &&
(handshaking == 0) ) { /* BORED - new 0.7c */
union REGS r;
r.h.ah = 0x84; /* "network" idle call */
int86(0x2a, &r, &r); /* network interfaces */
}
...
... process events in the queue ...
...
}
> If you have the source code, this should be easy. ...
> look for processor loops and put in some HLTs.
Because EDIT has a message pump, it was less easy there.
On the other hand, as said, most DOS apps poll for user
input at some point, usually when they have time to do
things for the user, in other words, when they are idle.
As long as that polling is "blocking" (wait for key!) and
not "busy waiting" (key pressed? no? then check again at
once!) it is easy enough for FDAPM in APMDOS mode to get
your CPU usage down by doing some HLT and similar for you.
For comparison, EDIT also has non-user events which have
to get pumped through the message pump, so if you were to
just use blocking wait for input, the clock and maybe a
screen update here and there would freeze while the user
is not typing (or clicking, EDIT has mouse...) anything.
In SSH2DOS, for example, the problem is that it always is
keeping an eye on the network to see whether there is any
new data to display, which makes your CPU go to 100%. If
it had some concept of "now I have looked often enough in
the incoming network data buffer for this second", and a
buffer which can block when it gets full, it would help.
Regards, Eric
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
