TUHS

tuhs@tuhs.org

46 participants
6502 discussions

by KenUnix

Hi, I am having a problem clearing a dup inode. Here is what I have tried: # icheck /dev/rp0 <=== Ran this /dev/rp0: 4244 dup; inode=323, class=data (small) <=== Dup files 231 (r=207,d=7,b=4,c=13) used 4265 (i=115,ii=2,iii=0,d=4146) free 537 missing 0 # icheck -s /dev/rp0 <== Tried to rebuild /dev/rp0: 4244 dup; inode=323, class=data (small) # icheck /dev/rp0 /dev/rp0: 4244 dup; inode=323, class=data (small) files 231 (r=207,d=7,b=4,c=13) used 4265 (i=115,ii=2,iii=0,d=4146) free 536 missing 0 # icheck -b 323 /dev/rp0 <=== Tried /dev/rp0: 4244 dup; inode=323, class=data (small) <=== Dup persists files 231 (r=207,d=7,b=4,c=13) used 4265 (i=115,ii=2,iii=0,d=4146) free 536 missing 0 # Thanks, Ken -- WWL 📚

2 years, 2 months

Re: Unix V7 enblock.c

by jnc＠mercury.lcs.mit.edu

> From: Michael Huff > All of the simh vax tutorials on Gunkies still give instructions to turn > all of the tar files (plus things like miniroot) into a single tap file > for installation. If those are out-of-date, you/someone should get a CHWiki account and update them! :-) Documentation skew from code has always been a problem... Noel

2 years, 2 months

Unix V7 enblock.c

by KenUnix

Morning, I am using enblock to create tap files from tar files. Was a program ever written to convert tap files to tar files or a Linux program that could read tap files? I also see that writing to a tap file from Unix the size increases when writing multiple files however when writing 1 file to the tap file "tar cv0 ..." the tap file still remains at its larger size from the previous larger writes. Is this what is expected? Thanks, Ken -- WWL 📚

2 years, 2 months

Unix/Linux games [was Re: Early GUI on Linux]

by Andy Kosela

On Monday, February 27, 2023, Dan Cross <crossd(a)gmail.com> wrote: > On Mon, Feb 27, 2023 at 12:22 PM Paul Ruizendaal via TUHS <tuhs(a)tuhs.org> > wrote: > > Thanks all for the insights. Let me attempt a summary. > > > <SNIP> > Oh, and lots of games; I had a nice > Solitaire version that I can no longer recall the name of. > > Coming from the 8-bit microcomputer world (Atari 8-bit, C64), and then upgrading to 16-bit (Amiga and PC MS-DOS) I experienced a myriad of unforgettable games on those platforms. They were mostly commercial but they were very much different from modern games. It was the era of innovation and pouring all your soul into the games you produce. I still think that some of them have not been surpassed in quality and playability. I still play them on period correct hardware as they are still extremely fun and challenging. This is my top 10 list (sorted by year): * Prince of Persia * The Secret of Monkey Island * Civilization * Dune II * Master of Orion * Reunion * Warcraft * Ascendancy * Quake * Half-Life As I started to play with Linux in the mid 90s I remember a port of Doom and then Quake, but not that many other games. Can you elaborate more on what Unix afficionados played in the late 80s/early 90s? --Andy

2 years, 2 months

Fwd: Re: Generational development [was Re: Re: Early GUI on Linux]

by Adam Thornton

And, you know, let's say you have all the time and patience in the world and you download the source and read it carefully and determine it's not malicious... I believe there might have been a lecture/paper about this once. https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrust… (I can just hear them damn kids standing on my lawn chanting "You can't spell 'trust' without 'rust'!") I keep trying to give VSCode a go. It seems really nifty. And somehow I keep bouncing off and landing in Emacs, every time. Maybe when I finally get around to writing, rather than cargo-culting TypeScript, or Unity/C#, it'll be a better fit. But for my current life, which is mostly Python...I appear to be sticking with Emacs. Adam

2 years, 2 months

UNIX 4.1 User's Manual Restoration

by segaloco

Got a little present for folks today. Been working on this for a little while now, and while there'll probably be some edits here and there, I believe it to be quite accurate. After the link is a manpage restoration of the UNIX 4.1 User's Manual (3B20S) that I bought a little while ago: https://gitlab.com/segaloco/pwb4u_man The permuted index is the only significant piece that isn't done, but that shouldn't impact the informational value. Note this is just u_man, I haven't found a complimentary a_man copy yet. I hope one will turn up one of these days, but I plan on at least analyzing the gap between System III and System V with regards to those pages as a future project. My process involved diff'ing the available III and V manpage sources and reconciling differences between the two and 4.1 with some copy-paste here and some restoration there. Where differences couldn't be resolved, I simply removed content to match the physical pages. One minute detail that is also not filled in is the page count in M.folio. So I didn't count the pages. Maybe someday. In any case, I appreciate the opportunity this has given me to learn the manpage macros pretty well. Anywho, in the second pass of verifying the changes I took some notes on noteworthy mentions. This list is not an exhaustive analysis but represents some of the areas where significant developments shine through in the text: System III->4.1 (No claims are made as to what occurred at 4.0): - The documentation is cleaned up quite a bit in general, in what seems like a push towards commercial-ready manuals. Many sections are edited to be more clear and descriptive. There is also a notable shift towards gender neutral language. The editors and acknowledgements info are removed, casting an anonymous shadow over the manual maintainers and their muses alike. - The tty manpage is renamed termio, reflecting the shifting terminal interface landscape at this time. - This release adds IPC with a familiar interface to what is in System V. According to various accounts the IPC was under heavy development at this time, but while the underlying components may have been shifting and changing, the documentation changes suggest a relatively stable programmer API by this point. The only IPC-related piece System V adds is icprm(1). - The LP print service is added here. The old lpr system is still there in the background; it is in System V. However, it is relegated to DEC only status. - SGS and COFF development components show up with 4.1 3B-20. No telling what else they officially supported in the 4.x timeframe. The System V pages as described below indicate a number of supported platforms. - The shell gets the $CDPATH and ulimit features - Many system features show a trend towards portability (except the PDP-11, the system appears to be moving away from it) - The Virtual Protocol Machine (VPM) seems to go from targeting KMC11 to UN53 and V.35. Haven't researched what these are yet, but VPM is on the move. - As of 4.1, 3B-20 does *not* support: Fortran, BASIC, Honeywell/GCOS 6000 connectivity, lpr printing, SNOBOL, standalone C - Added pages include cflow(1), cprs(1), cxref(1), dis(1), dump(1) (was a tape dump (1m), now a SGS tool), enable(1), hpio(1), ipcs(1), list(1), lp(1), lpstat(1), newform(1), sadp(1), trouble(1), x25pvc(1), msgctl(2), msgget(2), msgop(2), plock(2), semctl(2), semget(2), semop(2), shmctl(2), shmget(2), shmop(2), sys3b(2), drand48(3c), getcwd(3c), hsearch(3c), ld*(3x) (COFF library), setbuf(3s), stdipc(3c), strtol(3c), termio(4) (renamed from tty(4)), ldfcn(5), mosd(5), mptx(5), jotto(6) - Removed pages include cref(1), dump(1m), fget.odemon(1c), odpd(1c), orjestat(1c), reform(1), tp(1), typo(1), xref(1), tp(4), tty(4) (renamed to termio(4)) - Some pages were skipped and show back up in System V with minimal changes, meaning they were probably in 4.x: adb(1), arcv(1), bs(1), dpd(1c), dpr(1c), efl(1), f77(1), factor(1), fget(1c), fget.demon(1c), fsend(1c), gcat(1c), gcosmail(1c), kas(b)/kun(b)(1), lpd(1c), lpr(1), ratfor(1), scc(1), sno(1), vpr(1) 4.1->System V (Likewise, there was at least a 4.2): - Documentation is cleaned up and edited some more. Almost everywhere that the name "UNIX" occurs, it has been replaced with some variation on "The UNIX System" with a capital S. This is lower case in my 5.0 manual which I have not combed for differences with System V yet. Still, the "system" following is standard by 5.0 it seems. This is right around the time of dashing Bell associations too, so variations of this manual exist with and without the Bell logo on the front, and with varying degrees of modification to explain the legal landscape involved. - Section 3 in particular sees a pretty significant rewrite effort. This coincides with MR 1055 here: https://archive.org/details/unix-system-release-description-system-v/I%20-%… - A new portable archive format is introduced. By the sounds of it, this introduces a new header type into the ar(4) format. - A new 1024-block filesystem is introduced, along with necessary support. - A new synchronous terminal interface is added. - VAX is supported by SGS/COFF now. Additional platforms as suggested by formatting marks in the pages include: Basic-16, Bellmac 32, and 8086, in addition to the already supported 3B-20. Unknown whether these platforms found any support with USG releases. - ex(1) is added (along with vi(1) and edit(1)). There is also the se(1) editor which I don't know much about. - CB-init is added, shaking up the /etc/inittab format and many login-related features. MAUS also steps in from CB for shared memory on PDP-11. - Added pages include asa(1), convert(1), cpp(1), edit(1), ex(1), fsplit(1), ipcrm(1), machid(1), makekey(1), net(1c), nscstat(1c), nsctorje(1c), nusend(1c), scat(1), se(1), stlogin(1), ststat(1), vi(1), maus(2), clock(3c), dial(3c), erf(3m), getut(3c), matherr(3m), memory(3c), sputl(3x), ttyslot(3c), x25*(3c), filehdr(4), gettydefs(4), issue(4), linenum(4), reloc(4), scnhdr(4), syms(4) - Removed pages include vpmc(1c), vpmsave(1c), vpmset(1c), x25pvc(1c), fptrap(3x) That's all I've got. As time goes on I'll start documenting worthwhile tidbits in the Wiki. If there's any question of the contents of any of the pages, I'll happily consult the original and make corrections, and can scan any page to verify the contents if needed. I'll eventually be scanning the whole thing, just not right now. Feel free to open a pull request if you think something needs to change. - Matt G.

2 years, 2 months

Unix v7 vi

by KenUnix

Was work ever done for v7 Unix to support 'vi' when using a tek or vt05 terminal? And, is it available? Thanks, Ken -- WWL 📚

2 years, 2 months

Re: Origins of the SGS (System Generation Software) and COFF (Common Object File Format)

by Paul Winalski

On 2/25/23, Brian Walden <tuhs(a)cuzuco.com> wrote: > It was originaly 205. See A.OUT(V) (the first page) at > https://www.bell-labs.com/usr/dmr/www/man51.pdf it was documented as to > why. > > > The header always contains 6 words: > 1 "br .+14" instruction (205(8)) > 2 The size of the program text > 3 The size of the symbol table > 4 The size of the relocation bits area > 5 The size of a data area > 6 A zero word (unused at present) > > I always found this so elegant in it's simplicity. Just load and start > execution at the start (simplifies exec(2) in the kernel) I always wondered > if this has done anywhere else before, or invenetd first in unix. IBM's Basic Program Support (BPS) for System/360 was a set of stand-alone utilities for developing and running stand-alone programs. BPS/360 wasn't really an operating system because there wasn't any resident kernel. You just IPLed (Initial Program Load; IBM-speak for "boot") your application directly. So the executable format for BPS had a bootstrap loader as the "program header". Not quite the same thing as a.out's 205(8) magic number, but similar in concept. I don't know of any other OS ABI that uses this trick to transfer control to application programs. Microsoft uses something similar in PECOFF. A PECOFF executable for x86 or X86-64 starts with a bit of code in MS-DOS MZ executable format that prints the message "This program cannot be run in DOS mode". -Paul W.

2 years, 2 months

Re: Origins of the SGS (System Generation Software) and COFF (Common Object File Format)

by Brian Walden

It was originaly 205. See A.OUT(V) (the first page) at https://www.bell-labs.com/usr/dmr/www/man51.pdf it was documented as to why. The header always contains 6 words: 1 "br .+14" instruction (205(8)) 2 The size of the program text 3 The size of the symbol table 4 The size of the relocation bits area 5 The size of a data area 6 A zero word (unused at present) I always found this so elegant in it's simplicity. Just load and start execution at the start (simplifies exec(2) in the kernel) I always wondered if this has done anywhere else before, or invenetd first in unix. Theres was also a recent discussion of ar(1). That pdf also explains its magic number a few pages later. It was simply choosen because it seemed unique. A file produced by ar has a "magic number" at the start, followed by the constituent files, each preceded by a file header. The magic number is -147(10), or 177555(8) (it was chosen to be unlikely to occur anywhere else). -Brian On Sat, 25 Feb 2023, Dave Horsfall wrote: > On Thu, 23 Feb 2023, Paul Winalski wrote: > > > a.out was, as object file formats go, a throwback to the stone age from > > the get-go. Even the most primitive of IBM's link editors for > > System/360 supported arbitrary naming of object file sections and the > > ability for the programmer to arrange them in whatever order they > > wished. a.out's restriction to three sections (.text, .data, .bss) did > > manage to get the job done, and even (with ZMAGIC) could support > > demand-paged virtual memory, but only just. > > That may be so, but those guys didn't exactly have the resources of > IBM behind them... > > And I wonder how many people here know the significance of the "407" magic > number? > > -- Dave

2 years, 2 months

Origins of the SGS (System Generation Software) and COFF (Common Object File Format)

by segaloco

Good day all, figured I'd start a thread on this matter as I'm starting to piece enough together to articulate the questions arising in my research. So based on my analysis of the 3B20S UNIX 4.1 manual I've been working through, all evidence points to the formalized SGS package and COFF originating tightly coupled to the 3B-20 line, then growing legs to support VAX, but never quite absorbing PDP-11 in entirety. That said, there are bits and pieces of the manual pages for the object format libraries that suggest there was some providence for PDP-11 in the development of COFF as well. Where this has landed though is a growing curiosity regarding: - Whether SGS and COFF were tightly coupled to one another from the outset, with SGS being supported by the general library routines being developed for the COFF format - Whether COFF was envisioned as a one-size-fits-all object format from its inception or started as an experiment in 3B-20 development that wound up being general enough for other platforms - If, prior to this format, there were any other efforts to produce a unifying binary format and set of development tools, or if COFF was a happy accident from what were a myriad of different architectural toolset streams One of the curious things is how VAX for a brief moment did have its own set of tools and a.out particulars before SGS/COFF. For instance, many of the VAX-targeted utilities in 3.0/System III bear little in common option/manual-wise with the general common SGS utilities in System V. The "not on PDP-11" pages for various SGS components in System V much more closely resemble the 3B-20 utilities in 4.1 than any of the non PDP-11/VAX-only bits in System III. Some examples: - The VAX assembler in System III contains a -dN option indicating the number of bytes to set aside for forward/external references for the linker to fill in. - The VAX assembler in System V contains among others the -n and -m options from 4.1 which indicate to disable address optimization and use m4 respectively - The System V assembler goes on to also include -R (remove input file after completion) -r (VAX only, add .data contents to .text instead) and options -b, -w, and -l to replace the -d1, -d2, and -d4 options indicated in the previous VAX assembler - System V further adds a -V to all the SGS software indicating the version of the software. This is new circa 5.0, absent from the 4.1 manual like the R, r, b, w, and l options - The 4.1 manual's singular ar(1) entry still agrees with the System III version. No arcv(1) is listed, implying the old ar format never made it to 3B-20 - The System V manual has both this ar(1) version as well as the new COFF-supporting version. Not sure if this implies the VAX ar format was expanded to support the COFF stuff for a little while until they decided on a new one or what. - The System III ld (which is implied to support PDP and VAX) survives in System V, but is cut down to supporting PDP-11 only - The COFF-ish ld shows up in 4.1, is then extended to VAX presumably in the same breath as the other COFF-supporting bits by Sys V, leading to two copies like many others, PDP-11-specific stuff and then COFF-specific stuff The picture that starts to form in the context of all of this is, for a little while in the late 70s/early 80s, the software development environments for PDP-11, VAX-11, and 3B-20 were interplaying with each other in often times inconsistent ways. Taking a peek at the 32V manuals, the VAX tools in System III appear to originate with that project, which makes sense. If I'm understanding the timeline, COFF starts to emerge from the 3B-20 project and USG probably decides that's the way to go, a unified format, but with PDP-11 pretty much out the door support wise already, there was little reason to apply that to PDP-11 as well, so the PDP-11 tools get their swan song in System V, original VAX-11 tools from 32V are likely killed off in 4.x, and the stuff that started with the 3B-20 group goes on to dominate the object file format and development software stuff until ELF comes along some time later. I guess other questions this raises are: - Were the original VAX tools built with any attention to compatibility with the PDP-11 bits Ken and Dennis wrote many years prior (based on some option discrepancies, possibly not?) - Do the VAX utilities derive from the Interdata 8/32 work or if there was actually another stream of tools as part of that project? - Was there any interplay between the existing tool streams (original PDP-11, 32V's VAX utilities, possibly Interdata 8/32) and the eventual COFF/SGS stuff, or was the latter pretty well siloed in 3B-20 land until deployment with 4.1? - Matt G.

2 years, 2 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS