OS/2

From: Doug Salot <doug_at_blinkenlights.com>
Date: Fri May 26 19:05:17 2000

I can believe that, but I thought we were talking about Gordon Letwin and
the days when Microsoft designed/shipped OS/2. Letwin's book was
published in 1988, well before OS/2 2.x.

In any case, page faults are not required for DLL loading in any x86 OS.
If you're using a flat memory model, then it might make sense. Was 2.x
using a flat memory model?

BTW, anybody have an MS-labeled version of OS/2? I think I still have a
1.2 box someplace.

Cheers,
Doug

On Fri, 26 May 2000, Steve Mastrianni wrote:

> 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 - 19:05:17 BST