A Black Falcon Wrote:That is just not true, particularly for DOS games. DOS, remember, gives the game FULL control -- there isn't really much of an OS between your game and the hardware. Only commands the game allows work. Now, if you're running in Windows some commands will come through -- Alt-Enter for resize, Alt-Tab for task switching, the Windows key to open the Start menu, and a few others (also stuff like Control-F11/F12 in DOSBox, to change the speed of emulation)... but printscreen?Thats now true all DOS games running must still report to HAL the Hardware Abstraction Layer on 2000 and XP kernals which proves that all major functions of windows still have control of the program at least on 2000 and XP.
Hmm... you made me wonder, actually... and indeed, Printscreen (and Alt-Printscreen) are override commands in Windows DOS boxes, at least in WinME. That is, it'll override the internal game command for the button and do a default function, and do the windows default action, unless you disable the override keys in the properties screen (I think XP cripples these options, so don't be surprised if you don't get such choices as enabling or disabling memory types or specific override keys on a per-game basis...)
Testing with DOSBox, printscreen does seem to take shots inside the emulation, but the colors are all messed up... not surprising that there are issues... really, just run the game in a DOS or DOSBox window and take Printscreen shots there, remembering Alt-Enter to resize (if it won't run in a window as a dos program, emulate, because that can run in a window just fine).
Addentionaly DOS porgrams have no direct contol of your computers hardware, DOS programs must report to HAL. If a direct hardware call is made HAL troughs an exception on behalf of the DOS program and the windows kernal terminates the APP. It's one of the security mesures on 2000 based kernals it prevents DOS programs from bypassing NTFS file system security and reading the files directly.
If you were to boot up without the hardware abstraction layer NTFS file system security is completly null and void because you could just make a direct call to the harddrive and read the file directly. To restore a NTFS file I once I booted up in a pure dos mode with a dos boot disk and used a free utility to read the NTFS partition directly, with out the hardware abstraction layer to prohibit direct calls, reading the file is a simple matter of sorting out the data portion from the file attribute portion of the NTFS file. NTFS files by default arn't even encripted.
To test this knowledge I tried to run the utility while windows was running and as expected an exception was throne and the appropreate HAL valation error message was displeyed.
As a safety measure windows refuses to do anything without HAL.dll
See Attached....
It all boils down to this: Windows has complete control of DOS programs and PrintScreen is a part of Windows.
However programs can request to recieve keboard events before the operating system in which case if the program has a printscreen key event handler, it would prohibit the kernals printscreen handlers for screen shots from being called allowing the program to choose weather printscreen will work or not.
The solution to your problem is a third party screen shot program, there is plenty of freeware screen capture programs available, they request to recieve keyboard events first before all other programs and should be able to accomplish your screen capture.