Hi Eric,
> another chance would obviously be making fdapm aware :-)
Do you mean, authors making their programs FDAPM aware? Of
course this would be ideal.
> Do you know what makes fdapm unaware of the programs that
> you mention, while dpakbd (?) is aware of their idleness?
Sorry, as I'm just a user I have no idea of the complicated
stuff that goes on behind the scenes.
The only programs I write are in high-level languages such as
Euphoria. Interestingly, I checked the Euphoria manual, and
found that there are two distinct input commands, get_key() and
wait_key(). The difference is that
"on multi-tasking systems like Windows or Linux/FreeBSD,
this 'busy waiting' would tend to slow the system down.
wait_key() lets the operating system do other useful work
while your program is waiting for the user to press a key."
So I changed all the get_key's in my programs into wait_key's,
and it really worked ... it even passed the finger-on-CPU test
:-) But that's just about the kind of stuff I'm able to do, not
more.
Examples of non-aware programs which I use often and typically
for long periods are: SuperCalc spreadsheet, DataPerfect
database, Desi-III CAD, and the image viewers ShowJPG, PictView
and LXPic. I don't think their authors would change them at this
juncture. Fortunately, DPAKBD has been working well with them,
but subject to the inconveniences I reported in the previous
email, like freezing and rebooting.
Text editors are no problem, since the best of them -- Aurora,
FTE, Thomson-Davis, SetEdit -- are all natively FDAPM-aware.
Same for the Links browser.
Regards,
Marcos
--------------------------------------
Marcos Fávero Florence de Barros
Campinas, Brazil
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Freedos-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-user
