89 lines
3.2 KiB
Plaintext
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.
|