Description, taken from USENET Post

I figured out a generic way to prevent NS from raising any of its'
threads priorities.
I have definitely seen an improvement, not only from other programs
(which are no longer cut off from the CPU when sending news/mail, or
cleaning the cache), but within netscape itself;  it seems at least one
of the threads used to compete too hard for processor time, causing
display of web pages to occur slowly & in chunks.  Now things seam to
simply "flash" onto my screen.  This might just be an illusion, since
the overall loading time might be the same, but it is more pleasing to
the eye.
I redirected Netscape's reference to "DOSCALLS.DLL" to a new dll of my own,
where I hook DosSetPriority() and forward the rest to the real DOSCALLS,
exactly like I did in the article I wrote describing how to prevent slow
OS2.INI writes.

Download the ZIPPed Archive w/Source Code

Feb 26, 2000
============
Tjhe remainder of this README deals with a previous, similar, api-hook
for DosOpen.  The Netscape 4.6 patch you are interested in is almost
exactly the same, but the DLL operated on is PR3246.DLL, and the API is
Dos32SetPriority().
Also, so as not to conflict with the newcalls.dll used below, the dll is
named newcalNS.dll.
I created some *.cmd files to save a little typing:
g.cmd: compiles newcalns.dll (review the file "log" after running)
t.cmd: runs DLLRNAME on pr3246.dll
The original code (for pmmerge/dosopen) is in newc1.lzh

----------------------------------------------------------------------------
Jan 22, 1997
What is NEWCALLS.DLL?
=====================
This is an example of how to redirect (or "hook") a function in a dll
that you don't have the code for.  My example hooks DosOpen() for
PMMERGE.DLL.  It works under Warp 3.0 or Warp 4.0.

How it Works
============
The exe header of PMMERGE.DLL is changed so that all refernces to
DOSCALLS.DLL go to NEWCALLS.DLL instead (IBM's compiler supplies a
utility called DLLRNAME to do this).
NEWCALLS.DLL contains a forwarder entry (to DOSCALLS.DLL) for every
function exept Dos32Open().  The forwarder entries are created, by the
linker (FWDSTAMP.EXE is NOT needed),  because the *.def file both
IMPORTS and EXPORTS all of the function names (except Dos32Open).
Since many of the ordinals are not referenced by name (and are not
documented),  I forward them with a manufactured names. Example:
   _undoc4=DOSCALLS.4
Since the real doscalls.dll does not export a name for ordinal 4, it
should not make any difference what it is called.  The important thing
is that an oridinal of 4 does exist,  in case pmmerge.dll uses it (it
will use it by ordinal number, not by name).  This may seem
untrustworthy, but you have to keep in mind we are redirecting DOSCALLS
only for one specific piece of code (pmmerge.dll);  and if we get it
wrong it will fail to load.
Additionally,  newfwd.def IMPORTS the real Dos32Open,  for its own use,
by ordinal (273), and calls it _Dos32Open().  _Dos32Open() is a private
name,  only seen by newcalls.dll.
        _DOS32OPEN =DOSCALLS.273

Newcalls.c only has to contain code for one function, Dos32Open().  All
other functions are automatticaly redirected,  at load time,  to the
real doscalls.dll;  thus there is NO runtime performance impact,  only a
slight (probably immeasurable) loadtime impact.

Why NEWCALLS.DLL?
=================
Whenever anything changes on your WPS (which can happen simply by
referencing an object),  changes are made to OS2.INI and/or OS2SYS.INI.
Every so often (2 mins or so) these changes are written to disk.  Since
OS/2 2.1,  *.ini files are kept completely in (swappable) memory,  and
are rewritten, in their entirety,  whenever updates are required (this
means the system will have to swap out memory equal to the size of your
*.ini files,  swap in the memory where the *.ini file data is,  write
them out, etc...this design sucks;  I liked the way os/2 1.1 through 2.0
did it better).
To further complicate things,  the *.ini file data is written out in
chunks of 32k or less.  My os2*.ini files are 1.2mb;  that means about
40 DosWrite's.
The code for PrfOpenProfile() is in pmmerge.dll. PrfOpenProfile() calls
DosOpen with the "OPEN_FLAGS_WRITE_THROUGH" bit on.  This causes each
DosWrite() to the *.INI files to completely update all disk structures
before it returns (this is VERY slow on HPFS).
It takes a good 15-20 seconds to write my *.ini files out (and this
happens every few mins).  Not only do I have an annoyingly loud
harddisk,  but the performance of my PC will sometimes crawl while the
update is taking place (a priority boost is giving to threads blocked on
disk i/o).
My replacement DosOpen() masks off the OPEN_FLAGS_WRITE_THROUGH bit,  so
that all operations to the *.ini files are cached.  Now my *.ini file
updates are next to instant (a second or so),  and a lot quieter;  file
system structures are only updated once,  instead of after each
DosWrite().
I'm sure someone at IBM thought they were being "safe" by using
write-through mode.  I disagree.  The *.ini files are actually written
as "os2.!!!" and "os2sys.!!!",  then renamed to os2*.ini after they are
on the disk.  A power failure will only cause a problem if it occurs
when the *.!!! files are renamed (regardless if you're using
newcalls.dll or not).  A power failure while the ini file data is being
written to disk will cause the system to use the older *.ini files
already present.  It actually makes more sense to write the data out as
fast as you can,  to get ahead of the power failure.

How to use NEWCALLS.DLL
=======================
 1) Compile/link newcalls.c using IBM's compiler (the IBM linker is key;
    it creates the forwarder entries from the *.def file).  Simply:
    icc /Gn /O /Fenewcalls.dll newcalls.c newfwd.def os2386.lib
 2) Backup your original pmmerge.dll.   Run:
       \ibmcpp\bin\dllrname pmmerge.dll doscalls=NewCalls /q
    (You can't use the pmmerge.dll that is active;  copy it somewhere
     else, modify the copy, boot to the command line,  copy new dll to
     \os2\dll).
    This command will change all references to DOSCALLS to NEWCALLS.DLL.
    This only affects pmmerge.dll.  It does not directly affect any
    programs that use pmmerge.dll.  Furthermore,  only DosOpen
    (Dos32Open actually) has replacement code -- all other entry points
    are forwarded to the real doscalls.  There is ZERO runtime
    performance impact on forwarded calls (there is a slight LOAD time
    impact,  as the loader does its stuff).


Peter Fitzsimmons,
President,
A:WARE Inc (OS/2 Contracting)
Voice:  905 858 3222
Internet: pfitzsim@home.com
Copyright (C) 1997, A:WARE Inc.