... to map the video memory myself, possibly hook ZwDisplayString in the SSDT and re-route all calls to ZwDisplayString to my own method?!
Also, is the assumption correct, that a driver getting an IRP from my SMSS replacement and then issuing the map request to the video driver will act on behalf of my process, i.e. the mapped addresses still being valid.
Last but not least I'd like anyone who responds to give an advice, whether my driver should dispatch requests so that multiple displays could be used (or even some kind of display substitute).
Thanks in advance,
Oliver Schneider
PS: Does anyone here have informations about VESA (text) modes in conjunction with the system-supplied video driver?
May the source be with you, stranger 
ICQ: #281645
URL: http://assarbad.net
> Replace SMSS? Why would you want to do that? To get access to the
video screen? That seems like bringing in a bull dozer to smash a
mailbox. By "replace" SMSS, you mean you've created your own completely
home grown SMSS?
So, you've reimplemented Terminal Services and all the other portions
that are required to be in there and the communications to CSRSS and
everything?
Yes, replace SMSS.EXE from the recovery console/setup/setup CD.
No, I do not intend to create a full-blown replacement with TS support and so on and I believe this has not been part of the question either. I have searched the archive before posting the question and it seems many people need to question anything related with ZwDisplayString. However, I am not going to re-implement the session manager for a GUI-system! My SMSS.EXE replacement is going to be purely console-based.
Someone was able to replace the boot screen and things without resorting
to an SMSS replacement:
http://ian.joeuser.com/index.asp?c=1&aid=409
Yap, so you suggest that whatever I do, I do in kernel mode? So any un-caught exception will cause a blue-screen?!
Regards,
Oliver
--
May the source be with you, stranger
ICQ: #281645
URL: http://assarbad.net