OK.., well thanks about the info on the ring0 code especially...... As for
the getting around laterally & not being dependent on the Win32API, my
conversations with the Win2k debug manager would point in other directions
(granted, he had to ask what VPN meant..., but when you spend that much time
in front of a terminal it is nice just to get to talk to real people!!).
These being 1) DirectX will not run without the kernel*.dll/rundll*.*
services in place (be nice if it ran on DOS alone though...), 2) in the most
pure sense, Win32--since it isn't really an operating system, has to deal
with the problems of command.com; however it is the existence of some of
these holes that allow things like DirectX to talk to the hardware without
using kernel*.dll/rundll*.* as an intermediary. And yes, I just did a
find.., there is no longer a kernel32.exe. And as for not using the GDI, it
was my understanding that DirectX has a hook into the GDI code that allows
it to take over certian functions when the application (also hooked to the
GDI) supports that particular implimentation (thus being a hell of a lot
faster).
Anyway.., this knowledge may be becoming a little outdated as M$ moves more
toward its newer WDM/HAL model for hardware. I don't, however; expect to
see the userland portion of things change too much over time, unless
winoldapp.exe/.dll takes the place of the module handler sometime soon &
Windows segways to true multitasking. I guess those of us on the outside
will have to wait & see!
Drew Northup, N1XIM
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
> Of Colin Davidson
> Sent: Wednesday, November 01, 2000 10:23 AM
> To: [EMAIL PROTECTED]
> Subject: RE: plex86 video proposal
>
>
> 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
> > >
> > >
>
>
