B INTERPROCESS COMMUNICATION

This appendix contains the following sections:

COM Interface

Introduction

Using the COM Object Interface
Run-time Environment
Command Line Options
Startup Directory

COM Interfaces
Activating the COM Object
Methods
Implementation Details

Events

Examples
Python Examples
Visual Basic Examples
Word Examples
Excerpt of the MIDL Definition

DDE Server Interface

Introduction

DDE Items and Topics
Packet Format

CrossView Pro DDE Specific Options and Commands
Command Line Options
Commands

Examples
Evaluating an Expression
Reading Target Memory
Writing to Target Memory
Requesting Current File and Line Number
Using CrossView Pro as Pure Server

1 COM Interface

1.1 Introduction

CrossView Pro provides a COM object interface on MS-Windows platforms. The purpose of the COM object interface is to make the command-line interface of the command window available to the outside world. Simultaneously, a callback mechanism is provided which allows the outside world to tap into events that occur within CrossView Pro (for example a breakpoint hit message). This is achieved by a COM connection point interface to which multiple programming languages can connect.

The CrossView Pro COM object can be used in programming languages like Python, Visual C++ or Visual Basic. Applications that are COM clients can also make full use of the CrossView Pro COM object interface. COM is a binary reusable object technology, linked tightly to MS-Windows. COM is closely related to ActiveX and Automation. ActiveX consists of a set of predefined interfaces to be implemented in a COM object and used to create plugable GUI components. Automation is a similar set of predefined COM interfaces, but with a wider range of applications than ActiveX.

1.2 Using the COM Object Interface

1.2.1 Run-Time Environment

The CrossView Pro COM object executes as an out-of-process server. Only one client per instantiated CrossView Pro COM object can connect. Each CrossView Pro executable has a unique identification (so-called UUID or GUID), independent of the version number. This is especially important for Visual Basic which stores the TypeLib UUID. This requires recompilation if the UUID changes across different versions of the same CrossView Pro executable.

1.2.2 Command Line Options

To prevent initialization dialogs at CrossView Pro startup (for example a dialog to specify which CPU type you use), you can use several command-line options which you can specify via the Init() method.

Use the following options instead of startup dialogs:

-tcfg file Specifies a target configuration file which contains, among other things, the GDI module to be loaded among other things. This overrules the filename specified in xvw.ini.

-C cpu Specifies the CPU type.

-D device_type,opt1[,opt2]
Specifies communications parameters such as communication port and baud rate.

-G path Specifies the startup directory for CrossView Pro

-ini Specifies the xvw.ini file.

Section Startup Options

1.2.3 Startup Directory

The startup directory of CrossView Pro determines where the xvw.ini file is written. When CrossView Pro is invoked via its COM interface on MS-Windows, the startup directory is usually C:\WINNT\system32. You can change the location of the xvw.ini file with the -G command line option. This feature is useful when you are using two different CrossView Pro instances simultaneously.

1.3 COM Interfaces

The following interfaces are provided with CrossView Pro:

ICommandLine

Default interface; provides CrossView Pro command interpreter access.

ICommandLineEvents

Connection point; provides the events output stream of CrossView Pro. Works as a callback.

1.3.1 Activating the COM object

Command line options are passed to CrossView Pro via the Init() method. It is necesarry to call the Init() method before you can use the CrossView Pro COM object. CrossView Pro does not start as COM object, until after you have actually called the Init() method. If you do not need to pass any options, invoke Init() with an empty string.

Registering the server

Before you can use the COM object, you must register it in the MS-Windows Registry. Run CrossView Pro from the command line as follows:

Similarly, you can remove the COM object from the Registry:

To avoid the popup message when registering, two more command line options are available that are useful when you use batch files:

1.3.2 Methods

This section lists the methods that are supported by the CrossView Pro COM object's default interface 'ICommandLine'. The data types and return values are expressed as COM base types. For example, BSTR is a wide-character UNICODE string type, which is the same type as Visual Basic strings.

Init()

void Init(BSTR CommandlineOptions)

Passes command line options to the CrossView Pro COM. It is necesarry to call the Init() method before you can use the CrossView Pro COM object. If you do not need to pass any options, invoke Init() with an empty string.

CommandlineOptions
The string with the command line options. The options are written as on a regular command line.

The list of supported command-line options can be found in the CrossView Pro User Manual.

See Section Startup Options for a complete overview of all available command line options.

Execute

BOOLEAN Execute(BSTR Command, long SequenceNumber,
BSTR *Result)

Passes a command to CrossView Pro, executes it and returns TRUE or FALSE after the command has been executed.

Command The command to be executed by CrossView Pro.

SequenceNumber
A number that is unique for each command. You can use this number to distinguish the output in the events stream. If you do not use this, specify a value of 0.

Result The textual output of the command window, encapsulated in an annotated format. See CmdAnnotatedOutput in section Events for the format description. Specify NULL if you do not want any output.

Returns: TRUE on success, FALSE on error.

ExecuteNoWait

BOOLEAN ExecuteNoWait(BSTR Command,
long SequenceNumber)

Queues a command for execution and returns TRUE of FALSE after the command has been passed but before it is executed.

Command The command to be executed by CrossView Pro.

SequenceNumber
A number that is unique for each command. You can use this number to distinguish the output in the events stream. If you do not use this, specify a value of 0.

Returns: TRUE if the command is successfully passed, FALSE on error.

Halt

void Halt(void)

Halts the execution of the current command.

1.3.3 Implementation Details

A multi-threading (MTA) type of appartment is used with a free-threading model, for example, ThreadModel=Free. However, each CLSID can have its own distinct ThreadingModel. Only one client can connect to a COM object instance of CrossView Pro. Each next CoCreateInstance() will result in a new CrossView Pro COM object instance being created.

Be aware that DLLs are not supposed to call CoInitialize themselves. Once the concurrency model for a thread is set, it cannot be changed. A call to CoInitialize on an apartment that was previously initialized as multithreaded will fail and return RPC E CHANGED MODE.

Typically, the COM library is initialized on a thread only once. Subsequent calls to CoInitialize or CoInitializeEx on the same thread will succeed, as long as they do not attempt to change the concurrency model, but will return S FALSE. To close the COM library gracefully, each successful call to CoInitialize or CoInitializeEx, including those that return S FALSE, must be balanced by a corresponding call to CoUninitialize. However, the first thread in the application that calls CoInitialize(0) or CoInitializeEx(COINIT APARTMENTTHREADED) must be the last thread to call CoUninitialize(). If the call sequence is not in this order, then subsequent calls to CoInitialize on the STA will fail and the application will not work.

Because there is no way to control the order in which in-process servers are loaded or unloaded, it is not safe to call CoInitialize, CoInitializeEx, or CoUninitialize from the DllMain function.

So, take care when establishing more CLSIDs in a GDI module.

1.4 Events

CrossView Pro provides an events source, into which a client can tap via a COM connection point. Examples of events are "reporting which breakpoint has been hit" and "symbols have been loaded". Currently the following events are defined. Each event is terminated by a newline character. Prepare your client for new events, basically by ignoring unrecognized ones.

CommandInterpreterBusy

The debugger's command interpreter is executing a command line, or a GUI operation is in progress. A command line can comprise multiple target execution commands, so arbitrary Running and Stopped events may occur before the command line has been finished. An example for using this event is the disabling of menu entries in your tool.

You can send multiple CommandInterpreterBusy events without the CommandInterpreterReady counterpart. New commands can be send to the debugger after this event has been issued, but they will be queued until the debugger is ready for new command input.

CommandInterpreterReady

The entire command line or GUI operation has either been executed completely or aborted. You can send multiple CommandInterpreterReady events without the CommandInterpreterBusy counterpart.

CommandCanceledByUser

The entire command line or GUI operation has can been canceled by the user, usually via the Halt button.

In case of DDE, the CrossView Pro command queue will be emptied. The command queue of all other IPCs, for example COM, will be preserved. This has been designed for the multi-core debugger which relies on commands -submitted by the multi-core debug system- always being executed, even if the user hits the Halt button.

Note that every command can be canceled this way, even when asking a variable's value. Often no value will be returned at all, because Halt aborted the evaluation.

HaltButtonPressed

Tells that the user has pressed the Halt button. This is necessary because in CrossView Pro Halt means stop executing the current command line. If an external client needs to know this too, the Halt button must be reported explicitly. If not, only when the Halt button actually is hit during a command line execution, cancellation is the case, and reported via an event. If the command line just finished, nothing is being done, so needs to be canceled, hence no cancellation is reported either.

An example would be a client interpreting breakpoint hits and issuing continue commands to resume execution. If the halt button should also stop the client from doing this, the HaltButtonPressed event must be used.

Running

Started executing the target.

RunningInBackground

Started target execution in background mode. This is usually a mode in which a restricted set of operations can be performed, for example read from a memory location.

Stopped cause

Stopped target execution. The cause is reported. Possible causes:

STEP A single step of any kind was finished. Be aware that when using single-step, the debugger does not report any breakpoints the program counter arrives at.

BREAKPOINT "name"
Breakpoint name was hit. This includes cycle breakpoints, time elapsed or number of instructions types. Breakpoints that the user has set are reported as well.
Nameless breakpoints are reported using as name #number#, where number is the CrossView Pro administration number.
If no name or number is known, NAMELESS BREAKPOINT will be used.

ASSERTION number
Assertion number was hit.

UNKNOWN The process has stopped. The cause is unknown or cannot be described with one of the previous reasons.
One of the causes may be that the user presssed the Halt button.

More causes may be added in the future.

Reset

Hardware reset command has been executed by the debugger.

ResetProgram

Software reset of the program command has been executed by the debugger.

ViewedLineNrChanged number

The line being displayed changed to the specified one. If the source window is closed, or the cursor is not in a file but somewhere in assembly, this event will not be sent.

SourceFileChanged "filename"

The debugger displays an other source file. An empty file name "" will be sent if no source is being displayed at all.

DidLoadSymbols "filename"

The symbols of an application have been loaded.

DidAddSymbols "filename"

An application's symbols have been added to the ones already present.

DidDownloadImage "filename"

The code and data image of an application has been downloaded into target memory.

DestroyedAllSymbols "filename"

The symbol table of the application filename has been destroyed.

BreakpointsChanged

The list of breakpoints changed (for example when a breakpoint was added).

AssertionsChanged

Either the list of assertions or assertion mode changed (for example when an assertion was added). Note that the assertion numbering can be entirely altered when an assertion is removed.

MenuEntrySelected "id-string"

The menu entry id-string was selected by the user. Only menu entries created with the AddDDEMenuEntry or AddCOMMenuEntry command are reported.

CmdAnnotatedOutput<\n>
annotated-output

Provides the command window output in an annotated form.

The first line indicates the error status and says OK, ERROR or NOT EXECUTED. The second line has the form SEQ:sequence_number, where the sequence number is either 0 or the number specified with the command. Although the sequence number is optional (it may be omitted in some commands) this line is always present. The next lines are either output or error messages. A label indicates the type (OUTPUT or ERROR) and the number of lines that follow.

Example

The reason behind this event is the inevitable merging of all data streams into one when TCP/IP server is provided next to for example the DDE server.

Quit

The debugger is about to terminate. This is not necessarily the last event. nor is it guaranteed that a CommandInterpeterReady event was send before. The quit event may not be send at all, due to technical restrictions.

1.5 COM Examples

1.5.1 Python Examples

To use COM objects for Python, you must first install the Python interpreter and the Win32COM extensions. You can use the Python interpreter distrubed with the TASKING EDE. Or you can download the Python interpreter from http://www.python.org (May 2001) or use win32all.exe from http://aspn.activestate.com/ASPN/ Downloads/ActivePython/Extensions/Win32all (May 2001).

Synchronous Calls

Replace all occurences of Xfw<targ> in the example below by the name of your CrossView Pro executable to make the text applicable.

#
# Example without events callback
#

import win32com.client
# Python 1.4 requires "import ni" first.

class Xfw<targ>:
"Xfw<targ> via COM wrapper class"
def __init__(self, cmdline_options = ""):
try:
self.COMobject = win32com.client.Dispatch(
"Xfw<targ>.CommandLine")
self.COMobject.Init(cmdline_options)
except Exception,e:
print '(Is the Xfw<targ> COM object installed,
using "xfw<targ>.exe -RegServer"?)'
raise e

def Execute(self, text, sequence_number = 0):
result = self.COMobject.Execute(text, sequence_number)

# convert Unicode to Python string
retval = (result[0], str(result[1]))

return retval

def test_xfw<targ>_com_object():
xvw = Xfw<targ>(r"-sd c:\\testdir")

(success, result) = xvw.Execute("echo Hello from Python")
print "received", result

(success, result) = xvw.Execute("l d")
print "success=",success
print result
(success, result) = xvw.Execute("++$hoi")
print result
(success, result) = xvw.Execute("++$hoi")
print result
(success, result) = xvw.Execute("++$hoi")
print result

del xvw

if __name__ == "__main__":
test_xfw<targ>_com_object()

Events Callback

#
# Example with Events callback
#

import win32com.client
# Python 1.4 requires "import ni" first.
import win32ui

import re

seen_ready_event = 0

class xvw_events:
def OnCrossViewEvent(self, strUnicode):
global seen_ready_event
print "CrossViewEvent: " + str(strUnicode)
if (re.match("CommandInterpreterReady.*", str(strUnicode))):
seen_ready_event = 1

class Xfw<targ>:
def __init__(self, cmdline_options = ""):
self.COMobject = win32com.client.DispatchWithEvents(
"Xfw<targ>.CommandLine", xvw_events)
self.COMobject.Init(cmdline_options)

def Execute(self, text, sequence_number = 0):
result = self.COMobject.Execute(text, sequence_number)

# convert Unicode to Python string
retval = (result[0], str(result[1]))

return retval

if __name__ == "__main__":
xvw = Xfw<targ>("-sd testdir1")

print xvw.Execute('"hello Python";$hoi++')

while seen_ready_event == 0:
win32ui.PumpWaitingMessages(0, -1)

print "terminating"

del xvw

Python Makepy Utility

In the examples above Python will load the type info dynamically from the COM object. This is called 'dynamic' binding or 'late' binding in PythonCOM jargon. However, PythonCOM also provides a mechanism to generate a Python module which contains this type info and thus speeds up the loading process. This is called early binding in the PythonCOM package.

Python uses the makepy utility to support early-bound automation. Makepy is a Python script that translates the COM type library to a Python module which wraps the COM object's interfaces. Once you use the makepy utility, early binding for the objects is automatically supported. There's no need to do anything special to take advantage of the early binding.

Advantages:

Disadvantages:

To speed up starting a Python script that loads the CrossView Pro COM object, you can generate a Python module with makepy.py:

This script will place a module in the win32com\gen_py subdirectory.

For more information on COM programming with Python refer to Python Programming on Win32 - Help for Windows Programmers (Mark Hammond & Andy Robinson; 1st Edition January 2000; 1-56592-621-8).

1.5.2 Visual Basic Examples

Replace all occurences of Xfw<targ> in the example below by the name of your CrossView Pro executable to make the text applicable.

Synchronous Calls

This example demonstrates plain commands being executed in CrossView Pro, without receiving any events from CrossView Pro.

Dim Xvw As Object
Dim Result As String

' here we invoke the PowerPC \xvw{}
' replace xfw<targ> by your executable name
Set Xvw = CreateObject("Xfw<targ>.CommandLine")
Call Xvw.init("")

Call Xvw.Execute("I", Result, 0)
MsgBox Result

End

Events Callback

Visual Basic provides a special feature, WithEvents, to connect to the connection point of a COM interface. It is also available in VBA 5.0. You must use WithEvents in a variable declaration. There is a catch, however: you can only use it in a class module (including form modules) and it must appear in the declaration section. You cannot declare a variable using WithEvents in the body of a procedure. For this example, first select Xfw<targ> type library in the Project References dialog:

1. In Microsoft Word or Microsoft Excel, start the Visual Basic editor and go to Tools|References or:

In Visual Basic, go to Project|References.

Note that VBA differs from VB. See the Word example for VBA.

2. Search and check the CrossView COM Interface Type Library entry.

Option Explicit

Public WithEvents Xvw As Xfw<targ>

Private Sub Form_Load()
Dim Result As String

Set Xvw = CreateObject("Xfw<targ>.CommandLine")
Call Xvw.Init("")

Call Xvw.Execute("echo Hello", Result, 0)
End
End Sub

Private Sub Xvw_CrossViewEvent(ByVal EventText As String)
MsgBox "Called back with: " & EventText
End Sub

1.5.3 WORD Examples

Here is an example of connecting to CrossView Pro PowerPC. It starts xfw<targ> and shows all messages that CrossView Pro sends to Word. Visual Basic for Applications provides a special feature, WithEvents, to connect to the connection point of a COM interface. You must use WithEvents in a variable declaration. There is a catch, however: You can only use it in a class module (including form modules) and it must appear in the declaration section. You cannot declare a variable using WithEvents in the body of a procedure.

Replace all occurences of Xfw<targ> in the example below by the name of your CrossView Pro executable to make the text applicable. To add the example to Word:

1. Start the Visual Basic editor and go to Tools|References

2. Search and check the CrossView COM Interface Type Library entry

3. Insert a class module, via the menu bar: Insert|Class Module

4. Change its name to clsXfw<targ> in the properties pane

5. Paste the following text:

6. Insert a module, via the menu bar: Insert|Module

7. Paste the following text:

1.5.4 Excerpt of the MIDL Definition

The 'ICommandLine' interface is dual, the 'ICommandLineEvents' connection point interface is not. Replace all occurences of Xfw<targ> in the example below by the name of your CrossView Pro executable to make the text applicable.

interface ICommandLine
{
HRESULT Init([in] BSTR CommandLine);

HRESULT Execute([in] BSTR Command,
[in] long SequenceNumber,
[out] BSTR *Result,
[out, retval] VARIANT_BOOL *Ok);

HRESULT Halt(void);
HRESULT ExecuteNoWait([in] BSTR Command,
[in] long SequenceNumber,
[out, retval] VARIANT_BOOL *Ok);
};

library CrossViewLibXfw<targ>
{
dispinterface _ICommandLineEvents
{
methods:void CrossViewEvent([in] BSTR);
};

coclass Xfw<targ>
{
[default] interface ICommandLine;
[default, source] dispinterface _ICommandLineEvents;
};
};

2 DDE Server Interface

2.1 Introduction

CrossView Pro offers an Interprocess Communications (IPC) option using the Microsoft Windows Dynamic Data Exchange (DDE) interface for external control of CrossView Pro. The DDE interface offers direct access to the CrossView Pro command interpreter. Via the DDE interface you can execute every CrossView Pro command that you can access via the regular CrossView Pro command window, and retrieve the output produced by the executed command.

2.2 DDE Items and Topics

DDE function calls always return, whether they succeed or fail. They do not report application command errors. Retrieve and interpret the cmdoutput item or cmdannotatedoutput item to check for errors.

Help

Topic

System

Item

Help

Operations

Request, Advise

Description

Returns a brief overview of the topics and items in ASCII text format.

cmdoutput

Topic

Command

Item

cmdoutput

Operations

Request, Advise

Description

Retrieves all command window output of the last executed command via the Command topic. This item empties itself after it has been requested.

cmdanotatedoutput

Topic

Command

Item

cmdannotated output

Operations

Request, Advise

Description

The first line indicates the error status and says OK, ERROR or NOT_EXECUTED. The second line has the form SEQ:sequence_number, where the sequence number is either 0 or the number specified with the execext command. Although the sequence number is optional (it may be omitted in some commands) this line is always present. The next lines are either output or error messages. A label indicates the type (OUTPUT or ERROR) and the number of lines that follow.

Example

execext

Topic

Command

Item

execext:options:string

Operations

Execute

Description

Passes the specified string without interpreting it to CrossView Pro's command interpreter (see also Command\cmdannotatedoutput). The execext: prefix is part of the entire command string: it makes a distinction between the various commands. For example exec, execext or halt, received via the Command topic.

Options

wait=yesno yesno is 1 or 0. If you specify wait=1 is, the execext command blocks the DDE transaction until CrossView Pro has finished executing the command. Issue the Halt command in this case via a second conversation.
Be aware of the time limitation imposed by the DDE interface. It can wait for a period of 25 days. Use exec combined with either waiting for an Advise on the cmdoutput item, or with interpreting the event item to handle very long lasting commands.
When you do not specify a value, 1 is assumd by default.

seq=number A unique number to identify a command's specific result in the stream of events output via the event item. See the event item and cmdannotatedoutput item for more details.

silent=yesno yesno is 1 or 0. If 1, the command window output will be suppressed. See section Using CrossView Pro as Pure Server for the gus command.
When you do not specify a value, 1 is assumd by default.

Example

execext:seq=424564,wait:echo test

exec

Topic

Command

Item

exec

Operations

Execute

Description

Passes the specified string without interpreting it to CrossView Pro's command interpreter (see also Command\cmdoutput).

A major difference with regular MS-Windows applications is the immediate acknowledge of a command, before it has been completed. This is because the sender does not have to wait for the answer and can peform other tasks meanwhile. For example, you are able to issue a halt command to stop the debugger.

To simulate wait-till-completion command execution, wait until the cmdoutput item is assigned to the command's output via an Advisory link event, or interpret the event item.

The exec: prefix is part of the entire command string: it makes a distinction between the various commands. For example, exec, execext or halt, received via the Command topic.

halt

Topic

Command

Item

halt

Operations

Execute

Description

Forces CrossView Pro to stop target execution. You can issue the command via a second conversation.

event

Topic

Command

Item

event

Operations

Advise

Description

Reports event occurrences to the client, asynchronously. An event is reported by a string. To ensure capturing all events, use an Advise link. CrossView Pro only keeps the last event.

Request is not meant to be used; it can only be used after establishing an Advise link.

result

Topic

Command

Item

result:name

Operations

Execute

Description

The name that you specify provides a serve as DDE requestable item to obtain a message which describes the reason why a DDE command failed to execute. It does not return the CrossView Pro error message. It is always deleted after it has been requested.

The result: prefix is part of the entire command string: it makes a distinction between the various commands. For example, exec, execext or halt, received via the Command topic.

2.3 DDE Events

2.3.1 Packet Format

Each event is wrapped in a record and one DDE message contains one or more of these records. This means that multiple events can be received simultaneously in one DDE transaction. This is done because DDE can lose ("combines") events when XTYPF ACKREQ mode is selected, and because this channel will be redirected to TCP/IP in the future for portable IPC support in CrossView Pro.

To handle events with more than one line, a header (not a newline) is used to distinguish between the individual events. The header format is:

EVENT: number-of-characters<newline>

So you must always split events that arrive in one DDE message. An example of such a multi-event DDE message is:

For an overview of all available events, see section Events

2.4 CrossView Pro DDE Specific Options and Commands

2.4.1 Command Line Options

--ddeservername=name

This command line option specifies a unique DDE server name. This way it is easier to distinguish between multiple instances of the same debugger.

If you do not use this option, the server name is the name of the CrossView executable. To distinguish between multiple DDE servers with the same name, you must connect to all DDE servers using DdeConnectLists() and obtain distinguishing information.

2.4.2 Commands

With regard to DDE support, the following commands are available enhance integration support.

AddDDEMenuEntry

Syntax:

AddDDEMenuEntry "label","id-string" [,AlwaysEnabled]

Creates a menu entry with given label and id-string. The label also specifies the path from the main menu bar, for example:

An entry cannot be removed or replaced once it has been created. Neither is there support for enabling or disabling entries via this interface, this is somewhat problematic, since we are communicating across an asynchronous interface, so the disable may not be executed immediately.

AlwaysEnabled is either 1 (true) or 0 (false, default). CrossView Pro by default disables the menu entry when the command window disallows entering a command, for example when running an application.

To define the shortcut character of a menu entry, place a '&' before the character. The shortcut character will be underlined. To add a seperator line in the menu, start the next menu entry with a '+'. The seperator line will precede this menu entry. For example:

2.5 Examples

2.5.1 Evaluating an Expression

To get the value of an expression, pass it to the command interpreter. The syntax of the returned value is:

identifier = value

The value can even be a complete structure or union. For example, execute via the Command topic:

The returned string could look like:

2.5.2 Reading Target Memory

You can retrive target memory either via requesting a variable's value, or with the dump command. The dump command can dump both byte (MAU) sized hex values or C type values, for example long or double. The resulting output must be interpreted to get the values.

The basic syntax of the returned values for plain MAU size hex dumps is:

address: value value ASCII-dump

The basic syntax of the returned values for formatted dumps is:

address = value value

For example, execute via the Command topic a hex dump command:

The returned text could be:

0x2000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .......

For example, execute via the Command topic a formatted dump command, requesting 16bit integers:

The returned text could be:

The number of values per line differs. This depends on both the size and type of the values, as well as the architecture of the processor that is connected to the debugger.

2.5.3 Writing Into Target Memory

To write to target memory, use one of the following three methods.

1. Assign a value to a variable.

2. Use one of the the mF or mf commands.

For example, the following stores the byte (MAU) sized values 1 2 3 4 5 in memory starting at memory location 0x2000.

3. Write into memory using a type cast.

For example:

*(long*)0x2000 = 0x12345

2.5.4 Requesting Current File and Line Number

To determine the location of the source window cursor position, request the following special variables:

$FILE The file in which the source window cursor position is. If the position is outside any file, the error message 'No current file' is returned.

$PROCEDURE
The name of the function in which the source window cursor position is. If the position is outside any function, the error message 'No current function' is returned.

$LINE The line number of the cursor in the source window. If the position is outside any file, the error message 'No current line' is returned.

You can also use the command "l s" to get all special variables, including the ones above. If a variable is not set, it is not included in the list, or set with the error message as described above.

To make sure the cursor is at the current execution position, precede the L command before requesting the variable. For example, issue:

Error messages appear when a variable fails.

To obtain the current execution positions, you can also interpret the result of the L command directly.

2.5.5 Using CrossView Pro as Pure Server

To have CrossView Pro act as server only, updating windows can be turned off with the command gus on. This inhibits all windows from being updated, except for the command window. Note that also the GUI does not refresh anymore.

Also the execext:silent=1:... command via DDE inhibits the command window output.


Copyright © 2002 Altium BV