old fashioned memory access in a visual C++ console application?
-
I was wondering if one can still use direct video memory access in text mode to write characters to certain screen (screen now-a-days would just be a console window) positions. In visual C++ 6, is there anything special you have to do to be able to use address 0xB8000000 in this way? I was thinking that the address should still be used for the console windows to maintain backwards compatibility with the old DOS applications, but maybe the console windows used by win32 console applications are quite different from the command line windows? Thanks
-
I was wondering if one can still use direct video memory access in text mode to write characters to certain screen (screen now-a-days would just be a console window) positions. In visual C++ 6, is there anything special you have to do to be able to use address 0xB8000000 in this way? I was thinking that the address should still be used for the console windows to maintain backwards compatibility with the old DOS applications, but maybe the console windows used by win32 console applications are quite different from the command line windows? Thanks
-
The console windows are different in that they get the protection of the HAL, so direct video memory access is forbiden. Otherwise, you could access any hardware directly just by running through a console window and that would be a serious breach.
So is there a way to compile the program in visual C++ to be run within a true command window? I guess I'd need to be able to turn off the whole win32 as the target platform thing... I am not sure that is possible.
-
So is there a way to compile the program in visual C++ to be run within a true command window? I guess I'd need to be able to turn off the whole win32 as the target platform thing... I am not sure that is possible.
No. It's not a compiler issue or a 'true command line' issue. The operating system treats memory (all memory, including video) and I/O as protected resources. As such, the O/S reserves control over these resources in order to protect the system and other applications from ill-behaved applications.
Software Zen:
delete this; -
No. It's not a compiler issue or a 'true command line' issue. The operating system treats memory (all memory, including video) and I/O as protected resources. As such, the O/S reserves control over these resources in order to protect the system and other applications from ill-behaved applications.
Software Zen:
delete this;Sorry to be dense here, but doesn't that mean that old DOS programs would no longer run under windows? Hmm... I just got out 'Bad Blood' which is an old DOS game from 1990. It has reasonably fancy graphics (for the time). It ran fine on windows XP (much to my surprise) and my recollection from those days is that graphics pretty much always required direct video memory access. So there must be some special dispensation given by windows to these sorts of antiquainted programs... so presumably, if programs using old-style DMA don't work when compiled on visual C++ 6, the compiler must be adding some stuff to the executable indicated to the operating system that it shouldn't tolerate the DMA in the program.
-
Sorry to be dense here, but doesn't that mean that old DOS programs would no longer run under windows? Hmm... I just got out 'Bad Blood' which is an old DOS game from 1990. It has reasonably fancy graphics (for the time). It ran fine on windows XP (much to my surprise) and my recollection from those days is that graphics pretty much always required direct video memory access. So there must be some special dispensation given by windows to these sorts of antiquainted programs... so presumably, if programs using old-style DMA don't work when compiled on visual C++ 6, the compiler must be adding some stuff to the executable indicated to the operating system that it shouldn't tolerate the DMA in the program.
Probably what's happening in this case is that XP has 'virtualized' the hardware sufficiently to make the DOS program think that it is accessing the hardware directly. In actuality, the processor intercepts the I/O instructions executed by the DOS virtual machine, and substitutes whatever actions it deems appropriate. Windows XP goes much further along this path than any previous version, in order to smooth the way toward a common, Win32-based version of Windows. XP realizes that goal, partly through this virtualization and partly through the attrition of DOS applications. My intent in my original response was mainly to discourage the author from pursuing this method in a new application. A much better approach would be to use the API mechanisms provided for the purpose, rather than relying on a 'band-aid' that may not be around in the next major release of the O/S.
Software Zen:
delete this; -
I was wondering if one can still use direct video memory access in text mode to write characters to certain screen (screen now-a-days would just be a console window) positions. In visual C++ 6, is there anything special you have to do to be able to use address 0xB8000000 in this way? I was thinking that the address should still be used for the console windows to maintain backwards compatibility with the old DOS applications, but maybe the console windows used by win32 console applications are quite different from the command line windows? Thanks
For old dos16 application windows starts Virtual Dos Mashine to emulate DOS environment. You can see it in task manager as ntvdm.exe process. Video memory of dos application can be found in this process memory at 0xB8000. (BTW the keyboard buffer is at 0x41A) So, this is the way to control old dos application. You can grab sceeen, and send keystrokes. Dim.