Vassilis Virvilis wrote:
> David Elliott wrote:
> >
> > The page is a little flaky in Netscape, moving the bar between the frames
> > usually fixes the problem.
> >
> > Maybe try going to http://www.microsoft.com/ddk/ddkdocs/win2k/vdd_24px.htm
> > instead. Then you can use the back and forward buttons on the page instead of
> > the Java crap. Although I'll have to admit, I cheated and am using IE in
> > Win4Lin.
>
> Interesting trick. Last time I checked I was not able to avoid the java
> beast. With this starting address you can use wget to download all the
> ddkdocs directory in simple grepable HTML.
>
> >
> > Yes actually, that's why I wanted to get some comments before I started. I'd
> > like to look at it before it goes in CVS. I am hoping that whatever you did is
> > probably just a step closer to going to Windows NT style interface.
> >
>
> Well if you want comments here is one. It doesn't look easy. Seriously
> though, AFAIU the difficult part is the VMM and not the VDD stuff. The
> VDD stuff looks useful if you want to support native vdds. Do you want
> something like that?
>
>
Actually, no. I figured it would be an added bonus assuming there weren't any other
major obstacles. The main reason is that it would appear to be the right thing to
do. There is no reason to continue to use an interface that is almost identical
when there is a perfectly good interface already defined. I am looking to allow
interrupts to be implemented as a VDD (.DLL basically) so we can seperate out the
DOS stuff properly. Also, it would have added benefits like allowing you to right
an ANSI.VDD (or something like that) much like OS/2 did. That might be another good
place to check for documentation. I did grab the OS/2 VDD kit as well for some more
background info, it's a tougher read though because IBM tried to do everything
object oriented (sort of) and even though I like OO programming, I sometimes get
caught up trying to read descriptions that would just be a lot simpler if they'd go
out and say it a normal way!
Anyway, about implementing this. It would seem that the correct way to do it would
be to have a program (a modified version of dosmod would probably be the way to
go) that is a Win32 app that starts a DOS session. We could do away with having to
pass a CONTEXT86 around everywhere, and instead use a global context. That makes
implementing all of the get and set register functions pretty trivial. And since
DOS isn't multithreaded, I don't see any reason for not using a global CONTEXT86
structure, I mean, it's kind of global on the processor anyway.
I am not planning on all of a sudden writing this whole thing in a day and releasing
it. The plan is to gradually move to this interface. Any functions that we don't
need to implement won't be implemented until someone needs the functionality either
to write a VDD module specifically for Wine, or to use a native one.
Like I said though, I am not looking to support native VDDs, just to fix the
DOS support the right way.
-Dave
