OS/2

From: Steve Mastrianni <stevemas_at_persys.com>
Date: Fri May 26 15:14:10 2000

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 - 15:14:10 BST