OS/2

From: Steve Mastrianni <stevemas_at_persys.com>
Date: Fri May 26 18:21:53 2000

Eh, no. The paging was totally rewritten for OS/2 2+.

OS/2 must assuredly used 4K pages (and still does). OS/2 for the 286 was
version 1.x.

I worked on the memory manager.

At 05:36 PM 5/26/00 -0400, you wrote:
>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
> >


- Steve Mastrianni
Received on Fri May 26 2000 - 18:21:53 BST