Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

polling (Announce)

posted by ecm Homepage E-mail, Düsseldorf, Germany, 21.08.2011, 16:28

Just for the record, in my applications I idle with the following sequence:

* issue 2F.1680, done if it zerod al

* if in DPMI protected mode, issue 2F.1680 via 31.0300 (ie from real/V86 mode), done if it zerod al

* otherwise insure interrupts are enabled (via sti) then execute a hlt instruction, assume this did it

The second way is necessary because at least some DPMI environments (including the NTVDM's) do not support 2F.1680 even though it's supported in their real/V86 mode.

The third way, executing hlt, is a default handler to idle directly. It doesn't work in some environments. I provide an option to change whether hlt will be used at all; if that option is set, my handler gives up instead of attempting to idle via hlt.

I additionally currently never issue hlt in DPMI protected mode because DPMI hosts seem to dislike that instruction (or possibly sti, not sure).

I'm not using Int28 primarily because there is no intrinsically supported way to determine whether it did something useful at all. (One could check for, say, whether the handler wasn't a single iret, but that wouldn't always indicate that the handler would do something useful if called right now.) If it did something, additionally attempting to idle by hlt or 2F.1680 afterwards would decrease performance and responsiveness. If it didn't, not additionally attempting to idle in other ways afterwards would mean not to idle at all. (I might add an option to my application to call Int28 instead or additionally though.)

I assume that Int2F can be called without crashing the machine. But then again, I make that assumption everywhere, so if I'd crash because Int2F is invalid, then I'd crash much earlier before ever reaching the idling code.

One could say I'm running the idling method detection every time I am idling. I recognize that this may not be the best way to do it. However, some of my applications stay resident in one or another way, so they want to catch changes in interrupt handlers and such - necessitating running the detection again. I might change that so I won't try detecting changes every time I idle though.

---
l

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22632 Postings in 2109 Threads, 402 registered users, 298 users online (0 registered, 298 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum