OS/2

From: Doug Salot <doug_at_blinkenlights.com>
Date: Fri May 26 16:36:39 2000

Eh? You're both wrong. OS/2 used the protected-mode multi-segment
support of the x86, but recall that OS/2 was originally released on the
286 -- it didn't have any paging support. It's easy to distinguish a
fault during a CS load from a GPF, and no page fault is involved.

Cheers,
Doug

On Fri, 26 May 2000, Steve Mastrianni wrote:

> Close, but not quite correct.
>
> GPF is a general protection fault, the most common problem is a bad or
> uninitialized pointer.
>
> What makes a DLL get loaded, or paged in, is a page fault. Its the same
> mechanism that causes a swapped out page to be swapped back in on a 4K
> boundary.
>
> At 02:56 PM 5/26/00 -0400, you wrote:
>
> > > Don't forget that OS/2 was written by Gordon Letwin
> > > AT MICROSOFT!
> > >
> > >
> > > You might enjoy reading "Inside OS/2" by Gordon Letwin; from Microsoft
> > > Press.
> >
> >While I agree OS/2 is a better operating system than Windows, this
> >book depressed me due to Gordon's wrongheaded-belief that a GPF
> >should always be considered an indicator of a programming problem.
> >
> >Since Intel didn't give us a pointer fault, the GPF is the only
> >proper way to implement dynamic linking. As they shipped, OS/2
> >from version 1.0 to 1.2 never did properly implement dynamic linking;
> >and Windows inherits the wrong way from OS/2.
> >
> >Strangely, Ed Iacobucci (who was Gordon Letwin's counterpart at IBM)
> >wrote an article that appeared in a magazine that described OS/2's
> >dynamic linking as operating the way it should.
> >
> >The key difference is this: in real dynamic linking, CALL instructions
> >that are supposed to invoke procedures in a DLL are constructed in the
> >executable image such that when the processor executes the CALL, it
> >causes a GPF [pointer fault]; then the GPF handler looks at the faulting
> >instruction. If the pointer is a faulted pointer to a routine in a DLL,
> >then snap the link [map the DLL into memory and then modify the faulting
> >instruction to point to the entry point of the routine as described in
> >the DLL's export table], and restart the instruction. Otherwise, it's a bug
> >and you signal a condition which somehere generates an error message.
> >In this scenario, programs start up much faster because the OS is not
> >reading and linking every routine in the executable's import table. If
> >you never use feature <X> in the program, and if feature <X> resides
> >tottally in a separate DLL, then that DLL never gets mapped into RAM.
> >MUCH, MUCH better execution, more robust operation, in particular, the
> >machine wouldn't thrash at startup dur to all those programs in your
> >startup folder.
> >
> >Due to Ed's article, I always assumed that there was a turf was between
> >IBM and Microsoft on this and other salient technical points. MS won
> >and was wrong.
> >
> >So, having said that, you might see why I'm not a big fan of Letwin's.
> >
> >Shew! Glad I got _that_ off my chest again.
> >
> >respectfully submitted,
> >-doug quebbeman
>
>
> - Steve Mastrianni
>
Received on Fri May 26 2000 - 16:36:39 BST