TUHS

tuhs@tuhs.org

21 participants
6516 discussions

by Warren Toomey

All, sorry for the test post. Grant Taylor has been helping me resolve the mail bounces, which we think are due to the mailing list preserving the existing DKIM information when forwarding to e-mail. This e-mail is going to a test address which should strip the inbound DKIM stuff before passing to the TUHS list. Hopefully we can observe the result and check the logs. Warren

7 years, 8 months

Steering it back again ....

by Warren Toomey

And ... we now bring the threads on current Unix-like systems and current mail configuration to a close, and remind the group that the mailing list is about _old_ things :-) Mind you, if the list lasts another 25 years, these two threads will meet that criterion. Thanks, Warren

7 years, 8 months

Re: [TUHS] Who is running their own mail server and what do you r un?

by Jason Stevens

I use Exchange 5.5 & MacOS + Outlook... I know very un-unixy but it's more so a test bed for a highly modified version of Basilisk II (more so to test appletalk of all things) I route it through Office 365, since I use that for my company, and they have a 'connector' to route a domain through their spam filters and then drop it to my legacy Exchange server. I gave up on the SPAM fight, it really was far too much of a waste of my time. That and this email address is in far far too many databases... :| I'm on the fence if it's really worth the effort though. I wanted to setup some kind of UUCP / Exchange relay, and maybe go full crazy with X.25 but at some point I need to maybe let some of this old stuff just die... It's the same reason I don't run ATM at home. > ---------- > From: Larry McVoy > Sent: Thursday, September 21, 2017 12:25 AM > To: TUHS main list > Subject: [TUHS] Who is running their own mail server and what do you > run? > > I tried running my own server on mcvoy.com but eventually gave up, the > spam filtering was a non-ending task. > > If someone has a plug and chug setup for MX I'd love to try it. > > Thanks, > > --lm >

7 years, 8 months

Test on TUHS mail config

by Warren Toomey

Sorry all, just trying a change on the TUHS mail list config. I'll set it back once I see what this message does. Warren

7 years, 8 months

UNIX of choice these days?

by Rudi Blom

Maybe I'm the odd one out here, but at home I've only got a Windows/10 notebook :-) Mind you, at work I play with . aDEC 400xP, DECpc MTE, Prioris XL server running SCO UNIX 3.2V4.2 . AlphaServer DS10 running Digital Unix 4.0g . AlphaServer DS15 running Tru64 Unix 5.1B . HP(E) rx-servers rx1620, rx2620, rx2660 running HP-UX 11.23 . HP(E) rx-servers rx2800 i2/i4 running HP-UX 11.31 . DOS 6.22, Windows/Xp, Windows/7 clients Maintaining applications which were conceived late 80s is fun :-)

7 years, 8 months

ping

by ron minnich

I got a note about excessive bounces. Can you give me more info? I think somebody is up to something but can't be sure what.

7 years, 8 months

Re: [TUHS] PDP-10 UNIX?

by Nelson H. F. Beebe

I worked on, and co-managed, TOPS-20 on DECsystem 20/40 and 20/60 systems with the PDP-10 KL-10 CPU from September 1978 to 31 October 1990, when our 20/60 was retired. (A second 20/60 on our campus in the Department of Computer Science had been retired a year or two earlier). There were two C compilers on the system, Ken Harrenstien's kcc, and Steve Johnson's pcc, the latter ported to TOPS-20 by my late friend Jay Lepreau (1952--2008). pcc was a straightforward port intended to make C programming, and porting of C software, fairly easy on the PDP-10, but without addressing many of the architectural features of that CPU. kcc was written by Ken Harrenstien from scratch, and designed explicitly for support of the PDP-10 architecture. In particular, it included an O/S system call interface (the JSYS instruction), and support for pointers to all byte sizes from 1 to 36. Normal addressing on the PDP-10 is by word, with an 18-bit address space. Thus, two 18-bit fields fit in a 36-bit word, ideally suited for Lisp's CAR and CDR (contents of address/decrement register, used for first and rest addressing of lists). However, PDP-10 byte pointers encode the byte size and offset in the second half of a word. Pointer words could contain an indirect bit, which caused the CPU to automatically load a memory word at that address, and repeat if that word was found to be an indirect pointer. That processing was handled by the LOAD instructions, so it worked for all programming languages. Characters on the ten-or-so different PDP-10 operating systems were normally 7-bit ASCII, stored left to right in a word, with the right-most low-order bit set to 0, UNLESS the word was intended to be a 5-decimal-digit line number, in which case, that bit was set to 1. Compilers and some other tools ignored line-number words. As the need to communicate with other systems with 8-, 16-, and 32-bit words grew, we had to accommodate files with 8-bit characters, which could be stored as four left-adjusted characters with 4 rightmost zero bits, or handled as 9 consecutive 8-bit characters in two adjacent 36-bit words. That was convenient for binary file transfer, but I don't recall ever seeing 9-bit characters used for text files. By contrast, on the contemporary 36-bit Univac 11xx systems running EXEC-8, the O/S was extended from 6 six-bit Fieldata chararacters per word to 9-bit extended ASCII (and ISO 8859-n Latin-n) characters: the reason was that the Univac CPU had quarterword access instructions, but not arbitrary byte-size instructions like the PDP-10. I don't think that there ever was a C compiler on those Univac systems. On the PDP-10, memory locations 0--15 are mapped to machine registers of those numbers: short loops could be copied into those locations and would then run about 3x faster, if there weren't too many memory references. Register 0 was not hardwired to a zero value, so dereferencing a NULL pointer could return any address, and could even be legitimate in some code. The kcc documentation reports: >> ... >> The "NULL" pointer is represented internally as a zero word, >> i.e. the same representation as the integer value 0, regardless of >> the type of the pointer. The PDP-10 address 0 (AC 0) is zeroed and >> never used by KCC, in order to help catch any use of NULL pointers. >> ... In kcc, the C fopen() call second argument was extended with extra flag letters: >> ... >> The user can override either the bytesize or the conversion >> by adding explicit specification characters, which should come after >> any regular specification characters: >> "C" Force LF-conversion. >> "C-" Force NO LF-conversion. >> "7" Force 7-bit bytesize. >> "8" Force 8-bit bytesize. >> "9" Force 9-bit bytesize. >> "T" Open for thawed access (TOPS-10/TENEX only) >> >> These are KCC-specific however, and are not portable to other >> systems. Note that the actual LF conversion is done by the USYS (Unix >> simulation) level calls (read() and write()) rather than STDIO. >> ... As the PDP-10 evolved, addressing was extended from 18 bits to 22 bits, and kcc had support for such extended addresses. Inside the kcc compiler, >> ... >> Chars are aligned on 9-bit byte boundaries, shorts on halfword >> boundaries, and all other data types on word boundaries (with the >> exception of bitfields and the _KCCtype_charN types). Converting any >> pointer to a (char *) and back is always possible, as a char is the >> smallest possible object. If the original object was larger than a >> char, the char pointer will point to the first byte of the object; this >> is the leftmost 9-bit byte in a word (if word-aligned) or in the halfword >> (if a short). >> ... That design choice meant that the common assumption that a 32-bit word holds 4 characters remained true on the PDP-10. The _KCCtype_charN types could have N from 1 to 36. The case N = 6 was special: it handled the SIXBIT character representation used by compilers, linkers, and the O/S to encode external function names mapped to a 6-bit character set unique to the PDP-10, allowing 6-character unique names for symbols. I didn't readily find documentation of kcc features on the Web, so for those who would like to learn more about support of C and Unix code on the PDP-10, I created this FTP/Web site today: http://www.math.utah.edu/pub/kcc ftp://ftp.math.utah.edu/pub/kcc It supplies several *.doc files; the user.doc file is likely the one of most interest for this discussion. Getting C onto TOP-20 was hugely important for us, because it gave us access to many Unix tools (I was the first to port Brian Kernighan's awk language to the PDP-10, and also to the VAX VMS native C compiler), and eased the transition from TOPS-20 to Unix that began for our users about 1984, and continued until our complete move in summer 1991, when we retired our last VAX VMS systems. Finally, here is a pointer to a document that I wrote about that transition: http://www.math.utah.edu/~beebe/reports/1987/t20unix.pdf P.S. I'll be happy to entertain further questions about these two C compilers on the PDP-10, offline if you prefer, or on this list. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

7 years, 8 months

V7 chroot author?

by Warren Toomey

All, I just had this question popped into my inbox. Cheers, Warren ----- Forwarded message from Evan Koblentz <evan(a)snarc.net> ----- Hi Warren. Evan K. here from Vintage Computer Festival, etc. I'm trying to find out who invented the Chroot command in Version 7 Unix. Could you help, possibly including a post to TUHS email list on my behalf? I posted to our local (northeast US) list and also emailed Brian Kernighan and Bill Cheswick. Hoping this leads to an answer. I'm looking for a name, not just generalities. Thanks very much. ----- End forwarded message -----

7 years, 8 months

Re: [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

by norman＠oclsc.org

Random832: Just out of curiosity, where does perror(filename), quite possibly the *most* common error message on Unix as a whole, fall on your scale? It says which of the file location or permissions (or whatever else) it is, but not whether it was attempting to open it for reading or writing. ===== I never liked perror much. It's a little too primitive: you get exactly one non-formatted string; you get only stderr, so if you're sending messages separately to a log or writing them to a network connection or the like, you're out of luck. strerror(errno) hits the sweet spot for me. Until it appeared in the standard library (and until said standard spread enough that one could reasonably expect to find it anywhere) I kept writing more or less that function into program after program. I guess the problem with perror is that it isn't sufficiently UNIX-like: it bundles three jobs that are really separate (convert errno to string message, format an error message, output the message) into one function, inseparably and inflexibly. Norman Wilson Toronto ON

7 years, 8 months

B Source Code

by Robert Swierczek

Does anyone know of the existence of source code written in B (C's predecessor?) I have encountered a few snippets here and there, but nothing substantial. The only "real" program that I know of is AberMUD-1. It looks like there exists a physical print-out of it: https://dropsafe.crypticide.com/article/12714 Could it be that this is the only artifact left of this most important "missing link" of C and Unix History? How can this (and any other B source) be gathered and preserved?

7 years, 8 months

Re: [TUHS] Weird nix? Regulus

by Derek Fawcus

> What a pain, almost like Unix, and not quite. l It was a clone of Unix for the 68k. Funny, I was just poking through some ccpm68k source/tools, which happened to contain the Alcyon C compiler source, and one of the files is: $ cat v103/doc/files/Sectioname .fo 'REGULUS Reference Manual'- % -'FILES' $ The same system? DF

7 years, 8 months

PDP-10 UNIX?

by Arthur Krewat

Was there ever a UNIX or even the thought of porting one to a PDP-10? 36-bit machine, 18-bit addresses (more on KL10 and KS10), and: *0 would return register 0 instead of a SIGSEGV ;) 8-bit bytes would have been a wasteful exercise, but you never know. (losing 4 bits of every 36-bit word) thanks! art k.

7 years, 8 months

Re: [TUHS] PDP-10 UNIX?

by jnc＠mercury.lcs.mit.edu

> That makes sense if it's '73. That would be the Ritchie front end and > v5/v6 syntax as I remember=20 Here: http://publications.csail.mit.edu/lcs/specpub.php?id=717 is the TR describing it (well, this report covers one by him for the Honeywell 6000 series, but IIRC it's the same compiler). I didn't read the whole thing slowly, but glancing quickly at it, it sounds like it's possible a 'from scratch' thing? Noel

7 years, 8 months

Re: [TUHS] B Source Code

by jnc＠mercury.lcs.mit.edu

> From: Alec Muffett > "threaded code" in the old sense could be smaller than the equivalent > CISC binary on the same machine One can think of 'threaded code' as code for a new virtual machine, one specialized to the task at hand. > https://en.m.wikipedia.org/wiki/Threaded_code For those who really want to delve in some depth, see the chapter "Turning Cousins into Sisters" (Chapter 15, pg. 365) in "Computer Engineering: A DEC View of Hardware Systems Design", by Bell, Mudge and McNamara. Interesting factoid: The PDP-11 initially used a threaded FORTRAN implementation. In line with the observation above (about a new virtual machine), DEC actually looked into writing microcode for the -11/60 (which had a writeable control store) to implement the FORTRAN virtual machine. Noel

7 years, 8 months

Re: [TUHS] PDP-10 UNIX?

by Johnny Billquist

On 2017-09-17 18:33, Arthur Krewat <krewat(a)kilonet.net> wrote: > Was there ever a UNIX or even the thought of porting one to a PDP-10? Definitely a thought. An attempt was started on NetBSD for the PDP-10, and it sortof got halfway of getting into single-user, but I'm not sure if the person who worked on it just got distracted, or if he hit problems that were really hard to solve. I certainly know the person, and can find out more if people really are interested. > 36-bit machine, 18-bit addresses (more on KL10 and KS10), and: > > *0 would return register 0 instead of a SIGSEGV ;) Yes. Not the first machine that would be true for. You don't have address 0 unmapped on a PDP-11 either. > 8-bit bytes would have been a wasteful exercise, but you never know. > (losing 4 bits of every 36-bit word) Uh... Why 8 bit bytes? That way lies madness. There exists a really good C compiler for TOPS-20 - KCC. It uses 9 bits per byte. Works like a charm, except when some people write portable code that is not so portable. ;-) KCC was written by KLH, unless I remember wrong. Same guy who also wrote the KLH-10 emulator. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

7 years, 8 months

Weird nix? Regulus

by David

What a pain, almost like Unix, and not quite. l It was a clone of Unix for the 68k. The APIs were ever so slightly different because the authors were concerned about copyright infringement. libc calls had different argument orders or types and in general it was just off enough that you wanted to claw at the screen every time something went wrong. To top it off, the system we were hosting it on was so slow that a full rebuild of our meager (10k lines) software took overnight. I eventually ported all the software to a SparcStation-2 cross compiling to the 68k target we were embedded on. > To kick a more relevant thread off, what was the "weirdest" Unix system you used & why? Could be an emulation like Eunice, could be the hardware e.g NULL was not zero, NUXI byte ordering etc. > > Cheers, Warren

7 years, 8 months

Re: [TUHS] really Pottering vs UNIX

by Clem Cole

On Thu, Sep 14, 2017 at 4:09 PM, Jon Steinhart <jon(a)fourwinds.com> wrote: > > Well, I'd suggest that a lot of this has to do with people who have vision > and people who don't. When you look at UNIX, you see something created by > a bunch of very talented people who had a reasonably shared vision of what > they were trying to achieve. > Jon - I mostly agree, but would twist it a little differently (hey, we've been arguing since the 1970s, so why stop now). I think you are actually touching on an idea that has been around humanity for a long time that is independent of the computer field. We call it "good taste." Part of acquiring good taste is learning what is in bad taste, a heavy dose of experience and frankly the ability to evaluate your own flaws. What I always love about Dennis, Ken, Doug, Steve and the rest if the team is their willingness to accept the shortcomings and compromises that were made as the developed UNIX as a system. I never saw them trying to claim perfection or completeness, much less and end state had been reached. Always looking for something better, more interesting. And always, standing on the shoulders of others... What I really dislike about much of the crowd that has been discussed is that they often seem more contented to kick people in the shins that standing on their shoulders. I used to say, when we were hiring people for some of my start-ups, what we wanted was experienced folks that had demonstrated good taste. Those are people you can trust; and will get you pretty close to where you want to be. In fact, to pick on one of my previous employers, I have always said, what DEC got wrong, was it was always striving to be perfect. And lots of things never shipped, or when they did (like Alpha) it was wonderful, but it did not matter. The opportunity window had passed. Part of "good taste" is getting the job done and on time. Being "good enough" and moving on to the next thing. Sun (certainly at the beginning) was pretty good at this idea. The UNIX team clearly got a lot of it right. It is easy to throw stones at others. It is hard to repeatedly get so much right for so long and UNIX has and did. Clem

7 years, 8 months

really Pottering vs UNIX

by David

On Sep 15, 2017, at 1:32 AM, tuhs-request(a)minnie.tuhs.org wrote: > > From: "Steve Johnson" <scj(a)yaccman.com> > To: "Dan Cross" <crossd(a)gmail.com>, "Bakul Shah" <bakul(a)bitblocks.com> > Cc: "TUHS main list" <tuhs(a)minnie.tuhs.org> > Subject: Re: [TUHS] really Pottering vs UNIX > Message-ID: > <d92047c5a36c6e72bd694322acb4ff33e3835f9f(a)webmail.yaccman.com> > Content-Type: text/plain; charset="utf-8" > > > > More to do with a sense for quality. Often developed through > experience > (but not just that). I think what we need is a guild system for > programmers/engineers. Being an apprentice of a master craftsman is > essential for learning this "good taste" as you call it. > > Back when I was writing FORTRAN, I was > working for a guy with very high standards who read my code and got me > to comment or, more usually, rewrite all the obscure things I did. > He made the point that a good program never dies, and many people > will read it and modify it and try to understand it, and it's almost a > professional duty to make sure that you make this as easy as possible > for them. > When I taught at UCSD I always made it a point to inform the students that the person who will be maintaining their programs in the future will all be reformed axe murderers. These nice folks learned C (at the time) on MS-DOS 3.1 and weren’t as homicidal as they used to be. They would however be given your home address and phone number in case they had questions about your code. It was always good for a laugh and I went on to explain how code outlives the author and so you should take care to make it easy for someone else to work on your code. The other thing I did was to have students give their programs half way through the project to a randomly chosen (by me) other student. They were not allowed to assist the recipient and grades were based on how well the final program met the requirements given at the beginning of the project. Code quality went way up on the second project compared to the first. David

7 years, 8 months

Re: [TUHS] And now ... Weirdnix?

by David

I had almost wiped any memory of DG/UX from my memory. Now I’m quite sure I must resume therapy for it. I wrote device drivers for that . . . thing to drive graphics cards for Megatek and its custom version of X11 that buried about 1/2 of the server in the hardware. David > On Sep 17, 2017, at 12:01 PM, tuhs-request(a)minnie.tuhs.org wrote: > > From: Chet Ramey <chet.ramey(a)case.edu> > To: arnold(a)skeeve.com, wkt(a)tuhs.org, tuhs(a)tuhs.org > Subject: Re: [TUHS] And now ... Weirdnix? > Message-ID: <58b4bb3e-1b94-0e3d-312d-9151e8a057a6(a)case.edu> > Content-Type: text/plain; charset=utf-8 > > On 9/17/17 3:28 AM, arnold(a)skeeve.com wrote: > >> Whatever Data General called their Unix layer on top of their native >> OS for the Eclipse or whatever it was (32 bit system). > > I think they called it DG/UX -- just like they called their wretched > System V port.

7 years, 8 months

Re: [TUHS] Happy birthday, Dennis Ritchie!

by Norman Wilson

arnold(a)skeeve.com: > This not true of ALL the GNU project maintainers. Don't tar everyone > with RMS's brush. John Steinhart: What are we supposed to to then? cpio? === I guess we're supposed to tp his house. Norman Wilson Toronto ON

7 years, 8 months

Re: [TUHS] Writable Control Store and UNIX

by Clem Cole

On Fri, Sep 15, 2017 at 11:21 AM, Noel Chiappa <jnc(a)mercury.lcs.mit.edu> wrote: > > > Why not just write a Unix-native one? They aren't that much work - I > created a > > uassembler overnight (literally!) for the QSIC project Dave Bridgham and I > > have been working on. Agreed Terry Hayes, tjt and I hacked an assembler and loader for Masscomp together years ago pretty fast. We actually, made all those tools look a lot like the DEC ones because a lot of same HW people were writing the uCode for the Masscomp FP/APs as had written the much of the 11 and Vax code. [Fun story, that a few other tools that had been written for UNIX that patriots older RSX/VMS support tools were quietly traded to DEC WRL for some HW libraries. We both were using the same brand CAD system and our HW guys wanted some design rule stuff WRL had done for Jupiter, and they wanted UNIX based tools to run on Ultrix]. As for Tektronix earlier, we did not know much about the WSC unit and basically the CSAV/CRET stuff was supposed to be a one shot thing. We just wanted to use the tool that came with it; cause we did not think we were going to do much with it. In hind sight and knowing what I would learn 3-5 years later, writing our own would have made more sense; but I'm not sure it was very well documented. Clem

7 years, 8 months

Re: [TUHS] B Source Code

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall > Did anyone actually use the WCS? Well, the uassembler was a product for a while, so they must have.. > I had visions of implementing CSAV and CRET on our -60, but never did > get around to it. I recently had the idea of programming them into an M792 ROM card (100nsec access time); user programs couldn't have used it without burning a segment (to map in the appropriate part of the I/O space), but it might have sped up the kernel some (and it would have been trivial to add, once the card was programmed - with a soldering iron - BTDT, BITD :-). Haven't gotten to it yet - still looking for an M792 (I don't want to trash any of my pre-programmed M792-xx's :-). > From: Clem Cole <clemc(a)ccc.com> > A big issue, again IIRC, was the microcode compiler/tools for the WSC > ran on RSX so it meant UNIX was not running, which was not popular. Why not just write a Unix-native one? They aren't that much work - I created a uassembler overnight (literally!) for the QSIC project Dave Bridgham and I have been working on. It's been improved a lot since the first version (e.g. the entire uengine description is now read in from a config file, instead of being compiled in), but that first version did work fine... Or was the output format not documented? Noel

7 years, 8 months

UNIX: An Application Delivery Vehicle vs. SW Development Platform

by Clem Cole

I been watching and thinking a bit about this exchange particularly, since I had a paper accepted in "Unix in Europe: between innovation, diffusion and heritage" Symposium which touches on this topic. I think it is really gets to the core of the problem that UNIX was caught with and I certainly did not understand at the time. The issue here is were are all technologist and as such, we think in terms of the technology and often forget that its the economics that is the long pole in the tent. *Simply, computers are purchased as a tool to help to solve problems for people*. And the question remains who controls the money being spend. *UNIX was written originally by a group of people for themselves.* The problem that they were solving, *was how to build better programs and systems for those programs*. Vendors, particularly hardware centric vendors, really only care that you buy their (HW) product which is where they make their money. As it turns out applications software vendors, don't care about operating systems - as we used to say Larry Ellison never cared for VMS, UNIX, Solaris, or MVS, he cared how many copies of Oracle's DB he sold. So UNIX comes on the scene and strange thing happens. First AT&T is required by 1956 consent decree to make the IP available, they have processes and procedures to do so, so they do. So in the 70s certainly, when the HW delivery platform for UNIX is a DEC, the people that want it are the same type of people that it was originally written -- programmers. UNIX is a hit.... by the 80s and 90s, now we have two different group of peoples working with UNIX. As Steve and Larry point out, those same type of developers that originally had used UNIX in the first place [which was cool... I'm one of them too]. The problem was the economics started getting driven by a different group, the people that did not care - it was purely a means to get a job done (we the programmers lost control of the tiger in return for a lot of money to start to develop the systems). As Larry pointed, most of the care takers of the second class of UNIX customer, did not give a hoot about the programmers or many of the 'norms' from the previous world. Sun, Masscomp and eventually DEC did make SunOS, RTU, and Ultrix sources available to university customers (IBM may have also I'm not sure), but the hoops to get it could be painful; because they did not really understand that customer base as Steve pointed out (which turns out to have been an undoing). But that was the issue. Sun was able too see that trying to help the programmer was a good thing, but in the end, they could not sustain it either. In the end, they got sucked in the same economics of cutting at deal with AT&T to create Solaris SVR4 etc. Opposed Sun Forever, might have made it if they had actually make OSF 'Open Source' but they were too caught in fighting with each other. Imagine if the Mach based OSF1/386 has been released, which was running before Linux with a window manager and you had IBM, DEC, HP, et al working to make it 'FOSS' - how different the world might have been. But that would have gotten back to my point... they made their money selling an application delivery vehicle. They had liked to the control it, because it was easy to keep the customer if they did, but in the end, they really did not care. Now they have seeded the field to Linux and just left the OS to the SW developers and fallen back to what they really care about. A place to run applications. Clem

7 years, 8 months

Re: [TUHS] X and NeWS history (long)

by Richard Tobin

> I really kind of liked that toolkit, it was all key/value like so: > > panel = xv_create( > frame, PANEL, > XV_WIDTH, WIDTH, > XV_HEIGHT, 30, > PANEL_LAYOUT, PANEL_HORIZONTAL, > XV_SHOW, FALSE, > NULL); > > So the order of the args didn't really matter, I think the first one > maybe did because that was the parent but not sure, the rest could > be any order you wanted. Pretty simple. The first two were fixed; the prototype was Xv_object xv_create (Xv_opaque owner, Xv_pkg *pkg, ...); The keywords (XV_WIDTH etc) contained a bitfield encoding the type and cardinality of the value argument(s) so that the argument list could be traversed without knowing every package's keywords. Using NULL as the terminating argument looks unportable. -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

7 years, 8 months

Re: [TUHS] B Source Code

by Doug McIlroy

> Check out: ybc: a compiler for B <https://github.com/Leushenko/ybc> >From a historical standpoint, a plain B compiler lacks a very important attribute of B in Unix. Yes, B presaged some C syntax. But its shining property was that it produced threaded code, for which both compact and expanded runtime support was available. The latter had software paging. Thus B transcended the limited physical memory of the early PDP-11s. If you can't compile something, you can't run it. A prime example was B itself. Without software paging it would not have been able to recompile itself, and Unix would not have been self-supporting. Doug

7 years, 8 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS