Hi, doesn't anybody know if there is a disk size limit on Unix 6? I wrote a
C program to create a file and it won't go above around 1.5Mb. It doesn't
crash or report any errors but the file size never exceeds around that size.
Maybe it's a disk size limitation?
Also, is it possible to add other devices? like using an ISO file perhaps.
Regards,
Andrew.
On Thu, Apr 8, 2010 at 7:40 PM, John  Holden <johnh(a)psych.usyd.edu.au> 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;
>> Â Â Â Â Â Â Â };
>
> Endian should not be a problem on a Intel/AMD processor. More likely your C
> compiler is padding out the array for alignment. Try a '-fpack-struct' or
> more safely, read the elements individually rather than a structure.
>
In the PDP-11 long is 32 bits, int 16 bits. Â And the PDP-11 is
determinedly little-endian if you stick to integers.
They got floating-point software right in 1971, but somebody screwed
up the word order when building FP hardware, which led to the
middle-endian mess.
  carl
--
  carl lowenstein     marine physical lab   u.c. san diego
                        clowenstein(a)ucsd.edu
> 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;
> };
Endian should not be a problem on a Intel/AMD processor. More likely your C
compiler is padding out the array for alignment. Try a '-fpack-struct' or
more safely, read the elements individually rather than a structure.
PS
To check, see what 'sizeof (struct ar_hdr_)' returns.
John
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)
On Thu, 8 Apr 2010, Michael Davidson wrote:
> Your modern compiler is almost certainly inserting two bytes of padding
> after ar_name[]
> so that the int32_t ar_date is aligned on a 4 byte boundary - that shifts
> everything else
> down by 2 bytes and means that ar_size lines up with the last 2 bytes of the
> size in
> the header which, as luck would have it, is the low order 16 bits of the
> size as it would
> have been stored in a 32 bit long.
>
> Something like this should work on a modern little endian processor"
>
> struct {
>     char  ar_name[14];
> Â Â Â Â int16_t ar_date_16_31;
> Â Â Â Â Â Â Â int16_t ar_date_00_15;
>     char   ar_uid;
>     char  ar_gid;
>     uint16_t    ar_mode;
>     uint16_t    ar_size_16_31;
>        uint16_t       ar_size_00_15;
> } ar_buf;
Thank you! That works for me! I can now get correct sizes, names, and
data. I will clean up my little ar extractor over the next few days and
share it.
I want to look in some .a files identified by file(1) as "old PDP-11
archive".
Anyone know what tool I can use on a modern *BSD or Linux system to
extract the files from an "old PDP-11" ar archive?
GNU ar complains "File format not recognized". ar tells me:
ar: supported targets: elf64-x86-64 elf32-i386 a.out-i386-netbsd
coff-i386 efi-app-ia32 elf64-little elf64-big elf32-little elf32-big
srec symbolsrec tekhex binary ihex netbsd-core
But I have no idea how to try different targets. The GNU ar manual page
doesn't tell me much.
Or how can I use modern pcc or gcc to compile old pre-ansi ar.c?
Any suggestions?
Now I found a simtools.zip via http://simh.trailing-edge.com/ which is
"a collection of tools for manipulating simulator file formats and for
cross-assembling code for the PDP-1, PDP-7, PDP-8, and PDP-11." But I am
not sure if this is related. On that note, any ideas how to extract
files from a ".tap" file used by simh? (For now I use view or strings to
look at it.)
Thanks,
Jeremy C. Reed
echo 'EhZ[h ^jjf0%%h[[Zc[Z_W$d[j%Xeeai%ZW[ced#]dk#f[d]k_d%' | \
tr '#-~' '\-.-{'
I forgot to mention that I had a friend help me out, and he got SYSIII
running on SIMH.......!
I don't know if there would be any interest in this... I don't have a good
layout of 'steps' as it was so... chained from 32v, and from within itself
as it can't boot from the tape..
But I can supply a working disk image to anyone that wants it... or should I
send it to Warren 1st, and he can send it to all the ancient/sysv licenses?
sorry if i'm not all that coherent.
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
Several people have noticed that the web archive for the TUHS mailing list
had stopped at June 2009, which was when I migrated over to another box.
Looks like I had a perms problem, which should be now fixed, but this e-mail
is just to test that it is indeed fixed. Please ignore, and/or browse the
old mail at http://minnie.tuhs.org/pipermail/tuhs/ :-)
Cheers,
Warren
Is anything likely to happen to the status of various historical
Unices? Is Novell likely to keep the Ancient Unix license intact or
are they likely to lock things back up? Is there any chance that
SysIII and early SysV might finally get opened up? Does anybody have
any ideas here?
Mike
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
I was idly going through the 1999 Swartz memo
(http://www.groklaw.net/pdf/Swartz.pdf) wherein the source code of
RedHat 5.2 and UnixWare are compared for similarities. Most of those
are either bogus (just some #includes) or BSD-derived code. There is
one file which is concerning: drand48.c. The RedHat 5.2 file is very
similar to the UnixWare file, including headers and #ifdef's e.g.
/* @(#)drand48.c 2.2 */
/*LINTLIBRARY*/
/*
* drand48, etc. pseudo-random number generator
* This implementation assumes unsigned short integers of at least
* 16 bits, long integers of at least 32 bits, and ignores
* overflows on adding or multiplying two unsigned integers.
* Two's-complement representation is assumed in a few places.
* Some extra masking is done if unsigneds are exactly 16 bits
* or longs are exactly 32 bits, but so what?
* An assembly-language implementation would run significantly faster.
*/
#include <stdlib.h>
#ifndef HAVEFP
#define HAVEFP 1
#endif
As far as I can determine, drand48() arrived in SysVR1 and is defined
in the first SVID. It doesn't appear in SysIII, nor in the early BSDs.
Can anybody shed some light on drand48()? Could it have been written
elsewhere and made available e.g on a Usenix tape or comp.sources.*,
and included into SysV, or is SysV the origin of the code?
I'm sure the algorithm comes from elsewhere, e.g. Knuth, but the
strong code similarity is a worry.
Thanks,
Warren
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
