Re: Disassembler



"Alistair" <alistair@xxxxxxxxxxxxxxxxxxxxx> wrote in message
news:1141054122.657116.316160@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Pete Dashwood wrote:

I still can't see much point in going to all the trouble of disassembling
code ifyou have the source. If you DON'T have the source, then
disassembling
it is really not going to help much... Maybe, if it is absolutely Mission
Critical code and you really MUST amend it. Personally I wouldn't. I'd
take
the opportunitiy to rewrite it. But then, in my case it would be
component
based and I don't NEED the source anyway :-).

Pete.


I may be misleading you slightly. The program that source-recovery.com
uses reconstitutes the cobol code from the executable (disassembles
first then pattern matches for code equivalent to assembled cobol
verbs). If you have the fd then they use that to give "meaningful" data
names to items ('Pete the delete' was well known for using PH1 and PH2
as variable names, being his initials).

As for not needing the source if, as a new boy, you were asked to use a
pre-existing component to provide a certain function, how would you
know with what parameters to invoke it? unless you had perfect
documentation (of which source code is the prime example).
#
Source code is only the prime example of documentation iif you are
maintaining source code.

The prime example of documentation for an object-only component is the Help
file that documents its Methods, Events and Properties. This will also
document the interface it implements, and what parameters are required,
along with sample code for invoking it in various languages You register the
component and consult the help file. As the component doesn't change, the
help file doesn't either. It always documents what the component does.

If you simply didn't know WHAT component to use, or what might be available,
you would consult the site component register.

(More and more sites are building them... they are pretty essential for
serious component based design.) The register has a description of each
component and can be searched using KWIC (Key Words in Context), which is
like a free format text matching tool. You give it keywords and it searches
the component descriptions and returns the sentence in which each word
appears, and a link to that component description.

Over the last couple of days I have been having great fun getting the
Rational toolset to implement exactly this type of search. I have been
building hooks into Clear Quest to make it scan certain free format
descriptions and apply a regular expression to them that returns the
sentence any match occurs in. These 'contexts' are then pushed to a screen,
along with the key of the record each one was found in. This enables us to
find cases where duplicate errors may have been raised by different teams.
The component register uses exactly the same technique to help you find the
component you need. (Seeing a keyword in context allows you to decide
whether you are interested in THAT particular use of it or some other
one...)

Hope this helps.

Pete.



.