jseidman@jarthur.Claremont.EDU (Jim Seidman) (04/17/91)
Does anyone know a way to determine from an app if the screen is currently displaying a full-screen DOS session? (Of course I'm talking 386Enh here, since in standard mode a winapp wouldn't be running at all while a DOS session was on the screen.) Bonus question: Can anyone guess why a program in a PeekMessage() loop (which is yielding control) would go through the loop several times more often when a (non-exclusive) DOS session was full-screen than when the same DOS session was windowed and in the foreground? (And no, the PeekMessage loop isn't doing graphics or anything like that...) Any help would be greatly appreciated! -- Jim Seidman, Headland Technology, 46221 Landing Parkway, Fremont CA 94538 UUCP: ames!vsi1!headland!jls INTERNET: hsv3!jls@apple.com "Love your enemy, smite your enemy, you still need an enemy!" -Joseph, in "Heart of the World"
wolf@netcom.COM (Buckskin Tech.) (04/19/91)
jseidman@jarthur.Claremont.EDU (Jim Seidman) writes: >Bonus question: Can anyone guess why a program in a PeekMessage() loop >(which is yielding control) would go through the loop several times more >often when a (non-exclusive) DOS session was full-screen than when the >same DOS session was windowed and in the foreground? (And no, the >PeekMessage loop isn't doing graphics or anything like that...) >Jim Seidman, Headland Technology, 46221 Landing Parkway, Fremont CA 94538 >UUCP: ames!vsi1!headland!jls INTERNET: hsv3!jls@apple.com >"Love your enemy, smite your enemy, you still need an enemy!" > -Joseph, in "Heart of the World" I'd suspect that since the DOS session is full-screen, a) the timeslicer is running and it's anybody's guess as to timing issues, and b) Windows may "know" that no human input will reach your app (no focus, no mouse, etc) so it's not spending any time correlating mousemoves and such. The "holes" in the queue might then show up to PeekMessage(). - Wolf