From: dic5340@hertz.njit.edu (David Charlap)
Newsgroups: comp.os.os2.advocacy
Subject: Re: NT vs OS/2 features (was Re: Misinformation about os2-dos HW access)
Date: 2 Sep 92 13:04:50 GMT
Organization: New Jersey Institute of Technology, Newark, N.J.

In article <1992Sep01.181607.4094@microsoft.com> philipla@microsoft.com (Phil Lafornara) writes:
>
>>I'd like to see a easy-to-write printer driver.  Also, I've heard
>>trouble with installing printer drivers under NT.
>
>      Come now - it's not even in beta yet...

It seems to me that printer drivers for bit-image printers (like dot-
matrix and non-PostScript lasers) should be easy to write.  Take
generic code and fill in the strings to go to graphics mode, exit
grpahics, etc.  It should be doable with a script file, much like Word
fod DOS's MAKEPRD.EXE program made Word printer drivers from a script.

>>>      This is not strictly true.  Windows NT runs 16-bit Windows
>>>and DOS apps in subsystems - when running a 16-bit Windows apps,
>>>any time spent in API calls will be mapped to the appropriate
>>>Win32 calls.  All the drivers can be fully 32 bit.
>>
>>Hmmm...the same way OS/2 does it.  How interesting. =)  Are you
>>guys doing it via thunk?  Is there any other way to do it?
>
>      Don't know about thunks - probably couldn't tell you if I
>did.

Thunks are small code fragments that go between procedure calls and
the procedures.  They translate parameters in both directions.  In
OS/2, they are used to let 32-bit code access 16-bit system calls and
vice versa.  Thunking is the way current 32-bit code can work with a
16-bit graphics engine, and how 16-bit OS/2 1.x code can work with the
(RSN) 32-bit graphics engine.

But thunking is more generic than this.  It was invented for the
Algol-68 language to implement "pass by name" function parameters.
Plese respond in e-mail or (better) post to comp.lang.misc if you want
to know more about this.

The term "thunk" was invented because a program doesn't have to
"think" to perform the translation.  It's been "thunk" out at
compile-time (or in the case of OS/2, at run-time, but by the OS).

>      Is there any other way?  Almost certainly.  Are those other
>ways better?  Possibly.

Considering the broad definition I gave thunking, it probably includes
most everything else.  Note that I didn't mention how OS/2 (or NT)
performs thunking.  I don't know.  And the point isn't really an
issue, since apps don't need to know.

>>>     Strangely enough, FAT is faster than HPFS under Windows NT at
>>>the moment.
>>
>>Now, that's **weird**.  You guys aren't running the 1.3 version of
>>HPFS are ya?  =)
>
>     I think the current caching schemes are optimized for FAT.

They would be.  If you only have one caching scheme, you want to
optimize it for the worst file system you have.  This way they will
see the most improvement (and they need it more).  The others already
have a "leg up" so don't need as much help.

It's better to use a separate caching scheme for each file system, the
way OS/2 does.  This is why you have a /CACHE= parameter in the
HPFS.IFS driver, and a DISKCACHE parameter separately for FAT volumes.

But for a pre-beta release, the cahce scheme isn't overly important.
As long as the one they release is sufficiently fast and bug-free.
(Actually, a cache had better be COMPLETELY bug-free, since failure
can mean crashed drives!).  The one being shipped with the pre-release
SDK is just there so you can get some pre-release development work
done.  It'll certainly be better upon GA.

-- 
   |)  David Charlap           "TELEPHONE, n.  An Invention of the devil which
  /|_  dic5340@hertz.njit.edu   abrogates some of the advantages of making a
 ((|,)                          disagreeable person keep his distance."
  ~|~                              --- Ambrose Bierce, The Devil's Dictionary
Newsgroups: comp.os.os2.advocacy