Hey Colin, you should work on NE2000 support for Bochs under Windows!!!!!!
Colin Davidson wrote:
> 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
> > >
> > >
