This contains fixes since xr_e002/xr_m015/mcp/acp. Important note: If you use
the OS/2 SES facility, you need a new sesdd32.sys dated April 2001 or later
to use this kernel. Also, a matching dump formatter (df_ret.exe), provided
separately, is required, if you want to analyze a dump from this kernel.
Finally, note that os2ldr is only required for the >64mb memory detection
mentioned below.


***New as of 2002/04/16: I'm including an updated os2dump module, because the
   one that comes with mcp2/acp2 can possibly OVERWRITE your partition(s)!
   If you plan to use standalone dump and you have mcp2 or acp2, use this!
   Caveat: This os2dump will *not* work on non-LVMized systems (i.e. Warp 4+
   FP13-16). On the other hand, the bad os2dump wasn't distributed for FP13-16.


New function:
    1) Support for >64m memory using int15 func e820. Note, this support is
       enabled ONLY for Intel Pentium Pro or later, or non-Intel Pentium-class
       machines. This is done in an effort to prevent problems on older PCs.
    2) The presence of \os2\boot\os2norev.$$$ suppresses the display of 
       internal revision during boot.
    3) Adding "EARLYMEMINIT=TRUE" to config.sys will allow device drivers, etc.,
       access to the memory above 16mb early in boot. Previously, this was only
       available after DD and IFS init was completed. This has various
       implications when enabled:
	  a) AHA154X.ADD may do bad things to your system. Don't even ask.
	  b) There may be some settings of HPFS386 cache that are incompatible.
    4) Trap messages will now give the module name instead of the device name.
       For example, "Exception in module: CLOCK01" instead of "Exception in
       Device Driver: CLOCK$". 
	***change from 0220/0223: Traps in 32 bit code now show the modname, too
    5) Systems with a 486SX chip running FP15 will function correctly. Note,
       they will NOT work with ACP or (necessarily) on MCP.
    6) SESDD32 will now work correctly (I hope) for both uni and smp
    7) All process dumps should now be considerably faster. paddr(all) dumps
       should take about 40% less time and others around 80-90% less time.
    8) EXE names will now also be displayed in alt-f2/alt-f3 processing (note
       that CMD file names, e.g. MPTSTART, will NOT be displayed, only cmd.exe)
    9) alt-f4 is like alt-f2 plus it pauses after displaying each names (does
       not pause after BASEDEV= or PSD=) and, by pressing F1, allows you to
       skip loading/running the file displayed.  Alt-f5 is like alt-f4+alt-f1.
    10) The dump formatter (in dfxxx.zip) should be faster and also work on
        dumps >= 2gb, which was not formerly possible.
  04/16/2002:
    11) Added "1" as an OK setting for flags in config.sys. Now, things like
        EARLYMEMINIT=TRUE can also be YES,ON, or 1 (or FALSE,NO,OFF, or 0).
	I wish I could make stuff like this NLV-independent but that is 
	ABSOLUTELY IMPOSSIBLE without HUGE changes.

 2002/01/02:
    Support for 16bit filesystems with >2gb file support (e.g.the forthcoming
    >2gb dump support ifs)

 9/13/01
    11) If you also install the enclosed clock01.sys to \os2\boot, you can 
        add "CLOCKSCALE=x" to config.sys. The choices for x are 1 (the default,
	which is the old behavior), 2, and 4. The number represents a scale 
	factor for the frequency of clock ticks. The theory is that CLOCKSCALE=4
	will speed up some apps (maybe Netscape and/or Java).

Bug Fixes:
  Fixes from earlier "dated" kernels:
    Fixed a trap 000d in w_OpenCreate (140:4dfd or so in uni/w4 krnls, don't
              have regs for SMP). This was a post mcp/acp regression
    Fixed strange loader i/o problems specific to the 0111 kernel.
    Fixed a bootup sys31xx problem specific to the 0123 kernel.
    Fixed a problem that was (I think) specific to  Janauary uni & W4 kernels

          which resulted in odd ring 3 (maybe ring 0?) traps and hangs
    Fixed some trap and other peculiar problems specific to the 0206 kernel.
          Those were the result of a build problem.
    Fixed some trap and other problems specific to the 0220/0223 kernels
    Fixed a regression from JR15038 that caused a trap in CWBBS.IFS and
	    PCSFLR0.IFS (AS/400 shared folders access).
    Fixed a regression in the 0330 kernel that messed up getting procdumps
    Fixed a regression in the 0416 kernel that caused some hangs and also
    	    affected APM
    Fixed a regression in the 0502 kernel that prevented booting altogether or
            caused other very bad problems.
    Fixed a regression in the 0502/0503 kernels that caused some odd trap d/e's
            in the scheduling code
    Don't use the 0601 kernels.
    Don't use the 0615 kernels, either. There seems to have been some kind of
            build problem, there.
    Removed the int 3's I'd accidentally left in some EA code in 0727 build
    The 0730-0801 kernels all had problems due to various attempts to fix
            PJ28078. Sorry about that!
    10/16: the 1015 os2ldr was broken on some CPUs
    11/29: Trap 000e (DS will be 0) in 11/28 kernels (only)
           Some peculiarities deleting files
    01/18: Some hang/trap problems relating to the 01/17 kernel
    01/25: Fixed regression from DosDelete change where some files weren't
    	   getting deleted if DELDIR was set.
    02/21: Strange problems on SMP kernel, particularly with HPFS386 (related to
    	   0201 kernel, only)
    02/22: 2/21 kernel fix for PJ28434 fix was bad. Unknown possible side-
           effects during bootup.
    03/15: Chgfileptr (seek) ops may fail on FAT, particularly on a vdisk
    04/01: df_ret/df_deb trap on some memory analysis operations. note, you can
           use this df_ret.exe (& df_deb.exe) on dumps of kernels back to about
	   Sep 2001 or so. Just always use the symbols that match the dump.
    04/16: Added test fix for trap 000e in _ldrSegFixAddIterRec
           - *May* have fixed some strange program load behavior with the
	     implementation of the latest JR15038 fix.

  Fixes to problems that exist in released code:
    JR15494: Delayed response of Ctrl-C or Ctrl-S (pause) in os/2 windows
    JR15405: (probably) DosQueryAsyncTimer fails on timecritical thread after
    	     mscount rolls over after 49.7 days of uptime
    JR15030: TRAPDUMP QUERY doesn't show PD (needs a new trapdump.exe, too)
    JR13335: Some VDMs won't run, complaining of too-long command lines
    JR15194: XCOPY fails with SYS1186 or SYS1192 on (at least) MO drives 
    JR15038: Trap 8 in h_DeviceHelpDM running an app from a tcpbeui drive
    JR15229: Files left open after ERROR_TOO_MANY_OPEN_FILES returned to app
    PJ27700: SMP systems may get a trap 000e in _tkStopScan, particularly 
             during a procdump operation.
    PJ27676: Causes hangs on some systems running UNI or W4 kernels
    PJ27554: Hang or (on allstrict) trap 3 on SMP (only) during beeps
    PJ27678: SMP kernels could not be RIPL-booted. As part of this, there is
	     a new config.sys parameter I13PAGES= available. Adding I13PAGES=1
	     to config.sys (note, no SET) reduces the memory usage of the mini
	     VDM processes used by ibm1s506.add and the GRADD drivers. This
	     becomes important in RIPL-boot situations. It may be helpful for
	     UNI RIPL boot, as well.
    PJ27677: SMP systems hang with multiple threads of same process
	     entering a critical section (affects ADSM client)
    PJ27757: Trap 000e running Theseus/4 (note, theseus4.exe may still end up
             with a sys3175, but at least the system doesn't crash).
    PJ27736: Trap in _PLD_WriteReturnCode
    PJ27777: Set BEGINLIBPATH= (in config.sys ONLY) may be ignored. Also, 
             it would lead to a bogus copy of BEGINLIBPATH= in the environment.
    ;PJ27821: Trap 000e in SchedNextRet2 on some APM-enabled machines
    ;         *removed as of 0508 -- original fix caused regressions. new fix
    ;         on hold, for now
    PJ27906: Trap 000e in pvwRegKrnlInstance running SPM/2 (may also cause
             unknown odd behavior in other performance monitors).
    PJ27919: Complete system hang running some apps (same as JR12136)
    PJ27544: Panic in SwitchNPX
    PJ27972: trap 000e in _SecExecPost (the actual fix is in ses0604 or later)
    PJ27952: DosFindFirst returns incorrect returncode for various bufsizes
             when querying extended attributes
    PJ28005: ProcDump command returns error code 6 (and the procdump is invalid)
    PJ28013: read of >2k from named pipe on a timecritical thread can cause
    	     loss of pipe data or session hang
    PJ28027: trap in KMQueryClientRegister reallocating a trace buffer
    PJ28068: trap 000e in clock$ where sslim is ffffffff (during JFS activity)
    PJ28076: "trapdump [PD|NOPD]" disables the procdump.exe command. Also, it
    	     causes a trap 000e if you initiate a dump with ctrl-alt-f10-f10
	     (or numlock-numlock).
    PJ28077: Some VPM apps will refuse to initialize
    PJ28078: Various traps with floppy disk hard errors when UDF is loaded
    JR13789: DRIVES does not reflect change in directory entries
    PJ28102: Performance tracing slow on Pentium 4 CPUs (this is the only 
             APAR listed here fixed in os2ldr)
  10/16:
    PJ28199  SES QUERYFILEINFO buffer pointer always -1
    PJ28207  SES callgate hooks don't work
  10/26
    PJ28215  Added HMA flag to DevHelp_GlobalToProcess. The new flag 20h (in
             EAX for the call to the DevHelp) allows a device driver to map
	     global memory to a process' high private arena.
    PJ264136 Trap 000e in the kernel when theseus gets system working set. Also
             fixed a theseus problem on systems with HPFS386.
  11/28	(MCP2/ACP2 kernel plus the following)
    IC32279  Trap 000e in TKDeclareInversion after killing a process while it's
             doing DosDelete processing.
  01/17 (happy new year) revision 14.086c
    PJ28355  SYS3175 (or other problems?) when booting a Pentium 4 machine when
             initializing testcfg.sys or apm.sys

    **Note: For those of you with ACP1 or earlier, the os2ldr contained here is
            also mandatory to fix the P4 problem.

  01/18 revision 14.086d
    PJ28362  traps in os2krnl running theseus/4
  01/25 revision 14.086e
    PJ28379  disallow alt-f4 and alt-f5 in the presence of altf1sec.cmd
  02/01 revision 14.086g
    PJ28392  trap in f_w16_DoPageIO ***** see 03/06 *******
  02/21 revision 14.088a
    PJ28434  swapper.dat can be trashed from a VDM session
    JR15405: Second attempt to fix this
  02/26  revision 14.088c
    PJ28450  fix random problems on SMP Pentium PRO machines that started as
             of 2001/08/21
    PJ28355 part 2 -- some P4 machines STILL had boot problems
  0306   revision 14.088d
    PJ28392   Again! Somehow, this fixed got dropped from 0226
  0311   revision 14.088e
    PJ28468   Undelete not working since CP2
  0315   revision 14.088f
    PJ28472   Trap 000e in THEArena_Get running theseus/4 (may also be in 0311)
  0401   revision 14.088g
    JR15405 part 2: more likely fix for 49.7 day hang (still in test)
    JR15038 part 2: more trap 8s running an app from a tcpbeui drive
  0408   revision 14.088h
    JR15038 part 3: more trap 8s running an app from a tcpbeui drive
  0416   revision 14.089b
    PJ28541 sys0008 trying to start up lots of huge DLLs
    JR15038 new version: rather than slowing executable loads for everyone, I've
            gone back to using the faster stack-based buffer allocations most
	    of the time. If you have loaded an ISS (security) or if you
	    explicitly add "LDRSTACKOPT=TRUE" (No "SET ,,," please) to
	    config.sys, we will try to minimize ring 0 stack usage by
	    allocating buffers off the heap.  This is slower, but prevents
	    ring 0 trap 0008s in some cases. If you use TCPBEUI, particularly
	    with the IBMTRP driver, you should probably add this parameter
	    to config.sys.
  0426   revision 14.089c
    Note: JR15038  from 0416 temporarily removed, as I think it was causing
          unstable behavior (including trap 000E and trap 0008). I left the
	  LDRSTACKOPT option in, but for now it does nothing.
    PJ28547 trap 000e in _ldrSegFixAddIterRec running Oracle 6 and other apps
    PJ28566 trap 000e at _PLD_WriteReturnCode + 169 or so during procdump.
    PJ28567 trap 0003 in _PLDClose during procdump.
  20020515   revision 14.089d  (note the new naming convention)
    PJ28600 non-zero return from SecOpenPost ISS callout after file create
    	    operation leaves zero length files around
    PJ28602 internal thread names wrong in df and debug krnl on 1 cpu SMP
    PJ28603 module name missing or incorrect in r0 trap screen
  20020516   revision 14.089e
  	A build problem caused the 20020515 PJ28600 fix to cause a trap. You
	will only see this if you have a security device driver installed.
  20020802   revision 14.091a
  	- not clear whether PJ28392 was included in recent kernels before this
	- IRQ sharing problem in os2ldr caused hang on reboot for some USB
	  controllers sharing IRQs
	- Yet another attempt (the last, we hope) to fix the 49.7 day hang
  20020822   revision 14.091b
  	- backed out the os2ldr junk from 20020802
	JR15405 (final) the 49.7 day change might not have been in 20020802.
  20021010   revision 14.091c
        - put back in the IRQ fix in os2ldr. seems to be ok
	- took clock01 out of the package.
  20021028   revision 14.093a
  	PJ28871 trap with TRACEBUF= .../D=ALL in config.sys
	- fix an obscure trap in KernelFaultEntry on debug kernel only
	- fix a trap if Kern32ReadFileAt called and an ISS is installed
  20021205 14.093c
	- fix a trap if Kern32ReadFileAt called and an ISS is installed
	  (the fix was not correct in 1028)
	- trap in w_dup trying to do DosDupHandle to target handle outside range
	  of current max file handle number
	PJ28941 trap 000e routine VMAliasToAlias doing procdumps on some systems
  20031226 14.093d
  	- back out all experimental stuff including the w_dup trap and trap 8
	  test fixes
  20030213 14.093e
	- close some files that had been left over by some inconsiderate DD
	  init code. the extra handles choked some apps, like MS C6
	- Prevent trap under some condtion I don't understand while using a
	  debugger (like codeview or ipmd or whatever) in DbgSeverConnection
	JR17862 fix a problem with a thread hanging (but not the whole system) 
	  after the 49.7 day rollover doing a DosSleep (*Not* fixed in 1226)
          Also, DosRequestMutexSem with 0 < timeout < ffffffff may hang if the
	  thread wakes up after rollover and still doesn't own the sem.
	PJ29032  trap in thesmte_get or themte_get running theseus4 or using
	         theseus4 APIs
  20030303 14.093f
       - backed out the file closing change in 0213, as it seems to be causing
         problems on some systems. the underlying problem will be investigated
	 later in individual drivers.
       - change to fix from JR17862 in 0213 kernel due to possible regression
         that would result in a semaphore not timing out properly
       PJ29066 possible fix for a rare trap in _qsSem running pstat
       JR17842 various dump formatter rc:5 problems (fixed in df_ret/df_deb)
  20030306 14.093g
       - w_dup fix back in
       - another shot at fixing the trap 8 problems while running an ISS or
      using tcpbeui. If you're using tcpbeui (*especially *under SMP), you
      should not use this. If you're using an ISS, we ignore this. For others,
      you may get some speed improvement in loading apps by adding
      LDRSTACKOPT=FALSE to config.sys (the default being true).
  20030415 14.093h
       - LDRSTACKOPT back out. It caused too much confusion and I'm not 100%
         sure about its stability. Sigh.
       - Some enhancements to the ".pb" command in the dump formatter
  20030501 14.093i
       - I kept forgetting to take out the code that closes file handles > 2
         before starting PROTSHELL. The good news is that doing the close
	 reduces the number of leaked file handles by a few in some systems.
	 The bad news is that it also makes PMDD$ trap on boot on other
	 systems. So, if that happened to you with 14.093h, get this kernel.
	 As of now, add CLOSEFILES=TRUE if, like me, you need the changed
	 behavior (in my case, Microsoft C 6 kept aborting).
       PJ29180  Trap 000E while taking a process dump
  20030620 14.093i1
  	- don't use this one. I put it out by accident due to packaging bug.
  20030621 14.094
  	- nothing new, but this is the first "official" (i.e. one where we'll
	  actually have full source code control) in a while. It leaves out
	  the CLOSEFILES keyword, though.
  20030822 14,096
  	PJ29349  Trap in ThePD_Get (another theseus/4 trap)
	PJ28318  problems accessing non-US filenames (regression due to PJ29234)
	         (related fix to cmd.exe to back out bogus changes will be 
		  available in next fixpack)
  20031031  14.096b
	- CLOSEFILES= back in
	- fix 2 traps in w_DupHandle
		   Seems to affect Netfinity remote access.
	PJ29849  trap 000c in w_NewSize during procdump processing
  20031103  14.096c
        - incorrect parameters being reported in some devhelp system traces
  20031110  14.096c
        - 1103 system trace fix not built into some kernels
	- fix named pipe regression in 1031 and 1103 kernels
	- os2ldr is now the version that "works" with shared interrupts. 
	  HOWEVER, if your system has shared interrupts that didn't used to
	  get noticed, then you may suddenly get much slower. This happens on
	  my personal Intellistation which shares an IRQ for the USB and audio.
  20031113  14.096e
	- trace fix didn't get into previous w4 and uni kernels
	- EXPERIMENTAL: Removed a bunch of redundant locking and unlocking of
	  some pages in filesystem code that's already pinned, anyway. This
	  ought to speed up a number of filesys-related APIs. Also, re-enabled
	  the un-pinning of numerous pages of memory from init code. This
	  memory is now available for other uses, which should reduce paging on
	  many systems. This had been turned off since WSeB!
	PJ29472: process hangs (and other things?) if named pipe handle is
		   closed while another thread is blocked in DosConnectNmPipe.
  20031117  14.097b  (post xr_c004)
  	- Some of the pages in the 20031113 package may possibly need to stay
	  resident to avoid any danger of a trap 000e if they're needed during
	  page fault processing or interrupt time. So, this time, I left those
	  pages resident,too.

  20040116 14.097d
  	- the code lock stuff seems to be working well, so it's no longer 
	   "experimental."
	- possible DosConnectNmPipe regression test fix
	- Support for loading pure 32 bit code and data objects in DLLs above
	  the 512mb line. More details on that to come separately.
  20040119 14.097d  (still)  *DON'T USE THIS OS2LDR*
 	No kernel changes from 0116, but OS2LDR changes:
 	- the interrupt sharing fix had, at some point, got taken back out.
	  users with seeming IRQ issues should try this
	- possible problem booting up P4 Xeon 4 gHz (hang at boot blob)
  20040123 14.097e
  	- fix bad cFH count in DosQuerySysState/QProcStatus with level=0
	- attempt to fix intermittent trap 000e resulting from highmem loadin
	  in 116 kernel
    	- bad fix for boot blob hang in 20040119 caused "unable to operate
	  hard disk" failures with os2ldr from 20040119 packages
  20040126 14.097f
  	- fix bad file handle array in DosQuerySysState/QProcStatus with level=0
  	- more changes related to boot hangs and other weirdness from 1/23
  20040126 14.097g
  	- more on file handle array in DosQuerySysState/QProcStatus with level=0
  	- another attempt to update os2ldr to work with everything from 486SX to P4 Xeon >3gHz....
	PJ29595: trap 000e at SftFileSize + 66 or so
  20040206 14.097h
  	PJ29602 trap 000d at h_DOS_ChDir + 28 or so after media change
	- backed out bogus os2ldr changes (again)
  20040323 14.098a
  	PJ29697 add debug support for disappearing browser windows
	- fix DevIOCtl passthru support
	- fixed the "k" command in the dump formatter (at least it's better)
  20040330 14.098b
  	PJ29712 (os2ldr) final fix for boot blob hang on fast (around 3+ gHz) CPUs
	- backed out some kernel stuff that accidentally got built
  20040621 14.100c
  	PJ29712 redux: totally different boot blob fix. Ought to fix not only
	       the P4 hang, but also probably the problem on some machines of
	       the blob disappearing too quickly to hit alt-f1, etc.
	PJ29846: Some DOS apps using FCB Open don't work with files on JFS and
	         maybe UDF.
  20041103 14.100d
  	WITHDRAWN

  20041105 14.100e
  	****** WARNING: Do NOT use this version on a Pentium Pro machine.
	    For the benefit of everyone else, I have temporarily removed a
	    workaround for a P-Pro chip bug. This will improve performance
	    under heavy load by a few percent for all other machines by 
	    correctly aligning the IDT entry.

	JR20486  More sys3175 during bootup on Pentium 4s (and maybe Opterons?)
		 with >512mb of RAM

	- changedd vmco_s to be 8 bytes instead of 5. This will break tools that
	depended on that length and will use an extra 184kb of resident memory.
	However, it greatly speeds up some memory management operations.

  20041210 14.100g
  20041214 14.100h
  20041215 14.100i
  	WITHDRAWN (kernel causes machines with older CPUs to hang on boot)
  20041216 14.100j

  20041216 14.100k
  	****** SEE WARNING UNDER 20041105
	** Experimental: Changed realmode transition code again to try to make
                         all CPUs happy with APM and TESTCFG.

	JR20486 (again): Even more P4-related changes. Athlon64 likely still not
	working reliably (or supported).
	- os2dump and os2ldr LBA changes in 20041105 backed out
	- *Very* small timing hole caused trap 3 in SwitchNPX

  20041216 14.100k
  	****** SEE WARNING UNDER 20041105
	PJ30111 Trap 000E in _vmAliasToAlias (only during debugging?)
	- trap 000e in os2lvm if eject command is performed on a removable
	          device while copy is in progress.

Following are rough instructions for applying the os2krnl fix:
In the directory from which you boot (C:\ or d:\ or whatever), type these
commands. Note that os2krnl should have come with this file.

Also, there are some REXX scripts written by third parties that might make
installation/archiving of your kernels easier. Go to http://hobbes.nmsu.edu
and search for "moritz", for example. This is unsupported by IBM!

1. attrib -r -s -h os2krnl
2. attrib -r -s -h os2ldr
3. copy os2krnl os2krnl.sav
4. copy os2ldr os2ldr.sav
5. copy \os2\system\trace\*.tdf  \save       (or wherever)
5. unzip -o xxx.zip
If you want, you can turn the os2krnl and os2ldr attributes back on, but
it's not necessary to do so.

Trace files (*.tdf)  have been included.

An os2krnl.sym file has been provided with this fix. Just save it somewhere
(root directory or anywhere). It is only needed in case OS/2 
service requests a standalone dump of your system in the future.
