windows-xp/Source/XPSP1/NT/admin/netui/shell/doc/winprof.rvw

Minutes of the WINPROF code review
1/17/91 9-11a
attending:  ANNMC CHUCKC JIMH JONN
Minutes by JONN


-- THE FOLLOWING OBSERVATION IS IMPORTANT TO ALL WINDOWS PROGRAMMERS:

   WinProf and the other modules reviewed frequently allocate objects on the
   stack, then pass these objects by far reference to other procedures.  This
   is dangerous where the called procedure could use Windows APIs or
   lose control to Windows.

   WINDOWS AND THE WINDOWS APIS CAN RELOCATE THE STACK SEGMENT!

   This means that the far pointer passed to the called procedure may be
   invalidated by a Windows call.  Remember that constructors and
   destructors are also called procedures, and that the implicit
   parameter "this" is passed by far reference.

   This occurs in this scenario:
   - Large Model (or where far pointers are used),
   - when objects are allocated on the stack,
   - when pointers to those objects are passed to procedures,
   - when those procedures call Windows APIs or lose control to Windows,
   - and the stack segment is not locked,
   - under Real Mode.

   In particular, BLT dialog objects are often allocated this way.
   Rustan says that he will fix DIALOG_WINDOW::Process() to
   automatically lock the stack segment for the duration of the
   Process() call.  A different approach to fixing the problem could be
   to allocate just a pointer on the stack, then allocate the object
   with New;  heap objects are always locked.


-- These modules, and all Windows modules which must run under Real Mode,
   should be unit-tested under real mode.  If it survives, try again
   while running Shaker.


-- General Windows coding practice:  For every routine, specify whether it
   calls Windows APIs which could potentially move memory.  In
   particular, routines which do not take hParent arguments but which
   can move memory should be clearly marked.  Routines which do not and
   will never call Windows APIs should not take an hParent argument.


-- We should resolve the problem with the two versions of CFGFILE,
   either by upgrading UserProfile to use the new versions, or by
   supporting the old version.  CHUCKC will look into this.


-- CHRISG has observed a speed problem where NetGetDCName is repeated
   when PROFILE::Read fails.  This should be fixed so that PROFILE::Read
   caches an empty profile even when it fails.  Thus, the first
   PROFILE::* call will fail if the profile is inaccessible, but subsequent
   calls will use the (empty) cached profile.


-- Callers of WinNet's MapError should not assume that
   (usNetErr != 0) => (wWnErr != 0).


-- Enable the WNetRestoreConnections bit in WNetGetCaps.  WNRC(0) should
   fail, only WNRC(1) is supported.


-- We should disable WNetAddConnection, ifdef out its code (return
   WN_NOT_SUPPORTED), disable its WNetGetCaps bit.


-- JONN should upgrade to Win31 beta as soon as a semi-stable version is
   available which runs Net APIs.


-- JONN should check:  Does SetNetError also prepare the error text?


-- JONN should file a Sev 4 bug against the use of locked memory for
   the user profile cache in UserProfile under Windows.


-- CHUCKC will look into the possibility of caching the DC name.


-- The pnlsUNCResourceName parameter to PROFILE::Load should be removed
   as it is never used.