9 Apr
2010
9 Apr
'10
1:13 a.m.
Bob Eager:
The 'ar' format of that vintage is trivial, and documentation easily
found. I wrote programs to read it back in 1976!
======
That's nothing. Either Ken or Dennis wrote such a program
years before that!
Warren even has a binary somewhere to prove it!
Seriously, it's a binary format, so I don't know that
it would be easy to process in awk. (At least not in
awk-classic; stuff that works only in ghootandwaveawk
is not all that interesting to me.) But the format is
simple, and any language new or old that can handle
binary data without tears should do.
If I didn't have an overfull plate already (and a
visit to the Auto-Electrocution Consultant tomorrow,
and one to the Canal Rooting Clinic Monday--proving
that one should follow Father's advice and Stay Away
From The Canal, Neddie) it would be interesting to
collect the different specifications for ar headers
over the years, and write a small suite of programs
to read them. Perhaps in Python, just to be difficult.
(Why isn't there a language called Goon, Warren?)
Norman Wilson
Toronto ON
(owwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww)
9 Apr
9 Apr
2:11 a.m.
New subject: [pups] extract old archive format?
On Thu, 8 Apr 2010, Norman Wilson wrote:
Bob Eager:
The 'ar' format of that vintage is trivial, and documentation easily
found. I wrote programs to read it back in 1976!
======
That's nothing. Either Ken or Dennis wrote such a program
years before that!
Warren even has a binary somewhere to prove it!
Seriously, it's a binary format, so I don't know that
it would be easy to process in awk. (At least not in
awk-classic; stuff that works only in ghootandwaveawk
is not all that interesting to me.) But the format is
simple, and any language new or old that can handle
binary data without tears should do.
I can't see how to do it in awk either.
If I didn't have an overfull plate already (and
a
visit to the Auto-Electrocution Consultant tomorrow,
and one to the Canal Rooting Clinic Monday--proving
that one should follow Father's advice and Stay Away
Well I found the ar specification (in ar.5 not ar.1).
struct ar_hdr {
char ar_name[14];
long ar_date;
char ar_uid;
char ar_gid;
int ar_mode;
long ar_size;
};
This is same as the old ar.c source.
(plus more in the manual page.)
Now my problem is I don't know what "long" or "int" is on the old
PDP-11
/ system 5 this was made on.
And I read about PDP-11 "middle endianess" (first time I heard of
"middle").
So I had (wrong but gets ar_name and ar_size correct for my few tests
for the first header but chops two characters into the data section).
struct {
char ar_name[14];
int32_t ar_date;
char ar_uid;
char ar_gid;
uint16_t ar_mode;
uint16_t ar_size;
} ar_buf;
Well I know above is wrong because ar_size and ar_date should be the
same. But I get ar_size correct each time. But it also loses the next
two bytes from the data. So I am guessing I have some endian issue where
I am getting some things reversed.
Any ideas?
Note I am not using any system 5 or PDP-11 system. I am using a modern
little endian (amd64) system to extract the files that were created in
1970s.
Once I figure out the structure and endianness (if applicable) I will
share back my code so others can extract ...
>From The Canal, Neddie) it would be
interesting to
collect the different specifications for ar headers
over the years, and write a small suite of programs
to read them. Perhaps in Python, just to be difficult.
(Why isn't there a language called Goon, Warren?) 
10:15 a.m.
New subject: [pups] extract old archive format?
Jeremy C. Reed wrote:
Well I found the ar specification (in ar.5 not ar.1).
struct ar_hdr {
char ar_name[14];
long ar_date;
char ar_uid;
char ar_gid;
int ar_mode;
long ar_size;
};
Simple enough... :-)
This is same as the old ar.c source.
(plus more in the manual page.)
Now my problem is I don't know what "long" or "int" is on the
old PDP-11
/ system 5 this was made on.
An int on the pdp11 is 16 bits, and a long is 32.
Remember? int is whatever size is most convenient for the architecture? :-)
And I read about PDP-11 "middle endianess"
(first time I heard of
"middle").
A mess, but we have to live with it.
In short, the bytes of a long on a PDP11 is likely laid out like this:
3412
So, the 16-bit values are each little-endian, but the 16 bit values as
such, in the 32-bit view, is laid out as big-endian.
Thus middle-endian... :-)
So I had (wrong but gets ar_name and ar_size correct
for my few tests
for the first header but chops two characters into the data section).
struct {
char ar_name[14];
int32_t ar_date;
char ar_uid;
char ar_gid;
uint16_t ar_mode;
uint16_t ar_size;
} ar_buf;
Well I know above is wrong because ar_size and ar_date should be the
same. But I get ar_size correct each time. But it also loses the next
two bytes from the data. So I am guessing I have some endian issue where
I am getting some things reversed.
Any ideas?
As others already said, it's your compiler trying to optimize the
alignments.
One solution (already presented) is to just play with 16-bit values.
You could also explain to the compiler that it shouldn't try to optimize
the alignments, but since you have to deal with the middle-endianess
anyway, you are probably better off just looking at 16-bit values and
combine them into 32-bit values as needed yourself.
Johnny
5:49 a.m.
New subject: [pups] extract old archive format?
On Thu, 08 Apr 2010 21:13:55 -0400 (EDT)
Norman Wilson <norman(a)oclsc.org> wrote:
The 'ar' format of that vintage is
trivial, and documentation easily
found. I wrote programs to read it back in 1976!
======
That's nothing. Either Ken or Dennis wrote such a program
years before that!
I know...I used it, in July 1976!
Mine was in PDP-11 assembler, for a different operating system.
Seriously, it's a binary format, so I don't
know that
it would be easy to process in awk.
I forgot that the first version was partially binary, but still easy in
most modern languages.
If I had more time, I'd have a go...again!
--
Bob
5130
days inactive
5130
days old
3 comments
4 participants
participants (4)
-
Bob Eager -
Jeremy C. Reed -
Johnny Billquist -
Norman Wilson