26 May
2000
26 May
'00
8:21 p.m.
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:
- Steve Mastrianni
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
>