Xref: news-dnh.mv.net comp.os.ms-windows.programmer.drivers:3787 
      comp.os.msdos.djgpp:1791
Path: news-dnh.mv.net!mv!news.sprintlink.net!sundog.tiac.net!basistech.com!bsg
From: bsg AT basistech DOT com (Bernard S. Greenberg)
Newsgroups: comp.os.msdos.djgpp,comp.os.ms-windows.programmer.drivers
Subject: Re: MAPPED DPMI VIDEO MEMORY
Followup-To: comp.os.msdos.djgpp,comp.os.ms-windows.programmer.drivers
Date: 28 Aug 1995 21:47:18 GMT
Organization: Basis Technology, Inc.
Lines: 80
References: <41rrbh$3ev AT harbinger DOT cc DOT monash DOT edu DOT au>
Nntp-Posting-Host: narita.basistech.com
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Dj-Gateway: from newsgroup comp.os.msdos.djgpp

Mr A. Walker (junaid AT silas DOT cc DOT monash DOT edu DOT au) wrote:
: 	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.

This doesn't make a whole lot of sense in the context of Win3.1/Win95.

: 	I think it is possible to use a VxD to create an memory
: mapping of the video segment in the

What do you mean "the"?  There are all different kinds of virtual
address spaces, depending if you're a DOS virtual machine, the System
Virtual Machine, or any of the Win32 redefinitions of the System
Virtual Machine.

:                                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.

What are you trying to -accomplish-?  It sounds like you're trying
to defeat Windows' virtualization of the video display.  What is
your extended DOS or whatever program going to do when time-sliced
into another running job?  Video virtualization is there for a reason.

: 	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.

Windows doesn't have any "32-bit DOS flat mode programs."  "32-bit flat
mode programs" are called "Win32" and are run in the System Virtual machine,
with the "private arena" swapped via page directories to multiprogram.
32-bit programs in Win3.1 and Win95 cannot use any of the file system
or system services except by thunking to 16-bit DLL's, which must be
 in the system VM.  The Virtual Machine Manager cannot accept INT's
from 32-bit user-ring code.

You can implemented your own DOS extender with ring 0 help, but
why? Win32 is a damned good one.

: This could be a way of implementing the much missed 0xd0000000
: video address in djgpp v1.12 .

djgpp is a single-user dos extender.  Windows is a multiprogrammed
dos-extender.  You have to play by its rules.  You cannot have
your cake and eat it- take over the video display without being
prepared to share it, and you'd better be prepared to take over
-all- the responsibilities of the operating system.

: 	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)?

Your understanding of what the DS register is used for seems deeply
flawed.  In DOS, protected 16, and protected 32 bit code it has three
different functions - in 32 bit code it is loaded with a constant that
never changes, addressing a descriptor that encompasses the 4gb
virtual address space of that Win32 process.

: 	How would one go about using the _MapPhysToLin , _CopyPageTable
: . Are these services available in a 32-bit DOS box?

There are no "32-bit DOS boxes".  Do you mean a Win32 command level shell?
In any case, the answer is -NO-, those are ring zero services available
to VxD's in any virtual machine.

What are you trying to -do-?

: 	Too bad DPMI V1.0 is not implemented in Windows ):

Now -that- I can agree with!

: Junaid.

Bernard S. Greenberg
bsg AT basistech DOT com