From boomer3200 at gmail.com Sun Dec 1 13:28:42 2024 From: boomer3200 at gmail.com (Dan Plassche) Date: Sat, 30 Nov 2024 22:28:42 -0500 (EST) Subject: [TUHS] Typesetter C Compiler and Troff (Re: Re: v6 Unix Documents) In-Reply-To: References: <20241018135806.ysgog7qde6xjodtu@illithid> <179b0bb4-73d1-fc81-b2d3-68b651e58bbd@gmail.com> Message-ID: > Date: Sun, 20 Oct 2024 22:47:43 > From: Jonathan Gray > > > I adapted Tim Newsham's v6 install scripts for PWB if you'd > like to run it on simh. > > https://github.com/jonathangray/pwb/ Thanks, very helpful and worked well. Since I was able to follow the setup script and rebuild the c versions of nroff/troff on PWB 1.0, I took a look at the new c compiler for differences with the UNSW copy. It turns out that the UNSW copy of the c compiler was definitely a earlier version than in PWB. The most noticeable difference in the UNSW stdio library was calloc.c not using malloc. The most major omission in the c compiler was casts and there were also some local changes to cc.c. Based on those differences, I'm thinking that the UNSW copy appears to be from late 1976 to early 1977. I was able to rebuild both the UNSW and the native PWB compiler on PWB 1.0, but not to backport either to vanilla v6. Best, Dan From jnc at mercury.lcs.mit.edu Sun Dec 1 14:21:31 2024 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 30 Nov 2024 23:21:31 -0500 (EST) Subject: [TUHS] Typesetter C Compiler and Troff (Re: Re: v6 Unix Documents) Message-ID: <20241201042131.E7DD318C075@mercury.lcs.mit.edu> > From: > I was able to rebuild both the UNSW and the native PWB compiler on PWB > 1.0, but not to backport either to vanilla v6. Any idea what the problem was? I'm curious, because we ran a version of the Typesetter compiler on the MIT systems, which ran an enhanced V6. Noel From ron at ronnatalie.com Mon Dec 2 01:40:58 2024 From: ron at ronnatalie.com (Ron Natalie) Date: Sun, 01 Dec 2024 15:40:58 +0000 Subject: [TUHS] Typesetter C Compiler and Troff (Re: Re: v6 Unix Documents) In-Reply-To: <20241201042131.E7DD318C075@mercury.lcs.mit.edu> References: <20241201042131.E7DD318C075@mercury.lcs.mit.edu> Message-ID: Agreed, the typesetter C ran on a virgin V6 system. That was the whole point. It came out before most of us got real V7s. ------ Original Message ------ >From "Noel Chiappa" To tuhs at tuhs.org Cc jnc at mercury.lcs.mit.edu Date 11/30/2024 11:21:31 PM Subject [TUHS] Re: Typesetter C Compiler and Troff (Re: Re: v6 Unix Documents) > > From: > > > I was able to rebuild both the UNSW and the native PWB compiler on PWB > > 1.0, but not to backport either to vanilla v6. > >Any idea what the problem was? I'm curious, because we ran a version of the >Typesetter compiler on the MIT systems, which ran an enhanced V6. > > Noel > From clemc at ccc.com Mon Dec 2 03:24:16 2024 From: clemc at ccc.com (Clem Cole) Date: Sun, 1 Dec 2024 12:24:16 -0500 Subject: [TUHS] Typesetter C Compiler and Troff (Re: Re: v6 Unix Documents) In-Reply-To: References: <20241201042131.E7DD318C075@mercury.lcs.mit.edu> Message-ID: Exactly -- remember Dennis and Brian wrote K&R in 1978 on V6, not PWB and not V7 (or anything from Summit like TS). When Brian's typesetter independent troff was released, that updated language was needed. That was what we referred to as "typesetter C". Brian and Dennis would have put together that kit. My >>guess<< is that Mashey et al. and the Summit folks forked Dennis compiler somewhere before this time -- so what got packaged with the typesetter kit vs what got packed with Mashey and the team's kit are close but >>slightly<< different. ᐧ On Sun, Dec 1, 2024 at 10:49 AM Ron Natalie wrote: > Agreed, the typesetter C ran on a virgin V6 system. That was the whole > point. It came out before most of us got real V7s. > > > > ------ Original Message ------ > From "Noel Chiappa" > To tuhs at tuhs.org > Cc jnc at mercury.lcs.mit.edu > Date 11/30/2024 11:21:31 PM > Subject [TUHS] Re: Typesetter C Compiler and Troff (Re: Re: v6 Unix > Documents) > > > > From: > > > > > I was able to rebuild both the UNSW and the native PWB compiler on > PWB > > > 1.0, but not to backport either to vanilla v6. > > > >Any idea what the problem was? I'm curious, because we ran a version of > the > >Typesetter compiler on the MIT systems, which ran an enhanced V6. > > > > Noel > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Mon Dec 2 03:27:04 2024 From: clemc at ccc.com (Clem Cole) Date: Sun, 1 Dec 2024 12:27:04 -0500 Subject: [TUHS] Typesetter C Compiler and Troff (Re: Re: v6 Unix Documents) In-Reply-To: References: <20241201042131.E7DD318C075@mercury.lcs.mit.edu> Message-ID: I should point out to add to the confusion, originally Mashey's team - the PWB 1.0 folks are != USG (Summit folks) although the later took over the PWB work as I understand it. ᐧ On Sun, Dec 1, 2024 at 12:24 PM Clem Cole wrote: > Exactly -- remember Dennis and Brian wrote K&R in 1978 on V6, not PWB and > not V7 (or anything from Summit like TS). When Brian's typesetter > independent troff was released, that updated language was needed. That > was what we referred to as "typesetter C". Brian and Dennis would have put > together that kit. My >>guess<< is that Mashey et al. and the Summit > folks forked Dennis compiler somewhere before this time -- so what got > packaged with the typesetter kit vs what got packed with Mashey and the > team's kit are close but >>slightly<< different. > ᐧ > > On Sun, Dec 1, 2024 at 10:49 AM Ron Natalie wrote: > >> Agreed, the typesetter C ran on a virgin V6 system. That was the whole >> point. It came out before most of us got real V7s. >> >> >> >> ------ Original Message ------ >> From "Noel Chiappa" >> To tuhs at tuhs.org >> Cc jnc at mercury.lcs.mit.edu >> Date 11/30/2024 11:21:31 PM >> Subject [TUHS] Re: Typesetter C Compiler and Troff (Re: Re: v6 Unix >> Documents) >> >> > > From: >> > >> > > I was able to rebuild both the UNSW and the native PWB compiler >> on PWB >> > > 1.0, but not to backport either to vanilla v6. >> > >> >Any idea what the problem was? I'm curious, because we ran a version of >> the >> >Typesetter compiler on the MIT systems, which ran an enhanced V6. >> > >> > Noel >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjenkin at canb.auug.org.au Wed Dec 4 13:17:49 2024 From: sjenkin at canb.auug.org.au (sjenkin at canb.auug.org.au) Date: Wed, 4 Dec 2024 14:17:49 +1100 Subject: [TUHS] After 50 years, what has the Impact of Unix been? Message-ID: <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> I was looking at the question of “impact of Unix" and thought that: initiating (Portable) Open Source Software including the BSD TCP/IP & Berkeley sockets libraries, the Unix -> Minix -> Linux -> Android sequence and BSD -> NeXtstep -> OS/X -> iOS sequence, plus running the Top 500 supercomputers and most of the Top 500 websites, including the infrastructure for trillion dollars companies, Facebook, Amazon (Netflix uses them), and Google plus so many embedded Linux / NetBSD based appliances even going into space - on small experiments or driving SpaceX’s Falcon 9 & presumably Starship, would be a slam-dunk for “really high impact” - dominating everywhere important, except Windows desktops. Unix wasn’t just a ’research project’, it was the result of years of work by a team of very capable, professional programmers, who weren’t looking for kudos or recognition, nor trying to add every conceivable ‘feature’ possible, but the inverse: how _small_ could it be and still be enough. When it left the Labs, Unix wasn’t just “Performant”, it came with a very useful set of tools for creating other tools (‘developing’) and while the kernel wasn’t perfect (some ‘panic’s), it was of “Production Quality”. For v6, I believe there were patches for 50-100 bugs circulating, perhaps the first demonstration of “no bug is intractable with ‘many eyeballs’”. All that in under 5 years of ‘development’, with the “initial release” stable & performant enough for cash-strapped Universities to gamble their reputations & budgets on running it. Imagine the grief academics would’ve got if their basic teaching systems failed continuously! This adoption path pushed Unix through another barrier: ’Security’ - with a lot of bright, bored & curious students banging on it as hard as they could for bragging rights. How long, in releases or years, did it take for other O/S’s to hit the “very stable” benchmark? I don’t know enough of Linux to answer that definitively, the *BSD’s grew there through usage and contribution, while Microsoft NT derivates widely suffered “Blue Screen of Death” for years. Even now, MS-Windows has serious Security / compromise issues, like the highly visible, global “Crowdstrike” event. Not a break-in or takeover, but an own-goal from Security perimeter control. ========== I now think Unix has had a much larger, direct and important impact - the C language and associated tools & libraries that begat modern toolchains and endless portability across platforms. In 1991, Bill Plauger had a year sabbatical at UNSW in Sydney, and happened to say : “C is wallpaper - people expect it everywhere”. C gained formal recognition with the POSIX standard, satisfying conservative users / enterprises that it wasn’t the work of a bunch of Hippies or ill-disciplined Hackers. Even Microsoft wrote 32-bit Windows NT in C, I presume starting by writing it’s own compiler and toolchain to start. Borland, Watcom and many others - including Microsoft - offered (Visual) C compile & build environments for Windows, directly responsible for creating the ’shrink-wrap’ third party software market that drove sales of Windows and x86 machines. Nobody had seen a market for a billion systems before, nor sold 300M+ CPU’s in a single year. People don’t buy Silicon Chips or nice Boxes, they buy Applications that solve their problems: Software drives Sales of Hardware - something that IBM deeply understood first with first the 1401 line, then 360-series. The other ’small’ achievement of C and Unix was creating the market for RISC chips. MIPS in the mid-1980’s was only able to design and build the first commercial RISC chip because it knew it could port Unix to it and find an immediate market - not at zero-cost, but a tiny fraction of what every other Vendor had done before reinventing the wheel from scratch to provide incompatible O/S & tools for their hardware. Unix on MIPS not only came with a host of proven software, that a large pool of people knew how to use, but it arrived as “Production Quality” - the porting team had to test their parts - compiler, linker, libraries - hard, but could trust the existing high-quality codebase. In "A New Golden Age for Computer Architecture”, 2019 by Hennessy & Patterson, make an aside: In today's post-PC era, x86 shipments have fallen almost 10% per year since the peak in 2011, while chips with RISC processors have skyrocketed to 20 billion. Today, 99% of 32-bit and 64-bit processors are RISC. i suggest this goes back to PCC followed by the MIPS R2000 - made possible by Dennis’ C language. The 1977 invention of ‘pcc’ and rewriting of Unix for cross-machine portability was the first time I’m aware of this being done. ( Miller @ UoW did a one-off hack, not to devalue his work, he ported, didn’t invent a multi-target portable compiler ) One of the effects of “portable C” was creating whole new industries for third party software developers or enabling niche products, like CISCO routers and the many embedded devices. C and Unix came with the tools to create new languages and new tools. AWK, sed (!) and shells are obvious examples, with Perl, Python & PHP very big in Internet of 2000. C was a new class of language - a tool to create tools. It creates a perfect mechanism to bootstrap any new language, tool or product, allowing to be refined & used enough to become reliable before being made self-hosting. Very widely used languages such as Python are written in C. ORACLE achieved its market dominance by providing ‘portability’ - exactly the same on every platform. Underpinned by portable C. The original 1127 team went on to create other systems and languages, not the least being a new Software Engineering tool, “Go” / golang, addressing a whole slew of deficiencies in the C/C++ approach and We’d have no Internet today without Apache written in C and being ported to every environment. Also, there’s a connection between C and ‘modern’ Software Engineering - distributed Repositories, automated builds & regression tests, and the many toolchains and tools used. They tended to be built in C to address problems (Open Source) developers were finding with existing toolchains. ‘make’ arose at Bell Labs to automate builds, along with PWB and Writers Workbench. There’s two questions / observations about 50 years of C in broad use: - Just how much C is out there and used ‘in production’? - C is ‘obviously’ a product of the 1970’s, not reflecting needs of modern hardware, networks, storage and systems, but _what_ can replace it? There is simply too much critical code written in C to convert it to another ‘better, modern’ language. Any new language that is a simple 1:1 rewriting of C cannot address any of the deficiencies, while any incompatible language requires redesign and reimplementation of everything - an unachievable goal. The Linux Kernel’s “rust” project shows the extent of the problem - even with the best team of the best developers, its a mammoth undertaking, with uncertain payoffs, unquantifiable effort & deadlines. My thesis is that portable, standard C: - not only co-evolved with other tools & needs to create the Modern Software Engineering environment, the basis for multiple Trillion dollar enterprises (FAANG) but - drove the biggest, most profitable software market ever seen (Wintel) - which drove sales volume of x86 chips (& DRAM, motherboards, LAN, GPU, monitors, peripherals…) over 2-3 decades, - which drove Silicon Valley, paying for new generations of Fabs and lowering chip prices further & further - and eventually created the Fabless RISC CPU company, which in the Post-PC era absolutely dominates chip sales. No Software, no Silicon… Gordon Moore, in an early comment on his 1968 startup with Robert Noyce, said: “we are the real revolutionaries" (vs Hippies & 1967 Summer of Love). I think Ken & Dennis [ and 1127/ Bell Labs folk ] can say the same. ========== I’ve written some notes, with links to Programming Languages, especially Jean Sammet’s Histories, and would like some critiques, suggestions & corrections if people have time and interest. Unix and C are intimately related - neither was possible or useful without the other. i think there’s an interesting article in there, but I’m not sure I have what it takes to write it, not in a finite time :) Very happy to help anyone who does! Did-C-lang-create-modern-software-industry.txt steve jenkin 04 - dec - 2024 ========== -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin From tuhs at tuhs.org Wed Dec 4 13:57:46 2024 From: tuhs at tuhs.org (Jan Schaumann via TUHS) Date: Tue, 3 Dec 2024 22:57:46 -0500 Subject: [TUHS] The History of the BSD Daemon Message-ID: Marshall Kirk McKusick gave a talk on the history of the BSD Daemon: https://www.youtube.com/watch?v=AeDaD-CEzzg "This video tells the history of the BSD Daemon. It starts with the first renditions in the 1970s of the daemons that help UNIX systems provide services to users. These early daemons were the inspiration for the well-known daemon created by John Lasseter in the early 1980s that became synonymous with BSD as they adorned the covers of the first three editions of `The Design and Implementation of the BSD Operating System' textbooks. The talk will also highlight many of the shirt designs that featured the BSD Daemon." From imp at bsdimp.com Wed Dec 4 14:07:21 2024 From: imp at bsdimp.com (Warner Losh) Date: Tue, 3 Dec 2024 21:07:21 -0700 Subject: [TUHS] The History of the BSD Daemon In-Reply-To: References: Message-ID: On Tue, Dec 3, 2024, 8:57 PM Jan Schaumann via TUHS wrote: > Marshall Kirk McKusick gave a talk on the history of > the BSD Daemon: > > https://www.youtube.com/watch?v=AeDaD-CEzzg > > "This video tells the history of the BSD Daemon. It > starts with the first renditions in the 1970s of the > daemons that help UNIX systems provide services to > users. These early daemons were the inspiration for > the well-known daemon created by John Lasseter in the > early 1980s that became synonymous with BSD as they > adorned the covers of the first three editions of `The > Design and Implementation of the BSD Operating System' > textbooks. The talk will also highlight many of the > shirt designs that featured the BSD Daemon." > Great talk and awesome T Shirts... Warner > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Dec 4 18:50:38 2024 From: imp at bsdimp.com (Warner Losh) Date: Wed, 4 Dec 2024 01:50:38 -0700 Subject: [TUHS] The History of the BSD Daemon In-Reply-To: References: Message-ID: https://youtu.be/7d7fwAE-2Aw?si=au0vDr2XAHfAJOc1 Has remastered sound... sounds a lot better to my ears. Warner On Tue, Dec 3, 2024, 8:57 PM Jan Schaumann via TUHS wrote: > Marshall Kirk McKusick gave a talk on the history of > the BSD Daemon: > > https://www.youtube.com/watch?v=AeDaD-CEzzg > > "This video tells the history of the BSD Daemon. It > starts with the first renditions in the 1970s of the > daemons that help UNIX systems provide services to > users. These early daemons were the inspiration for > the well-known daemon created by John Lasseter in the > early 1980s that became synonymous with BSD as they > adorned the covers of the first three editions of `The > Design and Implementation of the BSD Operating System' > textbooks. The talk will also highlight many of the > shirt designs that featured the BSD Daemon." > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.donner at gmail.com Wed Dec 4 23:05:45 2024 From: marc.donner at gmail.com (Marc Donner) Date: Wed, 4 Dec 2024 08:05:45 -0500 Subject: [TUHS] After 50 years, what has the Impact of Unix been? In-Reply-To: <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> References: <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> Message-ID: I would add one more important impact: making data a first class component of the computing environment. With the notion of pipes it became possible to operate on data quickly and flexibly. There was nothing new from a fundamental capability point of view, but the ease with which one could construct pipelines enabled rapid experimentation and encouraged the development of pipe-able components to add to the tool set. I may not have articulated this as well as it deserves. Marc ===== nygeek.net mindthegapdialogs.com/home On Wed, Dec 4, 2024 at 3:43 AM wrote: > I was looking at the question of “impact of Unix" and thought that: > > initiating (Portable) Open Source Software including the BSD > TCP/IP & Berkeley sockets libraries, > the Unix -> Minix -> Linux -> Android sequence > and BSD -> NeXtstep -> OS/X -> iOS sequence, > plus running the Top 500 supercomputers and most of the Top 500 > websites, > including the infrastructure for trillion dollars companies, > Facebook, Amazon (Netflix uses them), and Google > plus so many embedded Linux / NetBSD based appliances > even going into space - on small experiments or driving SpaceX’s > Falcon 9 & presumably Starship, > > would be a slam-dunk for “really high impact” > - dominating everywhere important, except Windows desktops. > > Unix wasn’t just a ’research project’, it was the result of years of work > by a team of very capable, professional programmers, > who weren’t looking for kudos or recognition, nor trying to add every > conceivable ‘feature’ possible, but the inverse: > > how _small_ could it be and still be enough. > > When it left the Labs, Unix wasn’t just “Performant”, it came with a very > useful set of tools for creating other tools (‘developing’) > and while the kernel wasn’t perfect (some ‘panic’s), it was of “Production > Quality”. > > For v6, I believe there were patches for 50-100 bugs circulating, perhaps > the first demonstration of “no bug is intractable with ‘many eyeballs’”. > > All that in under 5 years of ‘development’, with the “initial release” > stable & performant enough for cash-strapped Universities > to gamble their reputations & budgets on running it. > Imagine the grief academics would’ve got if their basic teaching systems > failed continuously! > > This adoption path pushed Unix through another barrier: > > ’Security’ - with a lot of bright, bored & curious students > banging on it as hard as they could for bragging rights. > > How long, in releases or years, did it take for other O/S’s to hit the > “very stable” benchmark? > > I don’t know enough of Linux to answer that definitively, the *BSD’s grew > there through usage and contribution, > while Microsoft NT derivates widely suffered “Blue Screen of Death” for > years. > > Even now, MS-Windows has serious Security / compromise issues, like the > highly visible, global “Crowdstrike” event. > Not a break-in or takeover, but an own-goal from Security perimeter > control. > > ========== > > I now think Unix has had a much larger, direct and important impact > > - the C language and associated tools & libraries > that begat modern toolchains and endless portability > across platforms. > > In 1991, Bill Plauger had a year sabbatical at UNSW in Sydney, > and happened to say : > “C is wallpaper - people expect it everywhere”. > > C gained formal recognition with the POSIX standard, satisfying > conservative users / enterprises that it wasn’t the work of a bunch of > Hippies or ill-disciplined Hackers. > > Even Microsoft wrote 32-bit Windows NT in C, I presume starting by writing > it’s own compiler and toolchain to start. > > Borland, Watcom and many others - including Microsoft - offered (Visual) C > compile & build environments for Windows, > directly responsible for creating the ’shrink-wrap’ third party software > market that drove sales of Windows and x86 machines. > > Nobody had seen a market for a billion systems before, nor sold 300M+ > CPU’s in a single year. > > People don’t buy Silicon Chips or nice Boxes, they buy Applications that > solve their problems: > > Software drives Sales of Hardware > - something that IBM deeply understood first with first the 1401 > line, then 360-series. > > > The other ’small’ achievement of C and Unix was creating the market for > RISC chips. > MIPS in the mid-1980’s was only able to design and build the first > commercial RISC chip > because it knew it could port Unix to it and find an immediate market > - not at zero-cost, but a tiny fraction of what every other Vendor > had done before > reinventing the wheel from scratch to provide incompatible > O/S & tools for their hardware. > > Unix on MIPS not only came with a host of proven software, that a large > pool of people knew how to use, > but it arrived as “Production Quality” - the porting team had to test > their parts - compiler, linker, libraries - hard, but could trust the > existing high-quality codebase. > > In "A New Golden Age for Computer Architecture”, 2019 by Hennessy & > Patterson, > make an aside: > > In today's post-PC era, x86 shipments have fallen almost 10% per > year since the peak in 2011, > while chips with RISC processors have skyrocketed to 20 billion. > > Today, 99% of 32-bit and 64-bit processors are RISC. > > i suggest this goes back to PCC followed by the MIPS R2000 - made possible > by Dennis’ C language. > > The 1977 invention of ‘pcc’ and rewriting of Unix for cross-machine > portability was the first time I’m aware of this being done. > ( Miller @ UoW did a one-off hack, not to devalue his work, he ported, > didn’t invent a multi-target portable compiler ) > > One of the effects of “portable C” was creating whole new industries for > third party software developers > or enabling niche products, like CISCO routers and the many embedded > devices. > > C and Unix came with the tools to create new languages and new tools. > AWK, sed (!) and shells are obvious examples, with Perl, Python & PHP very > big in Internet of 2000. > > C was a new class of language - a tool to create tools. > It creates a perfect mechanism to bootstrap any new language, tool or > product, > allowing to be refined & used enough to become reliable before being made > self-hosting. > > Very widely used languages such as Python are written in C. > ORACLE achieved its market dominance by providing ‘portability’ - exactly > the same on every platform. > Underpinned by portable C. > > The original 1127 team went on to create other systems and languages, > not the least being a new Software Engineering tool, “Go” / golang, > addressing a whole slew of deficiencies in the C/C++ approach and > > We’d have no Internet today without Apache written in C and being ported > to every environment. > > Also, there’s a connection between C and ‘modern’ Software Engineering > - distributed Repositories, automated builds & regression tests, and the > many toolchains and tools used. > > They tended to be built in C to address problems (Open Source) developers > were finding with existing toolchains. > ‘make’ arose at Bell Labs to automate builds, along with PWB and Writers > Workbench. > > There’s two questions / observations about 50 years of C in broad use: > > - Just how much C is out there and used ‘in production’? > > - C is ‘obviously’ a product of the 1970’s, not reflecting needs > of modern hardware, networks, storage and systems, > but _what_ can replace it? > > There is simply too much critical code written in C to > convert it to another ‘better, modern’ language. > Any new language that is a simple 1:1 rewriting of C > cannot address any of the deficiencies, > while any incompatible language requires redesign and > reimplementation of everything - an unachievable goal. > > The Linux Kernel’s “rust” project shows the extent of the problem > - even with the best team of the best developers, its a mammoth > undertaking, with uncertain payoffs, unquantifiable effort & deadlines. > > My thesis is that portable, standard C: > > - not only co-evolved with other tools & needs to create the > Modern Software Engineering environment, the basis for multiple Trillion > dollar enterprises (FAANG) > but > - drove the biggest, most profitable software market ever seen > (Wintel) > - which drove sales volume of x86 chips (& DRAM, motherboards, > LAN, GPU, monitors, peripherals…) over 2-3 decades, > - which drove Silicon Valley, paying for new generations of Fabs > and lowering chip prices further & further > - and eventually created the Fabless RISC CPU company, > which in the Post-PC era absolutely dominates chip sales. > > No Software, no Silicon… > > Gordon Moore, in an early comment on his 1968 startup with Robert Noyce, > said: > > “we are the real revolutionaries" (vs Hippies & 1967 Summer of > Love). > > I think Ken & Dennis [ and 1127/ Bell Labs folk ] can say the same. > > ========== > > I’ve written some notes, with links to Programming Languages, especially > Jean Sammet’s Histories, > and would like some critiques, suggestions & corrections if people have > time and interest. > > Unix and C are intimately related - neither was possible or useful without > the other. > > i think there’s an interesting article in there, but I’m not sure I have > what it takes to write it, not in a finite time :) > Very happy to help anyone who does! > > Did-C-lang-create-modern-software-industry.txt > < > https://drive.google.com/file/d/1k936sgqHc-vHBvfCdLoSxFhdT9NaijU2/view?usp=sharing > > > > steve jenkin > 04 - dec - 2024 > > ========== > -- > Steve Jenkin, IT Systems and Design > 0412 786 915 (+61 412 786 915) > PO Box 38, Kippax ACT 2615, AUSTRALIA > > mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ches at cheswick.com Wed Dec 4 23:40:28 2024 From: ches at cheswick.com (William Cheswick) Date: Wed, 4 Dec 2024 08:40:28 -0500 Subject: [TUHS] After 50 years, what has the Impact of Unix been? In-Reply-To: References: <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> Message-ID: This alludes to an important step that should be mentioned. Plan 9 was a rethinking of the whole Unix world. Though it didn’t spread like C, many of its ideas were adopted elsewhere. And its approach to multi-machine compilation and tools is clearly reflected in the design and implementation of golang. ches > On Dec 4, 2024, at 8:05 AM, Marc Donner wrote: > > > The original 1127 team went on to create other systems and languages, > not the least being a new Software Engineering tool, “Go” / golang, > addressing a whole slew of deficiencies in the C/C++ approach and > From rich.salz at gmail.com Thu Dec 5 01:02:14 2024 From: rich.salz at gmail.com (Rich Salz) Date: Wed, 4 Dec 2024 10:02:14 -0500 Subject: [TUHS] After 50 years, what has the Impact of Unix been? In-Reply-To: References: <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> Message-ID: > > I would add one more important impact: making data a first class component > of the computing environment. > Related to that is getting rid of "file types". I remember at a "lessons of Unix" panel at a Usenix, that someone from the Labs gave an example of a situation where the operating system treated a file as more than just a set of bytes (think IBM, VMS, etc). Read a source file (required them to do a bunch of file-conversion operations), write an output, perhaps changing a variable name from 'foo' to 'bar', and then compiling the output, which also required a bunch of file-conversion operations. -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Thu Dec 5 05:07:07 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Wed, 4 Dec 2024 14:07:07 -0500 Subject: [TUHS] After 50 years, what has the Impact of Unix been? Message-ID: Rich's remark about file types reminded me of an ancient non-Unix story that I sent to Coff. Doug From johnl at taugh.com Thu Dec 5 13:08:43 2024 From: johnl at taugh.com (John Levine) Date: 4 Dec 2024 22:08:43 -0500 Subject: [TUHS] After 50 years, what has the Impact of Unix been? In-Reply-To: References: <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> Message-ID: <20241205030843.8552FAB1EDA5@ary.qy> It appears that Marc Donner said: >With the notion of pipes it became possible to operate on data quickly and >flexibly. There was nothing new from a fundamental capability point of >view, but the ease with which one could construct pipelines enabled rapid >experimentation and encouraged the development of pipe-able components to >add to the tool set. Pipes were invented at least three times I'm aware of, but what made them work so well in Unix is that they looked to the program the same as a file so any program could use them for input or output without special arrangements, and the shell made it easy to start two programs and pipe them together. The Dartmouth Time-Sharing System in the late 1960s had communication files which were essentially two-way pipes, but they were asymmetrical. One end, the slave end, looked like a file, but the other end, the master end, was different and the program had to know it was a com file. They were mostly used to pass terminal I/O between user programs at the slave end and SIMON at the master end, the terminal monitor that talked to the front end computer than ran the TTYs. They were invented again at IBM in the 1970s and described in this paper. I wrote them a letter, which they published, saying that Unix pipes did the same thing. https://dl.acm.org/doi/10.1147/sj.174.0383 R's, John From boomer3200 at gmail.com Thu Dec 5 16:38:34 2024 From: boomer3200 at gmail.com (Dan Plassche) Date: Thu, 5 Dec 2024 01:38:34 -0500 (EST) Subject: [TUHS] Typesetter C Compiler and Troff (Re: Re: v6 Unix Documents) In-Reply-To: <20241201042131.E7DD318C075@mercury.lcs.mit.edu> References: <20241201042131.E7DD318C075@mercury.lcs.mit.edu> Message-ID: On Sat, 30 Nov 2024, Noel Chiappa wrote: > > > I was able to rebuild both the UNSW and the native PWB compiler on PWB > > 1.0, but not to backport either to vanilla v6. > > Any idea what the problem was? I'm curious, because we ran a version of the > Typesetter compiler on the MIT systems, which ran an enhanced V6. > > Noel Yes, I have a general sense after making some progress building on v6 and further exploring the PWB 1.0 and UNSW sets as noted below. Would be interested to complete the process and add any details I am missing. I had to use the new c compiler and assembler from the Shoppa disk (nix_v6.rl02.gz) to bootstrap the build using the UNSW files on v6. The original typesetter c distribution was supposed to be for v6, which is my intended use case, but it appears the third-party copies we have available drifted: - the stock v6 compiler could not build the new "Portable I/O Library" (/lib/libS.a supporting stdio) from UNSW or PWB as the pre-requisite to building the new compiler. The code is almost all the same in both, although UNSW is missing tmpnam.c. - "old" cc gave a lot of basic syntax errors from the included stdio.h and the library files with some of the most common issues being redeclared items and classes. - I had to adjust the UNSW includes to point to the in-directory stdio.h file rather than the to be created include path (/usr/include/stdio.h from #include ) that was assumed to already exist (not on v6). - table.o for the stdio library appears to require the new as - PWB 1.0 builds already have ncc and are straightforward, but rely on makefiles and use syscalls that are not available on v6 - UNSW's set provides traditional run shell scripts, but incorporates features -- the Bourne shell colon no-op and as with an -o flag -- that are not on v6 - everything for stdio and the new compiler apart from c1 built cleanly using ncc with /xlib I am still tracking down why building c1 lead to an error (_itol undefined). I think the build is getting close. Also, I suspect that the typesetter c distribution from AT&T differed from what we have in terms of the build scripts and likely included binaries with the source: it seems that at some point ncc became necessary to build later verison of ncc. Thanks, Dan From jsg at jsg.id.au Thu Dec 5 19:26:17 2024 From: jsg at jsg.id.au (Jonathan Gray) Date: Thu, 5 Dec 2024 20:26:17 +1100 Subject: [TUHS] Amdahl UTS use by 386 designers Message-ID: I found it interesting that Amdahl UTS was used by designers of the 386. "we instituted Unix for the 386 design. Again if management knew what we were doing they wouldn't have let us do it." https://archive.computerhistory.org/resources/text/Oral_History/Intel_386_Design_and_Dev/102702019.05.01.acc.pdf pp. 14-15 Intel Alumni Network, 386 panel https://www.youtube.com/watch?v=fj8fnwuJGto&t=1540s Pat Gelsinger - UTS for Design Engineers https://www.gregbryant.com/intel/pat_gelsinger_unix_1984.pdf via https://mastodon.social/@aka_pugs/111723262047370983 "Given Pat was a bit of a UNIX hacker at the time, he set up the entire design team inside of his CMS account which was running the UTS UNIX environment from Amdahl." Gelsinger, Kirkpatrick, Kolodny, Singer Coping with the Complexity of Microprocessor Design at Intel - A CAD History https://kolodny.net.technion.ac.il/files/2016/07/IntelCADPaperFinal2.pdf From ron at ronnatalie.com Fri Dec 6 00:27:35 2024 From: ron at ronnatalie.com (Ron Natalie) Date: Thu, 05 Dec 2024 14:27:35 +0000 Subject: [TUHS] Porting AIX / Was Amdahl UTS use by 386 designers In-Reply-To: References: Message-ID: Years ago I worked on a project to port AIX to a couple of I860 microchannel add in cards. The first was the Intel “Wizard” card and the second was a four processor card with integral framebuffer coded the W4. We were running the AIX for the PS/2 on the host machine. AIX had a feature lifted from UCLA they called the Transparent Computing Facility. This allowed each executable to exist in the filesystem for multiple processor types. If you attempted to run an executable you didn’t have for your local machine, it would remote execute one of the ones you did have. This came in handy for the porting process. Amusingly, the i860 kernel I wrote bore more resemblance to the AIX/370 code than it did to the PS/2 (x86) code. We did have some laughs at IBM’s expense. The PS/2’s had this feature called the “High Function Terminal” that allowed you to switch the console between different virtual environments. We didn’t really have a console on the W4 so we referred to its virtual console as the “Low Function Terminal.” From crossd at gmail.com Fri Dec 6 01:19:15 2024 From: crossd at gmail.com (Dan Cross) Date: Thu, 5 Dec 2024 10:19:15 -0500 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact of Unix been?) In-Reply-To: <20241205030843.8552FAB1EDA5@ary.qy> References: <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> <20241205030843.8552FAB1EDA5@ary.qy> Message-ID: On Wed, Dec 4, 2024 at 10:18 PM John Levine wrote: > It appears that Marc Donner said: > >With the notion of pipes it became possible to operate on data quickly and > >flexibly. There was nothing new from a fundamental capability point of > >view, but the ease with which one could construct pipelines enabled rapid > >experimentation and encouraged the development of pipe-able components to > >add to the tool set. > > Pipes were invented at least three times I'm aware of, but what made them > work so well in Unix is that they looked to the program the same as a file > so any program could use them for input or output without special arrangements, > and the shell made it easy to start two programs and pipe them together. Once you have coroutines and queues for passing data between them, a lot of things start to look like pipes. > The Dartmouth Time-Sharing System in the late 1960s had communication files > which were essentially two-way pipes, but they were asymmetrical. One end, the > slave end, looked like a file, but the other end, the master end, was different > and the program had to know it was a com file. They were mostly used to pass > terminal I/O between user programs at the slave end and SIMON at the master end, > the terminal monitor that talked to the front end computer than ran the TTYs. Doug has written at some length on this list about communication files and their homomorphism to the way Plan 9 presented and handled resources. > They were invented again at IBM in the 1970s and described in this paper. I wrote > them a letter, which they published, saying that Unix pipes did the same thing. > > https://dl.acm.org/doi/10.1147/sj.174.0383 Don't forget CMS pipelines, too! Sadly, the Morrison paper cited above is not easily accessible, though I acquired a copy from IEEE; perhaps a sucker's game as it was not cheap. Your subsequent letter, and part of Morrison's response to you, however, is available, gratis. Reading through Morrison, one gets the impression that there are some substantial differences with Unix pipelines; or rather, the way that Unix pipelines are usually used. In particular, he describes his linked streams in terms of a "network", by which he appears to mean an arbitrary directed graph. Crucially, he describes combining nodes, for merging data from multiple streams. Unix pipelines, on the other hand, tend to be used in a manner that is strictly linear, without the fan-out and fan-in capabilities described by Morrison. Of course, nothing prevents one from building a Morrison-style "network" from Unix processes and pipes, though it's hard to see how that would work without something like `select`, which didn't yet exist in 1978. Regardless, Unix still doesn't expose a particularly convenient syntax for expressing these sorts of constructions at the shell. As an aside, Morrison has a web page dedicated to "flow-based programming", that he claims to have invented in the late 1960s. That seems like a bit of a tall claim, and I'd wager Doug gives him a run for his money on that. https://jpaulm.github.io/fbp/ - Dan C. From johnl at taugh.com Fri Dec 6 02:00:40 2024 From: johnl at taugh.com (John R Levine) Date: 5 Dec 2024 11:00:40 -0500 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact of Unix been?) In-Reply-To: References: <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> <20241205030843.8552FAB1EDA5@ary.qy> Message-ID: <32bf4263-277d-8c8b-6bf7-e33df04a2c3c@taugh.com> On Thu, 5 Dec 2024, Dan Cross wrote: >> Pipes were invented at least three times I'm aware of, but what made them >> work so well in Unix is that they looked to the program the same as a file >> so any program could use them for input or output without special arrangements, >> and the shell made it easy to start two programs and pipe them together. > > Once you have coroutines and queues for passing data between them, a > lot of things start to look like pipes. They also can look a lot like temporary files. Someone, probably Heinz, did a shell for the tiny Unix that ran on floppies so this foo | bar actually did this foo > tmpfile ; bar < tmpfile; rm tmpfile to avoid having to swap programs in and out on floppies. The main disadvantage was that the tmpfile could overflow the tiny disks of the time. >> They were invented again at IBM in the 1970s and described in this paper. I wrote >> them a letter, which they published, saying that Unix pipes did the same thing. >> >> https://dl.acm.org/doi/10.1147/sj.174.0383 > > Don't forget CMS pipelines, too! > > Sadly, the Morrison paper cited above is not easily accessible, though If anyone else needs a copy, just ask. Regards, John Levine, johnl at taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From heinz at osta.com Fri Dec 6 02:17:01 2024 From: heinz at osta.com (Heinz Lycklama) Date: Thu, 5 Dec 2024 08:17:01 -0800 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact of Unix been?) In-Reply-To: <32bf4263-277d-8c8b-6bf7-e33df04a2c3c@taugh.com> References: <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> <20241205030843.8552FAB1EDA5@ary.qy> <32bf4263-277d-8c8b-6bf7-e33df04a2c3c@taugh.com> Message-ID: John, thanks for the reminder of the implementation of pipes on a constrained version of UNIX in the early days. The exact implementation is described on page 2095 of the BSTJ July-Aug 1978 for interested parties. Heinz On 12/5/2024 8:00 AM, John R Levine wrote: > On Thu, 5 Dec 2024, Dan Cross wrote: >>> Pipes were invented at least three times I'm aware of, but what made >>> them >>> work so well in Unix is that they looked to the program the same as >>> a file >>> so any program could use them for input or output without special >>> arrangements, >>> and the shell made it easy to start two programs and pipe them >>> together. >> >> Once you have coroutines and queues for passing data between them, a >> lot of things start to look like pipes. > > They also can look a lot like temporary files.  Someone, probably > Heinz, did a shell for the tiny Unix that ran on floppies so this > >  foo | bar > > actually did this > >  foo > tmpfile ; bar < tmpfile; rm tmpfile > > to avoid having to swap programs in and out on floppies.  The main > disadvantage was that the tmpfile could overflow the tiny disks of the > time. > >>> They were invented again at IBM in the 1970s and described in this >>> paper.  I wrote >>> them a letter, which they published, saying that Unix pipes did the >>> same thing. >>> >>> https://dl.acm.org/doi/10.1147/sj.174.0383 >> >> Don't forget CMS pipelines, too! >> >> Sadly, the Morrison paper cited above is not easily accessible, though > > If anyone else needs a copy, just ask. > > Regards, > John Levine, johnl at taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: RGxkomgHdfzyhAUv.png Type: image/png Size: 138780 bytes Desc: not available URL: From athornton at gmail.com Fri Dec 6 02:55:30 2024 From: athornton at gmail.com (Adam Thornton) Date: Thu, 5 Dec 2024 09:55:30 -0700 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact of Unix been?) In-Reply-To: References: <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> <20241205030843.8552FAB1EDA5@ary.qy> Message-ID: On Thu, Dec 5, 2024 at 8:20 AM Dan Cross wrote: > > Unix pipelines, on the other hand, tend to be used in a manner that is > strictly linear, without the fan-out and fan-in capabilities described > by Morrison. Of course, nothing prevents one from building a > Morrison-style "network" from Unix processes and pipes, though it's > hard to see how that would work without something like `select`, which > didn't yet exist in 1978. Regardless, Unix still doesn't expose a > particularly convenient syntax for expressing these sorts of > constructions at the shell. > > Rick Troth has recently published xfl, which is pretty much CMS Pipelines for Unix. https://github.com/trothtech/xfl He's got a slide deck on it at http://www.casita.net/pub/xfl/pervasive-vmws-2024.pdf . There are a lot of really cool things you can do with fanin/fanout. Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrochkind at gmail.com Fri Dec 6 03:06:47 2024 From: mrochkind at gmail.com (Marc Rochkind) Date: Thu, 5 Dec 2024 10:06:47 -0700 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact of Unix been?) In-Reply-To: References: <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> <20241205030843.8552FAB1EDA5@ary.qy> <32bf4263-277d-8c8b-6bf7-e33df04a2c3c@taugh.com> Message-ID: I don't think files as pipes would be "transparent to the user." Reading an empty pipe causes a wait until the bytes requested are available, unless the pipe is closed first. Reading to the end of a file results in an end-of-file error. This problem is avoided if the source process completes before the target process begins, but then there is a different lack of transparency, which is that the processes don't run simultaneously. (I think this is the case with the implementation that Heinz showed.) Still, the same sort of pseudo-pipes were in MS-DOS, and they were occasionally useful. Marc On Thu, Dec 5, 2024 at 9:17 AM Heinz Lycklama wrote: > John, thanks for the reminder of the implementation > of pipes on a constrained version of UNIX in the early > days. The exact implementation is described on page 2095 > of the BSTJ July-Aug 1978 for interested parties. > > > > Heinz > > On 12/5/2024 8:00 AM, John R Levine wrote: > > On Thu, 5 Dec 2024, Dan Cross wrote: > > Pipes were invented at least three times I'm aware of, but what made them > work so well in Unix is that they looked to the program the same as a file > so any program could use them for input or output without special > arrangements, > and the shell made it easy to start two programs and pipe them together. > > > Once you have coroutines and queues for passing data between them, a > lot of things start to look like pipes. > > > They also can look a lot like temporary files. Someone, probably Heinz, > did a shell for the tiny Unix that ran on floppies so this > > foo | bar > > actually did this > > foo > tmpfile ; bar < tmpfile; rm tmpfile > > to avoid having to swap programs in and out on floppies. The main > disadvantage was that the tmpfile could overflow the tiny disks of the > time. > > They were invented again at IBM in the 1970s and described in this paper. > I wrote > them a letter, which they published, saying that Unix pipes did the same > thing. > > https://dl.acm.org/doi/10.1147/sj.174.0383 > > > Don't forget CMS pipelines, too! > > Sadly, the Morrison paper cited above is not easily accessible, though > > > If anyone else needs a copy, just ask. > > Regards, > John Levine, johnl at taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > > -- *My new email address is mrochkind at gmail.com * -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: RGxkomgHdfzyhAUv.png Type: image/png Size: 138780 bytes Desc: not available URL: From paul.winalski at gmail.com Fri Dec 6 03:22:05 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Thu, 5 Dec 2024 12:22:05 -0500 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact of Unix been?) In-Reply-To: References: <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> <20241205030843.8552FAB1EDA5@ary.qy> <32bf4263-277d-8c8b-6bf7-e33df04a2c3c@taugh.com> Message-ID: Regarding pipes and pipe-like interprocess communications facilities in other operating systems, VMS has always had a pipe-like communications pseudo-devices called mailboxes. The main difference between Unix pipes and VMS mailboxes is that pipes have distinct read-only and write-only file descriptors. Mailboxes do not--channels (VMS-speak for file descriptors) assigned to a mailbox can be used for both reading and writing. This means that it is not possible to do "broken pipe"-type detection on a mailbox. This very much restricts the usefulness of mailboxes. I wrote a true pipe device driver for VMS as part of the DEC Shell product (a port of the Unix Bourne shell to VMS). -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Dec 6 03:35:31 2024 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Thu, 5 Dec 2024 09:35:31 -0800 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact of Unix been?) In-Reply-To: References: <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> <20241205030843.8552FAB1EDA5@ary.qy> Message-ID: <2fd6a361-b26f-4ca4-9c65-b6ba0559644e@case.edu> On 12/5/24 10:19 AM, Dan Cross wrote: > Unix pipelines, on the other hand, tend to be used in a manner that is > strictly linear, without the fan-out and fan-in capabilities described > by Morrison. Of course, nothing prevents one from building a > Morrison-style "network" from Unix processes and pipes, though it's > hard to see how that would work without something like `select`, which > didn't yet exist in 1978. Regardless, Unix still doesn't expose a > particularly convenient syntax for expressing these sorts of > constructions at the shell. Process substitution is about as close as we can get, but most programs still process their filename arguments one at a time, beginning to end. The canonical process substitution example is diff <(old-program-version) <(new-program-version) to do simple regression testing. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From cowan at ccil.org Fri Dec 6 03:53:06 2024 From: cowan at ccil.org (John Cowan) Date: Thu, 5 Dec 2024 12:53:06 -0500 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact of Unix been?) In-Reply-To: References: <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> <20241205030843.8552FAB1EDA5@ary.qy> <32bf4263-277d-8c8b-6bf7-e33df04a2c3c@taugh.com> Message-ID: There was no concurrency in mini-Unix; the first pipeline component ran to completion, and when it exited the next component ran, and so on. In this way a pipeline could be arbitrarily long using just two disk files. On Thu, Dec 5, 2024, 12:07 PM Marc Rochkind wrote: > I don't think files as pipes would be "transparent to the user." Reading > an empty pipe causes a wait until the bytes requested are available, unless > the pipe is closed first. Reading to the end of a file results in an > end-of-file error. This problem is avoided if the source process completes > before the target process begins, but then there is a different lack of > transparency, which is that the processes don't run simultaneously. (I > think this is the case with the implementation that Heinz showed.) > > Still, the same sort of pseudo-pipes were in MS-DOS, and they were > occasionally useful. > > Marc > > On Thu, Dec 5, 2024 at 9:17 AM Heinz Lycklama wrote: > >> John, thanks for the reminder of the implementation >> of pipes on a constrained version of UNIX in the early >> days. The exact implementation is described on page 2095 >> of the BSTJ July-Aug 1978 for interested parties. >> >> >> >> Heinz >> >> On 12/5/2024 8:00 AM, John R Levine wrote: >> >> On Thu, 5 Dec 2024, Dan Cross wrote: >> >> Pipes were invented at least three times I'm aware of, but what made them >> work so well in Unix is that they looked to the program the same as a >> file >> so any program could use them for input or output without special >> arrangements, >> and the shell made it easy to start two programs and pipe them together. >> >> >> Once you have coroutines and queues for passing data between them, a >> lot of things start to look like pipes. >> >> >> They also can look a lot like temporary files. Someone, probably Heinz, >> did a shell for the tiny Unix that ran on floppies so this >> >> foo | bar >> >> actually did this >> >> foo > tmpfile ; bar < tmpfile; rm tmpfile >> >> to avoid having to swap programs in and out on floppies. The main >> disadvantage was that the tmpfile could overflow the tiny disks of the >> time. >> >> They were invented again at IBM in the 1970s and described in this >> paper. I wrote >> them a letter, which they published, saying that Unix pipes did the same >> thing. >> >> https://dl.acm.org/doi/10.1147/sj.174.0383 >> >> >> Don't forget CMS pipelines, too! >> >> Sadly, the Morrison paper cited above is not easily accessible, though >> >> >> If anyone else needs a copy, just ask. >> >> Regards, >> John Levine, johnl at taugh.com, Taughannock Networks, Trumansburg NY >> Please consider the environment before reading this e-mail. https://jl.ly >> >> >> > > -- > *My new email address is mrochkind at gmail.com * > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: RGxkomgHdfzyhAUv.png Type: image/png Size: 138780 bytes Desc: not available URL: From johnl at taugh.com Fri Dec 6 04:05:41 2024 From: johnl at taugh.com (John Levine) Date: 5 Dec 2024 13:05:41 -0500 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact of Unix been?) In-Reply-To: References: <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> <20241205030843.8552FAB1EDA5@ary.qy> <32bf4263-277d-8c8b-6bf7-e33df04a2c3c@taugh.com> Message-ID: <20241205180541.E2818AB56024@ary.qy> It appears that Marc Rochkind said: >-=-=-=-=-=- >-=-=-=-=-=- > >I don't think files as pipes would be "transparent to the user." Reading an >empty pipe causes a wait until the bytes requested are available, unless >the pipe is closed first. ... You should read Meinz' paper. This was a cut down version of Unix that ran in 40K bytes on an LSI-11 with a couple of floppy disks. It ran one program at a time, since swapping to floppies was absurdly slow. The pseudo-pipe ran the first program which wrote the output to a file, then ran the second program which read it. It was close enough for most purposes so long as the disk didn't fill up. >Still, the same sort of pseudo-pipes were in MS-DOS, and they were >occasionally useful. I can think of lots of places that had a way for one program to write a temporary file that a subsequent one read. For example, in OS/360 JCL you'd write (well, punch) something like this for the object output of the Fortran compiler //SYSLIN DD DSNAME=&OBJECT,DISP=(NEW,PASS),UNIT=SYSSQ and then in the linker read it in //SYSIN DD DSNAME=&OBJECT,DISP=(OLD,DELETE) The & in the name said it was a temp file so make up a unique name. I probably didn't get the JCL exactly right since it's been about 50 years since I wrote any. R's, John From ron at ronnatalie.com Fri Dec 6 04:19:16 2024 From: ron at ronnatalie.com (Ron Natalie) Date: Thu, 05 Dec 2024 18:19:16 +0000 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact of Unix been?) In-Reply-To: <32bf4263-277d-8c8b-6bf7-e33df04a2c3c@taugh.com> References: <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> <20241205030843.8552FAB1EDA5@ary.qy> <32bf4263-277d-8c8b-6bf7-e33df04a2c3c@taugh.com> Message-ID: I remember on MiniUnix (a stripped down kernel that would run on PDP11’s without memory management, in our case 11/03, 11/20, and an older 11/40) there were no kernel pipes (and limited process concurrency). The shell used the aforementioned emulation of pipe by just running the output of one process into a temporary file subsequently loaded as stdin of the other. We kind of put all that to bed when the 11/23s came out and we could run our full up kernel on the micros. From cmhanson at eschatologist.net Fri Dec 6 05:23:01 2024 From: cmhanson at eschatologist.net (Chris Hanson) Date: Thu, 5 Dec 2024 11:23:01 -0800 Subject: [TUHS] I threw together a MINIX 1.5 system call emulator Message-ID: <51ACDEF8-362E-46AB-9B24-39A7FB273D57@eschatologist.net> Since MINIX was a UNIX V7 clone for teaching, I figure this is at least somewhat on-topic. I’ve wanted to port MINIX 1.5 for M68000 to other systems besides Amiga, Atari ST, and the classic Mac, but trying to do that within a system emulator is a pain and doesn’t help you use a modern editor or SCM system. So I took the Musashi M68000 emulator and, using the MINIX 1.5 sources for Atari ST for reference, I’ve implemented a system call emulator that’s now _almost_ sufficient to run /usr/bin/cc. It’s up on GitHub at https://github.com/eschaton/MINIXCompat and I’ve released it under an MIT license. It requires my forked version of the Musashi project that supports implementing a TRAP instruction via a callback, which is necessary for implementing system calls on the host side. I reference this via a submodule so it can be kept at least logically distinct from the rest of the code. There’s no Makefile as I’m using Xcode on macOS to develop it, though I expect to write one at some point so I can run it on NetBSD and Linux as well as on macOS; writing one should be straightforward. -- Chris From arnold at skeeve.com Fri Dec 6 06:55:34 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 05 Dec 2024 13:55:34 -0700 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact of Unix been?) In-Reply-To: <2fd6a361-b26f-4ca4-9c65-b6ba0559644e@case.edu> References: <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> <20241205030843.8552FAB1EDA5@ary.qy> <2fd6a361-b26f-4ca4-9c65-b6ba0559644e@case.edu> Message-ID: <202412052055.4B5KtYf1781856@freefriends.org> Chet Ramey via TUHS wrote: > On 12/5/24 10:19 AM, Dan Cross wrote: > > > Unix pipelines, on the other hand, tend to be used in a manner that is > > strictly linear, without the fan-out and fan-in capabilities described > > by Morrison. Of course, nothing prevents one from building a > > Morrison-style "network" from Unix processes and pipes, though it's > > hard to see how that would work without something like `select`, which > > didn't yet exist in 1978. Regardless, Unix still doesn't expose a > > particularly convenient syntax for expressing these sorts of > > constructions at the shell. > > Process substitution is about as close as we can get, but most programs > still process their filename arguments one at a time, beginning to end. > > The canonical process substitution example is > > diff <(old-program-version) <(new-program-version) > > to do simple regression testing. And fanout is simply ... | tee >(pipeline1) >(pipeline2) Arnold From crossd at gmail.com Fri Dec 6 07:12:34 2024 From: crossd at gmail.com (Dan Cross) Date: Thu, 5 Dec 2024 16:12:34 -0500 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact of Unix been?) In-Reply-To: <202412052055.4B5KtYf1781856@freefriends.org> References: <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> <20241205030843.8552FAB1EDA5@ary.qy> <2fd6a361-b26f-4ca4-9c65-b6ba0559644e@case.edu> <202412052055.4B5KtYf1781856@freefriends.org> Message-ID: On Thu, Dec 5, 2024 at 3:56 PM wrote: > Chet Ramey via TUHS wrote: > > On 12/5/24 10:19 AM, Dan Cross wrote: > > > > > Unix pipelines, on the other hand, tend to be used in a manner that is > > > strictly linear, without the fan-out and fan-in capabilities described > > > by Morrison. Of course, nothing prevents one from building a > > > Morrison-style "network" from Unix processes and pipes, though it's > > > hard to see how that would work without something like `select`, which > > > didn't yet exist in 1978. Regardless, Unix still doesn't expose a > > > particularly convenient syntax for expressing these sorts of > > > constructions at the shell. > > > > Process substitution is about as close as we can get, but most programs > > still process their filename arguments one at a time, beginning to end. > > > > The canonical process substitution example is > > > > diff <(old-program-version) <(new-program-version) > > > > to do simple regression testing. > > And fanout is simply > > ... | tee >(pipeline1) >(pipeline2) And indeed these things are pretty nifty, but don't they generate trees, and not arbitrary dags? They don't quite capture the full generality of Morrison-style networks since it doesn't seem like there's a way to connect process substitution fan-out with fan-in; at least, not conveniently. It is, perhaps, notable that Go allows me to do this sort of thing with channels and goroutines, but it has `select` built into the language. Funny, despite using Unix almost daily for over 30 years now, I don't think I've ever felt limited by the power of pipelines. On the contrary, I've lost count of the times I've felt limited on systems that do Not support pipes. - Dan C. From mrochkind at gmail.com Fri Dec 6 07:50:56 2024 From: mrochkind at gmail.com (Marc Rochkind) Date: Thu, 5 Dec 2024 14:50:56 -0700 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact of Unix been?) In-Reply-To: References: <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> <20241205030843.8552FAB1EDA5@ary.qy> <2fd6a361-b26f-4ca4-9c65-b6ba0559644e@case.edu> <202412052055.4B5KtYf1781856@freefriends.org> Message-ID: Some of the posts in this thread confuse pipes in UNIX shells (the | symbol) with the pipe system call. In the shell, how two processes can be connected with a pipe is very constrained (only one unidirectional pipe). But the pipe system call can be used to build much more elaborate connections. Back in 1980, when I was still at Bell Labs, I wrote a shell called 2dsh ("two dimensional shell) that had a more complex syntax. The memo I wrote, "2DSH—An experimental shell for connecting processes with multiple data streams", wasn't published externally, but exists as a Bell Labs memo. I found a reference here: https://scholar.google.com/scholar_lookup?title=2DSH%E2%80%94An+experimental+shell+for+connecting+processes+with+multiple+data+streams&author=M.+J.+Rochkind&publication_year=1980 . Here are two examples from that memo: [image: image.png] I stumbled across another paper from 2017 titled "Extending Unix Pipelines to DAGs," which references my un-published Bell Labs memo. I haven't read it since I don't subscribe to IEEE Transactions on Computers. A while ago Doug McIlroy was kind enough to send me a scan of my memo, but I don't think I'm allowed to publish it here. In that memo, I credit Doug for coming with a very similar idea around the same time ("A Notation for Arboreal Plumbing"). Marc Rochkind On Thu, Dec 5, 2024 at 2:13 PM Dan Cross wrote: > On Thu, Dec 5, 2024 at 3:56 PM wrote: > > Chet Ramey via TUHS wrote: > > > On 12/5/24 10:19 AM, Dan Cross wrote: > > > > > > > Unix pipelines, on the other hand, tend to be used in a manner that > is > > > > strictly linear, without the fan-out and fan-in capabilities > described > > > > by Morrison. Of course, nothing prevents one from building a > > > > Morrison-style "network" from Unix processes and pipes, though it's > > > > hard to see how that would work without something like `select`, > which > > > > didn't yet exist in 1978. Regardless, Unix still doesn't expose a > > > > particularly convenient syntax for expressing these sorts of > > > > constructions at the shell. > > > > > > Process substitution is about as close as we can get, but most programs > > > still process their filename arguments one at a time, beginning to end. > > > > > > The canonical process substitution example is > > > > > > diff <(old-program-version) <(new-program-version) > > > > > > to do simple regression testing. > > > > And fanout is simply > > > > ... | tee >(pipeline1) >(pipeline2) > > And indeed these things are pretty nifty, but don't they generate > trees, and not arbitrary dags? They don't quite capture the full > generality of Morrison-style networks since it doesn't seem like > there's a way to connect process substitution fan-out with fan-in; at > least, not conveniently. > > It is, perhaps, notable that Go allows me to do this sort of thing > with channels and goroutines, but it has `select` built into the > language. > > Funny, despite using Unix almost daily for over 30 years now, I don't > think I've ever felt limited by the power of pipelines. On the > contrary, I've lost count of the times I've felt limited on systems > that do Not support pipes. > > - Dan C. > -- *My new email address is mrochkind at gmail.com * -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 368482 bytes Desc: not available URL: From imp at bsdimp.com Fri Dec 6 08:03:18 2024 From: imp at bsdimp.com (Warner Losh) Date: Thu, 5 Dec 2024 15:03:18 -0700 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact of Unix been?) In-Reply-To: References: <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> <20241205030843.8552FAB1EDA5@ary.qy> <2fd6a361-b26f-4ca4-9c65-b6ba0559644e@case.edu> <202412052055.4B5KtYf1781856@freefriends.org> Message-ID: On Thu, Dec 5, 2024 at 2:13 PM Dan Cross wrote: > On Thu, Dec 5, 2024 at 3:56 PM wrote: > > Chet Ramey via TUHS wrote: > > > On 12/5/24 10:19 AM, Dan Cross wrote: > > > > > > > Unix pipelines, on the other hand, tend to be used in a manner that > is > > > > strictly linear, without the fan-out and fan-in capabilities > described > > > > by Morrison. Of course, nothing prevents one from building a > > > > Morrison-style "network" from Unix processes and pipes, though it's > > > > hard to see how that would work without something like `select`, > which > > > > didn't yet exist in 1978. Regardless, Unix still doesn't expose a > > > > particularly convenient syntax for expressing these sorts of > > > > constructions at the shell. > > > > > > Process substitution is about as close as we can get, but most programs > > > still process their filename arguments one at a time, beginning to end. > > > > > > The canonical process substitution example is > > > > > > diff <(old-program-version) <(new-program-version) > > > > > > to do simple regression testing. > > > > And fanout is simply > > > > ... | tee >(pipeline1) >(pipeline2) > > And indeed these things are pretty nifty, but don't they generate > trees, and not arbitrary dags? They don't quite capture the full > generality of Morrison-style networks since it doesn't seem like > there's a way to connect process substitution fan-out with fan-in; at > least, not conveniently. > > It is, perhaps, notable that Go allows me to do this sort of thing > with channels and goroutines, but it has `select` built into the > language. > > Funny, despite using Unix almost daily for over 30 years now, I don't > think I've ever felt limited by the power of pipelines. On the > contrary, I've lost count of the times I've felt limited on systems > that do Not support pipes. > The <() , >() syntax is a bash extension. Not all shells support it. And I couldn't find them in POSIX Issue 8. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Dec 6 08:05:26 2024 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Thu, 5 Dec 2024 14:05:26 -0800 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact of Unix been?) In-Reply-To: References: Message-ID: <19B4DBDC-4342-4557-925D-8D546DC9D84F@iitbombay.org> On Dec 5, 2024, at 1:13 PM, Dan Cross wrote: > > And indeed these things are pretty nifty, but don't they generate > trees, and not arbitrary dags? They don't quite capture the full > generality of Morrison-style networks since it doesn't seem like > there's a way to connect process substitution fan-out with fan-in; at > least, not conveniently. Isn’t that a limitation of the shell language(s)? It would be easier in a 2D graphical shell but that would perhaps make specifying the more common simpler pipelines harder! A "linear" syntax would require *naming*. For example, let-proc a = "foo -a", b = "bar -c -d", c = "zee" in a.in1 = file1, a.in2 = file2, b.in1 = a.out, b.in2 = file3, c.in1 = b.out1, c.in2 = a.out, c.out = file4; Here names a, b & c are used to denote *processes*, with connections specified in the next two lines. Once all the pipes are created, processes a, b & c can be started giving them the right endpoints in forked processes prior to execing. Doable but not really worth it. At this point you may as well use s-expressions! From tuhs at tuhs.org Fri Dec 6 08:19:43 2024 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Thu, 5 Dec 2024 14:19:43 -0800 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact of Unix been?) In-Reply-To: References: <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> <20241205030843.8552FAB1EDA5@ary.qy> <2fd6a361-b26f-4ca4-9c65-b6ba0559644e@case.edu> <202412052055.4B5KtYf1781856@freefriends.org> Message-ID: <002cf6d3-0ed2-46f2-9fae-19a3e10d7b9c@case.edu> On 12/5/24 5:03 PM, Warner Losh wrote: > The <() , >()  syntax is a bash extension. Not all shells support it. And > I couldn't find them in POSIX Issue 8. Credit where credit is due: I picked them up from ksh93, and extended them to use named pipes on systems where /dev/fd isn't available. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From mrochkind at gmail.com Fri Dec 6 09:07:14 2024 From: mrochkind at gmail.com (Marc Rochkind) Date: Thu, 5 Dec 2024 16:07:14 -0700 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact of Unix been?) In-Reply-To: <002cf6d3-0ed2-46f2-9fae-19a3e10d7b9c@case.edu> References: <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> <20241205030843.8552FAB1EDA5@ary.qy> <2fd6a361-b26f-4ca4-9c65-b6ba0559644e@case.edu> <202412052055.4B5KtYf1781856@freefriends.org> <002cf6d3-0ed2-46f2-9fae-19a3e10d7b9c@case.edu> Message-ID: I found that 2017 paper "Extending Unix Pipelines to DAGs". It's open access: https://ieeexplore.ieee.org/document/7903579 The open source code itself is here: https://github.com/dspinellis/dgsh Maybe an ambitious TUHS contributor can get the code running and give us a report. Marc Rochkind On Thu, Dec 5, 2024 at 3:38 PM Chet Ramey via TUHS wrote: > On 12/5/24 5:03 PM, Warner Losh wrote: > > > The <() , >() syntax is a bash extension. Not all shells support it. And > > I couldn't find them in POSIX Issue 8. > > Credit where credit is due: I picked them up from ksh93, and extended > them to use named pipes on systems where /dev/fd isn't available. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ > -- *My new email address is mrochkind at gmail.com * -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Fri Dec 6 09:07:10 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 05 Dec 2024 16:07:10 -0700 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact of Unix been?) In-Reply-To: References: <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> <20241205030843.8552FAB1EDA5@ary.qy> <2fd6a361-b26f-4ca4-9c65-b6ba0559644e@case.edu> <202412052055.4B5KtYf1781856@freefriends.org> Message-ID: <202412052307.4B5N7Ade790095@freefriends.org> Warner Losh wrote: > The <() , >() syntax is a bash extension. Not all shells support it. And > I couldn't find them in POSIX Issue 8. > > Warner It originated in ksh93. 30 years have gone by, it's time it was added to POSIX. At least, IMHO. Thanks, Arnold From flexibeast at gmail.com Fri Dec 6 10:46:43 2024 From: flexibeast at gmail.com (Alexis) Date: Fri, 06 Dec 2024 11:46:43 +1100 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact of Unix been?) In-Reply-To: <002cf6d3-0ed2-46f2-9fae-19a3e10d7b9c@case.edu> (Chet Ramey via TUHS's message of "Thu, 5 Dec 2024 14:19:43 -0800") References: <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> <20241205030843.8552FAB1EDA5@ary.qy> <2fd6a361-b26f-4ca4-9c65-b6ba0559644e@case.edu> <202412052055.4B5KtYf1781856@freefriends.org> <002cf6d3-0ed2-46f2-9fae-19a3e10d7b9c@case.edu> Message-ID: <87ttbhzlho.fsf@gmail.com> Chet Ramey via TUHS writes: > On 12/5/24 5:03 PM, Warner Losh wrote: > >> The <() , >()  syntax is a bash extension. Not all shells >> support >> it. And >> I couldn't find them in POSIX Issue 8. > > Credit where credit is due: I picked them up from ksh93, and > extended > them to use named pipes on systems where /dev/fd isn't > available. i must say i was moderately surprised to learn a few years ago that process substitution wasn't in POSIX - i find it succinct syntactic sugar. There's a post on Chris Siebenmann's blog about some of the issues involved, including the /dev/fd issue: https://utcc.utoronto.ca/~cks/space/blog/unix/ProcessSubstitutionWhyLate Can anyone point me to any discussions about process substitution potentially becoming part of POSIX? This search on the Austin Group tracker didn't yield any useful results: https://austingroupbugs.net/search.php?project_id=0&search=process+substitution&sticky_issues=off&sortby=last_updated&dir=DESC&hide_status_id=-2&FILTER_SEARCH_PLATFORM= Alexis. From g.branden.robinson at gmail.com Fri Dec 6 11:09:26 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Thu, 5 Dec 2024 19:09:26 -0600 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact of Unix been?) In-Reply-To: <202412052307.4B5N7Ade790095@freefriends.org> References: <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> <20241205030843.8552FAB1EDA5@ary.qy> <2fd6a361-b26f-4ca4-9c65-b6ba0559644e@case.edu> <202412052055.4B5KtYf1781856@freefriends.org> <202412052307.4B5N7Ade790095@freefriends.org> Message-ID: <20241206010926.btnkeeqx7hhnoh47@illithid> At 2024-12-05T16:07:10-0700, arnold at skeeve.com wrote: > Warner Losh wrote: > > The <() , >() syntax is a bash extension. Not all shells support > > it. And I couldn't find them in POSIX Issue 8. > > It originated in ksh93. Are you sure? I think Tom Duff originated it in his "rc" shell. https://archive.org/details/rc-shell Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From woods at robohack.ca Fri Dec 6 11:31:15 2024 From: woods at robohack.ca (Greg A. Woods) Date: Thu, 05 Dec 2024 17:31:15 -0800 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact of Unix been?) In-Reply-To: <20241206010926.btnkeeqx7hhnoh47@illithid> References: <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> <20241205030843.8552FAB1EDA5@ary.qy> <2fd6a361-b26f-4ca4-9c65-b6ba0559644e@case.edu> <202412052055.4B5KtYf1781856@freefriends.org> <202412052307.4B5N7Ade790095@freefriends.org> <20241206010926.btnkeeqx7hhnoh47@illithid> Message-ID: At Thu, 5 Dec 2024 19:09:26 -0600, "G. Branden Robinson" wrote: Subject: [TUHS] Re: Pipes (was Re: After 50 years, what has the Impact of Unix been?) > > [1 ] > At 2024-12-05T16:07:10-0700, arnold at skeeve.com wrote: > > Warner Losh wrote: > > > The <() , >() syntax is a bash extension. Not all shells support > > > it. And I couldn't find them in POSIX Issue 8. > > > > It originated in ksh93. > > Are you sure? I think Tom Duff originated it in his "rc" shell. The Wikipedia entry for "Process substitution" says: Process substitution was available as a compile-time option for ksh88, the 1988 version of the KornShell from Bell Labs. The rc shell provides the feature as "pipeline branching" in Version 10 Unix, released in 1990. So, if we believe that then indeed ksh88 pioneered process substitution. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From douglas.mcilroy at dartmouth.edu Fri Dec 6 11:36:15 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Thu, 5 Dec 2024 20:36:15 -0500 Subject: [TUHS] After 50 years, what has the Impact of Unix been? Message-ID: > Pipes were invented at least three times I would add a 4th: POGOL--a remarkable data-processing language from NSA, described by Gloria Lambert at the first POPL conference, 1973. A POGOL program is made of processes that read and write notional files. The compiler considers all the processes together and optimizes files out of existence wherever it sees that written data can be read immediately. Otherwise a buffering file is instantiated. Unlike Unix pipes, though, a pair of communicating processes must share common knowledge about the connection--the file name. A ready-made theory of pipe networks was published essentially simultaneously with the advent of DTSS communication files: R.M. Karp, R.E. Miller, and S. Winograd. The organization of computations for uniform recurrence equations. Journal of the ACM, 14(3):563-590, July 1967. Completely unsuspecting processes could have been connected by a pair of DTSS communication files controlled by a master relay process. As far as I know this was never done, although such a mechanism was used for the DTSS chat facility. For the special case of clocked sample-data networks, BLODI (block diagram compiler) by Lochbaum, Kelly and Vyssotsky was way ahead (1960) of all the pipe-based formalisms. Doug From johnl at taugh.com Fri Dec 6 12:02:24 2024 From: johnl at taugh.com (John Levine) Date: 5 Dec 2024 21:02:24 -0500 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact of Unix been?) In-Reply-To: References: <20241205030843.8552FAB1EDA5@ary.qy> <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> <202412052055.4B5KtYf1781856@freefriends.org> <2fd6a361-b26f-4ca4-9c65-b6ba0559644e@case.edu> Message-ID: <20241206020224.E59B3AB6EF07@ary.qy> According to Dan Cross : >> > diff <(old-program-version) <(new-program-version) >> > >> > to do simple regression testing. >> >> And fanout is simply >> >> ... | tee >(pipeline1) >(pipeline2) > >And indeed these things are pretty nifty, but don't they generate >trees, and not arbitrary dags? They don't quite capture the full >generality of Morrison-style networks since it doesn't seem like >there's a way to connect process substitution fan-out with fan-in; at >least, not conveniently. You can use mkfifo to make named pipes and then plumb them as wanted. It's not particularly beautiful but it's as general as you could want. That's worked since 4.4BSD which was quite a while ago. From usotsuki at buric.co Fri Dec 6 12:05:51 2024 From: usotsuki at buric.co (Steve Nickolas) Date: Thu, 5 Dec 2024 21:05:51 -0500 (EST) Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact of Unix been?) In-Reply-To: References: <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> <20241205030843.8552FAB1EDA5@ary.qy> <2fd6a361-b26f-4ca4-9c65-b6ba0559644e@case.edu> <202412052055.4B5KtYf1781856@freefriends.org> <202412052307.4B5N7Ade790095@freefriends.org> <20241206010926.btnkeeqx7hhnoh47@illithid> Message-ID: On Thu, 5 Dec 2024, Greg A. Woods wrote: > The Wikipedia entry for "Process substitution" says: > > Process substitution was available as a compile-time option for > ksh88, the 1988 version of the KornShell from Bell Labs. The rc > shell provides the feature as "pipeline branching" in Version 10 > Unix, released in 1990. > > So, if we believe that then indeed ksh88 pioneered process substitution. Confirming that ksh88d and ksh88i support <(command) at least. -uso. From crossd at gmail.com Fri Dec 6 12:21:49 2024 From: crossd at gmail.com (Dan Cross) Date: Thu, 5 Dec 2024 21:21:49 -0500 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact of Unix been?) In-Reply-To: <20241206020224.E59B3AB6EF07@ary.qy> References: <20241205030843.8552FAB1EDA5@ary.qy> <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> <202412052055.4B5KtYf1781856@freefriends.org> <2fd6a361-b26f-4ca4-9c65-b6ba0559644e@case.edu> <20241206020224.E59B3AB6EF07@ary.qy> Message-ID: On Thu, Dec 5, 2024 at 9:02 PM John Levine wrote: > According to Dan Cross : > >> > diff <(old-program-version) <(new-program-version) > >> > > >> > to do simple regression testing. > >> > >> And fanout is simply > >> > >> ... | tee >(pipeline1) >(pipeline2) > > > >And indeed these things are pretty nifty, but don't they generate > >trees, and not arbitrary dags? They don't quite capture the full > >generality of Morrison-style networks since it doesn't seem like > >there's a way to connect process substitution fan-out with fan-in; at > >least, not conveniently. > > You can use mkfifo to make named pipes and then plumb them as wanted. It's > not particularly beautiful but it's as general as you could want. > > That's worked since 4.4BSD which was quite a while ago. Sure, but that's orthogonal since it's not really using shell syntax to build the thing up in a canonical way. I mean, perhaps in some literal sense it is (one types the commands into the interpreter...) but nowhere near the expressiveness of `ls | grep foo | whatever`. Fundamentally, the questions here are all about syntax. As I wrote in my first email, the system calls are very general, and could be used to build arbitrary directed graphs (not even limited to DAGs) of processes connected by pipes in all sorts of configurations (presumably those processes would be written to handle multiple input and output streams), without having to resort to named pipes. One can imagine some sort of DSL that describes such graphs of pipes and processes (Bakul alluded to this), and an interpreter for that DSL that creates the described set of pipes and processes, all appropriately connected and running. One could even imagine such a thing being used as part of a more traditional pipeline. My claim is simply that extant shell syntax isn't really amenable to this in a natural way. As Chet and Arnold pointed out, process substitution as pioneered in ksh gets us a little closer, but it's not quite as general (I believe any such graphs would have to be acyclic); it's certainly not as syntactically pleasant. There has been work along these lines; I was sent a reference off-list to a paper by Spinellis and Fragkoulis about a DAG-oriented shell: https://www.spinellis.gr/sw/dgsh/, which seems relevant. - Dan C. From douglas.mcilroy at dartmouth.edu Fri Dec 6 12:26:48 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Thu, 5 Dec 2024 21:26:48 -0500 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact of Unix been?) Message-ID: Many tree and dag pipe notations have been proposed. Marc's was one of the first. I devised one myself, but didn't like it enough to publish it even as a TM. A recent one is Spinellis's dgsh. More elaborate networks with feedback loops evolve for power-series computation. The idea of implementing cellular automata as arrays of processes with nearest neighbors connected by pipes was suggested early on, but I've never seen such an arrangement implemented--it would be hideously slow. I once wrote a general plumber that worked from a connection list: connect fd m in process A to fd n in process B. The main challenge was to find an order of hooking things up so that the number of live file descriptors in the plumber didn't exceed the system limit. Doug From athornton at gmail.com Fri Dec 6 12:29:24 2024 From: athornton at gmail.com (Adam Thornton) Date: Thu, 5 Dec 2024 19:29:24 -0700 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact of Unix been?) In-Reply-To: References: <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> <20241205030843.8552FAB1EDA5@ary.qy> <32bf4263-277d-8c8b-6bf7-e33df04a2c3c@taugh.com> Message-ID: /23+, no? The basic 23 doesn't have an MMU, I'm pretty sure. On Thu, Dec 5, 2024 at 11:58 AM Ron Natalie wrote: > I remember on MiniUnix (a stripped down kernel that would run on PDP11’s > without memory management, in our case 11/03, 11/20, and an older 11/40) > there were no kernel pipes (and limited process concurrency). > The shell used the aforementioned emulation of pipe by just running the > output of one process into a temporary file subsequently loaded as stdin > of the other. > > We kind of put all that to bed when the 11/23s came out and we could run > our full up kernel on the micros. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dds at aueb.gr Fri Dec 6 18:16:38 2024 From: dds at aueb.gr (Diomidis Spinellis) Date: Fri, 6 Dec 2024 10:16:38 +0200 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact of Unix been?) In-Reply-To: References: <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> <20241205030843.8552FAB1EDA5@ary.qy> <2fd6a361-b26f-4ca4-9c65-b6ba0559644e@case.edu> <202412052055.4B5KtYf1781856@freefriends.org> <002cf6d3-0ed2-46f2-9fae-19a3e10d7b9c@case.edu> Message-ID: <4c107309-75b7-42b3-ada3-161ec1421bd5@aueb.gr> On 06-Dec-24 01:07, Marc Rochkind wrote: > I found that 2017 paper "Extending Unix Pipelines to DAGs". It's open > access: > > https://ieeexplore.ieee.org/document/7903579 ieeexplore.ieee.org/document/7903579> > > The open source code itself is here: https://github.com/dspinellis/dgsh > > > Maybe an ambitious TUHS contributor can get the code running and give us > a report. I wrote the dgsh code with my co-author Marios Fragkoulis, so I still have it running. Doug McIlroy, who also mentioned dgsh in another message, is too modest to say that its design owes much to his input. I asked him for feedback when I was working on it, and over several iterations he proposed important (and quite demanding as I recall) improvements to its design. The system allows the concise and readable expression of several graph topologies I had in mind when I started working on it, and more [1]. However, it hasn't caught on. I think the main reason is that it is based on modified versions of several existing tools (bash, cmp, comm, cut, diff, diff3, grep, join, paste, perm, sort) [2]. The modifications allow the tools to coordinate between them the setup of pipes when placed in a dgsh graph according to available inputs and required outputs. The changes (especially for bash) aren't small, which meant that I didn't think it was realistic to push them upstream, which now means that the modified tools are out of date and difficult to build. Not sure what can be done to address this problem. It seems that a widely adopted system, such as modern Unix/Linux, has too much inertia for it to adopt potentially disrupting innovations. In retrospect, the way we designed the pipe graph setup could also be improved. The current design involves an initial phase where IPC messages are circulating around the graph to communicate the I/O requirements of each tool, for example that comm(1) should expect input from two processes and output to three processes. The design is brittle and difficult to troubleshoot, because coordination happens dynamically behind the scenes. A better design (and one I think Doug was advocating) would statically analyze the graph's topology and invoke each tool with appropriate parameters or environment variables. However, this design would require significantly more extensive modifications to bash, or the implementation of a new shell. Both approaches required work for which we didn't have the time and energy at the time, and also had their own downsides regarding adoption potential. [1] https://www.spinellis.gr/sw/dgsh/#examples [2] https://www.spinellis.gr/sw/dgsh/#tools Diomidis From mrochkind at gmail.com Sat Dec 7 02:10:18 2024 From: mrochkind at gmail.com (Marc Rochkind) Date: Fri, 6 Dec 2024 09:10:18 -0700 Subject: [TUHS] Interesting post about Microsoft and UNIX Message-ID: I just came across a 1995 post from Gordon Letwin, early Microsoft employee and lead architect of OS/2, about the history of OS/2. There are a few paragraphs in it about Microsoft and UNIX. Here's Letwin's post: https://gunkies.org/wiki/Gordon_Letwin_OS/2_usenet_post And the UNIX-related paragraphs: *It's extremely hard to do development work on an operating system when someone else controls the standard. "Control" in this case is a matter of public perception. For example, Microsoft was once very big in the Unix world. In fact, we considered it our candidate for the future desktop operating system, when machines got powerful enough to run something good. We were the worlds biggest seller of Unix systems. DOS was, when we first wrote it, a one-time throw-away product intended to keep IBM happy so that they'd buy our languages.The UNIX contracts were all done when Bell Labs was regulated and couldn't sell Unix into the commerical marketplace. So although they wrote it and were paid royalties, they couldn't develop it in competition to us. But after a few years that changed. Bell was degregulated and now they were selling Unix directly, in competition to us! They might sell it for cheaper than we had to pay them in royalties! But that wasn't the real killer, the real killer was the Bell now controlled the standard. If we wrote an API extension that did X, and Bell wrote an incompatible one that did Y, which one would people write for? The ISVs know that AT&T was a very big company and that they'd written the original, so they'd believe that AT&T controlled the standard, not MS, and that belief would then define reality. So we'd always just be waiting for what AT&T announced and then frantically trying to duplicate it.Bill Gates knew, right away, that there was no strong future in Unix for us any more. Fortunately at that time, DOS was taking off and we were learning, along with everyone else, about the power of standards. So the primary OS team - the Unix guys - joined with the secondary OS team - the DOS guys - and the earliest versions of OS/2 were born. (This was before IBM came on board, so it wasn't called OS/2!)* Marc Rochkind -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Sat Dec 7 02:38:28 2024 From: krewat at kilonet.net (Arthur Krewat) Date: Fri, 6 Dec 2024 16:38:28 +0000 Subject: [TUHS] Interesting post about Microsoft and UNIX In-Reply-To: References: Message-ID: And by concatenation, that's how we wound up with a VMS clone on our desktops. ________________________________ From: Marc Rochkind Sent: Friday, December 6, 2024 11:10 AM To: The UNIX Historical Society Subject: [TUHS] Interesting post about Microsoft and UNIX I just came across a 1995 post from Gordon Letwin, early Microsoft employee and lead architect of OS/2, about the history of OS/2. There are a few paragraphs in it about Microsoft and UNIX. Here's Letwin's post: https://gunkies.org/wiki/Gordon_Letwin_OS/2_usenet_post And the UNIX-related paragraphs: It's extremely hard to do development work on an operating system when someone else controls the standard. "Control" in this case is a matter of public perception. For example, Microsoft was once very big in the Unix world. In fact, we considered it our candidate for the future desktop operating system, when machines got powerful enough to run something good. We were the worlds biggest seller of Unix systems. DOS was, when we first wrote it, a one-time throw-away product intended to keep IBM happy so that they'd buy our languages. The UNIX contracts were all done when Bell Labs was regulated and couldn't sell Unix into the commerical marketplace. So although they wrote it and were paid royalties, they couldn't develop it in competition to us. But after a few years that changed. Bell was degregulated and now they were selling Unix directly, in competition to us! They might sell it for cheaper than we had to pay them in royalties! But that wasn't the real killer, the real killer was the Bell now controlled the standard. If we wrote an API extension that did X, and Bell wrote an incompatible one that did Y, which one would people write for? The ISVs know that AT&T was a very big company and that they'd written the original, so they'd believe that AT&T controlled the standard, not MS, and that belief would then define reality. So we'd always just be waiting for what AT&T announced and then frantically trying to duplicate it. Bill Gates knew, right away, that there was no strong future in Unix for us any more. Fortunately at that time, DOS was taking off and we were learning, along with everyone else, about the power of standards. So the primary OS team - the Unix guys - joined with the secondary OS team - the DOS guys - and the earliest versions of OS/2 were born. (This was before IBM came on board, so it wasn't called OS/2!) Marc Rochkind -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Sat Dec 7 02:44:06 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 06 Dec 2024 09:44:06 -0700 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact of Unix been?) In-Reply-To: References: <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> <20241205030843.8552FAB1EDA5@ary.qy> <2fd6a361-b26f-4ca4-9c65-b6ba0559644e@case.edu> <202412052055.4B5KtYf1781856@freefriends.org> <202412052307.4B5N7Ade790095@freefriends.org> <20241206010926.btnkeeqx7hhnoh47@illithid> Message-ID: <202412061644.4B6Gi6Ok871437@freefriends.org> "Greg A. Woods" wrote: > > Are you sure? I think Tom Duff originated it in his "rc" shell. > > The Wikipedia entry for "Process substitution" says: > > Process substitution was available as a compile-time option for > ksh88, the 1988 version of the KornShell from Bell Labs. The rc > shell provides the feature as "pipeline branching" in Version 10 > Unix, released in 1990. > > So, if we believe that then indeed ksh88 pioneered process substitution. I'd forgotten that it was optional in ksh88. It was there out of the box in ksh93. Arnold From arnold at skeeve.com Sat Dec 7 02:46:31 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 06 Dec 2024 09:46:31 -0700 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact of Unix been?) In-Reply-To: References: <20241205030843.8552FAB1EDA5@ary.qy> <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> <202412052055.4B5KtYf1781856@freefriends.org> <2fd6a361-b26f-4ca4-9c65-b6ba0559644e@case.edu> <20241206020224.E59B3AB6EF07@ary.qy> Message-ID: <202412061646.4B6GkVgU871634@freefriends.org> Dan Cross wrote: > My claim is simply that extant shell syntax isn't really amenable to > this in a natural way. As Chet and Arnold pointed out, process > substitution as pioneered in ksh gets us a little closer, but it's not > quite as general (I believe any such graphs would have to be acyclic); > it's certainly not as syntactically pleasant. > > There has been work along these lines; I was sent a reference off-list > to a paper by Spinellis and Fragkoulis about a DAG-oriented shell: > https://www.spinellis.gr/sw/dgsh/, which seems relevant. In the early-to-mid 1980s, the Georgia Tech Software Tools Subsystem for Prime Computers offered three standard inputs, three standard outputs, and a shell with syntax to connect things as you desired. I don't remember the syntax though. I also don't know how much this feature was really used. Arnold From aek at bitsavers.org Sat Dec 7 03:05:29 2024 From: aek at bitsavers.org (Al Kossow) Date: Fri, 6 Dec 2024 09:05:29 -0800 Subject: [TUHS] Interesting post about Microsoft and UNIX In-Reply-To: References: Message-ID: On 12/6/24 8:38 AM, Arthur Krewat wrote: > /his was before IBM came on board/ and IBM had no interest in the 386 at the time, which set the wheels in motion for Gates to acquire Cutler and DECwest From tuhs at tuhs.org Sat Dec 7 03:28:57 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 06 Dec 2024 17:28:57 +0000 Subject: [TUHS] Interesting post about Microsoft and UNIX In-Reply-To: References: Message-ID: <26vRiRS2sO-BAumb5V9ClzUqNJTMHE6ISl04n95AGMV2z3Kx_mmG9qOIIsLMGAAWJKprznaC9rGeI7_bX842X__q39Ind8b5O0JfuSkoLkk=@protonmail.com> On Friday, December 6th, 2024 at 8:10 AM, Marc Rochkind wrote: > I just came across a 1995 post from Gordon Letwin, early Microsoft employee and lead architect of OS/2, about the history of OS/2. There are a few paragraphs in it about Microsoft and UNIX. Here's Letwin's post: > > https://gunkies.org/wiki/Gordon_Letwin_OS/2_usenet_post > > And the UNIX-related paragraphs: > > It's extremely hard to do development work on an operating system when someone else controls the standard. "Control" in this case is a matter of public perception. For example, Microsoft was once very big in the Unix world. In fact, we considered it our candidate for the future desktop operating system, when machines got powerful enough to run something good. We were the worlds biggest seller of Unix systems. DOS was, when we first wrote it, a one-time throw-away product intended to keep IBM happy so that they'd buy our languages. > > The UNIX contracts were all done when Bell Labs was regulated and couldn't sell Unix into the commerical marketplace. So although they wrote it and were paid royalties, they couldn't develop it in competition to us. But after a few years that changed. Bell was degregulated and now they were selling Unix directly, in competition to us! They might sell it for cheaper than we had to pay them in royalties! But that wasn't the real killer, the real killer was the Bell now controlled the standard. If we wrote an API extension that did X, and Bell wrote an incompatible one that did Y, which one would people write for? The ISVs know that AT&T was a very big company and that they'd written the original, so they'd believe that AT&T controlled the standard, not MS, and that belief would then define reality. So we'd always just be waiting for what AT&T announced and then frantically trying to duplicate it. > > Bill Gates knew, right away, that there was no strong future in Unix for us any more. Fortunately at that time, DOS was taking off and we were learning, along with everyone else, about the power of standards. So the primary OS team - the Unix guys - joined with the secondary OS team - the DOS guys - and the earliest versions of OS/2 were born. (This was before IBM came on board, so it wasn't called OS/2!) > Marc Rochkind > Regarding the Microsoft/UNIX connection, while AT&T was central in the UNIX world, Microsoft is famous for their volume, I find myself wondering if Microsoft ever considered working *with* AT&T as an angle. Would this have run afoul of their relationship with IBM? I understand it that AT&T was trying to posture themselves as an IBM competitor in the hardware market in the ATTIS era, so I could see this factoring into Microsoft pulling out rather than espousing an angle of "If you can't beat them, join them." Again though, given their volume, I could see an alternate timeline where Microsoft approached AT&T and AT&T was more than willing to leverage a relationship with Microsoft given the uptake of Xenix. AT&T would eventually plunder Xenix for bits leading up to SVR4 anyway, granted this was many years later with more perspective. Another angle I've pondered on too is if Microsoft would've been amenable to that sort of thing but AT&T wouldn't have. They had just settled a huge anti-trust case. Pairing themselves with the single largest distributor of UNIX may have been to scarily close to cornering a market for their comfort, so maybe even if Microsoft had considered that, I could see trepidation on AT&Ts part regarding high-profile integration with an operation like Microsoft at the time... Cool stuff though, I've been studying this point of history a bit lately WRT the UTS/386 connection brought up recently. In a similar "don't mess with IBM" vein, it's had me wondering if Intel management would've been sketchy about using UTS for anything since Amdahl was a prominent IBM competitor. I get the impression that industry players that managed to curry IBMs favor somehow then had to tiptoe carefully around anything that might smell of engaging with competition. Just my view in hindsight though, as always, I wasn't there, I'm just fascinated with the conditions that lead to the world I live in :) - Matt G. From johnl at taugh.com Sat Dec 7 04:33:11 2024 From: johnl at taugh.com (John Levine) Date: 6 Dec 2024 18:33:11 -0000 Subject: [TUHS] Interesting post about Microsoft and UNIX In-Reply-To: References: Message-ID: According to Al Kossow : >On 12/6/24 8:38 AM, Arthur Krewat wrote: >> /his was before IBM came on board/ > >and IBM had no interest in the 386 at the time, which set the >wheels in motion for Gates to acquire Cutler and DECwest That was oddly shortsighted of IBM. Was it 16 bits is enough for anything you'd do on your desktop, or 32 bits is too close to competing with our big machines? -- Regards, John Levine, johnl at taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From henry.r.bent at gmail.com Sat Dec 7 05:29:53 2024 From: henry.r.bent at gmail.com (Henry Bent) Date: Fri, 6 Dec 2024 14:29:53 -0500 Subject: [TUHS] Interesting post about Microsoft and UNIX In-Reply-To: References: Message-ID: On Fri, 6 Dec 2024 at 12:13, Al Kossow wrote: > On 12/6/24 8:38 AM, Arthur Krewat wrote: > > /his was before IBM came on board/ > > and IBM had no interest in the 386 at the time > Are you referring strictly to the 386 as a UNIX machine? The 386 shipped in 1986 and the IBM PS/2 Model 80 (with a 386) shipped in '87. My assumption is that the driving factor in keeping the lower end PS/2 machines around was cost - at launch, a PS/2 with an 8086 was $2300 while one with a 386 was over $10k. Of course, the 386 PS/2 was initially targeted at OS/2 and not UNIX; from what I can find AIX PS/2 didn't ship until at least late 1988. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sat Dec 7 07:46:02 2024 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Fri, 6 Dec 2024 13:46:02 -0800 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact of Unix been?) In-Reply-To: <87ttbhzlho.fsf@gmail.com> References: <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> <20241205030843.8552FAB1EDA5@ary.qy> <2fd6a361-b26f-4ca4-9c65-b6ba0559644e@case.edu> <202412052055.4B5KtYf1781856@freefriends.org> <002cf6d3-0ed2-46f2-9fae-19a3e10d7b9c@case.edu> <87ttbhzlho.fsf@gmail.com> Message-ID: <0c3c3028-9293-4251-9e68-4874654c561b@case.edu> On 12/5/24 7:46 PM, Alexis wrote: > Can anyone point me to any discussions about process substitution > potentially becoming part of POSIX? It's never come up in any serious way, maybe as a wish list item for some people on the mailing list. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From heinz at osta.com Sat Dec 7 08:04:26 2024 From: heinz at osta.com (Heinz Lycklama) Date: Fri, 6 Dec 2024 14:04:26 -0800 Subject: [TUHS] Interesting post about Microsoft and UNIX In-Reply-To: <26vRiRS2sO-BAumb5V9ClzUqNJTMHE6ISl04n95AGMV2z3Kx_mmG9qOIIsLMGAAWJKprznaC9rGeI7_bX842X__q39Ind8b5O0JfuSkoLkk=@protonmail.com> References: <26vRiRS2sO-BAumb5V9ClzUqNJTMHE6ISl04n95AGMV2z3Kx_mmG9qOIIsLMGAAWJKprznaC9rGeI7_bX842X__q39Ind8b5O0JfuSkoLkk=@protonmail.com> Message-ID: To add a footnote to this discussion regarding MS and UNIX. We started work on the "UNIX standard" in 1981 under the auspices of /usr/group. Many of the small UNIX system vendors and application developers joined the effort right up front, including UNIX-like vendors. It took a little longer to get AT&T to participate, and then even longer to get IBM to join. MS participated in our efforts because of their Xenix products for a while but then suddenly pulled out. Don't remember the exact date, but they never joined us again. The Proposed /usr/group Standard published in January 1984 includes one name from MS in its Working Group membership. The final /usr/group Standard was published in November 1984 still includes the one name from MS among its 60+ members. Letwin's 1995 post explains why MS withdrew from the /usr/group Standards effort, which is the foundation of today's POSIX Standard published by the IEEE. Heinz On 12/6/2024 9:28 AM, segaloco via TUHS wrote: > On Friday, December 6th, 2024 at 8:10 AM, Marc Rochkind wrote: > >> I just came across a 1995 post from Gordon Letwin, early Microsoft employee and lead architect of OS/2, about the history of OS/2. There are a few paragraphs in it about Microsoft and UNIX. Here's Letwin's post: >> >> https://gunkies.org/wiki/Gordon_Letwin_OS/2_usenet_post >> >> And the UNIX-related paragraphs: >> >> It's extremely hard to do development work on an operating system when someone else controls the standard. "Control" in this case is a matter of public perception. For example, Microsoft was once very big in the Unix world. In fact, we considered it our candidate for the future desktop operating system, when machines got powerful enough to run something good. We were the worlds biggest seller of Unix systems. DOS was, when we first wrote it, a one-time throw-away product intended to keep IBM happy so that they'd buy our languages. >> >> The UNIX contracts were all done when Bell Labs was regulated and couldn't sell Unix into the commerical marketplace. So although they wrote it and were paid royalties, they couldn't develop it in competition to us. But after a few years that changed. Bell was degregulated and now they were selling Unix directly, in competition to us! They might sell it for cheaper than we had to pay them in royalties! But that wasn't the real killer, the real killer was the Bell now controlled the standard. If we wrote an API extension that did X, and Bell wrote an incompatible one that did Y, which one would people write for? The ISVs know that AT&T was a very big company and that they'd written the original, so they'd believe that AT&T controlled the standard, not MS, and that belief would then define reality. So we'd always just be waiting for what AT&T announced and then frantically trying to duplicate it. >> >> Bill Gates knew, right away, that there was no strong future in Unix for us any more. Fortunately at that time, DOS was taking off and we were learning, along with everyone else, about the power of standards. So the primary OS team - the Unix guys - joined with the secondary OS team - the DOS guys - and the earliest versions of OS/2 were born. (This was before IBM came on board, so it wasn't called OS/2!) >> Marc Rochkind >> > Regarding the Microsoft/UNIX connection, while AT&T was central in the UNIX world, Microsoft is famous for their volume, I find myself wondering if Microsoft ever considered working *with* AT&T as an angle. Would this have run afoul of their relationship with IBM? I understand it that AT&T was trying to posture themselves as an IBM competitor in the hardware market in the ATTIS era, so I could see this factoring into Microsoft pulling out rather than espousing an angle of "If you can't beat them, join them." Again though, given their volume, I could see an alternate timeline where Microsoft approached AT&T and AT&T was more than willing to leverage a relationship with Microsoft given the uptake of Xenix. AT&T would eventually plunder Xenix for bits leading up to SVR4 anyway, granted this was many years later with more perspective. > > Another angle I've pondered on too is if Microsoft would've been amenable to that sort of thing but AT&T wouldn't have. They had just settled a huge anti-trust case. Pairing themselves with the single largest distributor of UNIX may have been to scarily close to cornering a market for their comfort, so maybe even if Microsoft had considered that, I could see trepidation on AT&Ts part regarding high-profile integration with an operation like Microsoft at the time... > > Cool stuff though, I've been studying this point of history a bit lately WRT the UTS/386 connection brought up recently. In a similar "don't mess with IBM" vein, it's had me wondering if Intel management would've been sketchy about using UTS for anything since Amdahl was a prominent IBM competitor. I get the impression that industry players that managed to curry IBMs favor somehow then had to tiptoe carefully around anything that might smell of engaging with competition. Just my view in hindsight though, as always, I wasn't there, I'm just fascinated with the conditions that lead to the world I live in :) > > - Matt G. From steve at quintile.net Sat Dec 7 08:07:00 2024 From: steve at quintile.net (Steve Simon) Date: Fri, 6 Dec 2024 22:07:00 +0000 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact Message-ID: <034FC1E9-1D6C-42B9-B1B1-8AA03379E70E@quintile.net> helios supported DAG shell syntax. helios was a unix style os (was it actually posix compliant?) for networks of transputers. -Steve From ylee at columbia.edu Sat Dec 7 08:43:09 2024 From: ylee at columbia.edu (Yeechang Lee) Date: Fri, 6 Dec 2024 14:43:09 -0800 Subject: [TUHS] Interesting post about Microsoft and UNIX In-Reply-To: References: Message-ID: <26451.32253.73591.816292@dobie-old.ylee.org> John Levine says: > That was oddly shortsighted of IBM. Was it 16 bits is enough for > anything you'd do on your desktop, or 32 bits is too close to > competing with our big machines? Compaq got its Deskpro 386 out by late 1986. IBM didn't see the urgency and released the PS/2 Model 80 in June 1987. Not just IBM; HP, for example, in 1987 was still saying publicly that it was evaluating when and how to release its own 386 system. Compaq's move panicked smaller competitors who didn't need to preserve their dignity and knew what the computer meant, with many showing hastily built prototypes at November 1986 Comdex. While Microsoft did help Compaq while designing Deskpro 386, and Gates attended the computer's announcement, I don't think it affected its plans for Xenix and OS/2. The announcement did establish Compaq as arguably the standard setter in IBM's place by 1990, or more accurately proved that IBM was no longer the standard setter. Had Dell been the first out with a 386 box that might have affected its plans for Dell Unix, but Compaq never had its own operating system until the DEC acquisition. From tuhs at tuhs.org Sat Dec 7 08:58:00 2024 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Sat, 7 Dec 2024 08:58:00 +1000 Subject: [TUHS] A re-analysis of some DECtapes from dmr Message-ID: All, I received this detailed e-mail from Yufeng Gao who has done a great job at analysing some of the DECtapes that Dennis made available to the Unix Archive. I'm sure many of you would be interested and, possibly, could provide some feedback on his work. A tarball of his efforts are here: https://mega.nz/file/1cJFTJxT#BgszYuFc_ebSMaQXAIG5b2NtaGInPWMoaxExPM5Lr9Y Cheers, Warren P.S. I have a follow-up e-mail coming ... ----- Forwarded message from Yufeng Gao ----- Subject: UNIX DECtapes from Ritchie Hi Warren, I am writing you this email after seeing the DECtapes from Dennis Ritchie that you put up last year. I found them while playing around with the early C compilers on Ritchie's site. After some research into the tapes, I have written a parser to parse them and convert them into tarballs suitable for preservation. Most importantly, the 'dmr' tape and 's1' tape are currently not decoded properly. The biggest issue with the current decoding of the 's1' tape is, well, there is none. After quickly glancing over the tape, I have concluded that it is in fact not one of the middle tapes of an rkd(1) backup, but a copy of UNIX INIT DECtape from a version of UNIX between V1 and V2. I have extracted its contents: Mode UID GID Size Date Name ---------- --- --- ----- ------------------- ------------ -rw-rw-rw- 0 0 512 1970-01-01 00:00:00 [vcboot] -rw-rw-rw- 0 0 2048 1970-01-01 00:00:00 [bos] -rw-rw-rw- 0 0 12288 1970-01-01 00:00:00 [wunix] -rw-rw-rw- 0 0 12288 1970-01-01 00:00:00 [cunix] -rw-rw-rw- 0 0 3072 1970-01-01 00:00:00 [unassigned] -rwxr-xr-x 1 0 424 1970-01-01 00:00:00 /etc/init -rwxrwxrwx 3 0 446 1970-01-01 00:00:00 /etc/getty -rwxr-xr-x 3 0 82 1970-01-01 00:00:00 /bin/chmod -rwsr-xr-x 0 0 794 1970-01-01 00:00:00 /bin/date -rwsr-xr-x 0 0 1290 1970-01-01 00:00:00 /bin/login -rwsr-xr-x 0 0 232 1970-01-01 00:00:00 /bin/mkdir -rwxr-xr-x 1 0 954 1970-01-01 00:00:00 /bin/sh -rwsr-xr-x 0 0 3678 1970-01-01 00:00:00 /bin/tap -rwxr-xr-x 3 0 2010 1970-01-01 00:00:00 /bin/ls 578 blocks, 98 (16.96%) used, 480 (83.04%) free. B = boot; D = directroy; . = free; X = file data; O = bos; W = wunix; C = cunix; S = rf slack; U = unassigned program; |0123456789ABCDEF --+---------------- 00|BOOOOWWWWWWWWWWW 01|WWWWWWWWWWWWWCCC 02|CCCCCCCCCCCCCCCC 03|CCCCCUUUUUUSSSSS 04|SDXDXDXDXXDXXXDX 05|DXXDXXXXXXXXDXXX 06|XD.............. 07|................ <...> What is significant here is it contains the vcboot and bos programs mentioned in bproc(7), as well as a Warm and a Cold UNIX kernel. This version of UNIX appears to be between V1 and V2, which I believe is the earliest to exist in binary form. The reason why I say it's between V1 and V2 is its bos program accepts the following console switches compared to V1 and V2: | UNIX V1 | s1 | UNIX V2 ----------------------+----------+-------+--------- Warm boot | [1]73700 | ??? | ??? Cold boot | 1 | 1 | 1 Unassigned 3K prog | 2 | 2 | Dump core & halt | 10 | 10 | 10 Boot from RK | | 20 | 20 Dump core & warm boot | | 40 | 40 Boot from paper tape | 0 | 0 | 0 Load DEC loaders | 57500 | 57500 | 77500 ----------------------+----------+-------+--------- UNIX load address | 400 | 400 | 600 ----------------------+----------+-------+--------- The boot-from-unassigned-3K-program option was probably in the process of being depreciated, as the 3K of space is also loaded as a part of the Cold UNIX despite it not being used by the Cold UNIX kernel. The list of files on the 's1' tape also appear to be between V1 and V2: | V1 | s1 | V2 -----------+-----+-----+----- /etc/init | Yes | Yes | Yes /etc/getty | No | Yes | Y/N /bin/chmod | Yes | Yes | Yes /bin/chown | Yes | No | No /bin/date | No | Yes | Yes /bin/login | No | Yes | Yes /bin/cp | Yes | No | No /bin/ln | Yes | No | No /bin/ls | Yes | Yes | Yes /bin/mkdir | Yes | Yes | Yes /bin/mv | Yes | No | No /bin/rm | Yes | No | No /bin/rmdir | Yes | No | No /etc/mount | No | No | Yes /bin/sh | Yes | Yes | Yes /bin/stat | Yes | No | No /bin/tap | Yes | Yes | Yes -----------+-----+-----+----- Given that the files on this tape are identical to the same files on the 's2' tape and that the files on the 's2' tape are also sort of between V1 and V2, and that this tape is named 's1' while the other is named 's2', they are probably from the same version of UNIX. I have tried booting the 's1' tape using SIMH, but unfortunately it did not work and I have not yet attempted to debug it. Next I'm going to talk about the 'dmr' tape. It’s interesting, most of it was written by tap(1) running under UNIX V1-V2, but files in the ./paper directory were written by tap(1) running under UNIX V4. When decoded using the tap(1) program itself, the timestamps and access modes of those files are garbled. My program corrected the timestamps and access modes in the converted tar(1) archive. The same goes for the 'nsys' tape. The tar(1) conversion of 's2' (/Archive/Distributions/Research/1972_stuff/s2-bits.tar.gz) in the TUHS archives is missing some files in the /etc directory - compare it with mine and Ritchie's (Ritchie's has wrong timestamps and access modes, however). Speaking of timestamps and the 's2' tape, the timestamps outputted by tap(1) are inaccurate because 1972 is a leap year and the ctime(3) function hard coded 28 for the number of days in February. I have attached an archive of my tar(1) conversion of each tape, as well as tarballs containing all the slack space data and unused blocks which I dumped for data recovery and forensic analysis purposes. There are some interesting bits and pieces in the unused blocks of various tapes, but I have not had time to look into them in detail. Just a very quick summary: * The 'config' tape has leftover of a dictionary file. * The 'dmr' tape has some assembler manual ?roff leftover. * The 'dmr2' tape has some paper ?roff leftover. * The 'e-pi' tape has a lot of interesting binary stuff, including bits and pieces of a B compiler from what I can tell. * The 'ken' tape has some C source fragments and Thompson’s mail templates and some UNIX manual ?roff leftover. * The 'ken-du' tape has some paper ?roff leftover. * The 'ken-sky' tape has some binary leftover. * The 'nsys' tape has some source code leftover of what seems to be the kernel. * The 's1' tape has some source code leftover of what seems to be userland programs. * The 'scratch' tape has some binary and source listing and ?roff leftover. * The 'unix' tape has some binary leftover. I hope that these newly extracted stuff could be put up in the TUHS archives :). If the attachment in this email somehow doesn't come through, I have also uploaded the archive [1]here. I have a disassembly of vcboot and bos from 's1', they may help with the UNIX V1 reconstruction project - let me know if you need them. If you can get the 's1' kernel to boot, I'd like to also receive an update. Sincerely, Yufeng Gao ----- End forwarded message ----- From tuhs at tuhs.org Sat Dec 7 09:01:48 2024 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Sat, 7 Dec 2024 09:01:48 +1000 Subject: [TUHS] A re-analysis of some DECtapes from dmr In-Reply-To: References: Message-ID: On 7/12/24 08:58, Warren Toomey via TUHS wrote: > All, I received this detailed e-mail from Yufeng Gao who has done a great > job at analysing some of the DECtapes that Dennis made available to the > Unix Archive.P.S. I have a follow-up e-mail coming ... Here is a follow-up e-mail from Yufeng, I just needed to ensure the colours got preserved :-) Cheers, Warren ---- From Yufeng Gao ---- If you're going to share my email, please consider adding the following information about the s1 and s2 files being from the same version of UNIX: "The maki.s source and a.out executable found in /usr/sys is the exact same maki program used to create the INIT tape, judging by the unzeroed/leftover bytes at the end of vcboot." And the row highlighted in green from the following table to the one from my last email:                | UNIX V1  | s1    | UNIX V2 ----------------------+----------+-------+--------- Warm boot             | [1]73700 | ???   | ??? Cold boot             | 1        | 1     | 1 Unassigned 3K prog    | 2        | 2     | Dump core & halt      | 10       | 10    | 10 Boot from RK          |          | 20    | 20 Dump core & warm boot |          | 40    | 40 Boot from paper tape  | 0        | 0     | 0 Load DEC loaders      | 57500    | 57500 | 77500 ----------------------+----------+-------+--------- *BOS load address      | 54000    | 54000 | 154000* UNIX load address     | 400      | 400   | 600 ----------------------+----------+-------+--------- Sorry if I sound like I'm asking for too much, the history is quite important so I want everything to be in the best possible state :). Sincerely, Yufeng Gao -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at oneiros.de Sat Dec 7 10:53:08 2024 From: martin at oneiros.de (=?UTF-8?Q?Martin_Schr=C3=B6der?=) Date: Sat, 7 Dec 2024 01:53:08 +0100 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact In-Reply-To: <034FC1E9-1D6C-42B9-B1B1-8AA03379E70E@quintile.net> References: <034FC1E9-1D6C-42B9-B1B1-8AA03379E70E@quintile.net> Message-ID: Am Fr., 6. Dez. 2024 um 23:07 Uhr schrieb Steve Simon : > helios supported DAG shell syntax. Wikipedia: "What is not immediately apparent is that Helios extends the notion of Unix pipes into a language called Component Distribution Language (CDL). In CDL, a typical Unix shell pipeline such as more is called a task force, and is transparently distributed by the Task Force Manager server across the available CPUs. CDL extends traditional Unix syntax with additional operators for bi-directional pipes, sequential and parallel process farm operators, load balancing and resource management." > helios was a unix style os (was it actually posix compliant?) for networks of transputers. Mostly. "The Unix compatibility library described in chapter 5, Compatibility, implements functions which are largely compatible with the Posix standard interfaces. The library does not include the entire range of functions provided by the Posix standard, because some standard functions require memory management or, for various reasons, cannot be implemented on a multi-processor system. The reader is therefore referred to IEEE Std 1003.1-1988, IEEE Standard Portable Operating System Interface for Computer Environments, which is available from the IEEE Service Center, 445 Hoes Lane, P.O. Box 1331, Piscataway, NJ 08855-1331, USA. It can also be obtained by telephoning USA (201) 9811393" http://www.transputer.net/hbooks/techref/hbk.pdf Does that number still connect to the IEEE? :-) Best Martin From henry.r.bent at gmail.com Sat Dec 7 13:11:26 2024 From: henry.r.bent at gmail.com (Henry Bent) Date: Fri, 6 Dec 2024 22:11:26 -0500 Subject: [TUHS] Interesting post about Microsoft and UNIX In-Reply-To: <26451.32253.73591.816292@dobie-old.ylee.org> References: <26451.32253.73591.816292@dobie-old.ylee.org> Message-ID: On Fri, 6 Dec 2024 at 17:53, Yeechang Lee wrote: > John Levine says: > > That was oddly shortsighted of IBM. Was it 16 bits is enough for > > anything you'd do on your desktop, or 32 bits is too close to > > competing with our big machines? > > Compaq got its Deskpro 386 out by late 1986. IBM didn't see the urgency > and released the PS/2 Model 80 in June 1987. Not just IBM; HP, for example, > in 1987 was still saying publicly that it was evaluating when and how to > release its own 386 system. > > Compaq's move panicked smaller competitors who didn't need to preserve > their dignity and knew what the computer meant, with many showing hastily > built prototypes at November 1986 Comdex. > > While Microsoft did help Compaq while designing Deskpro 386, and Gates > attended the computer's announcement, I don't think it affected its plans > for Xenix and OS/2. The announcement did establish Compaq as arguably the > standard setter in IBM's place by 1990, or more accurately proved that IBM > was no longer the standard setter. Had Dell been the first out with a 386 > box that might have affected its plans for Dell Unix, but Compaq never had > its own operating system until the DEC acquisition. > I may be showing my ignorance here, but Compaq rushed to market a 386 machine so it could run... what? 16 bit DOS? Other 16 bit operating systems? It's kind of astonishing to me that no one had a 32 bit operating system ready for the 386 PC market, especially given that Intel had released the chip to developers a year earlier. SVR2 was readily available as a porting base but it appears that pretty much everyone dropped the ball on having a UNIX ready for a fairly powerful $10k machine with a clearly established market acceptance (from any vendor, not just Compaq or IBM). -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From ylee at columbia.edu Sat Dec 7 13:38:16 2024 From: ylee at columbia.edu (Yeechang Lee) Date: Fri, 6 Dec 2024 19:38:16 -0800 Subject: [TUHS] Interesting post about Microsoft and UNIX In-Reply-To: References: <26451.32253.73591.816292@dobie-old.ylee.org> Message-ID: <26451.49960.376499.18073@dobie-old.ylee.org> Henry Bent says: > I may be showing my ignorance here, but Compaq rushed to market a > 386 machine so it could run... what?  16 bit DOS?  Other 16 bit > operating systems? Yes. Contemporary news articles on the announcement discuss this, stating that a) no current software takes full advantage of the 386's power, and b) regardless, those who need the added horsepower would still benefit. The Deskpro 386's strong sales proved that this view was correct. > It's kind of astonishing to me that no one had a 32 bit operating > system ready for the 386 PC market IBM, as mentioned, did not think the market wanted or needed a 386-based computer. In 1986 its fastest PC was the 286-based IBM AT, and in the two years since no one had released any software requiring the 286; everyone treated it as a faster 8088 or 8086. The AT was in 1984 an aberration, really the only time in the IBM PC's history that the IBM product was state of the art. IBM otherwise followed a PC product lifecycle similar to that of its big iron; the original 1981 IBM PC was still sold until the PS/2 introduction in 1987, for example. The company was very surprised when its 1985 discontinuation of the PCjr upset customers, because IBM expected that its normal practice of promising ongoing support for a period of years into the future would be sufficient. The only vendors with credibility to establish a new industry standard with an operating system in 1984 or 1986 were IBM and Microsoft. Had AT&T's entry into the computer market after divestiture not occurred, Microsoft would likely have continued pushing Xenix and might well have had a 386-specific version ready soon after the Deskpro 386. Such a product would in time surely have used the virtual 8086 hardware feature to execute DOS software on Xenix, akin to contemporary Windows's similar feature but with the advantages of a) actually working and b) with preemptive multitasking. From mrochkind at gmail.com Sat Dec 7 13:55:36 2024 From: mrochkind at gmail.com (Marc Rochkind) Date: Fri, 6 Dec 2024 20:55:36 -0700 Subject: [TUHS] Interesting post about Microsoft and UNIX In-Reply-To: References: <26451.32253.73591.816292@dobie-old.ylee.org> Message-ID: I'm sure Compaq was thinking ahead. They would be very aware of Microsoft's Windows plans. Buyers also think ahead, especially corporate buyers, who are the real customers. Marc On Fri, Dec 6, 2024, 8:11 PM Henry Bent wrote: > On Fri, 6 Dec 2024 at 17:53, Yeechang Lee wrote: > >> John Levine says: >> > That was oddly shortsighted of IBM. Was it 16 bits is enough for >> > anything you'd do on your desktop, or 32 bits is too close to >> > competing with our big machines? >> >> Compaq got its Deskpro 386 out by late 1986. IBM didn't see the urgency >> and released the PS/2 Model 80 in June 1987. Not just IBM; HP, for example, >> in 1987 was still saying publicly that it was evaluating when and how to >> release its own 386 system. >> >> Compaq's move panicked smaller competitors who didn't need to preserve >> their dignity and knew what the computer meant, with many showing hastily >> built prototypes at November 1986 Comdex. >> >> While Microsoft did help Compaq while designing Deskpro 386, and Gates >> attended the computer's announcement, I don't think it affected its plans >> for Xenix and OS/2. The announcement did establish Compaq as arguably the >> standard setter in IBM's place by 1990, or more accurately proved that IBM >> was no longer the standard setter. Had Dell been the first out with a 386 >> box that might have affected its plans for Dell Unix, but Compaq never had >> its own operating system until the DEC acquisition. >> > > I may be showing my ignorance here, but Compaq rushed to market a 386 > machine so it could run... what? 16 bit DOS? Other 16 bit operating > systems? It's kind of astonishing to me that no one had a 32 bit operating > system ready for the 386 PC market, especially given that Intel had > released the chip to developers a year earlier. SVR2 was readily available > as a porting base but it appears that pretty much everyone dropped the ball > on having a UNIX ready for a fairly powerful $10k machine with a clearly > established market acceptance (from any vendor, not just Compaq or IBM). > > -Henry > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjenkin at canb.auug.org.au Sat Dec 7 16:07:54 2024 From: sjenkin at canb.auug.org.au (sjenkin at canb.auug.org.au) Date: Sat, 7 Dec 2024 17:07:54 +1100 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact In-Reply-To: <034FC1E9-1D6C-42B9-B1B1-8AA03379E70E@quintile.net> References: <034FC1E9-1D6C-42B9-B1B1-8AA03379E70E@quintile.net> Message-ID: <5D2A3CE6-96C7-4A03-A0A7-7F645BAE637D@canb.auug.org.au> > On 7 Dec 2024, at 09:07, Steve Simon wrote: > > > helios supported DAG shell syntax. > > helios was a unix style os (was it actually posix compliant?) for networks of transputers. > > -Steve For anyone playing along at home, some links I turned up this afternoon. There are other O/S of the same name, using the capitalisation which the Perihelion version eschewed. One for Arduino and another Sel4 related microkernel Wikipedia - already mentioned [ with incorrect capitalisation? ] Helios books: many texts, PDF & html, available + names of many resources Helios Shell CDL - A Distributed Language for Helios CDL was mentioned by others, source code might still be available in Helios-NG Repo Helios-NG [ untouched for years ] This is a project for breathing new live in Helios, an OS from the 90's. Helios was developed by the (now defunct) company called Perihelion Ltd., mainly targeting the INMOS Transputer but later adding other CPUs like the ARM series or TMS320c4x DSPs when INMOS' decline became clear. Legal? I got the permission from Perhelions fromer CEO Tim King and main programmer Nick Garnett to "[...] do whatever you want with the Helios sources." So here we are: "Helios Next Generation” or Helios-NG for short, put under GPL v3. Author's Helios-NG page, 2014. ’The Plan' Transputer board, 2024 To make a long story short: This is basically a design, where the ATARI Mega-ST is used as a boot device and after that just handles file- and user-I/O. The Transputer is attached to the ST via DMA and runs the Helios OS and has direct access to the graphics controller called ‘Blossom’. Totally different concept. Author ‘about' ABOUT ME Hi! I’ll make this short… or at least try to. My name is Axel Muhr. Born 1970 I’m an fairly old geek compared to todays Web 2.0 standards. Let’s say I do remember how to cope with 4k RAM and considered a 174kb 5.25″ Floppy quite a big storage device… not mentioning it’s insane speed. -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin From henry.r.bent at gmail.com Sat Dec 7 18:46:49 2024 From: henry.r.bent at gmail.com (Henry Bent) Date: Sat, 7 Dec 2024 03:46:49 -0500 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact In-Reply-To: <5D2A3CE6-96C7-4A03-A0A7-7F645BAE637D@canb.auug.org.au> References: <034FC1E9-1D6C-42B9-B1B1-8AA03379E70E@quintile.net> <5D2A3CE6-96C7-4A03-A0A7-7F645BAE637D@canb.auug.org.au> Message-ID: On Sat, 7 Dec 2024 at 01:08, wrote: > > > On 7 Dec 2024, at 09:07, Steve Simon wrote: > > Wikipedia - already mentioned [ with incorrect capitalisation? ] > > Indeed. While the article uses correct capitalization throughout, the title of the article is incorrect. I have requested a move to the correct capitalization, which unfortunately (but probably understandably) in Wikipedia land is an involved process. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Sat Dec 7 19:32:58 2024 From: lars at nocrew.org (Lars Brinkhoff) Date: Sat, 07 Dec 2024 09:32:58 +0000 Subject: [TUHS] A re-analysis of some DECtapes from dmr In-Reply-To: (Warren Toomey via TUHS's message of "Sat, 7 Dec 2024 09:01:48 +1000") References: Message-ID: <7wr06jsur9.fsf@junk.nocrew.org> Is the kernel for a PDP-11/20 or /45? If /20, does it use the KS11 for memory mapping? From davida at pobox.com Sat Dec 7 19:56:12 2024 From: davida at pobox.com (David Arnold) Date: Sat, 7 Dec 2024 20:56:12 +1100 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact In-Reply-To: References: Message-ID: <9D33242B-DA95-4927-A73E-CC22CDD5723A@pobox.com> > On 7 Dec 2024, at 11:53, Martin Schröder wrote: > > Am Fr., 6. Dez. 2024 um 23:07 Uhr schrieb Steve Simon : >> helios supported DAG shell syntax. > > Wikipedia: > "What is not immediately apparent is that Helios extends the notion of > Unix pipes into a language called Component Distribution Language > (CDL). I have somewhere the CDL reference: a small volume, perhaps 50 pages. If I recall correctly, there’s some discussion in the two Helios books as well. I can dig them up if there’s interest. <…> >> helios was a unix style os (was it actually posix compliant?) for networks of transputers. > > Mostly. I think it was missing fork(), although I believe it had a vfork(). It was able to run a lot of the free software of the time with a little effort. There was a GCC port, gnumake, MicroEmacs, X11R4 (? Maybe R5?) It was an interesting OS. Not unlike Plan9: its file server protocol is roughly analogous to 9p. d From jsg at jsg.id.au Sat Dec 7 20:39:52 2024 From: jsg at jsg.id.au (Jonathan Gray) Date: Sat, 7 Dec 2024 21:39:52 +1100 Subject: [TUHS] Interesting post about Microsoft and UNIX In-Reply-To: References: <26451.32253.73591.816292@dobie-old.ylee.org> Message-ID: On Fri, Dec 06, 2024 at 10:11:26PM -0500, Henry Bent wrote: > On Fri, 6 Dec 2024 at 17:53, Yeechang Lee wrote: > > > John Levine says: > > > That was oddly shortsighted of IBM. Was it 16 bits is enough for > > > anything you'd do on your desktop, or 32 bits is too close to > > > competing with our big machines? > > > > Compaq got its Deskpro 386 out by late 1986. IBM didn't see the urgency > > and released the PS/2 Model 80 in June 1987. Not just IBM; HP, for example, > > in 1987 was still saying publicly that it was evaluating when and how to > > release its own 386 system. > > > > Compaq's move panicked smaller competitors who didn't need to preserve > > their dignity and knew what the computer meant, with many showing hastily > > built prototypes at November 1986 Comdex. > > > > While Microsoft did help Compaq while designing Deskpro 386, and Gates > > attended the computer's announcement, I don't think it affected its plans > > for Xenix and OS/2. The announcement did establish Compaq as arguably the > > standard setter in IBM's place by 1990, or more accurately proved that IBM > > was no longer the standard setter. Had Dell been the first out with a 386 > > box that might have affected its plans for Dell Unix, but Compaq never had > > its own operating system until the DEC acquisition. > > > > I may be showing my ignorance here, but Compaq rushed to market a 386 > machine so it could run... what? 16 bit DOS? Other 16 bit operating > systems? It's kind of astonishing to me that no one had a 32 bit operating > system ready for the 386 PC market, especially given that Intel had > released the chip to developers a year earlier. SVR2 was readily available > as a porting base but it appears that pretty much everyone dropped the ball > on having a UNIX ready for a fairly powerful $10k machine with a clearly > established market acceptance (from any vendor, not just Compaq or IBM). The 1986 press release for the Deskpro 386 mentioned 386 Xenix was planned for 1987. https://www.latimes.com/archives/la-xpm-1986-09-10-fi-13177-story.html Intel and AT&T had ISC do a 386 port for SVR3. "The 386/ix is based on Release 3.0, which was developed by Interactive Systems Corp. Santa Monica, Calif., under contract to Intel and AT&T. The code was tested through an extensive beta program managed by Intel (with more than 60 80386 beta sites)." Mini-Micro Systems, January 1988, p 45 https://archive.org/details/bitsavers_MiniMicroS_59292072/page/44/mode/2up https://bitsavers.org/magazines/Mini-Micro_Systems/198801.pdf AT&T sold rebadged Olivetti machines with SVR3 in 1987: "AT&T 6386 WGS is today's only 80386-based system to take full advantage of its 32-bit architecture" https://bitsavers.org/pdf/att/6386_wgs/6386_WGS_Brochure.pdf ISC work was also used by Microport: "Microport Runtime System V/386 is based on a version of Unix for the 80386 carried out by Interactive Technologies for AT&T and Intel." Microport to Ship Version of Unix for 386 InfoWorld, Volume 9, Issue 9, 2 Mar 1987, p 3 https://books.google.com/books?id=1TAEAAAAMBAJ&pg=PA3 From henry.r.bent at gmail.com Sat Dec 7 22:10:48 2024 From: henry.r.bent at gmail.com (Henry Bent) Date: Sat, 7 Dec 2024 07:10:48 -0500 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact In-Reply-To: <9D33242B-DA95-4927-A73E-CC22CDD5723A@pobox.com> References: <9D33242B-DA95-4927-A73E-CC22CDD5723A@pobox.com> Message-ID: On Sat, 7 Dec 2024 at 04:56, David Arnold wrote: > > It was able to run a lot of the free software of the time with a little > effort. There was a GCC port, gnumake, MicroEmacs, X11R4 (? Maybe R5?) > I was curious about the GCC port as I've spent far, far too much time looking through GCC support for various platforms and I have no memory of this target. Turns out it was an entirely independent effort, and probably a one-off: https://groups.google.com/g/comp.sys.transputer/c/Zt6WNxneS08/m/ZBRytllF_X8J . The standard C compiler was a different beast, and I was not immediately able to recognize its lineage; it may have been developed from scratch. A mostly complete archive of Helios sources is here: https://github.com/axelmuhr/Helios-NG -Henry -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Sat Dec 7 22:34:07 2024 From: henry.r.bent at gmail.com (Henry Bent) Date: Sat, 7 Dec 2024 07:34:07 -0500 Subject: [TUHS] Interesting post about Microsoft and UNIX In-Reply-To: References: <26451.32253.73591.816292@dobie-old.ylee.org> Message-ID: This is all very enlightening, thank you. Comments inline... On Sat, 7 Dec 2024 at 05:39, Jonathan Gray wrote: > The 1986 press release for the Deskpro 386 mentioned 386 Xenix > was planned for 1987. > https://www.latimes.com/archives/la-xpm-1986-09-10-fi-13177-story.html I found https://www.tech-insider.org/unix/research/1987/0902.html which includes the following quote: "UNIX System V and the 80386 are a perfect technological match," said Bill Gates, chairman of Microsoft Corporation, in remarks at AT&T's press conference here. AT&T and Microsoft are developing a new version of UNIX System V for the 80386 chip that will run XENIX System V as well as UNIX System V applications. This is September 1987, so perhaps Microsoft's abandonment of Xenix was not as early as I had thought. Though this does imply that the Xenix port was not ready at that point, and perhaps was ultimately abandoned by Microsoft. > Intel and AT&T had ISC do a 386 port for SVR3. > > "The 386/ix is based on Release 3.0, which was developed by Interactive > Systems Corp. Santa Monica, Calif., under contract to Intel and AT&T. > The code was tested through an extensive beta program managed by Intel > (with more than 60 80386 beta sites)." > Mini-Micro Systems, January 1988, p 45 > https://archive.org/details/bitsavers_MiniMicroS_59292072/page/44/mode/2up > https://bitsavers.org/magazines/Mini-Micro_Systems/198801.pdf I'm not familiar with 386/ix so I'll have to let others comment here, though I do note that we're now slipping into 1988. AT&T sold rebadged Olivetti machines with SVR3 in 1987: > "AT&T 6386 WGS is today's only 80386-based system to take full advantage > of its 32-bit architecture" > https://bitsavers.org/pdf/att/6386_wgs/6386_WGS_Brochure.pdf This is fascinating, as it claims "concurrent running of both MS-DOS and true 32-bit UNIX System V programs." They were also serious about market positioning - the larger model could handle up to 64MB of RAM and two 135MB disks. I'd appreciate any further details on the exact operating system. > ISC work was also used by Microport: > "Microport Runtime System V/386 is based on a version of Unix for the > 80386 carried out by Interactive Technologies for AT&T and Intel." > Microport to Ship Version of Unix for 386 > InfoWorld, Volume 9, Issue 9, 2 Mar 1987, p 3 > https://books.google.com/books?id=1TAEAAAAMBAJ&pg=PA3 Also interesting; I wonder if the "capability to run multiple MS-DOS applications under Unix" was shipped in a functional form, and what relation it might or might not have had to what was running on the AT&T hardware. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sat Dec 7 23:09:17 2024 From: tuhs at tuhs.org (Arrigo Triulzi via TUHS) Date: Sat, 7 Dec 2024 14:09:17 +0100 Subject: [TUHS] Interesting post about Microsoft and UNIX In-Reply-To: References: Message-ID: > On 7 Dec 2024, at 13:34, Henry Bent wrote: > > Also interesting; I wonder if the "capability to run multiple MS-DOS applications under Unix" was shipped in a functional form, and what relation it might or might not have had to what was running on the AT&T hardware. I used to run an 80286 “Taiwan clone” (as we called them in Italy) with Xenix 286 and, later, its 386 version which was SCO by then (memory a bit fuzzy on when Xenix became SCO Xenix and the Unix) and I definitely could run MS-DOS programs on the 386 - you would use the dos command which mapped drives either to physical drives (i.e. A: was the floppy) or directories within the filesystem. It was often used for businesses which had their inventory on MS-DOS bespoke software but wanted to “multitask” so we had some very dirty code which would run the DOS program on the serial terminals writing to a “network” drive which was actually a directory in the Unix filesystem. In the meantime I was busy writing a migration layer which would allow us to compile the MS-DOS C code on Unix natively replacing, for example, code writing the pretty box characters on MS-DOS with curses equivalents. Fortunately the DB stuff was all C-ISAM for which a portable library existed. All of this was strictly with licenses found off the back of a truck, of course. Licensing bypass in Italy was a national sport. (this was all done using the VM86 extension which, incidentally, still exists in Intel chips… this opens a whole other story about forgotten Intel extensions lingering in 2024 cores which can be used nefariously). Arrigo From henry.r.bent at gmail.com Sat Dec 7 23:45:15 2024 From: henry.r.bent at gmail.com (Henry Bent) Date: Sat, 7 Dec 2024 08:45:15 -0500 Subject: [TUHS] Interesting post about Microsoft and UNIX In-Reply-To: References: Message-ID: On Sat, 7 Dec 2024 at 08:09, Arrigo Triulzi wrote: > > > On 7 Dec 2024, at 13:34, Henry Bent wrote: > > > > Also interesting; I wonder if the "capability to run multiple MS-DOS > applications under Unix" was shipped in a functional form, and what > relation it might or might not have had to what was running on the AT&T > hardware. > > I used to run an 80286 “Taiwan clone” (as we called them in Italy) with > Xenix 286 and, later, its 386 version which was SCO by then (memory a bit > fuzzy on when Xenix became SCO Xenix and the Unix) and I definitely could > run MS-DOS programs on the 386 - you would use the dos command which mapped > drives either to physical drives (i.e. A: was the floppy) or directories > within the filesystem. > > It was often used for businesses which had their inventory on MS-DOS > bespoke software but wanted to “multitask” so we had some very dirty code > which would run the DOS program on the serial terminals writing to a > “network” drive which was actually a directory in the Unix filesystem. > Interesting, thank you for the explanation. How was file locking handled for DOS programs? Did it have some sort of internal call to "share" or was there a more elegant method? -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From davida at pobox.com Sun Dec 8 00:04:40 2024 From: davida at pobox.com (David Arnold) Date: Sun, 8 Dec 2024 01:04:40 +1100 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact In-Reply-To: References: Message-ID: <6835EFA5-A5C5-4F98-8F7F-9845BE83A504@pobox.com> > On 7 Dec 2024, at 23:11, Henry Bent wrote: > > The standard C compiler was a different beast, and I was not immediately able to recognize its lineage; it may have been developed from scratch. Derived from the Norcroft compiler Ihttp://www.codemist.co.uk/ncc/index.html d -------------- next part -------------- An HTML attachment was scrubbed... URL: From aek at bitsavers.org Sun Dec 8 00:09:28 2024 From: aek at bitsavers.org (Al Kossow) Date: Sat, 7 Dec 2024 06:09:28 -0800 Subject: [TUHS] Interesting post about Microsoft and UNIX In-Reply-To: References: Message-ID: On 12/7/24 5:09 AM, Arrigo Triulzi via TUHS wrote: > forgotten Intel extensions lingering in 2024 cores which can be used nefariously There has been an effort by Intel to expunge a lot of PC-isms from their CPUs and ASICs in recent years. I know someone who worked on that out of the architecture group in Oregon. WRT IBM's interest in the 386, OS/2 didn't release a 32 bit version until 2.0 in 1991, well into the 486 era (1989). https://www.quora.com/Why-did-IBMs-OS-2-project-lose-to-Microsoft-given-that-IBM-had-much-more-resources-than-Microsoft-at-that-time From henry.r.bent at gmail.com Sun Dec 8 01:08:00 2024 From: henry.r.bent at gmail.com (Henry Bent) Date: Sat, 7 Dec 2024 10:08:00 -0500 Subject: [TUHS] Xenix Distribution for PDP-11 Message-ID: Hello all, The recent discussion about Xenix has me curious: does any Xenix distribution for the PDP-11 survive? I've never seen one and it would be a fascinating historical artifact. That being said, I am not soliciting copyrighted software; I would be more than happy with a simple answer of, "yes, one has been archived." -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsg at jsg.id.au Sun Dec 8 01:27:59 2024 From: jsg at jsg.id.au (Jonathan Gray) Date: Sun, 8 Dec 2024 02:27:59 +1100 Subject: [TUHS] Interesting post about Microsoft and UNIX In-Reply-To: References: <26451.32253.73591.816292@dobie-old.ylee.org> Message-ID: On Sat, Dec 07, 2024 at 07:34:07AM -0500, Henry Bent wrote: > This is all very enlightening, thank you. Comments inline... > > On Sat, 7 Dec 2024 at 05:39, Jonathan Gray wrote: > > > The 1986 press release for the Deskpro 386 mentioned 386 Xenix > > was planned for 1987. > > https://www.latimes.com/archives/la-xpm-1986-09-10-fi-13177-story.html > > > I found https://www.tech-insider.org/unix/research/1987/0902.html which > includes the following quote: > > > "UNIX System V and the 80386 are a perfect technological match," said Bill > Gates, chairman of Microsoft Corporation, in remarks at AT&T's press > conference here. AT&T and Microsoft are developing a new version of UNIX > System V for the 80386 chip that will run XENIX System V as well as UNIX > System V applications. > > > This is September 1987, so perhaps Microsoft's abandonment of Xenix was not > as early as I had thought. Though this does imply that the Xenix port was > not ready at that point, and perhaps was ultimately abandoned by Microsoft. > > > > Intel and AT&T had ISC do a 386 port for SVR3. > > > > "The 386/ix is based on Release 3.0, which was developed by Interactive > > Systems Corp. Santa Monica, Calif., under contract to Intel and AT&T. > > The code was tested through an extensive beta program managed by Intel > > (with more than 60 80386 beta sites)." > > Mini-Micro Systems, January 1988, p 45 > > https://archive.org/details/bitsavers_MiniMicroS_59292072/page/44/mode/2up > > https://bitsavers.org/magazines/Mini-Micro_Systems/198801.pdf > > > I'm not familiar with 386/ix so I'll have to let others comment here, > though I do note that we're now slipping into 1988. ISC had it running well before then. I'm not sure when 386/ix was commercially available, 1987? "We keep reading articles that say there is no operating system that uses the full features of the 386, but we have had such an operating system functioning since last June." Betty Niimi, Interactive Systems Unix to Lead in 80386-Based Operating System Shipments InfoWorld, December 22, 1986, p 8 https://books.google.com/books?id=UjwEAAAAMBAJ&pg=PA8 > > AT&T sold rebadged Olivetti machines with SVR3 in 1987: > > "AT&T 6386 WGS is today's only 80386-based system to take full advantage > > of its 32-bit architecture" > > https://bitsavers.org/pdf/att/6386_wgs/6386_WGS_Brochure.pdf > > > This is fascinating, as it claims "concurrent running of both MS-DOS and > true 32-bit UNIX System V programs." They were also serious about market > positioning - the larger model could handle up to 64MB of RAM and two 135MB > disks. I'd appreciate any further details on the exact operating system. AT&T had 'Simul-Task 386' which was based on VP/ix from Phoenix Technologies Limited and Interactive Systems Corporation. VP/ix also appeared on the Sun 386i in 1988. > > > > ISC work was also used by Microport: > > "Microport Runtime System V/386 is based on a version of Unix for the > > 80386 carried out by Interactive Technologies for AT&T and Intel." > > Microport to Ship Version of Unix for 386 > > InfoWorld, Volume 9, Issue 9, 2 Mar 1987, p 3 > > https://books.google.com/books?id=1TAEAAAAMBAJ&pg=PA3 > > > Also interesting; I wonder if the "capability to run multiple MS-DOS > applications under Unix" was shipped in a functional form, and what > relation it might or might not have had to what was running on the AT&T > hardware. Microport sold 'Merge 386' from Locus Computing Corporation. Also available for AIX on PS/2 Model 80. AIX for PS/2 wasn't available till 1988. From jsg at jsg.id.au Sun Dec 8 02:02:11 2024 From: jsg at jsg.id.au (Jonathan Gray) Date: Sun, 8 Dec 2024 03:02:11 +1100 Subject: [TUHS] Interesting post about Microsoft and UNIX In-Reply-To: References: <26451.32253.73591.816292@dobie-old.ylee.org> Message-ID: On Sun, Dec 08, 2024 at 02:27:59AM +1100, Jonathan Gray wrote: > Microport sold 'Merge 386' from Locus Computing Corporation. > > Also available for AIX on PS/2 Model 80. AIX for PS/2 wasn't available > till 1988. It was planned for 1988, but was not available until 1989. From tuhs at tuhs.org Sun Dec 8 02:12:41 2024 From: tuhs at tuhs.org (Arrigo Triulzi via TUHS) Date: Sat, 7 Dec 2024 17:12:41 +0100 Subject: [TUHS] Interesting post about Microsoft and UNIX In-Reply-To: References: Message-ID: <91E629E9-2FCB-421A-8596-1D751656708E@alchemistowl.org> On 7 Dec 2024, at 14:45, Henry Bent wrote: > Interesting, thank you for the explanation. How was file locking handled for DOS programs? Did it have some sort of internal call to "share" or was there a more elegant method? Well, as the Unix filesystem was connected to MS-DOS as a “network drive” it had rudimentary opportunistic locking via the SMB protocol which I am not entirely sure actually translated to anything on the Unix side. There was often data corruption when writing from multiple MS-DOS sessions to the same file so the customer, who was particularly keen on the reading from multiple terminals more than the writing, simply decided that only one person could write into the inventory at one time. “Sneaker lock”? Anyway, the port to native Unix was achieved in a couple of months, this was the ‘80s, code was simple and you didn’t have three rows of obscure buttons, a menu on top, another one to the side, etc. to be able to write a letter… Once we moved to Unix C-ISAM implemented proper record-level locking in the library itself and the problem went away (except for the inevitable code changes to handle C-ISAM saying “can’t access the record as it is locked, try again later”). Arrigo From tuhs at tuhs.org Sun Dec 8 02:28:20 2024 From: tuhs at tuhs.org (Arrigo Triulzi via TUHS) Date: Sat, 7 Dec 2024 17:28:20 +0100 Subject: [TUHS] Interesting post about Microsoft and UNIX In-Reply-To: <91E629E9-2FCB-421A-8596-1D751656708E@alchemistowl.org> References: <91E629E9-2FCB-421A-8596-1D751656708E@alchemistowl.org> Message-ID: <119A33DC-0476-43E5-8BAD-A2F16280A7AC@alchemistowl.org> On 7 Dec 2024, at 17:12, Arrigo Triulzi via TUHS wrote: > Well, as the Unix filesystem was connected to MS-DOS as a “network drive” it had rudimentary opportunistic locking via the SMB protocol which I am not entirely sure actually translated to anything on the Unix side. There was often data corruption when writing from multiple MS-DOS sessions to the same file so the customer, who was particularly keen on the reading from multiple terminals more than the writing, simply decided that only one person could write into the inventory at one time. “Sneaker lock”? Correction: it cannot possibly be SMB, that came later - I haven’t the faintest idea of what the network protocol was called in MS-DOS, I just remember you had to load something in CONFIG.SYS on MS-DOS 4 or higher to make it work. Arrigo From imp at bsdimp.com Sun Dec 8 02:38:08 2024 From: imp at bsdimp.com (Warner Losh) Date: Sat, 7 Dec 2024 09:38:08 -0700 Subject: [TUHS] Interesting post about Microsoft and UNIX In-Reply-To: <119A33DC-0476-43E5-8BAD-A2F16280A7AC@alchemistowl.org> References: <91E629E9-2FCB-421A-8596-1D751656708E@alchemistowl.org> <119A33DC-0476-43E5-8BAD-A2F16280A7AC@alchemistowl.org> Message-ID: On Sat, Dec 7, 2024, 9:28 AM Arrigo Triulzi via TUHS wrote: > On 7 Dec 2024, at 17:12, Arrigo Triulzi via TUHS wrote: > > Well, as the Unix filesystem was connected to MS-DOS as a “network > drive” it had rudimentary opportunistic locking via the SMB protocol which > I am not entirely sure actually translated to anything on the Unix side. > There was often data corruption when writing from multiple MS-DOS sessions > to the same file so the customer, who was particularly keen on the reading > from multiple terminals more than the writing, simply decided that only one > person could write into the inventory at one time. “Sneaker lock”? > > Correction: it cannot possibly be SMB, that came later - I haven’t the > faintest idea of what the network protocol was called in MS-DOS, I just > remember you had to load something in CONFIG.SYS on MS-DOS 4 or higher to > make it work. > Yes. There were namespace hooks of a sort that one could hook into via a TSR... I wrote something for a DOS 3.1 system that had a few initial UNDOCUMENTED interfaces. I couldn't ever get anything to work beyond the init... Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sun Dec 8 02:41:28 2024 From: tuhs at tuhs.org (Arrigo Triulzi via TUHS) Date: Sat, 7 Dec 2024 17:41:28 +0100 Subject: [TUHS] Interesting post about Microsoft and UNIX In-Reply-To: References: <91E629E9-2FCB-421A-8596-1D751656708E@alchemistowl.org> <119A33DC-0476-43E5-8BAD-A2F16280A7AC@alchemistowl.org> Message-ID: <28A287D9-4D86-4DCF-9C23-32FD8D48CEEC@alchemistowl.org> On 7 Dec 2024, at 17:38, Warner Losh wrote: > Yes. There were namespace hooks of a sort that one could hook into via a TSR... I wrote something for a DOS 3.1 system that had a few initial UNDOCUMENTED interfaces. I couldn't ever get anything to work beyond the init... Yes, TSRs… the art of loading them in the correct sequence so that you did not make your machine unstable. Some we really quite useful, for example there was one which I seem to recall was called “Tornado” which allowed you to write linked and indexed notes, a bit like an early Hypercard? Then there were the ones hooking services to give you access to the RAM between 640kB and 1MB, the ones to page in & out memory > 1MB, oh the horrors… I was really rather pleased with my 386 running Unix! Arrigo From henry.r.bent at gmail.com Sun Dec 8 03:01:22 2024 From: henry.r.bent at gmail.com (Henry Bent) Date: Sat, 7 Dec 2024 12:01:22 -0500 Subject: [TUHS] Interesting post about Microsoft and UNIX In-Reply-To: <91E629E9-2FCB-421A-8596-1D751656708E@alchemistowl.org> References: <91E629E9-2FCB-421A-8596-1D751656708E@alchemistowl.org> Message-ID: On Sat, 7 Dec 2024 at 11:12, Arrigo Triulzi wrote: > On 7 Dec 2024, at 14:45, Henry Bent wrote: > > Interesting, thank you for the explanation. How was file locking > handled for DOS programs? Did it have some sort of internal call to > "share" or was there a more elegant method? > > Well, as the Unix filesystem was connected to MS-DOS as a “network drive” > it had rudimentary opportunistic locking via the SMB protocol which I am > not entirely sure actually translated to anything on the Unix side. There > was often data corruption when writing from multiple MS-DOS sessions to the > same file so the customer, who was particularly keen on the reading from > multiple terminals more than the writing, simply decided that only one > person could write into the inventory at one time. “Sneaker lock”? > Sadly, that's the answer I was expecting - the locking didn't really work in practice. That might go some way towards explaining why this concept of multiple DOS sessions under UNIX didn't really have widespread adoption. There were always all sorts of "DOS under UNIX" ideas, from these early concepts through all the way to Sun's physical PC boards, but none of them ever really seemed to gain significant traction. The only connecting concept seems to be that DOS just wasn't meant to be a multi-user OS, and certainly not a networked one. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sun Dec 8 04:15:55 2024 From: tuhs at tuhs.org (Arrigo Triulzi via TUHS) Date: Sat, 7 Dec 2024 19:15:55 +0100 Subject: [TUHS] Interesting post about Microsoft and UNIX In-Reply-To: References: <91E629E9-2FCB-421A-8596-1D751656708E@alchemistowl.org> Message-ID: <3FD82849-BDEB-4AED-A805-44D2FE45918E@alchemistowl.org> On 7 Dec 2024, at 18:01, Henry Bent wrote: > Sadly, that's the answer I was expecting - the locking didn't really work in practice. That might go some way towards explaining why this concept of multiple DOS sessions under UNIX didn't really have widespread adoption. I cannot honestly see how it could be made to work - locking, even in Unix, was very much a case of “let’s hope we all use the same function call” and, in the specific case of MS-DOS, was hardly necessary since it was a single-user OS running a single application at a time. The arrival of networking probably introduced locking to MS-DOS in the same way hopeful way. There was no real expectation on our part that the DB would not be corrupted by multiple MS-DOS sessions writing to it, even if using C-ISAM, because the assumption would have always been “one machine, one user, one task”. Fortunately the port to Unix fixed this because C-ISAM was conscious of the concept of multiple accesses to the database. > There were always all sorts of "DOS under UNIX" ideas, from these early concepts through all the way to Sun's physical PC boards, but none of them ever really seemed to gain significant traction. The only connecting concept seems to be that DOS just wasn't meant to be a multi-user OS, and certainly not a networked one. Even on the i286 there were attempts at having MS-DOS running within a multi-user OS. Remember that OS/2 on the 80286 used a triple fault to get you back into real mode to execute an MS-DOS program. "Running MS-DOS” was really important in those days and a lot of effort was expended trying to get that to work in some way[1]. Arrigo [1] I am a (very) guilty party for flooring my CPUs and making fans sound like 747s by running Simcity 2000 and Railroad Tycoon in dosbox on Linux. From ron at ronnatalie.com Sun Dec 8 06:38:02 2024 From: ron at ronnatalie.com (Ron Natalie) Date: Sat, 07 Dec 2024 20:38:02 +0000 Subject: [TUHS] Pipes (was Re: After 50 years, what has the Impact of Unix been?) In-Reply-To: References: <568FD44F-01FB-441B-846B-7D42C3A8E1FB@canb.auug.org.au> <20241205030843.8552FAB1EDA5@ary.qy> <32bf4263-277d-8c8b-6bf7-e33df04a2c3c@taugh.com> Message-ID: NO, the 11/23 has an MMU and was perflectly capable of running UNIX. The 23+ had the extra address lines allowing it to address 4 MB like the 11/70. ------ Original Message ------ >From "Adam Thornton" To "Ron Natalie" ; "The Eunuchs Hysterical Society" Date 12/5/2024 9:29:24 PM Subject Re: [TUHS] Re: Pipes (was Re: After 50 years, what has the Impact of Unix been?) >/23+, no? The basic 23 doesn't have an MMU, I'm pretty sure. > >On Thu, Dec 5, 2024 at 11:58 AM Ron Natalie wrote: >>I remember on MiniUnix (a stripped down kernel that would run on >>PDP11’s >>without memory management, in our case 11/03, 11/20, and an older >>11/40) >>there were no kernel pipes (and limited process concurrency). >>The shell used the aforementioned emulation of pipe by just running >>the >>output of one process into a temporary file subsequently loaded as >>stdin >>of the other. >> >>We kind of put all that to bed when the 11/23s came out and we could >>run >>our full up kernel on the micros. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Sun Dec 8 07:06:15 2024 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 7 Dec 2024 16:06:15 -0500 (EST) Subject: [TUHS] A re-analysis of some DECtapes from dmr Message-ID: <20241207210615.0CBA818C079@mercury.lcs.mit.edu> > From: Yufeng Gao > This version of UNIX appears to be between V1 and V2 It's too bad it's not 'between V2 and V3', since the UNIX kernels V2 and V3 are missing. (V4 is the earlist one that we have, after the V2 and onward gap.) So, depending on how far from V1 (which we have) it is, it _might_ be worth dis-assenbling. It would be particularly worth having it if it suppports the KS11, since almost no documentation of that has survived; code that uses it would allow re-creation of a programming manual for it. > From: Lars Brinkhoff > Is the kernel for a PDP-11/20 or /45? I don't think it can be the /45; as of V2, the /45 was apparently expected in the near future, and this was before the V2. Noel From tuhs at tuhs.org Sun Dec 8 11:01:28 2024 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Sun, 8 Dec 2024 11:01:28 +1000 Subject: [TUHS] A re-analysis of some DECtapes from dmr In-Reply-To: <7wr06jsur9.fsf@junk.nocrew.org> References: <7wr06jsur9.fsf@junk.nocrew.org> Message-ID: On Sat, Dec 07, 2024 at 09:32:58AM +0000, Lars Brinkhoff wrote: > Is the kernel for a PDP-11/20 or /45? If /20, does it use the KS11 for > memory mapping? Lars, it's the same kernel as in this project: https://github.com/DoctorWkt/unix-jun72 Here's part of the SimH config: set cpu 11/20 set cpu 32K set rk0 enabled set rf enabled set tc enabled set tc enabled set rf enabled set ke enabled set dci en Cheers, Warren From tuhs at tuhs.org Mon Dec 9 17:14:17 2024 From: tuhs at tuhs.org (Arno Griffioen via TUHS) Date: Mon, 9 Dec 2024 08:14:17 +0100 Subject: [TUHS] Interesting post about Microsoft and UNIX In-Reply-To: References: <26451.32253.73591.816292@dobie-old.ylee.org> Message-ID: On Sat, Dec 07, 2024 at 07:34:07AM -0500, Henry Bent wrote: > "UNIX System V and the 80386 are a perfect technological match," said Bill > Gates, chairman of Microsoft Corporation, in remarks at AT&T's press conference > here. AT&T and Microsoft are developing a new version of UNIX System V for the > 80386 chip that will run XENIX System V as well as UNIX System V applications. > > This is September 1987, so perhaps Microsoft's abandonment of Xenix was not as > early as I had thought.  Though this does imply that the Xenix port was not > ready at that point, and perhaps was ultimately abandoned by Microsoft. https://www.landley.net/history/mirror/unix/scohistory.html states that: "1987 - SCO ships SCO XENIX 386, the first 32-bit operating system (and first UNIX System) for Intel 386 processor-based systems." So it looks like XENIX development had been already stopped at MS and taken on/over by SCO in the meantime. Matches up with the WIKI doc on Xenix and the transfer of it's ownership from MS to SCO: https://en.wikipedia.org/wiki/Xenix#:~:text=SCO's%20Xenix%20System%20V%2F386,both%20Xenix%20and%20SCO%20Unix. So it seems around 1985/6 MS stopped any real Xenix development and got out of the UNIX market, after which SCO went on with it. Side-note... Compaq servers running SCO UNIX versions were *very* popular in the small to medium business area here from the late 80's onward. Lots of 'productivity' software like administrative/financial/etc. software on SCO that allowed many people to work concurrently using one or a few servers and either terminals or some sort of networking. (Ahhhhh... The days of the network-wars with oodles of competing more and lesser known network types.. Messy and convoluted, but quite fun... :) ) The fact that it was UNIX underneath was totally irrelevant to most end customers though. They just got/ran it to run their business and it worked much better than any MS-based solution until the early 2000s. Used to be a large part of my work during the early 90's to maintain, upgrade and fix such systems as the end customers usually had no technical people onsite anyway. Bye, Arno. From woods at robohack.ca Wed Dec 11 08:41:30 2024 From: woods at robohack.ca (Greg A. Woods) Date: Tue, 10 Dec 2024 14:41:30 -0800 Subject: [TUHS] Interesting post about Microsoft and UNIX In-Reply-To: References: <26451.32253.73591.816292@dobie-old.ylee.org> Message-ID: At Fri, 6 Dec 2024 20:55:36 -0700, Marc Rochkind wrote: Subject: [TUHS] Re: Interesting post about Microsoft and UNIX > > I'm sure Compaq was thinking ahead. They would be very aware of Microsoft's > Windows plans. Buyers also think ahead, especially corporate buyers, who > are the real customers. I was working on contracts at Canadian Pacific Railway at about that time. I'm pretty sure CP would have been a big customer for 386 machines. They were an early adopter of PCs in general for a larger corporation (CP was one of the first "paperless" companies in Canada, with PCs on every desktop and being pushed out to big customers to interface via 3270 emulation cards and custom software with their mainframe systems for ordering train cars, etc. Meanwhile many similar- sized companies with mainframes were still all just using plain old 3270 terminals (i.e. without custom interface software).) At the time of the debut of the 386 we were building a new track control system for the Broadview subdivision and it was being built with Intel 286 systems running Xenix. I think they may have been Compaq hardware, though earlier MS-DOS projects I worked on at CP were using Olivetti PCs, though CP also certainly had PCs from Compaq and IBM as well. I was doing device drivers (including one for a Matrox graphics card), various support libraries such as an IPC framework, and general toolchain and OS support for the project. I remember putting up a poster from Intel of the i386 chip in my cubicle to remind colleagues of the exciting 32-bit things soon to come. I don't remember having any worries that there would be any problem with getting a 386 version of Xenix or some other Unix. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: