TUHS

tuhs@tuhs.org

61 participants
6531 discussions

by jnc＠mercury.lcs.mit.edu

> when you're working below the reliable stream level, you can't just do a > blocking 'read' for a packet; it pretty much has to be asynchronous Oh, you should look at the early BBN TCP for V6 Unix - they would have faced the same issue, with their TCP process. They did have the capac() call (which kind of alleviates the need for non-blocking I/O), but that may have only been available for ports/pipes; I'm not sure if the ARPANET device supported it. (With the NCP as well, that did some amount of demultiplexing in the kernel, and probably had buffering there, so, if so, in theory capac() could have been done there. Of course, with the ARPANET link being only 100Kbit/sec maximum - although only to a host on the same IMP - the overhead of copying buffered data made kernel buffering more 'affordable'.) Noel

5 years

Re: [TUHS] non-blocking IO

by jnc＠mercury.lcs.mit.edu

> From: Paul Ruizendaal > This time looking into non-blocking file access. (... right now my > scope is 'communication files' (tty's, pipes, network connections). > ... > First appearance of non-blocking behaviour seems to have been with > Chesson's multiplexed files ... in 1979. At around that point in time (I don't have the very _earliest_ code, to get an exact date, but the oldest traces I see [in mapalloc(), below] are from September '78), the CSR group at MIT-LCS (which were the people in LCS doing networking) was doing a lot with asynchronous I/O (when you're working below the reliable stream level, you can't just do a blocking 'read' for a packet; it pretty much has to be asynchronous). I was working in Unix V6 - we were building an experimental 1Mbit/second ring - and there was work in Multics as well. I don't think the wider Unix community heard about the Unix work, but our group regularly filed updates on our work for the 'Internet Monthly Reports', which was distributed to the whole TCP/IP experimental community. If you can find an archive of early issues (I'm too lazy to go look for one), we should be in there (although our report will alsocover the Multics TCP/IP work, and maybe some other stuff too). There were two main generations of code; I don't recall the second one well, and I'm too lazy to go look, but I can tell you off the top of my head a bit about how the first one worked. Open/read/write all looked standard to the user in the process (the latter two were oriented to packets, a bit like raw disks being blocks); multiple operations could be queued in each direction. (There was only one user allowed at a time for the network device; no input demultiplexing.) Whenever an I/O operation completed, the process was sent a signal. Since the read/write call had long since returned, it had to do a getty() to get info about that operation - the size of the packet, error indications, etc. One complication was that for a variety of reasons (we wanted to avoid having to copy data, and the interface did not have packet buffers) we did DMA directly to/from the user's memory; this meant the process has to be locked in place while I/O was pending. (I didn't realize it at the time, but we dodged a bullet there; a comment in xalloc(), which I only absorbed recently, explains the problem. More here: https://gunkies.org/wiki/UNIX_V6_internals#exec()_and_pure-text_images if anyone wants the gory details.) That all (the queing, signals for I/O completion, locking the process to a fixed location in memory while it continued to run) etc all worked well, as I recall (although I guess it couldn't do an sbrk() while locked), but one complication was the UNIBUS map on the -11/70. The DSSR/RTS group at LCS wanted to have a ring interface, but their machine was a /70 (ours, the one the driver was initially done on/for, was a /40), so with DMA we had to use the UNIBUS map. The stock V6 code had mapalloc(), (and mapfree(), both called on all DMA operations), but... it allocated the whole map to whatever I/O operation asked for the map. Clearly, if you're about to start a network input operation, and wait a packet to show up, you don't want the disk controller to have to sit and wait for for a packet to show up so _it_ can have the map. Luckily, mapalloc() was called with a pointer to the buffer header (which had all the info about the xfer), so I added a 'ubmap' array, and called the existing malloc() on it, to allocate only a big enough chunk of the UNIBUS map for the I/O operation defined by the header. Since there was 248KB of map space, and the largest single DMA transfer possible in V6 was about 64KB (maybe a little more, for a max-sized process with its 'user' block), there was never a problem with contention for the map, and we didn't have to touch any of the other drivers at all. That was dandy, and only a couple of lines of extra code, but I somehow made a math error in my changes, and as I recall I had to debug it with a printf() in mapalloc(). I was not popular that day! Luckily, the error was quickly obvious, a fix was applied, and we were on our way. Noel

5 years

DEC RL01/RL02 RX01/RX02 Disk Image Creator

by Paul Ruizendaal

> Team Unix, Is there a Windows or Linux utility to create a disk image in any of the above formats, from a local folder tree? Paul *Paul Riley* It seems you are asking for two tools in the BK-UNIX toolbox, fsutil and dskutil https://github.com/sergev/bkunix/tree/master/fsutil https://github.com/sergev/bkunix/tree/master/diskutil The first generates a Unix 6th edition file system from a local directory tree. The result is a binary file with the 512 byte disk blocks stored in sequence. Maybe this is what SIMH needs, I’m not into the details of SIMH. The second appears to be a tool to take the a file generated by the fsutil tool and split that into sectors and tracks. I’m not familiar with this tool, but it looks like you might need something similar (I assume that you have some way to hook up a 8” drive to your PC?). Sector interleaving may be an issue to look out for. When preparing a LSX system disk, you will need to think carefully about the layout: Presumably the disk works with 128 byte sectors and 4 sectors are grouped together to create a 512 byte unix block. Check out the disk driver code for details: https://www.tuhs.org/cgi-bin/utree.pl?file=LSX/sys/decfd.c Block 0 contains bootstrap code which is loaded/called from the monitor rom (or from a short code sequence keyed in on a “blinkenpanel” console). The filesystem itself starts at block 1 and runs up to a block N (you need to tell fsutil how big the filesystem needs to be). After block N up to the end of the disk is space to contain 2 swapped out programs plus 1 block for the return code of the third (default LSX has a maximum of 3 processes). You have to figure out how many 512 blocks are on your floppy and subtract out the swap space to arrive at a figure for N. In the LSX source code ’N’ is known as the define SWPLO, see param.h for details: https://www.tuhs.org/cgi-bin/utree.pl?file=LSX/sys/param.h In this file, 99 blocks are reserved for swap, corresponding to processes with 24KB memory; total disk size is defined as 500 blocks, 250KB - note that this slightly exceeds the 241KB offered by the standard IBM 77 track 26 sector formatting for 8” disks. Probably you will need to tweak the values in param.h Be careful with size units in the source code. Often sizes are expressed in words (2 bytes). Where memory is concerned it is often expressed in ‘clicks’, 64 bytes.

5 years

LSX on the PDP-11/03 (LSI-11)

by Paul Riley

I've managed to acquire a PDP-11/03 with twin floppy drives (Sykes Datatronics RX01 or RX02 equivalents, not sure yet which). I've stumbled across LSX, and I have it running on SimH. I'm quite inexperienced with Unix, but it's something I want to learn well, having brushed against it at university in the '80s, and having played with Linux somewhat. I have some interest in Forth, but I don't like the block system of early forths such as FigForth, and I plan to create a new Forth based on FigForth, but supporting external source files. Anyway, I've tried compiling Hello World on LSX, and I get "1: External definition syntax" error. Some help would be nice, but more generally, is anyone on this list more than vaguely familiar with LSX, or 6th Edition itself? void main () { printf("Hello World!"); } It seems that the 7th Edition was the beginning of the standard library in C, and that this is missing in LSX. I'm not sure if printf is an intrinsic function in (6th Edition) C, or if it's from a library. My questions are a bit random, but looking to converse with others with LSX experience. Paul *Paul Riley* Email: paul(a)rileyriot.com

5 years

DEC RL01/RL02 RX01/RX02 Disk Image Creator

by Paul Ruizendaal

> > In this file, 99 blocks are reserved for swap, corresponding to processes with 24KB memory; total disk size is defined as 500 blocks, 250KB - note that this slightly exceeds the 241KB offered by the standard IBM 77 track 26 sector formatting for 8” disks. Probably you will need to tweak the values in param.h Oops: 77 tracks by 26 sectors of 128 bytes, makes 250.25KB, so it should work as configured.

5 years

fmt(1): history, POSIX, -t, -c

by markus schnalke

Hoi, personally I use fmt(1) a lot for email formatting and such. Typically I only use the `-w' parameter. Now someone asked me about `-t' and `-c' of *GNU* fmt(1). I wasn't able to find good documentation on them. The manpage only tells that they have to do with different indentation for the first or first two lines. But what are the use cases? How would source text for these parameters look like? A look into the description and rationale sections of POSIX, which often provides helpful information, was not possible because fmt(1) is not part of POSIX (only fold(1) is). Why's that? Is it because fmt(1) differs so much between Unix implementations? On BSD `-c' centers text and `-t' sets tab widths. Plan 9 has none of these options. But still, `-w' could have been standardized. Or was the line filling algorithm different as well? How does fold(1) fit into the picture? Maybe you can answer some of these questions or give hints on where I could find answers myself. meillo

5 years

LSX on the PDP-11/03 (LSI-11)

by Paul Ruizendaal

> I've stumbled across LSX, and I have it running on SimH. I'm quite inexperienced with Unix, but it's something I want to learn well, having brushed against it at university in the '80s, and having played with Linux somewhat. I think you will experience a sizeable learning curve. You will be working with Unix and C as it stood around 1975 and that is substantially different from what it was in the 80’s. That said, I know from personal experience that it is an intriguing journey and certainly not impossible to do. > Some help would be nice, but more generally, is anyone on this list more than vaguely familiar with LSX, or 6th Edition itself? Many on this list are familiar with 6th edition. The best way to learn the internals of 6th edition is the “Lions’ book”: https://www.amazon.com/Lions-Commentary-Unix-John/dp/1573980137 Coming from today’s perspective (or a 1980’s one), you will find the following key challenges: - The version of C used for 6th edition is different from the 1980’s. Amongst other things the syntax of the assignment operators changed (not += but =+), the syntax for initialisation changed (not 'int a = 3', but 'int a 3’), the ‘long’ datatype (32 bit on a PDP-11) did not exist, the ‘void’ keyword did not exist, structs could not be assigned, passed or returned (only pointers to structs), etc. - The stdio library did not exist yet, in its place there was the ‘portable i/o library’. This may be the hardest part to get used to. - The file system was 16-bit based throughout. This has implications for stat(), lseek() did not exist (its precursor seek() used additional whence values to move the file pointer in 512 byte increments), etc. When it comes to LSX, there are a few people who have experience with it on the this list (that I know of - there may be many more). First of all, Heinz Lycklama, the original creator of LSX, appears to read this list from time to time. Second, Leonid Broukhis and Serge Vakulenko (who managed to recover the LSX sources 20 years ago) might be reading the list. They took the trouble to port LSX to the Soviet BK-0010 computer, an LSI-11 type system some 15 years ago: https://github.com/sergev/bkunix You can stand on their shoulders, as they already took the trouble to convert the kernel source from 1975 C to 1980’s C and to create a stdio compatible library for it; they are using the 2.11BSD C compiler, which generates tighter code than the 1975 compiler — hence they could squeeze a bit more functionality in. Third, I found the BK-0010 port some 5 years ago and used that as base to create a version that would run on a small TI990 clone: http://www.stuartconner.me.uk/mini_cortex/mini_cortex.htm This work later evolved into a stock 6th edition kernel and is now a curious mix of stuff dating from 1975 to 1985. Your main challenge will be that neither the BK-0010 work nor my work will run on your hardware as-is. I think you have two possible paths forward. The first is to learn C and the library as it stood in 1975, the second is to take the BK-0010 code and to make it run on a stock LSI-11 again.

5 years, 1 month

Re: [TUHS] fmt(1): history, POSIX, -t, -c

by Doug McIlroy

The title of the fmt man page in v9 was "ultra-simple text formatter". Gnu dropped the "ultra" in favor of AI. Sometimes it does a pretty job. Sometimes it messes up my typing style. Always it produces a an apparently wavering right margin, as it assigns a separate "optimal" line length to each paragraph. It's hard to imagine how this command could stray from classic Unix simplicity and intelligibility, but Gnu pulled it off. Doug

5 years, 1 month

Sad Times - hopefully this is just temporary

by Clem Cole

https://www.livingcomputers.org/Closure.aspx

5 years, 1 month

main

by Steve Simon

re: main. i was surprised not to see any mention of the entry keyword reserved but, i believe, never used in early c. it is listed in k&r ed1. i always assumed this was to allow the author to choose an alternative to main() for the program’s entry point, but we all know what assumption is... -Steve

5 years, 1 month

Re: [TUHS] History of popularity of C

by jnc＠mercury.lcs.mit.edu

> From: Tyler Adams > C is so prolific and influential because it's so easy to write a C > compiler. I'm not sure the implied corollary ('it's _not_ easy to write compilers for other languages') is correct. As a datapoint, I pulled "Algol 60 Implementation" (Randell and Russell) off the shelf, and it reveals that the Algol 60 compiler discussed there (for the KDF9), using lessons from the Algol compiler for the Electrologica X1, was 3600 words (roughly 3 instructions/word). So it was small. Now, small is not necessarily equivalent to easy, but it was clearly not a mountainous job. I imagine early BCPL, etc compilers were roughly similar. The only language from that era which I can think of which was a slog, compiler-wise, was PL/I. I suspect the real reason for C's sucess was the nature of the language. When I first saw it (ca. 1976), it struck me as a quantum improvement over its contemporaries. Noel

5 years, 1 month

where did "main" come from?

by Lawrence Stewart

C main programs define “main”. This also seems to be true of B main programs, according to the Johnson/Kernighan manual The 1967 Martin Richards BCPL manual doesn’t explain how programs get started The 1974 update from Martin Richards says there should be an OS addendum that explains this. The 1974 University of Essex BCPL manual says to use START The 1979 Parc Alto BCPL manual uses Main and I think that must be unchanged from 1972. The AMSTRAD BCPL guide from 1986 uses start() So who started “main” and when? I can’t find an online copy of the Bell Laboratories BCPL manual (Canaday/Thompson) from 1969 or anything about how to use BCPL on Multics or CTSS. -L

5 years, 1 month

Re: [TUHS] TUHS] where did "main" come from?

by Nelson H. F. Beebe

Lawrence Stewart <stewart(a)serissa.com> asks on Fri, 22 May 2020 14:43:40 -0400: >> So who started "main" and when? I have just checked several PDFs of IBM mainframe and Fortran manuals going back to 1954. The early manuals did not appear to use the name "main", but in ibm-7030/C22-6578_7030_Programming_Examples_Apr61.pdf, the phrase "the main program" occurs in the context of assembly language coding. In ibm-7030/C22-6751_7030_FORTRAN_IV_May63.pdf, on page 22, which begins with Part II. FORTRAN Programming for the IBM 7030 the first paragraph ends with "the main program". In silliac/SPMpart1-ocr.pdf, titled Silliac Programming Manual The Adolph Basser Computing Laboratory School of Physics The University of Sydney and dated January 1959, on page 99, I find >> ... >> In this way a program is seen to consist of several distinct, >> self-contained blocks, namely the various subroutines and the part of >> the program (usually called the main program or master routine) which >> ^^^^^^^^^^^^^^^^ >> makes use of its subroutines by sending control to them. >> ... I have many manuals for older systems, but most have not been subjected to optical-character recognition, so it is difficult to find specific text in them. Nevertheless, I have demonstrated that by at least January 1959, the phrase "main program" was common enough to appear in computer documentation, qualified by "usually". Some day, perhaps I'll find time to do OCR conversion on my extensive PDF file archives. I'll be pleased to hear of earlier uses of "main program" from TUHS list members. ------------------------------------------------------------------------------- - 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/ - -------------------------------------------------------------------------------

5 years, 1 month

Re: [TUHS] BBN technical reports?

by Paul Ruizendaal

> I went looking for the three IPC reports: > > For more information about this system, see: > - "Interprocess Communication Extensions for the UNIX Operating System: I - > Design Considerations", Rand Corporation, Report R-2064/1-AF, June 1977. > - "Interprocess Communication Extensions for the UNIX Operating System: II > - Implementation", Rand Corporation, Report R-2064/2-PR, April 1977. > - "UNIX TCP User's Guide", Bolt Beranek and Newman Inc., Report No. 3724 > > > And could only find the first one online at > > https://apps.dtic.mil/dtic/tr/fulltext/u2/a044200.pdf > > Do we have the other two anywhere? Yes we do. The first two are about Rand ports. You’ve found the overview by Carl Sunshine, the implementation by Steve Zucker is the next report up on DTIC: https://apps.dtic.mil/sti/pdfs/ADA044201.pdf The TCP User guide report you refer to is about a TCP implementation done by Jack Haverty, which took an implementation in PDP-11 assembler and wrapped it in a NCP Unix shell. Jack has a listing in his attic, but it is not scanned. The problem with this implementation was that it is was all very cramped in the kernel, so he had to reduce disk buffers substantially. As pipes (and Rand ports) use disk buffers to hold pipe data, which get swapped out to disk as needed, he found that his system trashed a lot and effective TCP speeds in his first trials were barely above few dozen byte per second. The report is actually on the TUHS tree: https://www.tuhs.org/cgi-bin/utree.pl?file=BBN-V6/doc (there is also nroff source for Steven Zucker’s report, and other interesting material in that directory - such as a report on pipe performance). The actual V6 implementation that is on that THUS page is not Jack Haverty’s version, but a version done from scratch by Mike Wingfield, using the learning’s of Jack’s work. Mike’s implementation worked quite well and won first prize in a March 1979 tongue-in-cheek TCP4 conformance & interop competition. The BBN report for that version is 4295. Craig Partridge was kind enough to dig it up from the BBN library - I can send you a copy if you like (it was cleared for public release). Although the implementation was done for research purposes (mainly Autodin II security features and simulation), it seems to have had a long life as a stop-gap to keep aging PDP-11’s connected after the switch from NCP to TCP in 1983. Paul

5 years, 1 month

BBN technical reports?

by Warner Losh

I went looking for the three IPC reports: For more information about this system, see: - "Interprocess Communication Extensions for the UNIX Operating System: I - Design Considerations", Rand Corporation, Report R-2064/1-AF, June 1977. - "Interprocess Communication Extensions for the UNIX Operating System: II - Implementation", Rand Corporation, Report R-2064/2-PR, April 1977. - "UNIX TCP User's Guide", Bolt Beranek and Newman Inc., Report No. 3724 And could only find the first one online at https://apps.dtic.mil/dtic/tr/fulltext/u2/a044200.pdf Do we have the other two anywhere? Warner

5 years, 1 month

Re: [TUHS] Chaos networking in 8th edition (and in 7th)

by Doug McIlroy

>> I don't recall any use of Chaos in 1127. Possibly one of >> the nearby groups who also used the Research system needed >> it at some point > Speculating wildly, maybe there was a Lisp machine somewhere? None that I can remember. Doug

5 years, 1 month

Re: [TUHS] algebraic syntax (was v7 K&R C)

by Doug McIlroy

> for some years I've been using the phrase "algebraic syntax" to > characterize languages such as Algol, C/C++, Fortran, Java(Script), Ruby, etc. ... > However, I can't find this usage in Wikipedia or elsewhere I think "Algol-like" is the closest term in common use, though it doesn't have the exact connotation that I think you intend. Nowadays, I think of languages like Haskell as being "algebraic" in the deeper sense of having taken much inspiration from modern algebra, and being preeminently suitable for application to algebraic domains. Vic Vyssotsky used the term "narrative language" as quite a close synonym of your "algebraic syntax", but I think his usage was equally idiosyncratic. Doug

5 years, 1 month

Re: [TUHS] v7 K&R C

by Doug McIlroy

> o operator overloading > > I never could figure out why Stroustrup implemented that "feature"; let's > see, this operator usually means this, except when you use it in that > situation in which case it means something else. Now, try debugging that. Does your antipathy extend to C++ IO and its heavily overloaded << and >>? The essence of object-oriented programming is operator overloading. If you think integer.add(integer) and matrix.add(matrix) are good, perspicuous, consistent style, then you have to think that integer+integer and matrix+matrix are even better. To put it more forcefully: the OO style is revoltingly asymmetric. If you like it why don't you do everyday arithmetic that way? I strongly encouraged Bjarne to support operator overloading, used it to write beautiful code, and do not regret a bit of it. I will agree, though, that the coercion rules that come along with operator (and method) overloading are dauntingly complicated. However, for natural uses (e.g. mixed-mode arithmetic) the rules work intuitively and well. Mathematics has prospered on operator overloading, and that's why I wanted it. My only regret is that Bjarne chose to set the vocabulary of infix operators in stone. Because there's no way to inroduce new ones, users with poor taste are tempted to recycle the old ones for incongruous purposes. C++ offers more features than C and thus more ways to write obscure code. But when it happens, blame the writer, not the tool. Doug

5 years, 1 month

Re: [TUHS] 2.11bsd boot countdown stuck at <5> on 11/73

by jnc＠mercury.lcs.mit.edu

> From: Jacob Ritorto > I had a suspicion that maybe the clock isn't working on the 11/73. > Would that make sense? Would definitely explain the symptoms. > Maybe I have to check jumpers on the 11/73 to be sure its clock is > enabled? There is a jumper on the KFJ11-A that enables/disables the clock&register; W9 (closest to the handles) should be removed to enable the clock. (I really need to add the jumpers to the KDJ11-A page on the Computer History Wiki, mumble....) Noel

5 years, 1 month

PiDP

by ron＠ronnatalie.com

I bought one of Oscar's kits a while back and I just got around to putting it together. It was kind of neat booting up a straight V6 (it's been a long time) and playing with those DEC operating systems that I had learned to hate (Really Sh-ty Timesharing System). I had hoped that someone, somewhere had a JHU/BRL dist around (well if you do, I'd love to get it). But since the thing is mostly just a decoration in my office, I just hacked the idle function in 2.11 BSD to mimic the one that JHU Unix had.

5 years, 1 month

2.11bsd boot countdown stuck at <5> on 11/73

by Jacob Ritorto

Hi, I had a disk in my 11/83 that I'd set up for autoboot. The pdp11 would load block 0, load /boot and happily count down 5 seconds, then continue on with kernel loading & regular bringing up of the system to multiuser. That was cool! So I pulled that disk out and plugged it into my other system with a dual height 11/73 (this system has same CMD CQD-200 scsi controller) and it gets to the countdown part and stops! I'm wondering why. The initial bootblock load is apparently fine and loading and running of boot is happening.. its just that the countdown stays stuck at five and I have to hit <cr> to get it to boot (and the rest of the boot sequence is totally normal). I had a suspicion that maybe the clock isn't working on the 11/73. Would that make sense? Maybe boot is actually using a clock somehow? Maybe I have to check jumpers on the 11/73 to be sure its clock is enabled? Just thought I'd float the question here in case someone remembers this oddity before I start digging / "use the source." thx jake

5 years, 1 month

Re: [TUHS] v7 K&R C

by jnc＠mercury.lcs.mit.edu

There was a recent message I now can't find that I wanted to reply to, something about which type to use to get a certain effect. I wanted to reply to say that I felt that it was not really the best way to go, to have one set of type names that tried to denote both i) the semantics of the data, and ii) the size of the item, using arbitrary names. This came up for me when we started to try and write portable networking code. There, you need to be able to specify very precisely how long fields are (well, in lower-level protocols, which use non-printable formats). How to do that in a way that was portable, in the compilers of the day, was a real struggle. (It might be doable now, but I think the fixes that allowed it were still just patches to something that had gone in the wrong direction, above.) I created a series of macros for type definitions, ones that separately and explicitly specified the semantics and size. They looked like 'xxxy', where 'xxx' was the semantics (signed and unsigned integers, bit field, etc), and 'y' was a length indication (byte, short, long, and others). So you'd see things like 'unsb' and 'intl'. The interesting twist was a couple of unusual length specifiers; among them, 'w' stood for 'the machine's natural word length', and 'f' meant 'no particular length, just whatever's fastest on this architecture/compiler, and at least 16 bits'. The former was useful in OSy type code; the latter for locals and things where nobody outside the machine would see them. Then you'd have to have a file of macro definitions (only one per machine) which translated them all into the local architecture/compiler - some didn't go, of course (no 'unsb' on a PDP-11), but it all worked really, really well, for many years. E.g. at one point, as a dare/hack, I said I'd move the MOS operating system, a version written in portable C (with that type name system) to the AMD 29000 over one night. This wasn't totaly crazy; I'd already gotten the debugger (a DDT written in similar portable C) to run on the machine, so I knew where the potholes were. I'd have to write a small amount of machine language (which I could traslate from the M68K version), but most of it should just compile and go. I didn't quite make it, it wasn't quite running when people started coming in the next morning; but IIRC it started to work later that day. Noel

5 years, 1 month

Re: [TUHS] v7 K&R C

by Richard Tobin

> Isn't it nonstandard (although I am aware of some compilers that do it) to > default the type of char to unsigned? No. "The implementation shall define char to have the same range, representation, and behavior as either signed char or unsigned char." - C99 (Technically it's a separate type from both of them.) -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

5 years, 1 month

Chaos networking in 8th edition (and in 7th)

by Norman Wilson

Paul Ruizendaal: Was Chaos networking in use at the labs, or is it just an artifact present on the surviving tape? === I don't recall any use of Chaos in 1127. Possibly one of the nearby groups who also used the Research system needed it at some point, perhaps before my time (I arrived in August 1984). I certainly don't remember anyone raising objections to discarding it. Norman Wilson Toronto ON

5 years, 1 month

Re: [TUHS] v7 K&R C

by Doug McIlroy

> [A]lthough these days "byte" is synonymous with "8 bits", historically it > meant "the number of bits needed to store a single character". It depends upon what you mean by "historically". Originally "byte" was coined to refer to 8 bit addressable units on the IBM 7030 "Stretch" computer. The term was perpetuated for the 360 family of computers. Only later did people begin to attribute the meaning to non-addressable 6- or 9-bit units on 36- and 18-bit machines. Viewed over history, the latter usage was transient and colloquial. Doug

5 years, 1 month

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