6 Jan
2020
6 Jan
'20
6:13 a.m.
Hi,
Does the wump.c source exist for v6? The game's in the distribution and
so is the man page, but I can't find the source. I see it's in v7, but I
don't know the provenance of the game source, hence the question.
I find the following interesting... in the v7 source it says:
/*
* wumpus
* stolen from PCC Vol 2 No 1
*/
But it's actually from PCC Vol 2 No 2 (Nov 1973):
https://archive.computerhistory.org/resources/access/text/2017/09/102661095…
and the basic source is given in the games issue:
https://archive.computerhistory.org/resources/access/text/2017/09/102661095…
The correct volume is noted in the v6 manpage:
This program is based on one described in 2 (No-
vember 1973). It will never replace Space War.
and in the v7 manpage:
This program is based on one described in People's Computer
Company, 2, 2 (November 1973).
BUGS
It will never replace Space War.
I'm curious if it was ported to c for v6, or if it was basic?
Thanks,
Will
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
6 Jan
6 Jan
3:20 p.m.
On Mon, Jan 6, 2020 at 1:14 AM Will Senn <will.senn(a)gmail.com> wrote:
Does the wump.c source exist for v6? The game's
in the distribution and so
is the man page, but I can't find the source. I see it's in v7, but I
don't
know the provenance of the game source, hence the question.
Interesting question for someone like Doug, Steve or Ken. I bet it is
pretty close, if not the same. I notice the V7 version used printf and
getchar, but does not define stdio.h. It also has a struct in it. So by
the time of that version, printf existed as did structs both of which were
in the V6 C compiler (V6 did not have stdio, it had Mike Lesk's 'Portable
I/O Library' (iolib in the sources).
I don't have v6 handy, so I can not run a nm on /usr/games/wump but I bet
if you did and compared it to an nm from V6 I bet they are darned close.
....
I'm curious if it was ported to c for v6, or if
it was basic?
I would guess B or C not basic. The UNIX basic was primitive compared to
Darthmouth (or HP - which would become HP-2000 basic but that's a different
story). Code from PCC (or later David Ahl's "101 Basic Computer Games"
<https://www.amazon.com/101-BASIC-Computer-Games-David/dp/B000CNZP5U/ref=smi_www_rco2_go_smi_3905707922>
)
would not work without extensive rewriting. Something that small,
converting to B or C would have been similar effort so I would have
expected that to have been what happened.
Remember Edition X, particularly for the first few, was the status of the
disks in research at the time. So there are a few cases of binaries in
some of the earlier editions being found in /usr/bin or the like and the
sources not there in the distribution.
4:35 p.m.
Ah - sadly not surprising thinking back. Binaries got stripped to save a
few bytes in those days.
On Mon, Jan 6, 2020 at 11:25 AM Will Senn <will.senn(a)gmail.com> wrote:
Sent from my iPhone
On Jan 6, 2020, at 9:20 AM, Clem Cole <clemc(a)ccc.com> wrote:
I don't have v6 handy, so I can not run a nm on /usr/games/wump but I bet
if you did and compared it to an nm from V6 I bet they are darned close.
nm wump
no name list
Bummer.
6:29 p.m.
The good news is that disassembly will tell you right away if it was
written in C or not.
On Mon, Jan 6, 2020 at 9:36 AM Clem Cole <clemc(a)ccc.com> wrote:
Ah - sadly not surprising thinking back. Binaries got
stripped to save a
few bytes in those days.
On Mon, Jan 6, 2020 at 11:25 AM Will Senn <will.senn(a)gmail.com> wrote:
>
>
> Sent from my iPhone
>
> On Jan 6, 2020, at 9:20 AM, Clem Cole <clemc(a)ccc.com> wrote:
>
>
> I don't have v6 handy, so I can not run a nm on /usr/games/wump but I bet
> if you did and compared it to an nm from V6 I bet they are darned close.
>
> nm wump
> no name list
>
> Bummer.
>
>
6:48 p.m.
On Mon, Jan 6, 2020 at 11:38 AM Will Senn <will.senn(a)gmail.com> wrote:
On 1/6/20 12:29 PM, Warner Losh wrote:
The good news is that disassembly will tell you right away if it was
written in C or not.
OK. I give up. How?
Generally, the C compiler generates code that's quite distinctive (at least
PCC does, not sure about Dennis' compiler). People writing free assembler
tend to do really weird things for function entry / return.
And it will likely tell you if it's some weird wrapper around another
binary, though that wasn't too common at bell labs.
Warner
9:08 p.m.
You got my curiosity up and found the V5 and V6 source code (I did not have
V4 easy to get, where I am today) ;-)
A big clue of it being C will be having crt0.s (below) in the first few
bytes of the disassembled code. We see the a.out header (i.e. start at
offset 20 for the code) and look what's there. I'm going to guess that is
at 046 is the address of _main, from the call instruction at address 034.
The Trap 1 is a sys exit @ address 044.
But .. the V6 crt0.s source has a call to _exit, which is lacking in the
binary below. So it means that the binary was not created with the C
runtime and probably not the v6 C compiler in the sources. So I took a
peak at the V6 crt0.s and guess what -- it matches!
So, I'm going to guess the binary was compiled and linked with an earlier
compiler. Ao ... if I had to guess, the programs are similar, but possibly
different.
% more wump.das
;
; pdp11dasm version 0.0.3
; disassembly of wump
;
000000: 000407 br 20 ; ..
;
000002: 005334 dec @(r4)+ ; \.
000004: 004524 jsr r5,(r4)+ ; T.
000006: 002312 bge 37777777634 ; J.
000010: 000000 halt ; ..
000012: 000000 halt ; ..
000014: 000000 halt ; ..
;
000016: 000001 wait ; ..
000020: 170011 setd ; .p
000022: 010600 mov r6,r0 ; ..
000024: 011046 mov (r0),-(r6) ; &.
000026: 005720 tst (r0)+ ; P.
000030: 010066 000002 mov r0,2(r6) ; 6...
000034: 004767 000006 call 46 ; w...
000040: 022626 cmp (r6)+,(r6)+ ; .%
000042: 005000 clr r0 ; ..
000044: 104401 trap 1 ; ..
000046: 004567 005174 jsr r5,5246 ; w.|.
000052: 005746 tst -(r6) ; f.
000054: 012716 011230 mov #11230,(r6) ; N...
000060: 004737 002776 call @#2776 ; _.~.
000064: 004767 002262 call 2352 ; w.2.
000070: 022700 000171 cmp #171,r0 ; @%y.
000074: 001027 bne 154 ; ..
000076: 005004 clr r4 ; ..
000100: 010400 mov r4,r0 ; ..
000102: 006300 asl r0 ; @.
000104: 005760 005334 tst 5334(r0) ; p.\.
000110: 001421 beq 154 ; ..
000112: 032704 000001 bit #1,r4 ; D5..
000116: 001403 beq 126 ; ..
000120: 012716 000024 mov #24,(r6) ; N...
000124: 000402 br 132 ; ..
;
000126: 012716 000003 mov #3,(r6) ; N...
000132: 010400 mov r4,r0 ; ..
000134: 006300 asl r0 ; @.
000136: 016046 005334 mov 5334(r0),-(r6) ; &.\.
000142: 004737 002776 call @#2776 ; _.~.
V6: s4/crt0.s:
/ C runtime startoff
.globl savr5
.globl _exit
.globl _main
start:
setd
mov sp,r0
mov (r0),-(sp)
tst (r0)+
mov r0,2(sp)
jsr pc,_main
mov r0,(sp)
jsr pc,*$_exit
sys exit
.bss
savr5: .=.+2
V5: s4/crt0.s:
/ C runtime startoff
.globl savr5
.globl _main
start:
setd
mov sp,r0
mov (r0),-(sp)
tst (r0)+
mov r0,2(sp)
jsr pc,_main
cmp (sp)+,(sp)+
clr r0
sys exit
.bss
savr5: .=.+2
On Mon, Jan 6, 2020 at 1:48 PM Warner Losh <imp(a)bsdimp.com> wrote:
On Mon, Jan 6, 2020 at 11:38 AM Will Senn <will.senn(a)gmail.com> wrote:
On 1/6/20 12:29 PM, Warner Losh wrote:
The good news is that disassembly will tell you right away if it was
written in C or not.
OK. I give up. How?
Generally, the C compiler generates code that's quite distinctive (at
least PCC does, not sure about Dennis' compiler). People writing free
assembler tend to do really weird things for function entry / return.
And it will likely tell you if it's some weird wrapper around another
binary, though that wasn't too common at bell labs.
Warner
9:38 p.m.
Some day .... So I took a peak at the V5 crt0.s and guess what -- it
matches!
On Mon, Jan 6, 2020 at 4:08 PM Clem Cole <clemc(a)ccc.com> wrote:
You got my curiosity up and found the V5 and V6 source
code (I did not
have V4 easy to get, where I am today) ;-)
A big clue of it being C will be having crt0.s (below) in the first few
bytes of the disassembled code. We see the a.out header (i.e. start at
offset 20 for the code) and look what's there. I'm going to guess that is
at 046 is the address of _main, from the call instruction at address 034.
The Trap 1 is a sys exit @ address 044.
But .. the V6 crt0.s source has a call to _exit, which is lacking in the
binary below. So it means that the binary was not created with the C
runtime and probably not the v6 C compiler in the sources. So I took a
peak at the V6 crt0.s and guess what -- it matches!
So, I'm going to guess the binary was compiled and linked with an earlier
compiler. Ao ... if I had to guess, the programs are similar, but possibly
different.
% more wump.das
;
; pdp11dasm version 0.0.3
; disassembly of wump
;
000000: 000407 br 20 ; ..
;
000002: 005334 dec @(r4)+ ; \.
000004: 004524 jsr r5,(r4)+ ; T.
000006: 002312 bge 37777777634 ; J.
000010: 000000 halt ; ..
000012: 000000 halt ; ..
000014: 000000 halt ; ..
;
000016: 000001 wait ; ..
000020: 170011 setd ; .p
000022: 010600 mov r6,r0 ; ..
000024: 011046 mov (r0),-(r6) ; &.
000026: 005720 tst (r0)+ ; P.
000030: 010066 000002 mov r0,2(r6) ; 6...
000034: 004767 000006 call 46 ; w...
000040: 022626 cmp (r6)+,(r6)+ ; .%
000042: 005000 clr r0 ; ..
000044: 104401 trap 1 ; ..
000046: 004567 005174 jsr r5,5246 ; w.|.
000052: 005746 tst -(r6) ; f.
000054: 012716 011230 mov #11230,(r6) ; N...
000060: 004737 002776 call @#2776 ; _.~.
000064: 004767 002262 call 2352 ; w.2.
000070: 022700 000171 cmp #171,r0 ; @%y.
000074: 001027 bne 154 ; ..
000076: 005004 clr r4 ; ..
000100: 010400 mov r4,r0 ; ..
000102: 006300 asl r0 ; @.
000104: 005760 005334 tst 5334(r0) ; p.\.
000110: 001421 beq 154 ; ..
000112: 032704 000001 bit #1,r4 ; D5..
000116: 001403 beq 126 ; ..
000120: 012716 000024 mov #24,(r6) ; N...
000124: 000402 br 132 ; ..
;
000126: 012716 000003 mov #3,(r6) ; N...
000132: 010400 mov r4,r0 ; ..
000134: 006300 asl r0 ; @.
000136: 016046 005334 mov 5334(r0),-(r6) ; &.\.
000142: 004737 002776 call @#2776 ; _.~.
V6: s4/crt0.s:
/ C runtime startoff
.globl savr5
.globl _exit
.globl _main
start:
setd
mov sp,r0
mov (r0),-(sp)
tst (r0)+
mov r0,2(sp)
jsr pc,_main
mov r0,(sp)
jsr pc,*$_exit
sys exit
.bss
savr5: .=.+2
V5: s4/crt0.s:
/ C runtime startoff
.globl savr5
.globl _main
start:
setd
mov sp,r0
mov (r0),-(sp)
tst (r0)+
mov r0,2(sp)
jsr pc,_main
cmp (sp)+,(sp)+
clr r0
sys exit
.bss
savr5: .=.+2
On Mon, Jan 6, 2020 at 1:48 PM Warner Losh <imp(a)bsdimp.com> wrote:
On Mon, Jan 6, 2020 at 11:38 AM Will Senn <will.senn(a)gmail.com> wrote:
On 1/6/20 12:29 PM, Warner Losh wrote:
The good news is that disassembly will tell you right away if it was
written in C or not.
OK. I give up. How?
Generally, the C compiler generates code that's quite distinctive (at
least PCC does, not sure about Dennis' compiler). People writing free
assembler tend to do really weird things for function entry / return.
And it will likely tell you if it's some weird wrapper around another
binary, though that wasn't too common at bell labs.
Warner
10:14 p.m.
You have V4 sources? The TUHS archive doesn't have them that I've seen...
Warner
On Mon, Jan 6, 2020, 2:38 PM Clem Cole <clemc(a)ccc.com> wrote:
Some day .... So I took a peak at the V5 crt0.s and
guess what -- it
matches!
On Mon, Jan 6, 2020 at 4:08 PM Clem Cole <clemc(a)ccc.com> wrote:
> You got my curiosity up and found the V5 and V6 source code (I did not
> have V4 easy to get, where I am today) ;-)
>
> A big clue of it being C will be having crt0.s (below) in the first few
> bytes of the disassembled code. We see the a.out header (i.e. start at
> offset 20 for the code) and look what's there. I'm going to guess that is
> at 046 is the address of _main, from the call instruction at address 034.
> The Trap 1 is a sys exit @ address 044.
> But .. the V6 crt0.s source has a call to _exit, which is lacking in the
> binary below. So it means that the binary was not created with the C
> runtime and probably not the v6 C compiler in the sources. So I took a
> peak at the V6 crt0.s and guess what -- it matches!
>
> So, I'm going to guess the binary was compiled and linked with an earlier
> compiler. Ao ... if I had to guess, the programs are similar, but possibly
> different.
>
> % more wump.das
> ;
> ; pdp11dasm version 0.0.3
> ; disassembly of wump
> ;
> 000000: 000407 br 20 ; ..
> ;
> 000002: 005334 dec @(r4)+ ; \.
> 000004: 004524 jsr r5,(r4)+ ; T.
> 000006: 002312 bge 37777777634 ; J.
> 000010: 000000 halt ; ..
> 000012: 000000 halt ; ..
> 000014: 000000 halt ; ..
> ;
> 000016: 000001 wait ; ..
> 000020: 170011 setd ; .p
> 000022: 010600 mov r6,r0 ; ..
> 000024: 011046 mov (r0),-(r6) ; &.
> 000026: 005720 tst (r0)+ ; P.
> 000030: 010066 000002 mov r0,2(r6) ; 6...
> 000034: 004767 000006 call 46 ; w...
> 000040: 022626 cmp (r6)+,(r6)+ ; .%
> 000042: 005000 clr r0 ; ..
> 000044: 104401 trap 1 ; ..
> 000046: 004567 005174 jsr r5,5246 ; w.|.
> 000052: 005746 tst -(r6) ; f.
> 000054: 012716 011230 mov #11230,(r6) ; N...
> 000060: 004737 002776 call @#2776 ; _.~.
> 000064: 004767 002262 call 2352 ; w.2.
> 000070: 022700 000171 cmp #171,r0 ; @%y.
> 000074: 001027 bne 154 ; ..
> 000076: 005004 clr r4 ; ..
> 000100: 010400 mov r4,r0 ; ..
> 000102: 006300 asl r0 ; @.
> 000104: 005760 005334 tst 5334(r0) ; p.\.
> 000110: 001421 beq 154 ; ..
> 000112: 032704 000001 bit #1,r4 ; D5..
> 000116: 001403 beq 126 ; ..
> 000120: 012716 000024 mov #24,(r6) ; N...
> 000124: 000402 br 132 ; ..
> ;
> 000126: 012716 000003 mov #3,(r6) ; N...
> 000132: 010400 mov r4,r0 ; ..
> 000134: 006300 asl r0 ; @.
> 000136: 016046 005334 mov 5334(r0),-(r6) ; &.\.
> 000142: 004737 002776 call @#2776 ; _.~.
>
>
>
>
>
> V6: s4/crt0.s:
> / C runtime startoff
>
> .globl savr5
> .globl _exit
>
> .globl _main
>
> start:
> setd
> mov sp,r0
> mov (r0),-(sp)
> tst (r0)+
> mov r0,2(sp)
> jsr pc,_main
> mov r0,(sp)
> jsr pc,*$_exit
> sys exit
>
> .bss
> savr5: .=.+2
>
> V5: s4/crt0.s:
> / C runtime startoff
>
> .globl savr5
>
> .globl _main
>
> start:
> setd
> mov sp,r0
> mov (r0),-(sp)
> tst (r0)+
> mov r0,2(sp)
> jsr pc,_main
> cmp (sp)+,(sp)+
> clr r0
> sys exit
>
> .bss
> savr5: .=.+2
>
> On Mon, Jan 6, 2020 at 1:48 PM Warner Losh <imp(a)bsdimp.com> wrote:
>
>>
>>
>> On Mon, Jan 6, 2020 at 11:38 AM Will Senn <will.senn(a)gmail.com> wrote:
>>
>>> On 1/6/20 12:29 PM, Warner Losh wrote:
>>>
>>> The good news is that disassembly will tell you right away if it was
>>> written in C or not.
>>>
>>>
>>> OK. I give up. How?
>>>
>>
>> Generally, the C compiler generates code that's quite distinctive (at
>> least PCC does, not sure about Dennis' compiler). People writing free
>> assembler tend to do really weird things for function entry / return.
>>
>> And it will likely tell you if it's some weird wrapper around another
>> binary, though that wasn't too common at bell labs.
>>
>> Warner
>>
>
11:46 p.m.
Sent from my iPhone
On Jan 6, 2020, at 3:38 PM, Clem Cole
<clemc(a)ccc.com> wrote:
Some day .... So I took a peak at the V5 crt0.s and guess what -- it matches!
Awesome. Thanks for sharing your approach to the disasm.
On another note,You said you looked in v5 and v6 source code? I looked at tuhs and didn’t
see anything earlier than v7. Where did you find them?
Thanks,
Will
7 Jan
7 Jan
8:04 p.m.
On Mon, Jan 06, 2020 at 11:48:02AM -0700, Warner Losh wrote:
On Mon, Jan 6, 2020 at 11:38 AM Will Senn
<will.senn(a)gmail.com> wrote:
A while back I did some analysis (https://ewe2.ninja/computers/cno/) of
another source-less v6 binary, cno. Fortunately, it hadn't been stripped but I
still did some disasembly because of the interesting differences. v6 binaries
have a different crt0 preamble and simpler subroutine setup, and I narrowed
dowh the library code to an intermediate stage of iolib (which IIRC still
exists in the UNSW archive on TUHS). There's a few cribs in that essay to help
you figure out some basic things, pdp11 assembly isn't hard to decode.
--
I love deadlines. I love the whooshing noise as they fly by.
On 1/6/20 12:29 PM, Warner Losh wrote:
The good news is that disassembly will tell you right away if it was
written in C or not.
OK. I give up. How?
Generally, the C compiler generates code that's quite distinctive (at least
PCC does, not sure about Dennis' compiler). People writing free assembler
tend to do really weird things for function entry / return.
And it will likely tell you if it's some weird wrapper around another
binary, though that wasn't too common at bell labs.
Warner
9:08 p.m.
Nice job -- one comment: You said at the end of your document:
"Both cno and phx were written at what appears to have been what I would
call v6b, version 6 as the standard library was moving from libS to libc,
as Dennis Ritchie formalised the library proper. This can be seen in crt0.s
where the form is not of standard V6 but of the libc V6 before it became
standard in V7 and changed yet again. I was able to track this using the
UNSW archives which have both libraries at the critical point."
I will place a bet it is not your v6b idea... (which was basically V6 plus
Ken's patch tape - although as Noel and I have decoded some of PWB 1.0 -
which was based on V6 too -- made it into the wild in a couple of places).
Anyway, I think you are seeing code output from what was called the
'Typesetter C" compiler release which came out before V7 and was needed to
compile troff *et al.* which actually what conforms with the original
K&R. Indeed, that compiler used libS as the library.
The other thing, many v6 implementations (like CMU's and I think MIT) had a
preprocessor (it was called /lib/cpp ) before we got Typesetter C. i.e. a
version of cpp that predated the Riesner cpp rewrite that was in Typesetter
C and later V7. Steve Johnson probably knows the history of the
preprocessor better than I. I know when we went through the V5 to V6
upgrade we somehow had a preprocessor. I remember being curious about it
and then being disappointed it was not as good as the BLISS macro facility.
But ... neither the binary nor the sources for that cpp are in Warner's
Archives for V6 when I just looked.
The Interdata 7/32 stuff Warren has is a V6 port, and has a version of cpp,
but a note in the source says it is based on what looks like the Typesetter
C compiler - which was sometimes called the Level 7 compiler because Dennis
had told us all it was the new compiler for the next releases (TS and V7).
PWB 1.0 has a copy of cpp in the sources, but a quick look its not clear
how close the V7 version it is.
So, unless anyone else can illuminate, I'm not sure where the first cpp
that some of us using v6 had originated.
On Tue, Jan 7, 2020 at 3:14 PM Sean Dwyer via TUHS <tuhs(a)minnie.tuhs.org>
wrote:
On Mon, Jan 06, 2020 at 11:48:02AM -0700, Warner Losh
wrote:
On Mon, Jan 6, 2020 at 11:38 AM Will Senn
<will.senn(a)gmail.com> wrote:
least
On 1/6/20 12:29 PM, Warner Losh wrote:
The good news is that disassembly will tell you right away if it was
written in C or not.
OK. I give up. How?
Generally, the C compiler generates code that's quite distinctive (at PCC does, not sure about Dennis' compiler).
People writing free assembler
tend to do really weird things for function entry / return.
And it will likely tell you if it's some weird wrapper around another
binary, though that wasn't too common at bell labs.
Warner
A while back I did some analysis (https://ewe2.ninja/computers/cno/) of
another source-less v6 binary, cno. Fortunately, it hadn't been stripped
but I
still did some disasembly because of the interesting differences. v6
binaries
have a different crt0 preamble and simpler subroutine setup, and I narrowed
dowh the library code to an intermediate stage of iolib (which IIRC still
exists in the UNSW archive on TUHS). There's a few cribs in that essay to
help
you figure out some basic things, pdp11 assembly isn't hard to decode.
--
I love deadlines. I love the whooshing noise as they fly by.
8 Jan
8 Jan
6:35 a.m.
On Tue, Jan 07, 2020 at 04:08:08PM -0500, Clem Cole wrote:
I will place a bet it is not your v6b idea... (which
was basically V6 plus
Ken's patch tape - although as Noel and I have decoded some of PWB 1.0 -
which was based on V6 too -- made it into the wild in a couple of places).
Anyway, I think you are seeing code output from what was called the
'Typesetter C" compiler release which came out before V7 and was needed to
compile troff *et al.* which actually what conforms with the original
K&R. Indeed, that compiler used libS as the library.
Ahh, that adds an extra wrinkle to the proceedings :) I wasn't aware of this
version, I was just going on what I disassembled and what I could dig up from
unix sources, but neither am I too surprised that there were intermediate
steps in between!
So, unless anyone else can illuminate, I'm not
sure where the first cpp
that some of us using v6 had originated.
It is as you note, a very confused picture where there was a lot of activity
from several different sources. It's pretty amazing to look at the UNSW and
Usenet archives and see the sheer volume of device and library hacks that were
going on during the v5 and v6 period alone.
On a related question, do we know that sources for code such as the ching
binaries was at least around at the time of the 32V port? I'm unsure when the
sources were lost, was that after V7? A reason I ask is that phx basically
remained untouched but the 32V version of cno was definitely changed in the
early BSDs, although it may have been a binary patch.
--
I love deadlines. I love the whooshing noise as they fly by.
6 Jan
6 Jan
7:10 p.m.
On Mon, 06 Jan 2020 12:38:25 -0600 Will Senn <will.senn(a)gmail.com> wrote:
On 1/6/20 12:29 PM, Warner Losh wrote:
Running strings on the wump binary in Dennis_v6 and comparing
its output with actual strings in the wump.c source n
Henry_Spencerv7 reveals they are pretty much the same.
The good news is that disassembly will tell you
right away if it was
written in C or not.
OK. I give up. How?
8:29 p.m.
On 1/6/20 1:10 PM, Bakul Shah wrote:
On Mon, 06 Jan 2020 12:38:25 -0600 Will Senn
<will.senn(a)gmail.com> wrote:
Oh. That's funny. I
tried strings in v6, it wasn't there. It didn't
occur to me to do it in MacOS...
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
On 1/6/20 12:29 PM, Warner Losh wrote:
Running strings on the wump binary in Dennis_v6 and
comparing
its output with actual strings in the wump.c source n
Henry_Spencerv7 reveals they are pretty much the same. The good news is that disassembly will tell you
right away if it was
written in C or not.
OK. I give up. How?
1569
days inactive
1571
days old
16 comments
5 participants
participants (5)
-
Bakul Shah -
Clem Cole -
Sean Dwyer -
Warner Losh -
Will Senn