26 May
2000
26 May
'00
8:25 p.m.
OS/2 was modified at 2.0 to include a flat memory model. Apps and DLLs went
to 32-bit flat model code. Legacy apps got their APIs thunked to 32-bits.
It was also possible to use legacy DLLs from 32-bit apps, which got their
APIs thunked 32 to 16 and back. Some called it a hack, for IBM it was a way
to get legacy 1.x apps to run in 2.x. Older DOS and Win apps were run the
V86 mode, each with their own 1MB sandbox.
Of course none of that matters now. 8-)
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
>