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