Download ddd debugger

Arm DDT runs everywhere - on your own laptop, the latest supercomputer and tomorrow's upcoming architectures. Maximize the results with on-site and web-based training courses from the experts in parallel debugging. A wide range of training materials and direct email access to our support team ensures you get the most out of your hardware and software for years to come. Being one of the very few parallel debuggers, Arm DDT is able to debug code for weather forecasting and climate modelling.

Arm DDT lowers the risk of major changes during code development — by working with software version control systems to automatically log values of variables across all processes at each changed section of code. Take advantage of the following:. Find resources that describe how to develop, deploy and optimize enterprise and scientific HPC High Performance Computing applications, including:.

Sorry, your browser is not supported. We recommend upgrading your browser. Arm Account Log in to access your Arm Account. Products Products Products. Why Arm. Multimedia Mali processors offer a complete multimedia solution for SoC. Security Security IP designed to protect against a variety of different vulnerabilities. Neoverse Processors for HPC and cloud-to-edge infrastructure workloads and solutions.

Ethos NPUs with enhanced processing capabilities to deliver highest performance for machine learning inference. Cortex-A Applications processors for devices undertaking complex compute tasks. Cortex-R Real-time processors offering fast, reliable performance for time-critical systems. Cortex-M Low-power processors for microcontrollers and constrained, energy-efficient applications.

Mali GPUs Graphics processors for a range of mobile devices from smartwatches to autonomous vehicles. Development Tools and Software. Artificial Intelligence Transform lives through machine learning solutions. Internet of Things Compute power built into everyday objects and physical systems.

Security Security for billions of devices through Arm technologies. Automotive Autonomous driving is the next frontier for car manufacturers. Gaming Advanced technology designed to deliver the latest gaming and graphics features to mobile devices.

Laptops Always-on, always connected laptops provide richer, more productive experiences. Healthcare Improve healthcare with proactive, and advanced treatment solutions. Industrial Industrial and operational practices become increasing efficient with connected IoT devices. Infrastructure IoT, cloud and 5G are driving the transformation from datacenter to devices. Mobile Computing Scalable solutions for a broad range of mobile devices power our connected digital lives on the go.

Smart Cities Transform cities to be more responsive to events and changes. Smart Homes The power of home automation through always-on IoT devices. Help Helpers : Helper programs invoked by Help. You can also turn off the hint that is displayed in the status line. See Options , for options to set this resource upon DDD invocation.

The actual tips are controlled by these resources see Customizing : startupTipCount class StartupTipCount Resource The number n of the tip of the day to be shown at startup. See also the tip n resources. Takes a compressed text from standard input and writes the uncompressed text to standard output. The default value is gzip -d -c ; typical values include zcat and gunzip -c. To specify netscape Useful for limiting DDD memory usage. A negative value means to place no limit. Default is , or kBytes.

You can also limit the number of entries in the undo buffer, regardless of size see Customizing : maxUndoDepth class MaxUndoDepth Resource The maximum number of entries in the undo buffer. This limits the number of actions that can be undone, and the number of states that can be shown in historic mode. A negative value default means to place no limit.

Splash Screen : Turning off the splash screen. Window Layout : Re-arranging windows. Customizing Fonts : Using alternate fonts. Toggling Windows : Turning off windows. Text Fields : Popdown histories. Icons : Iconifying DDD windows. Adding Buttons : Create your own button set. The value applies only to the next DDD invocation. Possible values include: c default for a color visual, g for a multi-level greyscale visual, g4 for a 4-level greyscale visual, and m for a dithered monochrome visual.

Here are the related DDD resources: separateDataWindow class Separate Resource If on , the data window and the debugger console are realized in different top-level windows.

If off default , the data window is attached to the debugger console. If off default , the source window is attached to the debugger console. By default, the DDD tool bars are located on top of the window. If you prefer the tool bar being located at the bottom, as in DDD 2. This is related to the toolbarsAtBottom resource: toolbarsAtBottom class ToolbarsAtBottom Resource Whether source and data tool bars should be placed above source and data, respectively off , default , or below, as in DDD 2.

The bottom setting is only supported for separate tool bars--that is, you must either choose separate windows or configure the tool bar to have neither images nor captions see Customizing the Tool Bar. If you use stacked windows, you can choose whether there should be one tool bar or two tool bars. By default, DDD uses two tool bars if you use separate windows and disable captions and images, but you can also explicitly change the setting via this resource: commonToolBar class ToolBar Resource Whether the tool bar buttons should be shown in one common tool bar at the top of the common DDD window on , default , or whether they should be placed in two separate tool bars, one for data, and one for source operations, as in DDD 2.

See Options , for options to set these resources upon DDD invocation. Each font is specified using two members: The font family is an X font specifications, where the initial foundry - specification may be omitted, as well as any specification after family.

Thus, a pair family - weight usually suffices. The Browse button opens a font selection program, where you can select fonts and attributes interactively.

Clicking quit or select in the font selector causes all non-default values to be transferred to the DDD font preferences panel. The following fonts can be set using the preferences panel: Default Font The default DDD font to use for labels, menus, and buttons. Default is helvetica-bold. Default is helvetica-medium. Fixed Width The fixed width DDD font to use for source code, the debugger console, text fields, data displays, and the execution window. Default is lucidatypewriter-medium. Changes in this panel will not take effect immediately.

After having made changes in the panel, DDD will automatically offer you to restart itself, such that you can see the changes taking effect. Note that even after restarting, you still must save options to make the changes permanent. The Reset button restores the most recently saved preferences. Here are the resources related to font specifications: defaultFont class Font Resource The default DDD font to use for labels, menus, buttons, etc.

The font is specified as an X font spec, where the initial Foundry specification may be omitted, as well as any specification after Family. Default value is helvetica-bold. This resource overrides any font size specification in the defaultFont resource see above. The default value is for a Default value is helvetica-medium-r. This resource overrides any font size specification in the variableWidthFont resource see above. Default value is to lucidatypewriter-medium.

This resource overrides any font size specification in the fixedWidthFont resource see above. As all font size resources have the same class and by default the same value , you can easily change the default DDD font size to, say, 9.

Here's how to specify the command to select fonts: fontSelectCommand class FontSelectCommand Resource A command to select from a list of fonts. Whether windows are opened or closed when starting DDD is controlled by the following resources, immediately tied to the View menu items: openDataWindow class Window Resource If off default , the data window is closed upon start-up.

A value of 0 default means an unlimited number of values. If off , most recently used values will appear at the top. This way, all DDD windows are iconified and deiconified as a group. Default is off , meaning that each DDD window can be iconified on its own. This way, you can iconify DDD while it is busy on a command e. See Program Stop , for a discussion. This way, you can iconify DDD during some longer operation and have it uniconify itself as soon as the program stops.

Setting this to off leaves the DDD windows iconified. Here's how it works: Identify the appropriate resource in the Ddd file. See Application Defaults , for details on the application-defaults file. The capabilities of the settings editor depend on the capabilities of your inferior debugger. Clicking on? Clicking on Reset restores the most recently saved settings. Some debugger settings are insensitive and cannot be changed, because doing so would endanger DDD operation.

See the gdbInitCommands and dbxInitCommands resources for details. All debugger settings except source and object paths are saved with DDD options.

Opening Files : How to open a program for debugging. Looking up Items : Searching files and functions. Customizing Source : Arranging the source window. Node: Compiling for Debugging , Next: Opening Files , Up: Navigating Compiling for Debugging In order to debug a program effectively, you need to generate debugging information when you compile it. This debugging information is stored in the object file; it describes the data type of each variable or function and the correspondence between source line numbers and addresses in the executable code.

Many C compilers are unable to handle the -g and -O options together. Using those compilers, you cannot generate optimized executables containing debugging information. We recommend that you always use -g whenever you compile a program. You may think your program is correct, but there is no sense in pushing your luck. When you debug a program compiled with -g -O , remember that the optimizer is rearranging your code; the debugger shows you what is really there.

Do not be too surprised when the execution path does not exactly match your source file! An extreme example: if you define a variable, but never use it, DDD never sees that variable--because the compiler optimizes it out of existence. Opening Programs : How to open a program for debugging. Opening Core Dumps : Analyze a previous crash.

Opening Source Files : Open a source file of the program. Filtering Files : DDD only lists matching files. This gives you a list of available classes to choose from.

If no sources are found, See Source Path , for specifying source directories. Click on Open to open the core dump. Using GDB , this gives you a list of the sources used for compiling your program. Using other inferior debuggers, this gives you a list of accessible source files, which may or may not be related to your program. Click on Open to open the source file. See Source Path , if no sources are found. This requires that DDD opens each file, which may take time.

See Customizing File Filtering , if you want to turn off this feature. In the source window, you can lookup and examine function and variable definitions as well as search for arbitrary occurrences in the source text. Looking up Definitions : Jump towards a specific item. Textual Search : Search within the current source. Looking up Previous Locations : Navigate back and forth. Node: Looking up Definitions , Next: Textual Search , Up: Looking up Items Looking up Definitions If you wish to lookup a specific function or variable definition whose name is visible in the source text, click with mouse button 1 on the function or variable name.

The name is copied to the argument field. Change the name if desired and click on the Lookup button to find its definition. As a faster alternative, you can simply press mouse button 3 on the function name and select the Lookup item from the source popup menu. As an even faster alternative, you can also double-click on a function call an identifier followed by a character to lookup the function definition. If a source file is not found, See Source Path , for specifying source directories.

The identifier is copied to the argument field. By default, DDD finds only complete words. Node: Source Path , Previous: Looking up Previous Locations , Up: Looking up Items Specifying Source Directories Executable programs sometimes do not record the directories of the source files from which they were compiled, just the names.

Even when they do, the directories could be moved between the compilation and your debugging session. Here's how GDB accesses source files; other inferior debuggers have similar methods. GDB has a list of directories to search for source files; this is called the source path. Each time GDB wants a source file, it tries all the directories in the list, in the order they are present in the list, until it finds a file with the desired name.

Note that the executable search path is not used for this purpose. Neither is the current working directory, unless it happens to be in the source path. If GDB cannot find a source file in the source path, and the object program records a directory, GDB tries that directory too. If the source path is empty, and there is no record of the compilation directory, GDB looks in the current directory as a last resort. If Debugger Settings has no suitable entry, you can also specify a source path for the inferior debugger when invoking DDD.

See Inferior Debugger Options , for details. If DDD does not find a source file for any reason, check the following issues: In order to debug a program effectively, you need to generate debugging information when you compile it. Without debugging information, the inferior debugger will be unable to locate the source code. To request debugging information, specify the -g option when you run the compiler.

See Compiling for Debugging , for details. You may need to tell your inferior debugger where the source code files are. See Source Path , for details. Using GDB , you can also create a local. Here, path is a colon-separated list of source paths. As an alternative, DDD can also indicate these positions using text characters. This also makes DDD run slightly faster, especially when scrolling.

This setting is tied to this resource: displayGlyphs class DisplayGlyphs Resource If this is on , the current execution position and breakpoints are displayed as glyphs; otherwise, they are shown through characters in the text. The default is on. See Options , for the --glyphs and --no-glyphs options.

You can further control glyphs using the following resources: cacheGlyphImages class CacheMachineCode Resource Whether to cache share glyph images on or not off. Caching glyph images requires less X resources, but has been reported to fail with Motif 2.

Default is off for Motif 2. A small value results in glyphs being scrolled with the text, a large value disables glyphs while scrolling and makes scrolling faster.

Default: Raising this value causes more glyphs to be allocated, possibly wasting resources that are never needed. Otherwise, occurrences are found regardless of case. Otherwise, arbitrary occurrences are found. The default is off. You can instruct DDD to indent the source code, leaving more room for breakpoints and execution glyphs.

The default value is 0 for no indentation at all. Default: 0. By default, DDD uses a minimum indentation for script languages. Default: 4. The maximum width of line numbers is controlled by this resource. Line numbers wider than this value extend into the breakpoint space. Default is 2. Default is 3.

This is related to the following resource: useSourcePath class UseSourcePath Resource If this is off default , the inferior debugger refers to source code locations only by their base names. If this is on default , DDD uses the full source code paths.

By default, DDD caches source files in memory. This is convenient for remote debugging, since remote file access may be slow. This is related to the following resource: cacheSourceFiles class CacheSourceFiles Resource Whether to cache source files on , default or not off. Caching source files requires more memory, but makes DDD run faster.

If this is off , DDD always presents all available files. Node: Stopping , Next: Running , Previous: Navigating , Up: Top Stopping the Program The principal purposes of using a debugger are so that you can stop your program before it terminates; or so that, if your program runs into trouble, you can investigate and find out why.

Inside DDD , your program may stop for any of several reasons, such as a signal, a breakpoint, or reaching a new line after a DDD command such as Step. You may then examine and change variables, set new breakpoints or remove old ones, and then continue execution.

The inferior debuggers supported by DDD support two mechanisms for stopping a program upon specific events: A breakpoint makes your program stop whenever a certain point in the program is reached. For each breakpoint, you can add conditions to control in finer detail whether your program stops. Typically, breakpoints are set before running the program.

A watchpoint is a special breakpoint that stops your program when the value of an expression changes. Breakpoints : Stop at a certain point. Watchpoints : Stop at a certain condition. Interrupting : Stop manually. Stopping X Programs : Take care of grabbed pointers! Setting Breakpoints by Location Breakpoints are set at a specific location in the program.

If the source line is visible, click with mouse button 1 on the left of the source line and then on the Break button. As a faster alternative, you can simply press mouse button 3 on the left of the source line and select the Set Breakpoint item from the line popup menu.

As an even faster alternative, you can simply double-click on the left of the source line to set a breakpoint. Click on the Break button and enter the location. If you find this number of alternatives confusing, be aware that DDD users fall into three categories, which must all be supported. Novice users explore DDD and may prefer to use one single mouse button. Advanced users know how to use shortcuts and prefer popup menus. Experienced users prefer the command line interface.

Breakpoints are indicated by a plain stop sign, or as n , where n is the breakpoint number. A stop sign with a question mark or? Setting Breakpoints by Name If the function name is visible, click with mouse button 1 on the function name. The function name is then copied to the argument field. Click on the Break button to set a breakpoint there.

As a shorter alternative, you can simply press mouse button 3 on the function name and select the Break at item from the popup menu. As yet another alternative, you can click on Break The breakpoint location is copied to the argument field.

Click on the Clear button to delete all breakpoints there. If the function name is visible, click with mouse button 1 on the function name.

The function name is copied to the argument field. Click on the Clear button to clear all breakpoints there. As a faster alternative, you can simply press mouse button 3 on the breakpoint and select the Delete Breakpoint item from the popup menu. This makes the breakpoint inoperative as if it had been deleted, but remembers the information on the breakpoint so that you can enable it again later.

To enable it again, select Enable Breakpoint. The Disable Breakpoint item is also accessible via the Clear button. Just press and hold mouse button 1 on the button to get a popup menu. Temporary breakpoints are convenient to make the program continue up to a specific location: just set the temporary breakpoint at this location and continue execution. The Continue Until Here item from the popup menu sets a temporary breakpoint on the left of the source line and immediately continues execution.

Execution stops when the temporary breakpoint is reached. Node: Editing Breakpoint Properties , Next: Breakpoint Conditions , Previous: Temporary Breakpoints , Up: Breakpoints Editing Breakpoint Properties You can change all properties of a breakpoint by pressing mouse button 3 on the breakpoint symbol and select Properties from the breakpoint popup menu. This will pop up a dialog showing the current properties of the selected breakpoint.

As an even faster alternative, you can simply double-click on the breakpoint. Click on Lookup to move the cursor to the breakpoint's location. Click on Enable to enable the breakpoint. Click on Disable to disable the breakpoint. Click on Temp to make the breakpoint temporary. You can also specify a condition for a breakpoint. A condition is just a Boolean expression in your programming language. A breakpoint with a condition evaluates the expression each time your program reaches it, and your program stops only if the condition is true.

This is the converse of using assertions for program validation; in that situation, you want to stop when the assertion is violated-that is, when the condition is false. In C, if you want to test an assertion expressed by the condition assertion , you should set the condition! Break conditions can have side effects, and may even call functions in your program. This can be useful, for example, to activate functions that log program progress, or to use your own print functions to format special data structures.

The effects are completely predictable unless there is another enabled breakpoint at the same address. In that case, DDD might see the other breakpoint first and stop your program without checking the condition of this one. Note that breakpoint commands are usually more convenient and flexible for the purpose of performing side effects when a breakpoint is reached.

See Breakpoint Commands , for details. This is so useful that there is a special way to do it, using the ignore count of the breakpoint. Every breakpoint has an ignore count, which is an integer. Most of the time, the ignore count is zero, and therefore has no effect. But if your program reaches a breakpoint whose ignore count is positive, then instead of stopping, it just decrements the ignore count by one and continues.

As a result, if the ignore count value is n , the breakpoint does not stop the next n times your program reaches it. In the field Ignore Count of the Breakpoint Properties panel, you can specify the breakpoint ignore count. Once the ignore count reaches zero, DDD resumes checking the condition.

For example, you might want to print the values of certain expressions, or enable other breakpoints. Using GDB , you can also record a command sequence to be executed. To record a command sequence, follow these steps:. Node: Moving and Copying Breakpoints , Next: Looking up Breakpoints , Previous: Breakpoint Commands , Up: Breakpoints Moving and Copying Breakpoints To move a breakpoint to a different location, press mouse button 1 on the stop sign and drag it to the desired location.

The new breakpoint inherits all properties of the old breakpoint, except the breakpoint number. After selecting a breakpoint from the list and clicking the Lookup button, the breakpoint location is displayed. As an alternative, you can enter n in the argument field, where n is the breakpoint number, and click on the Lookup button to find its definition. This will popup the Breakpoint Editor which displays the state of all breakpoints.

In the breakpoint editor, you can select individual breakpoints by clicking on them. To edit the properties of all selected breakpoints, click on Props. This command requires hardware support and some target hardware may not have this support. See Setting breakpoints , for details. Node: Watchpoints , Next: Interrupting , Previous: Breakpoints , Up: Stopping Watchpoints You can make the program stop as soon as some variable value changes, or when some variable is read or written.

This is called setting a watchpoint on a variable. You can also set conditions, ignore counts, and commands to be executed when a watched variable changes its value.

Please note: on architectures without special watchpoint support, watchpoints currently make the program execute two orders of magnitude more slowly. This is so because the inferior debugger must interrupt the program after each machine instruction in order to examine whether the watched value has changed. However, this delay can be well worth it to catch errors when you have no clue what part of your program is the culprit.

The variable name is copied to the argument field. Otherwise, enter the variable name in the argument field. Click on the Watch button to set a watchpoint there. Using GDB , you can set different types of watchpoints. Click and hold mouse button 1 on the Watch button to get a menu.

Click and hold mouse button 1 on the Watch button and select Watchpoint Properties. As an additional feature, you can click on Print to see the current value of a watched variable. This will popup the Watchpoint Editor which displays the state of all watchpoints. Node: Deleting Watchpoints , Previous: Editing all Watchpoints , Up: Watchpoints Deleting Watchpoints To delete a watchpoint, enter the name of the watched variable in the argument field and click the Unwatch button.

By default, DDD will check after each interaction whether the pointer is grabbed. If the pointer is grabbed, DDD will continue the debugged program such that you can continue to use your X display. This is how this feature works: When the program stops, DDD checks for input events such as keyboard or mouse interaction. If DDD does not receive any event within the next 5 seconds, DDD checks whether the mouse pointer is grabbed by attempting to grab and ungrab it.

If this attempt fails, then DDD considers the pointer grabbed. Unfortunately, DDD cannot determine the program that grabbed the pointer--it may be the debugged program, or another program.

Consequently, you have another 10 seconds to cancel continuation before DDD continues the program automatically. There is one situation where this fails: if you lock your X display while DDD is running, then DDD will consider a resulting pointer grab as a result of running the program--and automatically continue execution of the debugged program.

If this is so, DDD will automatically continue execution of debugged program. If DDD sees some pointer event within this delay, the pointer cannot be grabbed and an explicit check for a grabbed pointer is unnecessary. Default is , or 5 seconds. This is a list of newline-separated commands. Default is cont , meaning to continue the debuggee.

Other possible choices include kill killing the debuggee or quit exiting DDD. During this delay, a working dialog pops up telling the user about imminent execution of the grab action see the grabAction resource, above. If the pointer grab is released within this delay, the working dialog pops down and no action is taken. This is done to exclude pointer grabs from sources other than the debugged program including DDD.

Default is , or 10 seconds. You may redirect your program's input and output, debug an already running process, or kill a child process. You will then be prompted for the arguments to pass to your program. You can either select from a list of previously used arguments or enter own arguments in the text field. Afterwards, press the Run button to start execution with the selected arguments.

You may also enter run , followed by arguments at the debugger prompt instead. When you click on Run , your program begins to execute immediately. See Stopping , for a discussion of how to arrange for your program to stop. Once your program has stopped, you may call functions in your program to examine data.

See Examining Data , for details. If the modification time of your symbol file has changed since the last time GDB read its symbols, GDB discards its symbol table, and reads it again. Arguments : Your program's arguments. Environment : Your program's environment. Working Directory : Your program's directory. If you use another inferior debugger, the exact semantics on how the arguments are interpreted depend on the inferior debugger you are using.

Normally, the shell is used to pass the arguments, so that you may use normal conventions such as wildcard expansion or variable substitution in describing the arguments. Node: Environment , Next: Working Directory , Previous: Arguments , Up: Starting Program Execution Your Program's Environment Your program normally inherits its environment from the inferior debugger, which again inherits it from DDD , which again inherits it from its parent process typically the shell or desktop.

In GDB , you can use the commands set environment and unset environment to change parts of the environment that affect your program. See Your program's environment , for details. This is set for the inferior debugger only. The inferior debugger, in turn, might also set or unset some environment variables.

You can enter these shell redirections just like other arguments see Arguments. Warning: While input and output redirection work, you cannot use pipes to pass the output of the program you are debugging to another program; if you attempt this, DDD may wind up debugging the wrong program. See Attaching to a Process , for an alternative. If command output is sent to the debugger console, it is impossible for DDD to distinguish between the output of the debugged program and the output of the inferior debugger.

Program output that confuses DDD includes: Primary debugger prompts e. If the inferior debugger changes the default TTY settings, for instance through a stty command in its initialization file, DDD may also become confused. The same applies to debugged programs which change the default TTY settings. The behavior of the debugger console can be controlled using the following resource: lineBufferedConsole class LineBuffered Resource If this is on default , each line from the inferior debugger is output on each own, such that the final line is placed at the bottom of the debugger console.

If this is off , all lines are output as a whole. This is faster, but results in a random position of the last line. As an alternative, DDD can also invoke an execution window , where the program terminal input and output is shown. The execution window is opened automatically as soon as you start the debugged program.

While the execution window is active, DDD redirects the standard input, output, and error streams of your program to the execution window. You can override the DDD stream redirection by giving alternate redirection operations as arguments. A Bourne shell command to run in the separate TTY is appended to this string.

Default: xterm. If off default , the debugged program is executed in the console window. You can now choose from a list of processes. Then, press the Attach button to attach to the specified process. The first thing DDD does after arranging to debug the specified process is to stop it.

You can examine and modify an attached process with all the DDD commands that are ordinarily available when you start processes with Run. You can insert breakpoints; you can step and continue; you can modify storage.

If you would rather the process continue running, you may use Continue after attaching DDD to the process. When using Attach to Process , you should first use Open Program to specify the program running in the process and load its symbol table.

Detaching the process continues its execution. After Detach Process , that process and DDD become completely independent once more, and you are ready to attach another process or start one with Run. You can customize the list of processes shown by defining an alternate command to list processes. This command is defined by the psCommand resource. Usually ps. Depending on your system, useful alternate values include ps -ef and ps ux.

The first line of the output must either contain a PID title, or each line must begin with a process ID. Note that the output of this command is filtered by DDD ; a process is only shown if it can be attached to. The DDD process itself as well as the process of the inferior debugger are suppressed, too. A watched value changes see Watchpoints. The program is interrupted see Interrupting. A signal is received see Signals. Execution completes.

DDD shows the current program status in the debugger console. The current execution position is highlighted by an arrow. This way, you can iconify DDD during a lengthy computation and have it uniconify as soon as the program stops.

Any breakpoints set at the current execution position are bypassed. Stepping one Line To execute just one source line, click on the Step button. The program is executed until control reaches a different source line, which may be in a different function. Wintraday 1. Wintraday is the result of new market data display technology, and allows individual investors to keep on top of their investments with up-to-the-minute updates on stock activity.

Wintraday is being offered to individual investors as an alternative to Web browser stock tickers, for intraday charts viewing. Wintraday is unique because it is a small, single. Gene Expression Data Analysis Studio 1. GEDAS is a software to perform microarray data analysis with friendly user interface and convenient data display.

Currently some commonly used data clustering algorithms have been implemented in this software. Disk Investigator 1. Disk Investigator helps you to discover all that is hidden on your computer hard disk. It can also help you to recover lost data. Display the true drive contents by bypassing the operating system and directly reading the raw drive sectors. View and search raw directories, files, clusters, and system sectors. Undelete previously deleted files.

Verify the effectiveness of file and disk wiping programs. InstantCharts Market Browser for Traders 1. InstantCharts Market Browser is a market data display application for professional traders. It allows easy access to and manipulation of market data through a combination of specialized display objects and analytical tools, such as Tickers, Quote Lists, News, Time and Sales Information, Charting. Infinitiscope 1. Infinitiscope is a graphical display tool that has special characteristics for numerical data display.

It was essentially developed to be used in scientific research as an accurate and rich tool for creating graphs of numerical data. Even that it was made for scientific research purposes it is also a general interest powerful numerical analysis tool that connects to many popular data sources. Infinitiscope COM Standard 1.