«

On Jul 29, 12:38*am, buck <b...@private.mil> wrote:
> I can't ask the original coder what he was thinking because he's dead,
> having fallen off a mountain while attempting to climb it.
>
> Everyone seems to want to know what this code does. *There are 10
> objects that get linked into a TSR executable. *As concisely as I can
> describe it, it provides an interface into ISAM low level functions
> (add, delete, read, update, etc), "blasts" templates to the monitor,
> keeps track of how many users, allows only one instance per user,
> beeps the speaker...
>
> Yes I can compile it using the DeSmet development tools. *It has been
> working error-free since 1989 - and before, prior to a few small
> changes for much longer than that (though I don't know just how long. *
> I started working for the company January 1987.
>
> > 'static char v[]={-20,-124,-180,-93,-88,-73,-27,-146,9,-38,-179 ...'
>
> I've examined the object code to see what values are present there but
> haven't found this array yet.
>
> It seems that the concensus is that this project is fesable, but not
> by me. *I need more time to think about it, but will take all advice
> strongly into consideration.

You probably know this, but TSR (terminate and stay resident for all
the youngsters) adds a new dimension to what you're trying to
achieve. It's likely to mean there are fair-sized chunks of code that
are meaningless in a modern OS. Examples include saving and restoring
chunks of screen buffer around TSR pop-up sessions, monitoring
keystrokes and perhaps timer and communication interrupts, and probing
DOS data structures to determine if it's safe to run. Equivalent
functions can come for free in modern environments, such as the screen
buffer management. In other cases, like device I/O, things can be
significantly harder to implement. All in all as others have said you
are looking at a major porting effort that could take nearly as much
time as the original program.

I have heard people with problems like this were successful continuing
to use old code and tools with ExDOS http://www.exdos.com/ExDOS/ .

FWIW, I agree with those who speculate your array of chars might be
machine code. Little chunks of "canned" position-independent code
written as arrays like this were common in TSR code. I can't explain
the values outside the normal -128 to 127 range, however.

Joe Pfeiffer <> wrote in
news: :

> I can't resist pointing out that 1989 was 22 years ago. For it to
have
> been working for an equal time before then would require it to have
been
> written in 1967


The code was WRITTEN 10/27/1986. LAST MODIFIED 13 years ago.

There is a difference...
--
buck

buck <> writes:

> Joe Pfeiffer <> wrote in
> news: :
>
>> I can't resist pointing out that 1989 was 22 years ago. For it to
> have
>> been working for an equal time before then would require it to have
> been
>> written in 1967
>
>
> The code was WRITTEN 10/27/1986. LAST MODIFIED 13 years ago.
>
> There is a difference...

A significant difference! And what you said was:

> Yes I can compile it using the DeSmet development tools. It has been
> working error-free since 1989 - and before, prior to a few small
> changes for much longer than that (though I don't know just how long.
> I started working for the company January 1987.

I read this as a few small changes in 1989. The few small changes were
13 years ago?

On Jul 29, 7:01*pm, Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote:
> b...@cs.stanford.edu (Ben Pfaff) writes:
> > Keith Thompson <ks...@mib.org> writes:
>
> >> buck <b...@private.mil> writes:
> >> [...]
> >>>> 'static char v[]={-20,-124,-180,-93,-88,-73,-27,-146,9,-38,-179 ....'
>
> >>> I've examined the object code to see what values are present there but
> >>> haven't found this array yet.
>
> >> This might help:
>
> >> ec 84 4c a3 a8 b7 e5 6e 09 da 4d
>
> > Out of curiosity, I fed this into an 8086 disassembler, but the
> > results don't make much sense so I doubt that this is 8086
> > machine code:
>
> > * *0: * ec * * * * * * * * * * *in * * (%dx),%al
> > * *1: * 84 4c a3 * * * * * * * *test * %cl,-0x5d(%si)
> > * *4: * a8 b7 * * * * * * * * * test * $0xb7,%al
> > * *6: * e5 6e * * * * * * * * * in * * $0x6e,%ax
> > * *8: * 09 da * * * * * * * * * or * * %bx,%dx
> > * *a: * 4d * * * * * * * * * * *dec * *%bp
>
> I'm trying to guess why the original programmer initialized an array of
> char with some values that can't be expressed in 8 bits... *whatever the
> motivation, expressing the values as positive and negative decimals
> instead of as hex values makes it seem unlikely (to me, anyway) that
> it's assembly code.

This is logical and I agree it's probably not assembly in this case
(because the disassembly is nonsense), but people often grew up in
this era poking bytes in BASIC and storing machine code in Pascal
character arrays, where decimal could be all you had. So this could
reasonably have been a fragment ported from code in one of these
languages.

In article <>, buck <>
wrote:

> I can't ask the original coder what he was thinking because he's dead,
> having fallen off a mountain while attempting to climb it.

Douglas Kenney?

--
Michael Press