Re: DPMI raw mode switch

From: BSpider (nospam_peterbls_at_o2.pl)
Date: 06/05/04 

Date: Sat, 5 Jun 2004 00:22:53 +0200

Użytkownik "rjb" <nonesuch@here.com> napisał w wiadomości
news:c9oh1o$gkm$1@hercules.btinternet.com...
>
> "BSpider" <nospam_peterbls@o2.pl> wrote in message
> news:c9o5n6$q8p$1@nemesis.news.tpi.pl...
> >
> > > How can I save protected mode registers when I am in real mode? What
> > > registers? Where are they? This continual reference in the DPMI specs
to
> > > saving the "other" state just leaves me clueless. If I switch from
real
> to
> > > protected mode, the mode state that I land in is one that is defined
by
> me
> > > before I make the switch:-
> > >
> > > AX = New DS
> > > CX = New ES
> > > DX = New SS
> > > (E)BX = New (E)SP
> > > SI = New CS
> > > (E)DI = New (E)IP
> > >
> > > All those values are loaded up by me from memory locations constructed
> for
> > > the purpose. In other words I define the state I want before I enter
it.
> > So
> > > where does "saving the state" come into it. I do not know of any state
> > that
> > > has to be saved.
> > >
> >
> > I'm not an operating system expert and I never wrote advanced code that
> > handles all special protected mode features, but I presume that what
> you're
> > saving here is the state of the current task register. Not the general
> > purpose registers. When you look at the 386 CPU architecture there are
> some
> > special purpose registers like the control registers (CRx), the debug
> > registers (DRx), the test registers (TRx) and of course the TR register
> > (Task Register) which can only be accessed with priviledged instructions
> not
> > available for user programs running in ring 3 under a standard DPMI
host.
>
> Ah, that's more like it. I half suspected something like that. The "state"
> referred to is something outside what my program can see. I also saw in
the
> specs - and you said the same thing - that some implementations of dpmi do
> not need the state saved. Mine is one of those (I'm using WinXP), which I
> found out when it returned 0 as the length of the state-save buffer
needed.
> But I'm still including it in my code, in case I have to run it under some
> other implementation that does need the state saved. Just offhand, is
there
> any version of Windows that needs it saved?
>
> Well, it's academic, I suppose, because I've finally got my code
> successfully switching from pm to vm, and back, just by blindly following
> the procedure. But I just hate doing something without understanding what
it
> is I'm doing.
>
> Incidentally, I couldn't get the TRW2000 to work. It kept crashing on int
> 2F, and since that's how you begin any startup procedure with DPMI, it
> didn't do me a lot of good. And I didn't know of any other debuggers that
> could work through those state-switching procedure, so I had to do a
lash-up
> job with the Ketman Maximaster. It's only a 16-bit app, but it has great
> monitoring facilities, and I was finally able to make it do what I wanted.
> Now that I've got this far, I think I'll stick with it now. And that's the
> reason that I didn't use any of the other mode-switching systems you
listed,
> like the real-mode callback routine. They all kind of imply that your main
> mode is pm, and that going into vm is something you only want to do
> occasionally. But with me it's the other way round. I intend to build my
> program on Ketman, running mostly in vm, but using pm when I need to
access
> big memory. So I thought the raw-mode switching system would be better.
>

It's kind of weird but if it works for you. Anyway, constantly switching
between VM and PM takes time, thus your program executes slower. What more,
in fact you're writing 16-bit programs instead of 32-bit ones. Each 32 bit
register and memory access takes an additional clock (66h and 67h prefixes).
Any DPMI host out there was designed and optimised for clients that run in
protected mode.

I don't know if any other Windows version needs the state to be saved. I
could check it under Win 98SE if you need to know.

As for a good debugger. Well, when writing DOS software (assembly and C++) I
use the WD (Watcom Debugger) from the WATCOM C++ 11.0c compiler package.
Yes, the whole 32-bit DOS run time is based on DPMI. I don't bother writing
complicated startup code. I just use free dos extenders - like WDOSX or
DOS32ADV. BTW OpenWatcom is still free and can be downloaded from
www.openwatcom.org

BSpider

Relevant Pages

  • Re: Port Application to 32 bit
    ... 640Kbytes memory barrier is causing a problem. ... I have not worked with DOS before so I am having difficulty get a ... DJGPP produces 32-bit PM code and uses DPMI. ...
    (comp.os.msdos.programmer)
  • Re: TSR issues (with code)
    ... I'm not too sure what to try other than a different DOS version ... haven't found any DPMI host for any platform which supports the DPMI 1.0 TSR ... I continue to use DOS/4G and PMODEW... ...
    (comp.os.msdos.djgpp)
  • Re: 32.bit com
    ... DPMI specs. ... the DOS extender should try to enter PMODE via DPMI first. ... It means that the DOS extender has to do all the mode switch ...
    (alt.lang.asm)
  • Re: getting good at assembly language
    ... Ludwig wrote the following useful and helpful info - ... And writing assembly entices to get dirty in your code ... >> Again true, a debugger would require a lot of good OS knowledge, ... Thanks for that, maybe I will aim towards a kernel debugger, I've ...
    (alt.lang.asm)
  • Re: Vmode question
    ... but who does this DPMI belong to? ... The DPMI (DOS Protected Mode Interface) standard was released in 1990 and it ... The idea of such a DOS Extender is very simple. ...
    (alt.lang.asm)