Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #8857 > unrolled thread

13 year old C source - Thanks to all

Back to article view | Back to comp.lang.c

Contents

  13 year old C source - Thanks to all buck <buck@private.mil> - 2011-07-29 04:38 +0000
    Re: 13 year old C source - Thanks to all Roberto Waltman <usenet@rwaltman.com> - 2011-07-29 10:37 -0400
    Re: 13 year old C source - Thanks to all Kenneth Brody <kenbrody@spamcop.net> - 2011-07-29 11:02 -0400
    Re: 13 year old C source - Thanks to all Keith Thompson <kst-u@mib.org> - 2011-07-29 08:44 -0700
      Re: 13 year old C source - Thanks to all blp@cs.stanford.edu (Ben Pfaff) - 2011-07-29 09:26 -0700
        Re: 13 year old C source - Thanks to all Roberto Waltman <usenet@rwaltman.com> - 2011-07-29 12:42 -0400
          Re: 13 year old C source - Thanks to all Keith Thompson <kst-u@mib.org> - 2011-07-29 11:16 -0700
        Re: 13 year old C source - Thanks to all "BartC" <bc@freeuk.com> - 2011-07-29 23:23 +0100
        Re: 13 year old C source - Thanks to all Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-07-29 17:01 -0600
          Re: 13 year old C source - Thanks to all Gene <gene.ressler@gmail.com> - 2011-08-02 16:20 -0700
    Re: 13 year old C source - Thanks to all Stephen Sprunk <stephen@sprunk.org> - 2011-07-29 11:03 -0500
    Re: 13 year old C source - Thanks to all Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-07-29 16:57 -0600
      Re: 13 year old C source - Thanks to all buck <buck@private.mil> - 2011-08-02 17:11 +0000
        Re: 13 year old C source - Thanks to all Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-08-02 12:29 -0600
    Re: 13 year old C source - Thanks to all Gene <gene.ressler@gmail.com> - 2011-07-31 06:10 -0700
    Re: 13 year old C source - Thanks to all Michael Press <rubrum@pacbell.net> - 2011-08-03 21:08 -0700

#8857 — 13 year old C source - Thanks to all

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.

THANKS
--
buck

[toc] | [next] | [standalone]

#8870

buck wrote:
>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.
>
>THANKS

Buck, the information you provided "between the lines" in this post
suggests to me that porting that application would be the wrong
approach.

You mention TSRs. TSRs were a used to provide limited multitasking
capabilities to an otherwise single-task OS. In a contemporary OS (any
version of Windows, Linux, Mac's xxxBSD, etc) multitasking is a given.
Therefore, all the code used to setup and manage the TSRs can be
discarded.

You mention ISAM. So, this is a database related application. 
It is likely that the whole application could be implemented within a
modern database (FoxBASE, MS Access, FileMaker, DB2, etc. See
http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems
)

"blasts templates to the monitor, keeps track of how many users,
allows only one instance per user"...
All covered by the two points above.

My "new and improved" recommendation: Forget the code, understand what
the application does as a whole, then ask around to find the best way
to implement that functionality with modern tools. It will probably
requier a much smaller effort than what you expect.
--
Roberto Waltman

[ Please reply to the group,
  return address is invalid ]

[toc] | [prev] | [next] | [standalone]

#8873

On 7/29/2011 12:38 AM, buck wrote:
[..]
> Everyone seems to want to know what this code does.  There are 10
> objects that get linked into a TSR executable.

TSRs are no longer applicable in a Windows environment.  They were an old 
MS-DOS method of doing things such as "background task" or perhaps providing 
an API w/o using a device driver.

> 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...

I think your bigger problem is making this beast something that's meaningful 
in Windows.  (Assuming that you aren't simply asking how to maintain this 
under MS-DOS, that is.)

[...]
>> '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.

Since the compiler is still working, why not make a test program with this 
(untested) code?

=====

#include <stdio.h>

static char v[] = {-20,-124,-180,...};

int main()
     {
     int i;

     for (i=0 ; i < sizeof(v) ; i++)
         printf("%02x  ",(unsigned char)v[i]);
     printf("\n");
     return(0);
     }

=====

(Yes, I know "int main(void)" is "better", but we're talking about a 
pre-ANSI compiler here.)

> 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.

I think you need to define what you want this program to do, once you've 
updated it for Windows.  (Again, assuming that that's your goal.)

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#8876

buck <buck@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 

That's the hex representation of the array (assuming typical overflow
behavior).  Given the right tools, you might be able to search for it in
the binaries.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#8878

Keith Thompson <kst-u@mib.org> writes:

> buck <buck@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

-- 
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

[toc] | [prev] | [next] | [standalone]

#8879

Ben Pfaff wrote:
>Keith Thompson <kst-u@mib.org> writes:
>> buck <buck@private.mil> writes:
>>>> 'static char v[]={-20,-124,-180,-93,-88,-73,-27,-146,9,-38,-179 ...'
>>...
>> 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:

Wild guess: A key/password for the database?
--
Roberto Waltman

[ Please reply to the group.
  Return address is invalid ]

[toc] | [prev] | [next] | [standalone]

#8882

Roberto Waltman <usenet@rwaltman.com> writes:
> Ben Pfaff wrote:
>>Keith Thompson <kst-u@mib.org> writes:
>>> buck <buck@private.mil> writes:
>>>>> 'static char v[]={-20,-124,-180,-93,-88,-73,-27,-146,9,-38,-179 ...'
>>>...
>>> 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:
>
> Wild guess: A key/password for the database?

Wild guess: the late original programmer was really bad at choosing
variable names.

I'd search the source code for occurrences of "v" (full word only) to
see how it's used.  (And if nothing ever modifies it, I'd add "const" to
the declaration.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#8886

"Ben Pfaff" <blp@cs.stanford.edu> wrote in message
news:87fwlpvyrk.fsf@blp.benpfaff.org...
> Keith Thompson <kst-u@mib.org> writes:
>
>> buck <buck@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

Start disassembling at the 4C byte, it makes slightly more sense.

But even it it was machine code, why would it be expressed with an extra 9th
bit? And why not use the assembler that apparently is available?

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#8888

blp@cs.stanford.edu (Ben Pfaff) writes:

> Keith Thompson <kst-u@mib.org> writes:
>
>> buck <buck@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.

[toc] | [prev] | [next] | [standalone]

#8988

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.

[toc] | [prev] | [next] | [standalone]

#8877

On 28-Jul-11 23:38, 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.

Hopefully, he commented his code.  Novice programmers, take note.

> Everyone seems to want to know what this code does.  There are 10 
> objects that get linked into a TSR executable.

There's your first problem.  While you don't say what the new target
platform is, a "TSR" is a purely DOS concept and there is no 64-bit DOS.
 I assume your "64-bit" OS is either Windows or Unix, so you're already
looking at a fairly significant rewrite.

> 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...

Aside from "beeping the speaker", those are all functions I suspect you
would want in a "service" (Windows) or "daemon" (Unix).

However, I wonder if the "correct" solution would be rewriting the
entire application set to use a COTS database such as MySQL or SQLite.
That approach might have been "too slow" on PC hardware in the 1980s,
but it's not today, and would probably require less total effort
considering how much open-source code you could leverage.

> 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.

Well, that's something at least.  Many times, when folks arrive with
questions like this, they don't even have the original tool chain.  I'm
not sure how much it will help in this case, though.

> 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.

Please don't take that as an insult; we're just reacting to the skill
level implied by your original questions, which might not be correct
based on this follow-up.  However, what you seem to be asking for will
require significant skill in two different languages and two different
platforms, and probably databases as well.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

[toc] | [prev] | [next] | [standalone]

#8887

buck <buck@private.mil> writes:

> 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.

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 :)

[toc] | [prev] | [next] | [standalone]

#8965

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote in 
news:1b39holmoo.fsf@snowball.wb.pfeifferfamily.net:

> 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

[toc] | [prev] | [next] | [standalone]

#8966

buck <buck@private.mil> writes:

> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote in 
> news:1b39holmoo.fsf@snowball.wb.pfeifferfamily.net:
>
>> 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?

[toc] | [prev] | [next] | [standalone]

#8910

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.

[toc] | [prev] | [next] | [standalone]

#9015

In article <j0tdfo045i@news1.newsguy.com>, buck <buck@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.

Douglas Kenney?

-- 
Michael Press

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web