Hi Everyone,
Just to introduce myself, I'm Colin Davidson and I've been "lurking" on the
mailing list for a while. As some things are starting to come up that I can
actually contribute to, I thought I'd become active.
I've been programming for too many years, at least half the time at a
low/driver
level. Recently I've been working on Windows DirectX and display drivers, as
well as an NDIS NIC driver (among other things).
Now, on to the matter at hand.
Actually, Drew, DirectX (DirectDraw and Direct3d) are independant APIs,
designed to get around the GDI. They may use services in kernel32(.DLL! -
there is no kernel32.exe), but thay can't really be said to be "on top of"
it. It's more a lateral relationship. On Win9x, it is implemented in three
places, these being the display driver, the display VXD and the DirectDraw
HAL driver. Depending on which bit of code is running, the DirectX code will
run in either ring 0 with full kernel memory privilidges or in ring 3 with
elevated rights (above application privilidges).
DirectX gives the application a more direct (hence the name?) access to the
display hardware than the GDI and in particular, when running full-screen, a
DirectX application has sole posession of the graphics card. Even the
(non-directX portions of) the DDI display driver do not access the card.
On NT5 (oops, Win2000 :-), the details are a little different, but the
effect is the same, some DirectX code runs ring 3 kernel mode, the rest ring
0. Full screen apps are exclusive of each other and the rest of the OS.
The graphics portion of Plex86 certainly promises some fun, I must agree.
Regards, Colin
> From: "Drew Northup" <[EMAIL PROTECTED]>
> Subject: RE: plex86 video proposal
> Date: Tue, 31 Oct 2000 14:17:53 -0500
>
>
> I don't think that I made this clear...., but in Win32 all applications
are
> modules of kernel32.exe--which is the Win32API kernel NOT AN OPERATING
> SYSTEM KERNEL (command.com/io.sys are the operating system--so long as we
> are talking about an operating system in the _most_ purist sense). That is
> why I made a big deal about it. As for the similarity of how DirectX does
> things..., DirectX is an application--driver communication API. It sits ON
> TOP OF the Win32API. What it really does is offloads CPU intensive tasks
> from kernel32.exe's primary modules (like texture rendering, for
instance).
> It also DOES NOT FUNCTION LIKE A LINUX KERNEL MODULE. This is an important
> point that I seem to have neglected (I usually talk more with people who
> deal with Win32API more often....). None of the above function like a
LINUX
> kernel module, in part because all of them (in fact all of the
> Win32API--with, so far as I know, no exceptions) lives in userland. This
> could really make a Win32API port of plex86 a very interesting proposition
> indeed!!!!
>
>
> Drew Northup, N1XIM
>
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
> > Of Sintsov Dmitri
> > Sent: Tuesday, October 31, 2000 8:36 AM
> > To: [EMAIL PROTECTED]
> > Subject: RE: plex86 video proposal
> >
> >
> >
> >
> > On Tue, 31 Oct 2000, Drew Northup wrote:
> >
> > Sounds good to me so far......, the only major stumbling blocks to
> > implementing the full-screen video so far as I see it are as follows:
> > 1) We will need some sort of separate status window, so that if
> > something,
> > somewhere goes awry, we can always drop back to some sort of
> > console/std-error and recover,
> > This could be resolved by using a special "system key" (let's say sclock
> > or alt+something) to switch from full-screen guest to plex86 main
console
> > (or window) where you could manage running guests (switch/kill/change
> > priority etc.).
> >
> > 2) If we plan for this to run on win32 ever in the future we'll
> > need to deal
> > with the fact that windows just loves to access video memory
> > directly (there
> > is some sort of addressing "lock-out" to keep things down to the current
> > "master" application.....--i.e. in win95,98,&98se the shell
> > graphics/master
> > window handler, explorer.exe.... a module kernel32.exe, is usually the
> > master--but I have no idea how robust this is.....) and not use
> > some sort of
> > host buffer space in userland. If X uses a similar "painting
> > method" (does
> > it?) then we could, in theory, "grab" the video output pipe
> > directly..., or
> > maybe easier yet, we could just make the plex86 output take up
> > one entire
> > virtual desktop and just use the local accelerated X video
> > routines instead
> > of writing our own & re-inventing the wheel...per se.
> > Kernel module is allowed to do so, right? Btw, also Windows uses similar
> > to this technique to implement directx hardware acceleration? I see.
> >
> > These routines
> > should, in theory, allow us to get to the frame/z buffers
> > pretty directly
> > with little overhead. I am not sure, but I do believe that
> > this is how the
> > job is done for many "DirectX" [(c) MS] style games. So far as
> > I know the
> > rest of them just grab the output device directly, and do the rendering
> > themselves with no Win32API help--which is something that, to
> > my knowledge,
> > unix systems don't really appreciate!!!
> >
> > UNIX is all about portability, but in case of plex86 which is PC-only
> > project it's probably not worth to keep efforts for abstracting
everything
> > (the emulated hardware is the same), however for bochs (which is not
less
> > valuable project) portability is of course the only way.
> > Uhus
> >
> >
