

             =====================================================
             NOTES ON USING NEWVIEW TO ALTER SEGMENT TABLE RECORDS
             =====================================================


       This release of NewView provides the ability to change the attributes
     of a code/data segment, and you should be aware of the implications
     before you attempt to do this to a program you cannot relink yourself!


      ********************************************************************
     (WARNING:  THIS CAN BE DEADLY TO YOUR EXE, AND NO BACKUP IS CREATED!!)
      ********************************************************************


        To change a segment's attributes:

                - load the file, of course
                - push [Segments] to see the list of segments
                - hilite the segment to change
                - Hold CTRL+SHIFT down, and dblclick with the LEFT mouse.

        A dialog box will appear, showing you the bits currently in the file
       in one column, and the bits you can change in another. You change
       a bit by toggling it's ballot box (or radio button for Code/Data)

        When you press [OK], you will be prompted Save Y/N?.  At that time,
       the original file will be UPDATED, ON THE SPOT.  No backups, no nuthin'.
       There's no way to know what the bits USED TO BE once you confirm to
       make the changes.


        If you don't change any bits, or if you put them back the way they
       were when the dialog box opened, you won't get the "Save Y/N?" prompt.
       If you [Cancel], no changes are made to your executable file.



       BE AWARE OF THE SHORTCOMINGS IN USING THIS FEATURE TO ALTER PRELOAD:

        If your intent is to toggle the PRELOAD bit from on to off, or vice-
       versa, there are some other things you should know.  Some executables
       will contain a "gangload" or "fastload" setting.  If this has been set,
       it will appear in information available by pushing the button for the
       [New Header] report.  A "gangload" or "fastload" with a non-zero value
       informs the Windows loader to pre-read a large chunk of the file into
       a single buffer (up to 1Meg, I believe?).

          When the "fastload" or "gangload" area is used, Windows will allocate
       memory and perform a single _hread operation to avoid the overhead of
       frequently accessing the disk for each segment or resource that uses
       the PRELOAD attribute.  This way, Windows can simply copy the data from
       the big buffer as it creates the indivudual segments or resources
       instead of thrashing the disk for each small piece. (Well, segments used
       to be smaller before Win 3.0/3.1's improvements made it less important)

         If you make a segment PRELOAD, or clear the PRELOAD flag, NewView
       DOES *NOT* alter the values for the "gangload" or "preload" size or
       location.  When a "gangload" area is created, RC.EXE (or the linker)
       will order all of the PRELOADed items contiguously.  If NewView changes
       the settings for something inside the "gangload" area, it shouldn't
       hurt anything, except for the wasted memory temporarily occupied by
       this now-unused data inside the "gangload" area.  When that item is
       loaded on demand (it's not preload anymore), Windows will simply
       read it just as if it had been discarded and needs to be reloaded
       off the disk.

         Similarly, if you make a segment PRELOAD that used to be LOADONCALL,
       NewView WILL *NOT* alter the "gangload" area's size to include this
       segment, it will NOT reorder the positions of segments in the file
       to make such an adjustment easy to do, either.

         If your "fastload" setting is 0,0 then these issues are irrelevant
       to your program.  If your "fastload" settings are non-zero, then
       changing segment PRELOAD settings may cause Windows to either read
       more data into a fastload temporary buffer than it needs to, or
       read data from the disk that isn't part of the fastload.  It's this
       second case that concerns me.  I HAVE NO IDEA what will happen inside
       the loader when some PRELOAD segment is outside the fastload area.

         I would SPECULATE that it makes NO DIFFERENCE, and Windows will just
       go out and read the disk.  BUT, I DON'T KNOW FOR SURE.  It may cause
       Windows to discard the entire fastload buffer at that point, or it
       may cause Windows to try and use data that doesn't exist (although I
       doubt it, because it's easy to test that a segment is outside the
       range of the fastload area).  One other observation that suggests
       accessing information outside the fastload area will not be a problem
       is something I noticed when writing EXECHAIN.  EXECHAIN DOES adjust
       the size and location of the "fastload" or "gangload" area when needed.

         During my debugging of that code, I noticed that TLINK might leave
       the last segment's relocation records outside the "fastload" buffer's
       length value.  That means Windows has the segment's data loaded, but
       must go read the relocation records from the disk.  Yet, since it's
       the LAST segment to preload, I can't say what would happen if it
       was not, and other preloaded data followed it.  OTOH, before Matt
       Pietrek suggested that EXECHAIN needed to update the "fastload"
       values, EXECHAIN seemed to work anyway.

        SO, I really don't know what problems the "fastload" areas might
       encounter after changing the PRELOAD values for segments.


       ONE OTHER ISSUE TO BE AWARE OF WITH FIXED vs MOVEABLE SEGMENT CHANGES:

         The Windows 3.0 REAL MODE configuration requires many more entries
       in an executable's ENTRY TABLE.  Under Windows 3.1, the difference
       between MOVEABLE and FIXED formats in the ENTRY TABLE is not important
       and some linkers even force all ENTRY TABLE items to use the FIXED
       format (which is shorter) reguardless of the segment's actual setting.

         If your program needs to run under Windows 3.0 REAL MODE, beware
       that NewView does NOT adjust the format of ENTRY TABLE items when you
       alter the FIXED/MOVEABLE settings for a segment.  Under Windows 3.1
       it doesn't matter.  But under Windows 3.0 REAL MODE, I have no idea
       what will happen... other than your program is likely to crash sooner
       or later....


      THE BOTTOM LINE: My command will work, the results you create may not!


      SO, BE SURE you know what you're doing, and I would recommend copying
      the original file BEFORE changing the segment settings because there's
      NO automatic support for restoring previous settings!!


      Frank E. Haggar


