admiral coeyman wrote:
> David Elliott,
> >
> > 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!
> >
> Does this change the way that I'll have to write the code for the interrupts
> I'm working on? Somebody wanted INT 0x13 and I'm going to do some of 0x10 as
> soon as I figure out 8-bit directx. It's meaningless until somebody who knows
> how reenables the DOS loader, but I wouldn't like to have people with less free
> time than I do wasting effort in this area if we have changes to make.
>
Doubtful. I don't like doing major work and then releasing it in one huge patch.
Especially on a component that will be used by several other modules. I still haven't
heard back from Ove in a while though, I want to see what he's done. Supposedly he did
fix the dos loader and get it working again, which is the first step towards doing
this.
>
> > 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.
> >
> This seems to be what we're working towards, anyway. Modularity may allow us
> to write plug-in modules for single user OS other than DOS.
>
Hmmm.. I never even thought about that. How many other single-user x86 OSes are out
there though???
Along that lines, one interesting thought I did have was that once Wine gets to a
release
quality, it would provide a great foundation for "emulating" other operating systems on
top of UNIX. For instance, it would be a great foundation for an OS/2 on top of
UNIX thing. Of course there are not really that many great OS/2 programs out there
(other than Presentation Manager, which I think is the ultimate UI ever made).
>
> > 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.
> >
> I'm only getting involved in this discussion to make sure that the new code
>I,
> and others, write will not need rewrites once DOS support is restored.
Absolutely, like I said, no big changes. Nothing should need a big rewrite either,
just
some small changes, mostly of the search and replace type as things get changed around.
-Dave
