Title of Presentation Mark Hammond SkippiNet Australia

1
(No Transcript)
2
Title of PresentationMark HammondSkippi-Net
Australia
3
PDC Messages - How does your talk relate to these?

• NT5 Empower your current app with Windows NT 5.0
  to increase robustness and lower TCO
• Directory, Security, Management, Networking,
  Mobile, Multi Media
• DNA Build N-Tier apps using Windows NT 5.0 as
  your application server
• Presentation DHTMLScriptContrl, XML
• Middle Tier IIS, ASP, COM, MSMQ
• Data ADO, OLE DB, ODBC, XML
• NT5 Sys Services supporting the above

4
Active Debugging

• A study of a sample Active Scripting Language
  with Debugging support.

5
Talk Guidelines

• Sample Code in external File - Large Fonts
• \\starling\events\98pdc\sample_code\Session_Number
  \EmailName
• Tell them what you will tell them
• Tell them / show them with code demos
• Tell them what you told them
• Tell them what they should DO!
• Call To Action Slide at the end
• How does it relate to the PDC Objectives?

6
Engage in the PDC

• Create / Confirm your Talk Titles
• Action Oriented, Building, Using...
• Tie your talk into the PDC themes
• Create / Confirm your Talk Abstracts
• Sell your talk - what are the benefits?
• Make the logistical arrangements
• Hotel, travel, coaching, demo release forms
• Attend the Exec review with a finished talk
• Submit your talk to \\ShowsRUS - ASAP
• Participate in Ask the Experts / HOT

7
Killer Demo

• Mixed language debugging demo.
• Quite short - paying particular attention to the
  multiple languages in the call stack.
• Particular attention to Forth - indicate this is
  what we are talking about (ie, we have the full
  sources!)

8
Overview

• Part I
• Introduction to the ForthScript sample.
• Part II
• Discuss key Active Debugging concepts.
• Understand the implementation of these concepts
  in the ForthScript sample.
• Part III
• Discuss these concepts beyond the ForthScript
  sample.

9
Part IIntroduction to the ForthScript sample
10
What is ForthScript

• A Sample Program which implements an Active
  Scripting language based heavily on Forth.
• Written completely in C
• Makes heavy use of ATL and STL.
• Written specifically to be a sample
• Readability always favoured over speed.
• Structured to highlight AXScript and AXDebug
  support

11
So what is Forth?

• A stack based, reverse polish language.
• Similar to those HP calculators that dont have
  an button
• Eg, to add 2 numbers together in Forth
• 2 2
• The code above pushes 2 on the stack, pushes
  another 2 on the stack, and the operator
  pops the top 2 items from the stack, and pushes
  the result.

12
Why Forth?

• Very simple to implement
• Interpreter wont get in the way of the Active
  Scripting and Debugging code.
• Core Interpreter around 800 lines of C code.
• No parser needed, as there are no complex
  expressions.
• No need for this to be a viable language
• This language does not attempt to be everything
  needed for real use.

13
Sample Code Structure

• Main Directory contains the core Forth
  Interpreter.
• No Active Scripting or Debugging knowledge.
• Implemented as a family of COM objects.
• AXscript directory contains Active Scripting
  support without Active Debugging.
• AXdebug directory extends the Active Scripting
  implementation to be Active Debugging aware.

14
Active Scripting Support

• Based heavily on the axwrapper Microsoft
  sample.
• Much of this code will look familiar if you have
  seen this sample.
• Crucially, a fully implemented language now comes
  with the sample!
• Most of the hard code is handling events from
  the named objects provided by the Active
  Scripting host.
• Not specific to this sample - just clone it!

15
Active Debugging Support

• Completely new code
• But I still attempted to keep the flavour of the
  Active Scripting support.
• Nothing inherently difficult
• Working out the relationships between all the
  objects is the hardest.

16
Concessions to Active Debugging

• Changes made specifically because we were
  developing an Active Debugging Engine
• Uses COM from the ground up
• Interpreter, CodeBlock (ie module), Token etc
  all have COM interfaces.
• C virtuals were added that would not be
  necessary without Debugging
• (eg, OnProcessSourceCodeBlock,
  OnSourceCodeBlockDone, etc)

17
Part IIActive Debugging Concepts
18
Smart vs. Simple Hosts

• Smart Hosts are Active Debugging aware
• Know how to build a logical document model for
  the user.
• Script Engines have a much easier time, as the
  host does much more work.
• Simple Hosts are not Debugging aware
• Language Engine takes up the slack, providing the
  necessary abstractions.
• Life would be so much easier if all hosts where
  smart.

19
Initialization CodeSimple Hosts

• Determine if the host is smart or simple
• QI the ActiveScriptSite for ActiveScriptSiteDebug
• Failure means simple host.
• Simple Hosts require extra work
• Create a default application object.
• Create a debugger node.
• Add source code blocks
• Xref DForthScriptEngine.cpp, CDebuggableForthScri
  ptEngineAddToScript

20
Initialization Code (cont.)Smart Hosts

• Smart Hosts
• All work already done by the host.
• We simply remember the IActiveScriptSiteDebug
  interface for later use.
• Xref DForthScriptEngine.cpp, CDebuggableForthScri
  ptEngineAddToScript

21
Debug Documents(1 of 3)

• A family of IDebugDocument interfaces that
  abstract a debuggable document.
• Split into multiple interfaces to allow
  separation of instantiation from content.
• Smart Hosts provide most document interfaces, but
  delegate some back to the engine. This allows
  Smart Hosts to define document hierarchy.
• Simple Hosts provide the lot. This means the
  document hierarchy may not be optimal.

22
Debug Documents(2 of 3)

• Smart Hosts use a context cookie to map
  arbitrary source code blocks
• DWORD dwSourceContextCookie is passed by the
  debugger with all code
• Later this context is used to get a CodeContext
  object for the previously added code
• Xref DForthScriptEngine.cpp, CDebuggableForthScri
  ptEngineEnumCodeContextsOfPosition

23
Debug Documents(3 of 3)

• Simple Hosts use their document interface
• As the simple host provides all IDebugDocument
  interfaces, CodeContext interfaces are provided
  directly.
• Xref DebugSourceCodeBlock.cpp,
  CDebuggableSourceCodeBlockEnumCodeContextsOfPosi
  tion

24
IDebugDocumentContext(1 of 2)

• Conceptually a range of text in the debuggable
  document.
• Normally not an arbitary range - one statement.
• The debugger passes a character range, and is
  returned a DebugDocumentContext
• Debugger passes the complete range of the text
  currently selected in the debugger.
• Engine can choose to only use the portion it
  needs.

25
IDebugDocumentContext(2 of 2)

• Engine should return the first debug document
  context in the selection
• Debugger will then query the DebugDocumentContext
  for its real size, to obtain the correct size.
• Xref DebugSourceCodeBlock.cpp,
  DebuggableSourceCodeBlockGetContextOfPosition
• DebugDocumentContext then is queried for the
  DebugCodeContext objects it contains.

26
IDebugCodeContext(1 of 2)

• The smallest debuggable unit in a program.
• Typically one per DocumentContext
• This is true for ForthScript
• Notable exceptions would be include/import
  statements in C, etc.
• Breakpoints and stepping etc all occur at this
  level.

27
IDebugCodeContext(2 of 2)

• ForthScript implements both interfaces on the
  same object.
• Implemented on my Token object, as this is the
  executable item in ForthScript.
• Xref DebugToken.h, DebugToken.cpp
• BEGIN_COM_MAP(CDebugToken) COM_INTERFACE_ENTRY(I
  DebugDocumentContext) COM_INTERFACE_ENTRY(IDebug
  CodeContext)
• Again, note IDebugDocumentContext only provided
  for Simple Hosts.

28
BreakPointsBehind the scenes of a breakpoint

• IDebugDocumentInfoGetContextOfPosition provides
  a DebugDocumentContext.
• IDebugDocumentContextEnumCodeContexts returns a
  list of ICodeContexts
• Typically exactly one IDebugCodeContext objects
• ICodeContextSetBreakpoint called for the
  CodeContexts.
• Code runs as normal

29
Breakpoints(cont.)

• Engine itself must detect the break-point being
  hit.
• Engine calls back IDebugApplicationHandleBreakPo
  int
• Debugger interacts with user, and returns the
  resume action (eg, step in, step over
• Engine honours resume action, and if necessary
  repeats the above.
• Eg, if step-into, Engine calls HandleBreakPoint
  again at next opportunity

30
StackFrameDescriptor

• StackFrameDescriptor is a simple C structure
• Engine provides an enumerator for them.
• Only called when an engine (not necessarily this
  engine) is at a breakpoint.
• Provides
• IDebugStackFrame object.
• Physical address of the stack frame - used for
  sorting stack entries.
• Generic IUnknown to help with reference count
  management.

31
IDebugStackFrame(1 of 2)

• Encapsulates engine state at one stack frame.
  Provides
• Name of the language being debugged
• Typically static - eg, ForthScript
• The IDebugApplicationThread
• Previously provided by the Host, so only requires
  remembering it

32
IDebugStackFrame(2 of 2)

• Stack frames provide (cont.)
• The IDebugCodeContext for the stack frame
• As described in previous slides.
• Asynchronous Expression Evaluation interfaces
• Only IDebugExpression provided by Forth.
• Xref DebugStackFrame.cpp, DebugStackFrame.h

33
IDebugExpression(1 of 2)

• Used to parse and execute arbitrary code
• ie, code entered in the Command Window while at
  a breakpoint.
• Should understand the context at the stack frame
  - eg, local and global variables.
• Forth has no concept of locals or globals, so
  this is quite trivial.
• XrefDebugExpression.cpp, DebugExpression.h
• Provided by the IDebugStackFrame.

34
IDebugExpression(2 of 2)

• Interface assumes asynch evaluation
• Allows debugger to remain responsive during
  expensive evaluations
• ForthScript only supports synchronous, making for
  a trivial implementation.
• Allows for result to be returned as a string, or
  an IDebugProperty interface.
• IDebugProperty allows for much richer
  representation of results - eg, arrays or
  structures.
• ForthScript only supports strings

35
Walkthough of a debug session

• Host requests the language ForthScript by
  issuing a CoCreateInstance(CLSID_ForthScript)
• Engine fires up as a normal COM object.
  (COleScript.cpp, DOleScript.cpp)
• Host calls SetScriptSite(IActiveScriptSite) to
  let the engine know about its context
• Engine does a QI(IID_IActiveScriptSiteDebug ) on
  the provided site.
• (more)

36
END OF TALK

• What follows are additional slides which may
  assist you when perusing the ForthScript sample.

37
IDebugDocumentInfo objects

• The entry point for static details about the
  code.
• Provides the name, filename, URL, size, etc.
• Maps between character offsets and line numbers
• Debugger remembers and assumes nothing!
• Maps between a range of text, and
  DebugDocumentContext objects.

38
Summary
39
(No Transcript)