Readme.txt for WinScope Version 1.20

This file has information about changes to WinScope since the manual
was printed. Some of the changes are reflected in the online help,
including new and changed error messages, dialogs, and WINSCOPE.INI
settings. In case of differences, this file should be considered to
be correct, followed by the online help, and finally the manual.


COMMON TECHNICAL SUPPORT QUESTIONS
----------------------------------

Q. What do I need to do to capture API calls?

A. First you need to select the API calls of interest using the API
list. Then select the modules that will be calling these APIs.  You
can think of the selection as being *from* the module list *to* the
API list. If you're not sure which modules are involved, choose all
modules plus all new modules (see below). Finally, you'll need to do
one of the following -- select the windows involved or check the
'Collect APIs outside of Wnd Procs' checkbox in the
Options|Preferences dialog.

Q. What do I need to do to capture messages?  

A. Messages require one or more windows and one or more messages. 
Select the desired items from the window and message lists and start
WinScope's trace.

Q. How do I watch all windows, including windows that don't yet exist?

A. WinScope has a very flexible capturing engine that lets you select
just the windows you want to be used in a trace.  You can select
individual windows by clicking on the appropriate lines. You can use
the All button to select all *existing* windows, but to select
not-yet-created windows, use the New button to activate the New
Window dialog. Then enter the not-yet-created windows you want. For
all windows, enter an asterisk in the edit field. 

Q. How do I watch all modules, including ones that aren't yet loaded?

A. WinScope has a very flexible capturing engine that lets you select
just the modules you want to be used in a trace.  You can select
individual modules by clicking on the appropriate lines. You can use
the All button to select all *existing* modules, but to select
not-yet-loaded modules, use the New button to activate the New Module
dialog. Then enter the names of the modules you want. For all
modules, enter an asterisk in the edit field. 


NEW FILES
---------

There are quite a few new files on the disk in this release, so we've
restructured things a bit. The files used to generate the Bugspray
demo program are now in BUGSPRAY.ZIP. All the source scripts and some
of the lesser-used compiled scripts are in SCRIPTS.ZIP. All of the 
source files related to WinScope's external control and event
capturing are in WSMISC.ZIP. 

Other changes include the addition of a user-extendable DLL
(WSMISC.DLL), a driver to capture APIs accessed via GetProcAddress
(WSSYS.DRV), more commonly used scripts (COMBOLBX, MMSYSTEM, REGMSGS,
and USERMSGS).

For information on any of these files, please the the file
PACKING.LST.


SCRIPT CHANGES AND ADDITIONS
----------------------------
 
We've added quite a few scripts to WinScope, giving it the ability to
capture more APIs and messages than any other product on the market.
Please see the file PACKING.LST for the full list of all the source
(.scr) and compiled scripts (.wsc) available. In addition to these
scripts, we've posted others on our BBS and on CompuServe (Go
Periscope). If there's a script you need, please let us know!

The enumc, enum, enuml, benumc, benum, and benuml types are now
supported. Please see the description of the trace display changes
for more information.

The script compiler now supports four additional data types.  They
are:

message		2 byte windows message number
float		4 byte floating point number
double		8 byte floating point number
longdouble	10 byte floating point number

The message data type is used to show the name of the Windows message
in the trace window.  The formatting of the floating point numbers is
handled in WSMISC.DLL, which is also used for user-accesible
functions in WinScope. The make, source, def, and executable for
WSMISC.DLL are contained in the file WSMISC.ZIP. 

The script compiler now accepts characters commonly generated by C++
compilers in their mangled names, including '@', '$', '!', '&', etc.

The script compiler now accepts embedded spaces in a CLASS name when
the name is enclosed in single quotes. 

If you're writing your own scripts, please note that a declaration of
char[4] shows 'abcd' and BYTE[4] shows the data as hex characters
separated by commas.

You can use '_cdecl' in a script.  The manual indicates that you can
manually reverse the arguments, but it doesn't say that if you use
_cdecl, we'll do it for you. When used, the script should show the
arguments left to right. (The trace will show them right to left.)
For example, '_cdecl _DebugOutput(UINT flags, LPCSTR lpszFmt)' shows
the string then the flags in the trace window.

You can cause the CPU registers to be captured for API calls by
adding the 'REG16' keyword after the 'ITEM' and before the ordinal.
This is used by Dos3Call, InitTask, NoHookDOSCall, NetBiosCall, and
hardware_event.  For example, Dos3Call is shown in kernel.scr as
'ITEM REG16 102	void Dos3Call(void);'.

Large arrays may need to be broken up to be correctly displayed in
the Parameter window since the maximum width of the window is 512
characters. For example, an array of 128 BYTES would overflow the
window. It would require space for the array name plus four
characters per array element (each BYTE is displayed as two hex
characters, a comma, and a space).


MESSAGE CAPTURING
-----------------

WinScope's message capturing has been enhanced. Previously, WM_USER
messages were qualified by a specific class. Now, you can capture
WM_USER messages (0x0400-0x7fff) regardless of the class. Please see
the file USERMSGS.SCR in SCRIPTS.ZIP for the script used to generate
USERMSGS.WSC.

You can now capture reserved messages too. These messages are in the
range from 0x8000 to 0xbfff. To capture them, copy USERMSGS.SCR to
RSVDMSGS.SCR, change the class from USERMSGS to RSVDMSGS, add
messages in the range 0x8000 to 0xbfff, and compile the script.

We're still not done! You can capture registered messages (aka Atoms)
which are in the range 0xc000 to 0xffff too. Unlike other messages,
the 'ordinal number' is not used, but it still must be unique for the
script compiler to function correctly. For registered messages, the
match is made on the name (which is *not* case sensitive), instead of
the ordinal number.  To minimize the chance for confusion, we suggest
that you start your ordinal numbers at 0xc000. See the file
REGMSGS.SCR in SCRIPTS.ZIP for some examples.

You can also capture messages for which you don't have a script.
Please see the description of the WINSCOPE.INI variables AllMsgs and
AllRegMsgs.


API CAPTURING
-------------

We've added many more API scripts to WinScope, including support for 
system drivers (DISPLAY, HPPCL, MSNET, and SOUND), multimedia
(MMSYSTEM), Telephony API (TAPI and ATSP), ODBC, MAPI, and more.
Please see the file PACKING.LST for a list of all .SCR and .WSC files
available. Also, check our BBS and CompuServe forum for the latest
additions, such as OLE2, VIM, and WINSOCK.

WinScope can capture APIs of programs created without explicit
imported ordinals. Previous versions of WinScope could not capture
API calls in programs which did not input the API by its ordinal
value.  WinScope now captures these API calls as long as the API name
in the script matches the name in the executable file (the match is
not case sensitive).

WinScope now supports the capture of APIs that are accessed directly
after GetProcAddress is used to get their address. These APIs are
usually used by system drivers (.drv) such as video, printer, sound,
etc., but can be used by any program.

If you're installing a new version of WinScope, Setup will modify
SYSTEM.INI for you. If you're updating from a previous version,
you'll need to follow the steps below if you want to capture APIs
that are accessed via GetProcAddress.

a) Edit the [boot] section of SYSTEM.INI.

b) If you are using Adobe Type Manager, it will have already set
'system.drv=atmsys.drv' and 'atm.system.drv=system.drv'. You should
leave the first entry alone, change the second entry to point to
wssys.drv, and add a third entry to point to system.drv. The result
would be:

system.drv=atmsys.drv
atm.system.drv=c:\winscope\wssys.drv
ws.system.drv=system.drv

If you put wssys.drv in front of atmsys.drv, you *must* skip the
capturing of GDI functions by using 'GDI=*' in the '[wssys skip]'
section.

c) If you are not using Adobe Type Manager, change
'system.drv=system.drv' to 'ws.system.drv=system.drv' and add a new
line that reads 'system.drv=c:\winscope\wssys.drv'.

d) Optional: Add a new section named '[wssys]' with the following
entries (the values can be from 1 to 64K decimal):

JumpTableSize=16
StringTableSize=16

e) Optional: Add a new section named '[wssys skip]' to skip capturing
specified modules or functions. The format of each entry is one of
the following:

<modulename>=<apiname>,<ordinal>[,...]
<modulename>=*

In the first entry type, the module name is eight characters or less
and the apiname to be skipped is followed by a comma and the
corresponding ordinal number. In the second entry type, all functions
in the module are skipped. The line length must be 127 characters or
less.

For example, you could use:

'pointer=*' to skip all functions in the module pointer or
'pointer=CursorFeatureFilter,11,MouseFilterFunc,12' to skip two 
specific functions.

f) Restart Windows.

g) If you are using the 'Skip-To' feature of the Microsoft mouse
driver, you'll need to skip the capturing of all Pointer functions by
using 'Pointer=*' in the '[wssys skip]' section.

h) If you experience problems, please add a line of the form
'RecordOnly=1' to the [wssys] section of system.ini, restart Windows,
run the program SYSTEST.EXE (its in WSMISC.ZIP in the WinScope
directory), and send the WSSYS.DMP file to Periscope Tech Support.

Remember that API capturing requires that you select the module from
which the API is called. For APIs in .drv files, this usually means
selecting GDI and/or USER. Also, be sure the Options|Preference item
'Collect APIs outside of Wnd Procs' is checked.

Given the huge number of APIs capture by WinScope, you may need to be
aware of duplicate function names, such as in:

- BitBlt and others in GDI, HPPCL, HPPCL5A, DISPLAY, and other output devices
- Disable and Enable in lots of places
- LB_xxx in Combolbox and Listbox
- WNetxxx in MSNET and USER


EXCEPTION INTERRUPTS AND STACK TRACE CAPTURING
----------------------------------------------

WinScope now supports the capturing of exception interrupts. These
interrupts occur for a variety of reasons; capturing them in the
context of WinScope's trace can be very useful when trying to debug
an errant program. You can capture any or all of the following
interrupts:

0 - Divide by zero
1 - Single step (normally used by debuggers)
3 - Code breakpoint (normally used by debuggers)
6 - Illegal instruction
0x0c - Stack fault
0x0d - General protection fault
0x0e - Page fault

Also, you can direct WinScope to stop capturing information and/or
create a stack trace when an exception interrupt occurs. A stack
trace may also be written to WinScope's trace buffer when one of the
following toolhelp notifications occurs: RIP, LogError, or
LogParamError. Please see the description of the stack trace in the
Trace Buffer section of this document.


PSVXD.386 -- THE WINSCOPE DEVICE DRIVER
---------------------------------------

The device driver will now prompt you if it should install itself if
you add the line 'PsInquire' to the [386Enh] section of SYSTEM.INI.

WinScope's VxD has been enhanced to help WinScope capture more
information from other VxD's or DOS programs that you are running.
Using this new facility, you can capture the execution of virtual-86
mode (V86) interrupts and the corresponding register values in
WinScope's trace.  To capture an interrupt, add one or more lines of
the form 'pshookv86intxx' to the '[386Enh]' section of system.ini
where xx is the hex interrupt number from 00 to ff. The best place to
add these is just after the 'device=c:\winscope\psvxd.386' line.

If you add some code to your Vxd or DOS program, you can save
customized messages and/or register values in WinScope's trace. For
more information on this topic, please see the files TESTVXD.ASM and
TESTTSR.ASM in WSMISC.ZIP.

When the above methods are used to capture information for WinScope,
psvxd must buffer information locally until WinScope is able to poll 
the VxD for it. The size of the buffer defaults to 16KB. It can be
set to a minimum size of 4KB and a maximum size of 64KB, using the
statement 'PSBufferSize=nn' in the '[386Enh]' section of SYSTEM.INI.
The frequency of the polling by WinScope is controlled by the
WINSCOPE.INI variable PageDelay. If you see missed entries in the
trace buffer, try increasing the buffer size and/or decreasing the
polling interval.


WSMISC.DLL -- THE WINSCOPE MISCELLANEOUS DLL
--------------------------------------------

WSMISC.DLL is a new user-extendable DLL that is used as both a
service provider for WinScope and as a gateway for external processes
to both control WinScope and add information to its trace buffer. The
source and make files for WSMISC.DLL and some sample programs are in
the file WSMISC.ZIP. 

The current service provider functions include the formatting of the
floating-point numbers now available in the scripts (float, double,
and long double), plus a variety of notification functions. WinScope
calls WSMISC at various times so that user-written code may add 
information to WinScope's trace and/or control WinScope's operation.

WinScope calls functions in WSMISC when the following events occur:
start trace, stop trace, breakpoints, exception interrupts, toolhelp
notifications, stack trace, and for each stack frame within a stack
trace. All of the events are notifications that give you the
opportunity to add some information to WinScope's trace. For example,
when the trace is started or stopped, you could add specific system
information to WinScope's trace. The breakpoint notification also
returns a BOOL, allowing you to qualify the breakpoint with
user-written code.  Please see WSMISC.C for more information on the
WSNotify functions.

From the outside, WinScope can be controlled by another Windows
program (from an EXE, DLL, or DRV). (See the sample program WSTALK.C
for details on this interface or try running the WSTALK.EXE program.)
Also, other programs can add information to WinScope's trace buffer.
A Windows application can write arbitrary strings and/or processor
register information to the trace -- think of this as a way to get
your program's print statements into WinScope's trace, where you can
see everything that's happening in chronological order. A Win app can
also cause stack traces to be saved in WinScope's trace as desired
(no faults needed!).

Windows device drivers (VxDs or DRVs) can also write strings and/or
register information to WinScope's trace, as can DOS programs,
including TSRs, device drivers, and standard DOS applications. See
the sample programs TESTVXD.ASM and TESTTSR.ASM for details on this
interface.  Also, see the section on PSVXD.386 for information on the
V86 mode interrupts that can be captured by PSVXD.386.

The new event types that can be added to WinScope's trace include:
text only, interrupt start, interrupt return, and a stack trace.
Each event type can have no registers, 16-bit registers, or 32-bit
registers.


TRACE BUFFER CRASH RECOVERY
---------------------------

WinScope's trace buffer now survives crashes better. If you are
capturing a trace using page to disk (now the default) when the
system crashes, you can in most cases recover the file after a
reboot. When WinScope restarts, if it sees its temporary trace file
(WS$WS$WS.TRC) left over from a previous session, the file is renamed
to a unique name of the form WS$nnnnn.TRC, where nnnnn is a
five-digit number that is one higher than the last WS$nnnnn.TRC file
found in the WinScope directory.  A dialog is displayed to let you
know that this has happened.

To display the trace, just use the File|Open dialog as you normally
would. Unless the trace file contains just the header information and
no data (usually a file size of less than 1000 bytes, depending on
how many scripts you use), you should see the trace information. Note
that the INI variable PageDelay controls the maximum time between
trace file writes. You can set this variable to -1 to force a disk
write after every trace entry, but this can cause performance
problems.  A more practical value for PageDelay is 200, which causes
a disk write every 200 milliseconds. The smaller you set this value,
the closer to the edge of the cliff you can capture, but you do this
at the expense of writing to the disk more frequently.

Another way of capturing information up to a crash is outputting the
trace at runtime to a monochrome screen or out a serial link to
another PC.


TRACE BUFFER CHANGES
--------------------

The trace buffer display has had numerous improvements, including the
following:

We've added support for benum, benumc, benuml, enum, enumc, and
enuml in both the trace and far parameter displays when the detail
level is set to high.  The decoded name(s) are shown after the
parameter value in parentheses. For enums, only one string is shown
if and only if there is an exact match. For benums, zero to n strings
are shown, each separated by plus signs. This can make your trace
much more readable, by showing you names you're familiar with instead
of showing just the 'magic' numbers.

BOOLs are displayed as TRUE or FALSE when the detail level is set
to high. This applies to any item whose name ends in BOOL, such as
cBOOL, dBOOL, etc that has a size of byte, word, or double word.

Messages are also decoded by name when the detail level is set to
high. There's one exception -- message number 0 (WM_NULL) is not
decoded since it adds too much noise to the trace buffer.

When the detail level is set to medium, the (b)enum, BOOL, and
message decoding are turned off, but the full parameter names are
still shown.  The new medium detail level works like the previous
high detail level.

The calling address shown in API calls and toolhelp notifications has
been changed to show the module name and the logical segment and
offset instead of the previous absolute selector and offset. For 
example, a call by Terminal to an API is shown as '@TERMINAL
0009:03DF'.

If an API is accessed via GetProcAddress, '@@' is shown before the
caller's address instead of '@' to indicate access via
GetProcAddress().

The parameter window now supports nested structures. For example, the
'pt' structure referenced in lpmsgstruc by GetMessage() displays
'pt.' on one line, followed by 'x=nnnn', and 'y=nnnn', each on a 
separate line and indented by two spaces to indicate that they are
elements of the structure 'pt'.

The toolhelp messages have been modified to present more information.
All toolhelp messages that show the calling address now show the
module name and the logical segment instead of the absolute selector.
Also, the LogParamError notification now shows the error message
text, even when you're not using the debug version of Windows.  The
changes to the toolhelp message formats are:

Load Segment    Loading <Code|Data> Segment: <Selector> (instance <Number>) in
        	<ModuleName> logical segment <Segment> for <TaskName>:<hTask>

LogError	Error: <ErrorCode> <Description> Additional Info: <address>

LogParamError	Parameter Error: <ErrorCode> <Description> <ErrorValue> @CS:IP

WinScope can now capture external events in its trace. This feature allows
a variety of programs to add information about their state to WinScope's
trace so that you can better debug the complex interactions of programs
running in a Windows environment. The types of programs and information
supported are:

- Windows applications, Windows device drivers, and DOS programs can
add text strings to WinScope's trace to indicate their state. These
entries can be text only, or may include 16- or 32-bit register
values.

- Windows applications can save a stack trace at any time while running.
This can help you understand how your program got where it did.

- Windows device drivers and DOS programs can add interrupt and
interrupt return events to the trace buffer. These entries may
contain 16- or 32-bit register values.

A stack trace is saved in the trace buffer as one stack trace event,
followed by one or more stack frames. The format of a stack trace is:

  Stack Trace  Task: xxxxxxxx:nnnn  *** <description>
  Stack Frame n   <module>   @nnnn:nnnn  CS=nnnn  SS:BP=nnnn:nnnn  FAR|NEAR

External events added to WinScope's trace are preceded by three
asterisks (***) to make it obvious that they are not coming from
WinScope. Any text sent by the calling program is displayed after the
asterisks. If 16- or 32-bit register information was included, it is
displayed in the Parameter window.

We've added register support for Dos3Call() and other functions (see
the description of the REG16 keyword for more information).  When one
of these APIs is selected, the 16-bit CPU registers are displayed
(always in hex) in the parameter window. The only item missing is the
state of the CPU flags on entry to an API; they are displayed as
'????' since their value is not known. The value of the flags on
return from an API call is captured, however.

There's a new trace buffer event that indicates WinScope missed one
or more events intended for it. This item is displayed as 'Missed
event count: xxx'. This situation can occur when incoming events
overflow a special holding buffer used to store events while Windows
is in an unstable state, such as during toolhelp notifications and
when events are being captured by PSVXD.386. If you see this in a
trace, try one or more of the following: 

- increase the size of the toolhelp buffer (modify the INI variable
ToolhelpSize)

- increase the size of the VxD buffer (modify the SYSTEM.INI variable
PSBufferSize)

- decrease the timing interval (modify the INI variable PageDelay)

Any string characters with ASCII values below 32 are converted to a
period ('.') so they won't cause problems when saved to a file or
printed.

If you use the AllMsgs and/or AllRegMsgs settings in WINSCOPE.INI to
capture messages not in a script, the messages are saved in the trace
buffer as follows:

*** hwnd '<class>' wMsg=nnnn (<messagename>), wParam=nnnn, lParam=nnnn:nnnn

where hwnd is the window handle, <class> is the class name, and
<messagename> is the message name (displayed for registered messages
only). Please note that these events are preceded by three asterisks
(they are considered external events) and the message returns are
not captured.


NEW AND CHANGED ITEMS IN WINSCOPE.INI
-------------------------------------

The default trace buffer type is now page to disk, instead of
circular (BufferType=2).

The default setting of the 'Collect APIs outside of Wnd Procs'
checkbox in the Options|Preferences dialog is now checked
(AllApis=1).

The default setting of the 'Detail Level' in the Options|Trace
Options dialog is now 'High' (DetailLevel=2). Note that the previous
'High' corresponded to 1.

New INI variables in the [General] section include: DbgKey, MaxNest,
and PreAllocate.  New INI variables in the [Trace Options] section
include:  AllMsgs, AllRegMsgs, ApisInDataSeg, ExceptionInts,
ExceptionIntStop, ExternalEvents, NotifyEvents, OmitColon,
RunTimeDetail, StackTrace, ToolhelpSize, ToolhelpStackTrace, WSDebug,
and WSSysDrv. The [Print] and [SaveAsText] sections have a new
SaveTrees variable. For information on these items, please see the
online help.


PROJECT DIRECTORY
-----------------

If you need to have WinScope run out of a read-only directory or
if you work on different projects with different needs, the project
directory feature of WinScope can help you.

Copy WINSCOPE.INI and the script files you need to a directory of
your choice. Then copy the WinScope icon and modify the copied icon
to add a path name after WINSCOPE.EXE. Finally, double click on the
new icon to execute WinScope and other executable files from the
standard WinScope directory, but use the WINSCOPE.INI and *.WSC files
from the project directory.

You can further tune WinScope by replacing the standard hooks.wsc
with hookz.wsc (compile hooks.scr in scripts.zip) and/or replacing
all the message scripts with msgz.wsc (compile msgz.scr in
scripts.zip). These 'almost-empty' scripts let you minimize noise
from unwanted hooks and/or messages as you desire.


NEW AND CHANGED DIALOGS
-----------------------

The following dialogs are new or changed:

File|Load and File|Quick Load -- new command line field

Options|Trace -- now has three levels of detail

Options|Exception Interrupts -- new dialog to capture exception interrupts

Options|Toolhelp dialog -- new stack trace checkbox

Options|Capture External Events checkmark -- save external events in trace

Window|Iconize -- name changed to Window|Minimize All

For more information on these dialogs, please see the online help.


INSTALLING AND UNINSTALLING WINSCOPE
------------------------------------

The Setup program has changed slightly. There are some new dialogs
that are used to setup the WSSYS.DRV system driver.  Also, if SETUP
modifies SYSTEM.INI, it now prompts you to restart Windows so that
the new WinScope driver(s) (PSVXD.386 and/or WYSYS.DRV) are used by
Windows.

To remove WinScope from your system, follow the instructions in
Chapter 1. If you have installed the file wssys.drv as a replacement
for system.drv, you'll need to edit the [boot] section of system.ini.
If you're using Adobe Type Manager, delete the line
'atm.system.drv=c:\winscope\wssys.drv' and change the line
'ws.system.drv=system.drv' to 'atm.system.drv=system.drv'.
Otherwise, delete the line 'system.drv=c:\winscope\wssys.drv' and
change the line 'ws.system.drv=system.drv' to
'system.drv=system.drv'.


MISCELLANEOUS
-------------

The new and changed errors and warnings are:  Errors 824 and 825, and
Warnings 754, 755, 757, 758, 763, and 908 - 912.  For more
information on these error messages, please see the online help.

We've added a new Window arrangement. Trace 2 shows the Trace and
Parameter Windows in a horizontally tiled arrangement.

WinScope now supports Watcom C 32-bit executables.

WinScope's hotkey support has been implemented in psvxd.386 for
faster response under worst case conditions, such as when a program
doesn't yield for a long period of time. If you don't use the VxD,
you still have the original hotkey support.

This release also has various bug fixes, including the script
compiler, message capturing, working with the mouse snap-to option,
and breakpoint logic.

When using WinScope to watch a program that makes use of the 3-D
effects provided by COMMDLG.DLL (such as Microsoft Access), you'll
find that WinScope disables the 3-D effect. Since WinScope is
capturing all messages to the target program's windows, it subclasses
the windows, substituting WinScope's window procedure for the
original and passing any messages on to the original procedure.  By
so doing, we change the address of the window procedure. Evidently,
something in the common dialog code is checking for a hard-coded
window procedure address and disabling the 3D effect when it doesn't
find the magic value it is looking for. 

The +, -, and * keys used as the shortcut keys for the tree menu
refer to the grey (numeric keypad) keys, not the keys along the top
of the keyboard.

If you use CodeView 4.0x, you'll need to modify the steps in the 
'Using WinScope with CodeView' tutorial on page 30 of the manual.
When 4.0x is used, the Call menu will not show WinMain() after the
breakpoint. Bypass this step, and enter 'G .296' to go directly to
line 296 of BUGSPRAY.C. This Call menu bug has been fixed in CodeView
4.10.

WinScope does not capture all APIs for programs linked with OptLink
version 5.0 when the /WINPACK switch is used. To capture APIs for
your program, link it without the /WINPACK switch.

WinScope now always captures timing information, regardless of the
setting of the checkbox in the Options|Preferences dialog. The time
is displayed only when the checkbox is checked (never during a
running trace).  To avoid confusion, the timing information is not
displayed on Outstring messages in the trace buffer.

The Periscope BBS (404/888-5522) has a WinScope SIG in which we're
posting items of interest to WinScope users, such as scripts that
have been developed by other users. If you've developed any scripts
that you'd like to share with other WinScopers, please attach your
file to an email message to the sysop. We're also on CompuServe, so
you can find all of the same files by logging on to CompuServe and
entering Go Periscope. You can send email to us at 72662,3542.

If you get an exception in WinScope, we'd love to see a Dr. Watson
log so we can fix the problem. Please run Dr. Watson with the
following settings in WIN.INI.

[Dr. Watson]
SkipInfo=tim
ShowInfo=dis err loc mod par
DisLen=32
DisStack=500

For normal running, we use the above, omitting the 'par' argument on
ShowInfo.  WinScope will not receive LogParamError notifications if
Dr. Watson is loaded before WinScope and Dr. Watson is set up to log
parameter errors.  Both programs will receive LogParamError
notifications if Dr. Watson is loaded after WinScope or if you are
using Windows debug kernel.

WinScope now supports Memcheck 3.0. By using a customized error
callback, MemCheck can add its output to WinScope's trace. This
allows you to capture everything about your program in one place,
giving you the best of both worlds!

When using WinScope with trace buffers saved by prior versions of
WinScope, the selector portion of the address shown by some of the
toolhelp notifications will not be adjusted to show the new logical
selector. Also, the 16-bit registers shown for some functions will
not be displayed, since this information was not captured by previous
versions of WinScope.

The timing spike mentioned in the manual when the trace is saved via
page to disk has been eliminated.
