Nick, I used this toolset for years.

Hi...

I have two questions about programming for OS/2.

First, what is the DOS interrupt to give up
timeslicing back to the OS? I think its 2F, but can
someone tell me for sure? And when specifically should
a timeslice be given back to OS/2? (keyboard idling,
etc?)

Instead of working at it this way, I think you will be better served by giving a look not only at this, but the TAME330 utility, or one like it. It works for
most, but not all applications to bust up CPU bashing. At least do that for learning's sake first as well, OK?

For example, before I started fooling around with assembler code to break it up
in my actual programs, TAME330 took care of everything I ever threw at it via the M/S Bascom PD7 package. I had *LOTS* of code in it, actually over 750,000 lines of source.....

And second, I have MS-PDS 7.1 (QuickBasic), which can build both DOS and OS/2 applications. It works wonderful, except for some
reason I can't perform ANY "low level" operations if I
want to compile for OS/2 (ie. poking around in memory,
calling interrupts, etc). I think there is a way
around this in the BC compiler (or possibly the
linker?) but does anyone know why?

Aha! We are now on the same wavelength here, officially!

Some of the operations that are provided in DOS are not enabled in OS/2. I never continued toward native OS/2 applications with it. The reason for that was that things I distribute had to be Y2K certified. There was no way to stand on that toolset for that reason.

I still have all the hard bound docs for the toolset. I think if you read the reference guide carefully, you will find that certain functions are not enabled
in OS/2. Unless I miss this, for example, I think you will find that the direct port communications functions OUT and INP do not work in the OS/2 side of the house. Nor does anything else that makes direct use of the hardware ports, although there were cross platform communications functions for things like using the serial ports with file management techniques.

You could, indeed, and I did, as I recall, splice in assembler coded low level comm port operations via linking custom libraries to them.

I never, therefore, went beyond the low-level assembler stuff I managed to write which worked in DOS as well. I figured that when time came, I'd still be
OK porting it all to OS/2. But when the Y2K game hit, and I realized that there would be no further way to upgrade to anything with PD 7.1, I looked for another DOS solution. That just to get me through Y2K.

That move produced a decision, based on the time it would take and the Y2K deadlines, to at least temporarily use PowerBASIC as a substitute for PD 7.1 so
I did that. It has actually taken until this time to move everything there .. now a total of over 1,200,000 lines of source covering over 110 full inter-related executables and major common library modules in PB 3.5.

Of course I'm still stuck with what to do on moving to native OS/2, so where I really wanted to go, C++ in Watcom, has been waiting in the wings. Presently, I've managed to write a complete translator from about 138 off the 210 functions we use in PB 3.5, very much like BC 7.1, to Watcom C++ version 11b. That enroute to IBM's Visual Age for C++.. as well. Either way I can get to OS/2. But with VAC++ I can also get to LINUS/*IX if I must. I probably, like it or not must .. groan.

The number of lines in the suite will likely, from early research in the translator, grow to about 4,000,000 lines in C++ .... gloom.

From all this has come an assembly language snipset that I now use in the PowerBASIC compiler operations to give me time slice control in every program, as it now stands. The PowerBASIC compiler has a very easy to use in-line assembler interface, much like you can use with PD 7.1 ..

Here's how it looks in PB 3.5 code. I think if you look at it, you can likely adapt it to PD 7.1. That just *MIGHT* get you where you want to go in native 16 bit OS/2 as well. Hence the long pig trail to here!

IF ISTRUE BIT(pbvHost, 8%) THEN ' In WIN environment > ! push

DS

! mov AX, &H1680
! int &H2F
! pop DS
ELSE ' Not in a WIN environment > ! push DS

; Save DS for PowerBASIC > ! mov AX, &H8600 ; Place function $AH68in AX > ! mov CX, &H00 ; Use less than 1000 MS delay > ! mov DX, &H0A00 ; Try &H0A00 for a delay in DX

! int &H15 ; Call timer interrupt
! pop DS
END IF

In PowerBASIC I learned it is necessary, and safer for sure, to save the DS for
the compiler return. I never did that in M/S code. It may be useful even in BC 7.1 I think. As well, the internal function for pvbHost is a product specific internal function for PowerBASIC which does the above job of detecting
whether the box is operating in a WIN environmnet. That snoop lets you safely operatine in the &H2F mode you are seeking, I think.

I suspect that if you look at Ralf Brown's interrupt list site, you can find a non-PowerBASIC function that will let you determine if you are in WIN or an OS/2 environment, which the above does *NOT* address. I know there are several
ways at low level to do this.

If you get the TAME320 or TAME330 utility, which I think is on HOBBS, I think you will get all the help you need on identifying which polling monsters for which you should provice. The keyboard is the most obnoxious in my estimation.

But note!

To this very day I have *NEVER*, using any combination of third party tools,ever been able to break the PowerBASIC IDE of sucking eggs with the CPU. Never .. ever .. no never .. NEVER.

To that extent, be careful on the old classic Pentium CPU chips. Any application you distribute or run on them that maxes the CPU out, can trigger the F0 bug gambit. I've had PowerBASIC reduce my OS/2 hard disk to rubble twice, forcing a complete tape rebuild, just from accidentally leaving it up overnight running the IDE while four other sessions were doing DOS port applications and all writing and cross-writing to the hard disk. I fell asleep
and let PB 3.5 sit idle trashing the CPU on a classic P-box.


Cheers ..


Mike @ 1:117/3001


--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)

In a message to All, Nick Andre wrote:

And second, I have MS-PDS 7.1 (QuickBasic), which can build both DOS
and OS/2 applications. It works wonderful, except for some reason I
can't perform ANY "low level" operations if I want to compile for
OS/2 (ie. poking around in memory, calling interrupts, etc). I think
there is a way around this in the BC compiler (or possibly the
linker?) but does anyone know why?

First, OS/2 doesn't use interrupts. You have to use API calls. Second,
since OS/2 is a multitasking OS, it manages memory much differently than
DOS does.


N'a pale pi ta,
Rachel

http://www.netside.net/~rveraa/


--- timEd/2 1.10.y2k
* Origin: Well, you are a rare parrot-teacher. -- Much Ado About N (1:135/907)

Yes, Dave.

Koi.

of course.

But writing a deltree program is not rocket science.
There is nothing to be coy about, really. Just
remember to test it on a directory whose contents are
expendable, just in case it works.

Of course! Directorus Interuptis? ;)

Mike @ 1:117/3001

--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)

Hi Mike,

Replying to a message of Mike Luther to David Noon:

Ooooh Dave ..

BC? Is that the suffix for the year it was written? ... :-)

Gordon Letwin would roll in his grave if he were in it! ;)

I didn't think Gordon Letwin ever worked for Borland. Now Philippe Kahn or Anders Forsberg ...

... Since you asked about a deltree
program in the main OS/2 echo the other day, why don't
you try writing one of those? It would give you a nice
introduction to API programming if you bypass your
compiler's RTL and make direct calls into OS/2.

Remember the name for those pretty fishees that swim around in the
tanks im in the foyer of the better Asian restaurants? ;)

Koi.

But writing a deltree program is not rocket science. There is nothing to be coy
about, really. Just remember to test it on a directory whose contents are expendable, just in case it works.

Regards

Dave
<Team PL/I>

--- FleetStreet 1.25.1
* Origin: My other computer is an IBM S/390 (2:257/609.5)

Hi...

>
> I have two questions about programming for OS/2.
>
> First, what is the DOS interrupt to give up timeslicing
> back to the OS? I think its 2F, but can someone tell me for
> sure? And when specifically should a timeslice be given
> back to OS/2? (keyboard idling, etc?)

In warp 3 and warp 4 beyond FP 6, the call is AX = 1680h Int =
2fh. Note that the call was broken in the warp 4 GA version up
till FP 6 was released. You can also use the slightly less
effecient DOS IDLE Int = 28h.

I have a pascal unit that encapsulates all this and a lot more,
such as OS detection, for every Intel based OS, drop an email to
leea@psynet.net if you want a copy.


LRA


-- SPEED 2.01 #2720: Canadian DOS prompt: EH?\>

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

In warp 3 and warp 4 beyond FP 6, the call is AX = 1680h Int =
2fh. Note that the call was broken in the warp 4 GA version up
till FP 6 was released. You can also use the slightly less
effecient DOS IDLE Int = 28h.

I didn't know the FP 6 part of this!

I have a pascal unit that encapsulates all this and a lot more,
such as OS detection, for every Intel based OS, drop an email to
leea@psynet.net if you want a copy.

would you mind if I got it from you and posted in the

> source tidbits for the PowerBASIC crew? There have been a
> fair number of discussion threads on time releasing in that
> group, which always goes back to things which don't of
> course, include OS/2!

Posting it there, and/or, perhaps, adapting it to in-line

> assembler might be worth a lot to folks...

No I don't mind, although there is a commercial copyright in it.
IE: free for personal use, copyrighted for commercial use.

The unit is pretty much already all assembler, at least all the
OS detection code is.

Any competent programmer could read the pascal code for getting
the OS/2 FP version and setting the correct timeslice drop code,
and convert it as needed.

LRA


-- SPEED 2.01 #2720: Where in the *%&^% *IS* Carmen? San Diego?

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

Lee,

In warp 3 and warp 4 beyond FP 6, the call is AX = 1680h Int =
2fh. Note that the call was broken in the warp 4 GA version up
till FP 6 was released. You can also use the slightly less
effecient DOS IDLE Int = 28h.

I didn't know the FP 6 part of this!

I have a pascal unit that encapsulates all this and a lot more,
such as OS detection, for every Intel based OS, drop an email to
leea@psynet.net if you want a copy.

would you mind if I got it from you and posted in the source tidbits for the PowerBASIC crew? There have been a fair number of discussion threads on time releasing in that group, which always goes back to things which don't of course, include OS/2!

Posting it there, and/or, perhaps, adapting it to in-line assembler might be worth a lot to folks...

Sincerely ..


Mike @ 1:117/3001


--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)

In warp 3 and warp 4 beyond FP 6, the call is AX = 1680h Int =
2fh. Note that the call was broken in the warp 4 GA version up
till FP 6 was released. You can also use the slightly less
effecient DOS IDLE Int = 28h.

I didn't know the FP 6 part of this!

I have a pascal unit that encapsulates all this and a lot more,
such as OS detection, for every Intel based OS, drop an email to
leea@psynet.net if you want a copy.

would you mind if I got it from you and posted in the

> source tidbits for the PowerBASIC crew? There have been a
> fair number of discussion threads on time releasing in that
> group, which always goes back to things which don't of
> course, include OS/2!

Posting it there, and/or, perhaps, adapting it to in-line

> assembler might be worth a lot to folks...

No I don't mind, although there is a commercial copyright in it.
IE: free for personal use, copyrighted for commercial use.

The unit is pretty much already all assembler, at least all the
OS detection code is.

Any competent programmer could read the pascal code for getting
the OS/2 FP version and setting the correct timeslice drop code,
and convert it as needed.

LRA


-- SPEED 2.01 #2720: Where in the *%&^% *IS* Carmen? San Diego?

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

The OS/2 API is built on call gates and ring gates, not interrupts.

And are not those gates accessed via an interrupt?

No.

Call gates are simply part of protected mode execution.

> They do not generate any interrupt; they simply fiddle some
> segment registers [and control registers and stack frame,
> if they are ring gates too] and then continue execution as
> per a normal CALL instruction.

The use of an INT instruction in p-mode, as per PC-DOS/MS-

> DOS/DR-DOS + DPMI (e.g. Win 3.x/9x/Me), NT and LINUX, is an
> alternative way to switch ring levels. In addition to
> branching to the address in the interrupt vector (addressed
> by the IDTR in p-mode) the INT instruction switches to ring
> 0. But this is wholly redundant in an OS that uses
> call/ring gates.

My wrong. Thanks for taking the time to explain that. I had
simply assumed that OS/2 used the same invalid int trick to
switch rings as Win does.

I guess that makes OS/2 a "Gates environment".

AAAAAAAAAARRRRRRRRRGGGGGGGGGGGHHHHHHHHHH!!!!!!!!!!!



LRA


-- SPEED 2.01 #2720: "Give up integrity and the rest is a piece of cake." BG

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

Moin Murray!

25.05.2001, Murray Lesser wrote a message to Vitus Jensen:

I would like to have an Intel or AMD manual about the i386

because this stuff IMHO is best explained by the processor
vendor but I have only a bad german short reference. One
of these days I should "lend" one from the library...

I have an old (vintage 1987) book by Stephen P. Morse, Eric J. Isaacson, and Douglas J. Alpert: "The 80386/387 Architecture" [ISBN 0-471-85352-0012]. Morse was the architect of the 80386. I imagine
that this book is now out of print. You might be able to find it in
a secondhand bookstore, or on some Web bookstore site (avoid
amazon.com except as a last resort; they charge entirely too much for out-of-print books. bibliofind.com now belongs to amazon.com, so
they, too, are useless. Try ABEbooks.com. There may be others.)

...

Is this book black? I'm just asking because two of my friends had really good books about the 80286 while I had -- well, a reasonable book about 8086 and that short one.

Anyway, I trusted your words and ordered "The 80386/387 Architecture" from ABEbooks.com. It's only 12$, so no big deal. Oh yes, handling and shipping adds ~8$, delivery will take 1-2 months. :-/

Bye,
Vitus

---
* Origin: Mein Comuter gehorcht aufs Wort - dank OS/2 (2:2474/424.1)

Well, to be exact: OS/2 uses callgates to jump into kernel code. [...]

Ah, but are not those callgates accessed through an interrupt?

JdBP> No. That's why they are called "call gates" and not, say,
> "interrupt gates". (-:

Got it, got it...


LRA


-- SPEED 2.01 #2720: What if there were no hypothetical situations?

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

Well, to be exact: OS/2 uses callgates to jump into kernel code. [...]

Ah, but are not those callgates accessed through an interrupt?

No. That's why they are called "call gates" and not, say, "interrupt gates". (-:

» JdeBP «

... Jugiter pulsas, sed intrare non potes.
--- FleetStreet 1.22 NR
* Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)

I would like to have an Intel or AMD manual about the i386 because
this stuff IMHO is best explained by the processor vendor but I have
only a bad german short reference. One of these days I should "lend"
one from the library...

The Intel 32-bit Architecture manuals, volumes 1 to 3, are available from Intel
in PDF form.

» JdeBP «

... Certe, Toto, sentio nos in Kansate non iam adesse.
--- FleetStreet 1.22 NR
* Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)

First, OS/2 doesn't use interrupts. [...]

Not to niggle the point, but of course OS/2 uses interrupts. Each
and every one of those API calls is a wrapper around an interrupt call.

Leaving aside the point that Rachel meant that applications programmers writing
OS/2 applications programs don't use interrupts, I vaguely remember reading somewhere that OS/2 in fact uses call gates, not interrupt gates, to enter the kernel.

» JdeBP «

--- FleetStreet 1.22 NR
* Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)

(Vitus Jensen wrote to Murray Lesser on 05-27-01, topic: "Interrupts")

Hi Vitus--

I have an old (vintage 1987) book by Stephen P. Morse, Eric J. Isaacson, and Douglas J. Alpert: "The 80386/387 Architecture" [ISBN 0-471-85352-0012]. Morse was the architect of the 80386. I imagine
that this book is now out of print. You might be able to find it in
a secondhand bookstore, or on some Web bookstore site (avoid
amazon.com except as a last resort; they charge entirely too much for out-of-print books. bibliofind.com now belongs to amazon.com, so
they, too, are useless. Try ABEbooks.com. There may be others.)

>...

Is this book black? I'm just asking because two of my friends had

>really good books about the 80286 while I had -- well, a
>reasonable book about 8086 and that short one.

No, IIRC the "black books" were reference manuals published by
Intel. This book has a blue cover, and was published by John Wiley &
Sons. I have found (in general) that well-written explanatory texts by
people who really know the subject are more useful than are the vendors' reference manuals--in spite of the fact that I have learned most of the programming languages I know from compiler vendors' reference manuals.
The better texts tell you "why" as well as "what" and "how."

Anyway, I trusted your words and ordered "The 80386/387

>Architecture" from ABEbooks.com. It's only 12$, so no big
>deal. Oh yes, handling and shipping adds ~8$, delivery
>will take 1-2 months. :-/

The original price, as given on the cover of my copy, was $24.95, so
it appears that you have done very well :-). I guess they are shipping
surface rather than by air. Oh well, you have waited this long so a
little longer shouldn't hurt much. I hope you find that the book meets
your requirements.

Regards,

--Murray
<Team PL/I>
___
* MR/2 2.30 #120 * One printed manual is worth a thousand INF files

--- Maximus/2 3.01
* Origin: COMM Port OS/2 juge.com 204.89.247.1 (281) 980-9671 (1:106/2000)

I had assumed that OS/2 used the same method of
forcing a processor exception
to jump to ring zero as MonopolySoft uses, apparently I was wrong.

JdBP> Strictly speaking, the design of OS/2 in this area is partly Microsoft's.

I guess that would tell us something about what G. Letwin thought
of the jump to the bios IBM copyright notice as a means of
switching processor state then, eh?

Oddly enough, it was IBM that originally came up with that
method, although it was Bilge and crew that took a patent on the
use of the idea.


LRA


-- SPEED 2.01 #2720: The only good extremist is a dead extremist.

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

I had simply assumed that OS/2 used the same invalid int trick to
switch rings as Win does.

JdBP> The interrupt(s) used on DOS-Windows and and Windows NT
> aren't "invalid". They are perfectly valid. Their entries
> in the IDT point directly to the syscall dispatch routines.

<sigh> OK, poor choice of language. The int is fine.

What is done to switch control from the application to the OS is
a jump into the bios copyright notice to force a processor
exception.

Happy now?


LRA


-- SPEED 2.01 #2720: Sign Here: _______________________________

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

Moin Jonathan!

25.05.2001, Jonathan de Boyne Pollard wrote a message to Vitus Jensen:

I would like to have an Intel or AMD manual about the i386 because
this stuff IMHO is best explained by the processor vendor but I have
only a bad german short reference. One of these days I should
"lend" one from the library...

JdBP> The Intel 32-bit Architecture manuals, volumes 1 to 3, are available
JdBP> from Intel in PDF form.

A little hard to find (found them at "P IV manuals") and a little to big to load them just now, but thank you for that information. I will download them later and have a look at them.

Bye,
Vitus

---
* Origin: ?OUT OF COFFEE ERROR. (2:2474/424.1)

I had assumed that OS/2 used the same method of forcing a processor

exception

to jump to ring zero as MonopolySoft uses, apparently I was wrong.

Strictly speaking, the design of OS/2 in this area is partly Microsoft's.

» JdeBP «

--- FleetStreet 1.22 NR
* Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)

I had simply assumed that OS/2 used the same invalid int trick to
switch rings as Win does.

The interrupt(s) used on DOS-Windows and and Windows NT aren't "invalid". They
are perfectly valid. Their entries in the IDT point directly to the syscall dispatch routines.

» JdeBP «

--- FleetStreet 1.22 NR
* Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)

Moin Lee!

20.05.2001, Lee Aroner wrote a message to Rachel Veraa:

And second, I have MS-PDS 7.1 (QuickBasic), which can build both DOS
and OS/2 applications. It works wonderful, except for some reason I
can't perform ANY "low level" operations if I want to compile for
OS/2 (ie. poking around in memory, calling interrupts, etc). I think
there is a way around this in the BC compiler (or possibly the
linker?) but does anyone know why?

First, OS/2 doesn't use interrupts. You have to use API calls.
Second, since OS/2 is a multitasking OS, it manages memory much
differently than DOS does.

Not to niggle the point, but of course OS/2 uses interrupts. Each and every one of those API calls is a wrapper around an interrupt call.

Well, to be exact: OS/2 uses callgates to jump into kernel code. Callbacks are
similar to interrupt gates in that they switch priviledge levels and have a predefined entry point into the kernel but they additionally copy bytes from lower to higher level stacks while swichting (byte count defined in the callgate). Something what a interrupt gate won't do.
It is a common design of OSses to do this switching via a software interrupt but OS/2 is different.

Bye,
Vitus

---
* Origin: Even my cleaning lady won't do Windows. (2:2474/424.1)

Hi Lee,

Replying to a message of Lee Aroner to Rachel Veraa:

First, OS/2 doesn't use interrupts. You have to use API calls.
Second,

>> since OS/2 is a multitasking OS, it manages memory much differently
>> than DOS does.

Not to niggle the point, but of course OS/2 uses interrupts. Each and every one of those API calls is a wrapper around an interrupt call.

No, Rachel is correct.

The OS/2 API is built on call gates and ring gates, not interrupts.

Regards

Dave
<Team PL/I>

--- FleetStreet 1.25.1
* Origin: My other computer is an IBM S/390 (2:257/609.5)

And second, I have MS-PDS 7.1 (QuickBasic), which can build both DOS
and OS/2 applications. It works wonderful, except for some reason I
can't perform ANY "low level" operations if I want to compile for
OS/2 (ie. poking around in memory, calling interrupts, etc). I think
there is a way around this in the BC compiler (or possibly the
linker?) but does anyone know why?

First, OS/2 doesn't use interrupts. You have to use API calls. Second,

> since OS/2 is a multitasking OS, it manages memory much differently than
> DOS does.

Not to niggle the point, but of course OS/2 uses interrupts. Each
and every one of those API calls is a wrapper around an interrupt
call.


LRA


-- SPEED 2.01 #2720: As I said before, I never repeat myself.

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

Gordon Letwin would roll in his grave if he were in it! ;)

I didn't think Gordon Letwin ever worked for Borland. Now

> Philippe Kahn or Anders Forsberg ...

You would be meaning Anders Heiljsberg I believe, and that scummy
turncoat slimebait had better say his prayers if he and I are
ever in the same dark alley at the same time...


LRA


-- SPEED 2.01 #2720: Sure wish I could throw away that old boomarang!

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

Hi Vitus,

Replying to a message of Jonathan de Boyne Pollard to Vitus Jensen:

I would like to have an Intel or AMD manual about the i386 because
this stuff IMHO is best explained by the processor vendor but I have
only a bad german short reference. One of these days I should
"lend" one from the library...

JdBP> The Intel 32-bit Architecture manuals, volumes 1 to 3, are available
JdBP> from Intel in PDF form.

ftp server: download.intel.com
directory: /design/PentiumII/manuals
or: /design/Pentium4/manuals

Just slurp all the .PDF files (binary mode, of course) and you should have all the library that does not require a NDA.

Regards

Dave
<Team PL/I>

--- FleetStreet 1.25.1
* Origin: My other computer is an IBM S/390 (2:257/609.5)

Moin David!

29.05.2001, David Noon wrote a message to Vitus Jensen:

I would like to have an Intel or AMD manual about the i386 because
this stuff IMHO is best explained by the processor vendor but I
have only a bad german short reference. One of these days I should
"lend" one from the library...

JdBP>> The Intel 32-bit Architecture manuals, volumes 1 to 3, are
JdBP>> available from Intel in PDF form.

ftp server: download.intel.com
directory: /design/PentiumII/manuals
or: /design/Pentium4/manuals

Just slurp all the .PDF files (binary mode, of course) and you should
have all the library that does not require a NDA.

Looks like it will take an hour to complete the downloads. That's 1.74 DM, chiiinnnngg.


Thank you for the URL. It's also downloadable from the Intel website if you select developer information, Pentium IV, manuals but it took much longer to find that page.

Bye,
Vitus

PS: cool, the download aborted after 25 minutes. I love it.
---
* Origin: Oh, du todtrauriges Origin. Keiner liest dich. (2:2474/424.1)

Moin Lee!

23.05.2001, Lee Aroner wrote a message to Vitus Jensen:

First, OS/2 doesn't use interrupts. You have to use API calls.
Second, since OS/2 is a multitasking OS, it manages memory much
differently than DOS does.

Not to niggle the point, but of course OS/2 uses interrupts. Each
and every one of those API calls is a wrapper around an interrupt
call.

Well, to be exact: OS/2 uses callgates to jump into kernel code.
Callbacks are similar to interrupt gates in that they switch priviledge
levels and have a predefined entry point into the kernel but they
additionally copy bytes from lower to higher level stacks while
swichting (byte count defined in the callgate). Something what a
interrupt gate won't do.
It is a common design of OSses to do this switching via a software
interrupt but OS/2 is different.

Ah, but are not those callgates accessed through an interrupt?
It's irrelevant that it is an invalid interrupt, a spade 's a
spade after all...

It's no INT xx instruction but really a call far. You do a *CALL FAR XXXX:0000*.
The offset doesn't matter (as the callgate defines the entry point) but the XXXX (selector) points to an entry in the GDT or LDT (LDT should be possible but I've never seen a callgate in it in OS/2) which is a callgate (descriptor type 4). The descriptor defines the destination (selector:offset) and how many
words are copied from the lower ring stack to the new stack.

You can examine how this works by installing _Theseus_ on your machine. Debug your program using any debugger which can display assembler instructions and trace until you find a "CALL XXX:0000" instruction, write down the XXXX.
Now start Theseus and have a look at the GDT. Lookup XXXX (ignore bit 0-2), you find a descriptor with /Descriptor Priviledge Level/ 3 (because it's callable from a ring 3 application), some offset and a selector which is probably 0168 (perhaps dependent on OS/2 version).
Lookup 0168 in the GDT, you find the code selector for the kernel, ring 0, limit FFFFFFFF.

I would like to have an Intel or AMD manual about the i386 because this stuff IMHO is best explained by the processor vendor but I have only a bad german short reference. One of these days I should "lend" one from the library...

Bye,
Vitus

PS: I'm maintaining an OS for embedded systems where we use an interrupt, a structure pointed to by register XWA and a software dispatcher. This is probably what you have in mind.
PPS: just implemented preemptive multithreading for that system. Cool!
---
* Origin: Accelerate Windows, to escape velocity. (2:2474/424.1)

First, OS/2 doesn't use interrupts. You have to use API calls.
Second, since OS/2 is a multitasking OS, it manages memory much
differently than DOS does.

Not to niggle the point, but of course OS/2 uses interrupts. Each and every one of those API calls is a wrapper around an interrupt call.

Well, to be exact: OS/2 uses callgates to jump into kernel code. Callbacks

> are similar to interrupt gates in that they switch
> priviledge levels and have a predefined entry point into
> the kernel but they additionally copy bytes from lower to
> higher level stacks while swichting (byte count defined in
> the callgate). Something what a interrupt gate won't do.
> It is a common design of OSses to do this switching via a
> software interrupt but OS/2 is different.

Ah, but are not those callgates accessed through an interrupt?
It's irrelevant that it is an invalid interrupt, a spade 's a
spade after all...


LRA


-- SPEED 2.01 #2720: "Too much of a good thing is wonderful." <Mae West>

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

First, OS/2 doesn't use interrupts. You have to use API calls.
Second,

>> since OS/2 is a multitasking OS, it manages memory much differently
>> than DOS does.

Not to niggle the point, but of course OS/2 uses interrupts. Each and every one of those API calls is a wrapper around an interrupt call.

No, Rachel is correct.

The OS/2 API is built on call gates and ring gates, not interrupts.

And are not those gates accessed via an interrupt? An invalid
interrupt to be sure, but still an interrupt.


LRA


-- SPEED 2.01 #2720: Really its all fixed now, go ahead and reset the totals

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

Hi Lee,

Replying to a message of Lee Aroner to David Noon:

The OS/2 API is built on call gates and ring gates, not interrupts.

And are not those gates accessed via an interrupt?

No.

Call gates are simply part of protected mode execution. They do not generate any interrupt; they simply fiddle some segment registers [and control registers
and stack frame, if they are ring gates too] and then continue execution as per
a normal CALL instruction.

The use of an INT instruction in p-mode, as per PC-DOS/MS-DOS/DR-DOS + DPMI (e.g. Win 3.x/9x/Me), NT and LINUX, is an alternative way to switch ring levels. In addition to branching to the address in the interrupt vector (addressed by the IDTR in p-mode) the INT instruction switches to ring 0. But this is wholly redundant in an OS that uses call/ring gates.

I guess that makes OS/2 a "Gates environment".

Regards

Dave
<Team PL/I>

--- FleetStreet 1.25.1
* Origin: My other computer is an IBM S/390 (2:257/609.5)

Not to niggle the point, but of course OS/2 uses interrupts. Each
and every one of those API calls is a wrapper around an interrupt
call.

Well, to be exact: OS/2 uses callgates to jump into kernel code.
Callbacks are similar to interrupt gates in that
they switch priviledge
levels and have a predefined entry point into the kernel but they
additionally copy bytes from lower to higher level stacks while
swichting (byte count defined in the callgate). Something what a
interrupt gate won't do.
It is a common design of OSses to do this switching via a software
interrupt but OS/2 is different.

Ah, but are not those callgates accessed through an interrupt?
It's irrelevant that it is an invalid interrupt, a spade 's a
spade after all...

It's no INT xx instruction but really a call far. You do a

> *CALL FAR XXXX:0000*.
> The offset doesn't matter (as the callgate defines the
> entry point) but the XXXX (selector) points to an entry in
> the GDT or LDT (LDT should be possible but I've never seen
> a callgate in it in OS/2) which is a callgate (descriptor
> type 4). The descriptor defines the destination
> (selector:offset) and how many words are copied from the
> lower ring stack to the new stack.

You can examine how this works by installing _Theseus_ on

> your machine. Debug your program using any debugger which
> can display assembler instructions and trace until you find
> a "CALL XXX:0000" instruction, write down the XXXX.
> Now start Theseus and have a look at the GDT. Lookup XXXX
> (ignore bit 0-2), you find a descriptor with /Descriptor
> Priviledge Level/ 3 (because it's callable from a ring 3
> application), some offset and a selector which is probably
> 0168 (perhaps dependent on OS/2 version).
> Lookup 0168 in the GDT, you find the code selector for the
> kernel, ring 0, limit FFFFFFFF.

I would like to have an Intel or AMD manual about the i386

> because this stuff IMHO is best explained by the processor
> vendor but I have only a bad german short reference. One
> of these days I should "lend" one from the library...

Bye,

> Vitus

PS: I'm maintaining an OS for embedded systems where we use

> an interrupt, a structure pointed to by register XWA and a
> software dispatcher. This is probably what you have in
> mind.


Vitus, thanks for the detailed description, and for setting me
straight. I had assumed that OS/2 used the same method of forcing
a processor exception to jump to ring zero as MonopolySoft uses,
apparently I was wrong.

LRA


-- SPEED 2.01 #2720: Between two evils, pick the one you never tried before

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

As I am sure that you know (but perhaps Lee does not): The DOS

> interrupt system is emulated, not executed, when operating in a VDM.
> When running in a VDM, OS/2 2.0 and later use "Virtual Device Drivers"

I am well aware of how DOS emulation is provided. The topic was
whether or not OS/2 uses an interrupt sponsored processor
exception to crash from ring 3 to ring 0.

LRA


-- SPEED 2.01 #2720: But I never joined the Fertilizer-of-the-Month Club....

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

(Vitus Jensen wrote to Lee Aroner on 05-24-01:

Hi Vitus--

I would like to have an Intel or AMD manual about the i386

>because this stuff IMHO is best explained by the processor
>vendor but I have only a bad german short reference. One
>of these days I should "lend" one from the library...

I have an old (vintage 1987) book by Stephen P. Morse, Eric J.
Isaacson, and Douglas J. Alpert: "The 80386/387 Architecture" [ISBN 0-471-85352-0012]. Morse was the architect of the 80386. I imagine
that this book is now out of print. You might be able to find it in a secondhand bookstore, or on some Web bookstore site (avoid amazon.com
except as a last resort; they charge entirely too much for out-of-print
books. bibliofind.com now belongs to amazon.com, so they, too, are
useless. Try ABEbooks.com. There may be others.)

There is a description of call gates and the rationale for using
them to access operating-system functions given in this book, but the
material is too long for me to copy here.

As I am sure that you know (but perhaps Lee does not): The DOS
interrupt system is emulated, not executed, when operating in a VDM.
When running in a VDM, OS/2 2.0 and later use "Virtual Device Drivers"
to emulate DOS API calls. For calls to allowable device drivers, the
VDD calls on the appropriate OS/2 real device driver. Some DOS programs
"hook" hardware interrupts; OS/2 virtual device support allows a few DOS hardware interrupts to be "hooked" in VDM sessions under restricted
conditions. For software interrupts, most allowable calls are executed
by the appropriate VDD. The supported INT 15h (System Services) calls
are routed directly to the appropriate ROM BIOS routines by the "Virtual
ROM BIOS Driver." In general, "allowable" DOS emulation is limited to
those DOS API calls that will not compromise the integrity of the
underlying OS/2 operating system. See the IBM OS/2.0 Technical Library
manual "Virtual Device Driver Reference" for further information.

Regards,

--Murray
<Team PL/I>

___
* MR/2 2.30 #120 * Happily hitchhiking on the Information Highway

--- Maximus/2 3.01
* Origin: COMM Port OS/2 juge.com 204.89.247.1 (281) 980-9671 (1:106/2000)

PS: cool, the download aborted after 25 minutes. I love it.

I could file attach them to you(r boss node) over Fidonet if you like.

» JdeBP «

--- FleetStreet 1.22 NR
* Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)

I had assumed that OS/2 used the same method of
forcing a processor exception
to jump to ring zero as MonopolySoft uses, apparently I was wrong.

JdBP>> Strictly speaking, the design of OS/2 in this area is partly
JdBP>> Microsoft's.

I guess that would tell us something about what G. Letwin thought
of the jump to the bios IBM copyright notice as a means of
switching processor state then, eh?

That's not involved here, though. That particular mechanism was used, in OS/2 version 1.x, for switching from protected mode back to real mode in order to run DOS programs in the DOS box. Here, we are talking about the CPU remaining in protected mode, and simply switching from ring 3 to ring 0, which is what happens when a native OS/2 program calls into the kernel.

» JdeBP «

--- FleetStreet 1.22 NR
* Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)

I had simply assumed that OS/2 used the same invalid int trick to
switch rings as Win does.

JdeBP>> The interrupt(s) used on DOS-Windows and and Windows NT
JdeBP>> aren't "invalid". They are perfectly valid. Their entries
JdeBP>> in the IDT point directly to the syscall dispatch routines.

<sigh> OK, poor choice of language. The int is fine.

What is done to switch control from the application to the OS is
a jump into the bios copyright notice to force a processor exception.

Happy now?

No, because that's not what happens.

As I explained in my previous message, the forced exception was used in OS/2 version 1.x as a means of switching from protected mode back to real mode in order to run the DOS box. It's nothing whatever to do with how processes switch to kernel mode when executing system calls (which is done by the ordinary call gate mechanism of the 286, and always has been).

The forced exception mechanism isn't used *at all* in OS/2 version 2.0.0 and later, because version 2.0.0 was when "MVDM" support was introduced, which makes use of the Virtual 8086 mode of the 386 CPU. OS/2 version 2.0.0 and later don't use real mode after boot time at all.

» JdeBP «

--- FleetStreet 1.22 NR
* Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)

Moin Jonathan!

01.06.2001, Jonathan de Boyne Pollard wrote a message to Vitus Jensen:

PS: cool, the download aborted after 25 minutes. I love it.

JdBP> I could file attach them to you(r boss node) over Fidonet if you
JdBP> like.

Nonono, I retried the download later and it completed. It's just annoying that
you need something like wget to make sure you get the whole file.
Well, I have those files on my disk but ... until now I haven't read them. Let's wait until this book (the one Murray recommended) appears here.

Bye,
Vitus

---
* Origin: Dogs crawl under gates, software crawls under Windows (2:2474/424.1)

Moin Lee!

20.05.2001, Lee Aroner wrote a message to Rachel Veraa:

And second, I have MS-PDS 7.1 (QuickBasic), which can build both DOS
and OS/2 applications. It works wonderful, except for some reason I
can't perform ANY "low level" operations if I want to compile for
OS/2 (ie. poking around in memory, calling interrupts, etc). I think
there is a way around this in the BC compiler (or possibly the
linker?) but does anyone know why?

First, OS/2 doesn't use interrupts. You have to use API calls.
Second, since OS/2 is a multitasking OS, it manages memory much
differently than DOS does.

Not to niggle the point, but of course OS/2 uses interrupts. Each and every one of those API calls is a wrapper around an interrupt call.

Well, to be exact: OS/2 uses callgates to jump into kernel code. Callbacks are
similar to interrupt gates in that they switch priviledge levels and have a predefined entry point into the kernel but they additionally copy bytes from lower to higher level stacks while swichting (byte count defined in the callgate). Something what a interrupt gate won't do.
It is a common design of OSses to do this switching via a software interrupt but OS/2 is different.

Bye,
Vitus

---
* Origin: Even my cleaning lady won't do Windows. (2:2474/424.1)

Hi Lee,

Replying to a message of Lee Aroner to Rachel Veraa:

First, OS/2 doesn't use interrupts. You have to use API calls.
Second,

>> since OS/2 is a multitasking OS, it manages memory much differently
>> than DOS does.

Not to niggle the point, but of course OS/2 uses interrupts. Each and every one of those API calls is a wrapper around an interrupt call.

No, Rachel is correct.

The OS/2 API is built on call gates and ring gates, not interrupts.

Regards

Dave
<Team PL/I>

--- FleetStreet 1.25.1
* Origin: My other computer is an IBM S/390 (2:257/609.5)

And second, I have MS-PDS 7.1 (QuickBasic), which can build both DOS
and OS/2 applications. It works wonderful, except for some reason I
can't perform ANY "low level" operations if I want to compile for
OS/2 (ie. poking around in memory, calling interrupts, etc). I think
there is a way around this in the BC compiler (or possibly the
linker?) but does anyone know why?

First, OS/2 doesn't use interrupts. You have to use API calls. Second,

> since OS/2 is a multitasking OS, it manages memory much differently than
> DOS does.

Not to niggle the point, but of course OS/2 uses interrupts. Each
and every one of those API calls is a wrapper around an interrupt
call.


LRA


-- SPEED 2.01 #2720: As I said before, I never repeat myself.

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

Gordon Letwin would roll in his grave if he were in it! ;)

I didn't think Gordon Letwin ever worked for Borland. Now

> Philippe Kahn or Anders Forsberg ...

You would be meaning Anders Heiljsberg I believe, and that scummy
turncoat slimebait had better say his prayers if he and I are
ever in the same dark alley at the same time...


LRA


-- SPEED 2.01 #2720: Sure wish I could throw away that old boomarang!

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)