windows-nt/Source/XPSP1/NT/admin/netui/shell/doc/winprof.rvw
2020-09-26 16:20:57 +08:00

89 lines
3.2 KiB
Plaintext

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.