106

This is covered largely in the history section of Wikipedia’s entry on newlines. Basically there are two primary lineages of operating systems leading to modern-day desktop usage: Windows on the one hand, and Unix-like systems on the other. Windows descends from MS-DOS (because initially it was implemented on top of DOS), which itself inherits much of its ...


80

Keyboards have an asterisk because typewriters did, long before computers existed. Typewriters, particularly mechanical ones, typically made a number of compromises to reduce the number of keys required. For example, many didn‘t have 0 or 1, and people used O and I or l instead. Likewise, × wasn’t needed since x could be used instead, or · (. half-up). The ...


72

Computer terminal keyboards needed to reproduce the symbols available on punched cards and paper tape. In the US, punched cards dominated the data-processing industry (communications uses tended to paper tape). IBM punched card codes in particular were significant in the industry. The IBM 026 keypunch (and its replacement the 029) had an asterisk. By the ...


44

I own a clone produced in Ukrainian Soviet Republic - "ОРЕЛЬ БК-08". It supports Cyrillic and Latin fonts. The main idea is similar to ANSI.SYS approach for DOS. There is a special control symbol that is not displayed, but which will switch the current font when being sent to print. The БК-08 had a РУС key on its keyboard that "switch" ...


22

The "PETSCII" encoding is based on keyboard positions of the original PET chicklet keyboard (*1): (Taken from Wikipedia) The keyboard is made similar to basic typewriter keyboards, but ordered in a square fashion, including a top row of symbols but not numbers and a separate numeric keyboard. By every key holding only a single ASCII equivalent ...


21

The first 32 characters in code page 437 were apparently mostly chosen in a single, four-hour “meeting” in a plane, with three people: David J. Bradley, who developed the PC ROM-BIOS, Andy Saenz, who was responsible for the PC’s video card, and Lew Eggebrecht, the IBM PC’s chief engineer. An email conversation with David J. Bradley mentions that If you look ...


18

The reason to use * instead of × is disambiguation. × looks very similar to x now, even more so in the early days of computing, before the laser printer became ubiquitous and you needed typesetting software and a printing press to produce an × that was distinguishable from an x. According to this post, we can blame Fortran: While it is now common practice ...


13

Really early computers like the Mark I and ENIAC didn't have enough memory to attempt to handle text; also the use-case was mostly calculations. A number of decimal IBM computers used characters (with 5 or 6 usable bits) as the basic unit, and decimal digits were just a special usage of those characters: The IBM 1401 computer, and its compatible successors ...


12

At the time the PC came out, there were at least five common approaches used by ASCII-based devices and systems: Devices receiving a CR would advance to the start of the next line, and lines were delineated with just a CR. An LF might behave identically, or might advance to the same spot on the next line, but it wouldn't usually matter because LF codes ...


11

Circa 1950 Royal typerwriter. Top row of keys, second from the right. What do you see?


10

If you want to read it as octal, having the low order 3 bits grouped together is handy. Many of the early ASCII tables showed the codes in octal. HEX makes more sense once your computers begin to work on 8 bit bytes, but earlier computers had units like 36 bit words that were divisible by 3, and this led people to use octal for a few years. Punched cards ...


10

If your parser library is not designed to run on Classic Mac OS, there's no reason whatsoever to support a bare CR as a line ending. Modern macOS has only ever supported them insofar as some of its files might have originated on Classic Mac OS. Nobody uses them anymore and people who have got such files know that most of the tools they use will barf on them. ...


9

The pbpaste command used to generate CR line endings up until Mac OS 10.6, at least. With Mojave and Big Sur, however, it's long gone. MS Office on Mac used to be a dreadful emitter of CRs. It's now moved to CRLFs on CSV exports and text copied from Office apps and pasted using pbpaste. I have been unable to emit CRs on other modern Mac apps, so it's ...


9

It's not. The price you pay is that it basically makes all parsing optimizations that rely on a fixed relationship of byte offset to character position unusable. Okay, but what parsing optimisations do? “Character” is a meaningless concept for almost every syntax you might want to parse. If you use bytes, so long as your special characters (e.g. ={}()[];) ...


9

I think the codes were laid out so that when laid out sensibly on the PET keyboard, the shifted and unshifted forms of each key would have a consistent relationship. When the VIC-20 reduced the number of keys but added the Commodore key, this made it necessary to rearrange the placement of graphics on the keys; since Commodore kept the same arrangement of ...


8

It's important to keep in mind, that there weren't that much symbols using overstrike in basic (IBM) APL. By using an 8 bit codeset they all could be integrated. The most common charset on the mainframe side was Page 293 which extends EBCDIC with all (at that time) legal APL codes. With APL2 code handling became more complicated and Page 293 was replaced by ...


8

No. As an American, which I'm guessing you are, you probably operated in an ASCII bubble. As a Western European, which you might be, you at least had some not-quite-ASCII variant of a 7-bit character code, or maybe some 8-bit ISO code, that preserved the character/byte equivalence at the cost of having to associate an encoding with the text and/or some ...


8

Except for the full set of upper- and lowercase letters, there was. The Soviet character encoding standard GOST 10859-64 included all of the ALGOL-60 special characters, and there were card punchers controlled by electric typewriters (Consul-260) with a standard-compliant character set. Note the lack of distinct Latin letters graphically equivalent to ...


7

Within DEC, "all the time". Why send two bytes down a wire at a lousy 300-to-1200 bps when one byte would do? DEC terminals from the VT200 series onwards supported an 8-bit character set known as "DEC standard 169", a close cousin to ISO 8859-1 (there were a couple of different character assignments). I'm pretty sure the C1 controls ...


6

However, C1 have hardly left any impression nowadays beyond 0x85 Next Line. Not restricted to C1. Not much of any control character has still an 'impression' nowadays. Unicode just ignores other C1 control codes. Sorry to disappoint you, but Unicode does define all of them as part of the C1 Controls and Latin-1 Supplement page. What to do with them ...


6

Is the CR line ending still prevelant on new applications or should it be considered legacy? As usual it all depends on the environment your software is used in. If you're sure that all input will be [CR]LF delimited, then narrowing it down might work fine. If it's guaranteed that all data will be produced by Mac Software less than ~5 years old, chances may ...


5

IBM had several different APL mainframe implementations, and they where updated and modified over many years to support different types of hardware and I/O equipment over their life time. The source for one of the earliest APL implementations for System/360 is available from the Computer History Museum. As far as I can remember they assign unique codes to ...


5

I'll express a somewhat dissenting opinion to the rest of the provided until now answers: yes, UTF-8 (or, rather, more generally Unicode at large) is partially and indirectly responsible for the bloat in the required CPU resources. But its contribution is just a drop in the ocean, small enough for most people to say "no, it isn't". Rather, it's the ...


4

Some say UTF-8 was the best solution. No. Not really (*1). Of course it may have influence on some low level operations, but they are marginally. In addition, they are the very same as with any other multi byte character encoding. Not to mention that there is an essential classic version of this: Escape Codes :)) The price you pay is that it basically ...


4

I was once writing an APL compiler (never finished, having figured I could single-handedly write a compiler in a 10 week undergraduate programming project), and the choice I made was to have an internal 8-bit character set where each composite symbol was a single character. This seemed an obvious choice to me, since that way you're separated from how that ...


4

For what it's worth, I did a quick photo of my C-64 and VIC-20 keyboards, so it's very easy to see the physical grouping of the various graphics/symbols. Commodore C-64 Keyboard: Commodore VIC-20 Keyboard:


3

[No time for a real answer (got to push my narrowboat from Wolverhampton to B'ham), but ...] This page (which is a marvellous collection of TTY manuals) does have at least two charts (7171WD, 7172WD) showing their encoding/population side by side (caution, strange PDF settings).


3

For clarity, I decided to move the KDF9 part of my question to an answer, since that is what it really is... I have no intention of accepting my own answer. My submission for "most nearly fulfilling the requirements" was Algol 60 on the English Electric KDF9 using paper tape prepared on a Friden Flexowriter. The Flexowriter had two cases of ...


2

I think your question must be put a bit differently for a first step towards an answer, like "was it common to use localized Unix applications from 70ies to nineties?" - In my opinion, the answer to that is already "no" (although improving towards the end of the period). The simple reason for that that most applications were specialized, ...


1

Is it historically correct to say that Unix programmers, liking to pretend that character strings and byte arrays were the same thing anyway, never really adopted wchar_t and in practice wide use was never made of wchar_t support? Yes and no. For one, Unicode did make quite an inroad for Unix in the 90s - and more often than not using a 16 bit type. But of ...


Only top voted, non community-wiki answers of a minimum length are eligible