[fpc-devel]Calling previous INTroutine

[Thomas Schatzl]

Subject: Re: [fpc-devel]Calling previous INTroutine


> Ingmar Tulva wrote:
> >
> > On Mon, 18 Dec 2000, startx wrote:
> >
> > > >         {asm
> > > >                 mov ax, ds
> > > >                 mov ebx, offset dsdummy
> > > >                 mov cs:[ebx], ax
> > > >         end;} // this part traps on "mov ax, ds"
> > >
> > Hello, I just happened to read it and... Can a code selector be
writeable
> > at all?! I just like recall that it can be either execute-only or
> > read-and-execute. Or have I got something wrong (whitch is quite
> > possible, I've only read PM basics but never hacked in sutch a low
level)?
>
> Clearly, I don't know whether a code selector can be written to.

It depends on some attributes set. It's possible but not implemented.

> Probably not. That fragment comes right from a fpc example, which was
> not tested I think...

All examples from the go32 unit documentation (and I guess as well the
others) at least worked with _some_ version of the fpc compiler (e.g.
compiles and runs). It is sometimes hard to keep up to date in that respect
especially if somebody use the official version and others already work with
snapshots. Sometimes internal things just change without me taking
notice.... (well, at least for people like me not so involved with compiler
development).
Btw, the examples of the recent go32 docs (don't know whether 'snapshots'
are regulary made) have been updated to work fine with FPC 1.00 about three
months ago. For example they don't use any code segment quirks anymore (e.g.
storing djgpp_ds_alias using some awkward assembly code in code segment)
because there are cleaner ways to accomplish that.

Also the note about that the code segment selector can be written to has
certainly been removed too since I can't find this one anymore.

Please update your documentation (the go32 unit description part), for the
examples have changed a little in that respect. I guess not only this part
was updated btw.

> It seems to work, indeed, if you use the same displacement/offset, but
> inside the data segment.

Both the cs and ds selector map the same memory area. The only difference is
that cs and ds have different access rights. The memory allocation algorithm
always makes sure that they always map the same memory area.

Note that internal variables like ___v2prt0_ds_alias are not automatically
locked at program startup, I admit I missed that for some reason. So this
variable is not locked in the current example.

Btw, for every example in the go32 docs there is one available with comments
inside the code. They were skipped in the printable version due to size
constraints and for better readability. Please get the CVS doc sources if
you want/need them.

Regards,
    Thomas