Xref:	news-dnh.mv.net comp.os.ms-windows.programmer.drivers:3767
	comp.os.msdos.djgpp:1784
Path:	news-dnh.mv.net!mv!news.NH.Destek.Net!news2.net99.net!news.cais.net!news.sprintlink.net!simtel!harbinger.cc.monash.edu.au!silas.cc.monash.edu.au!not-for-mail
From:	junaid AT silas DOT cc DOT monash DOT edu DOT au (Mr A. Walker)
Newsgroups:	comp.os.msdos.djgpp,comp.os.ms-windows.programmer.drivers
Subject:	MAPPED DPMI VIDEO MEMORY
Date:	28 Aug 1995 07:30:57 GMT
Organization:	Monash University
Lines:	25
Nntp-Posting-Host:	silas.cc.monash.edu.au
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Dj-Gateway:	from newsgroup comp.os.msdos.djgpp

	Well after pondering over the frailty of the near pointer hack
to access physical memory under MS Win 3.1 and friends DPMI v0.9 
implementation i had a nice thought.
	I think it is possible to use a VxD to create an memory
mapping of the video segment in the virtual address space (and this
might provide the 'proper' privaledged operation to gain access
to this sensitive area of memory). It might even be possible to do
this so the virtual address remains constant regardless with 
changes in the program's address base.
	Eg 32-bit DOS flat mode program sets base of DS to some
physical address, but always at virtual address 0xnnnnnnnn the 
video segment is present, despite changes in the base and size of 
DS. This could be a way of implementing the much missed 0xd0000000
video address in djgpp v1.12 .

	Would someone familiar with Windows programming comment?
How would this be implemented, and how practical under;
MS Win 3.1 and '95 ? How can the virtual address be made constant especially
when changes in the DS base address are made (either explicitly or thru
resize requests)?
	How would one go about using the _MapPhysToLin , _CopyPageTable
.. Are these services available in a 32-bit DOS box?
	Too bad DPMI V1.0 is not implemented in Windows ):

Junaid.

- Raw text -