48

I’m not sure about specific events, but I think the main reason Base64 “won” is that it’s one of the binary encodings supported by MIME, and MIME took over. So perhaps the question then becomes two-fold: Why did MIME pick Base64 over UUencode? Possibly because Base64 is actually more resistant than UUencode: it only uses alphanumeric characters plus two ...


44

Do the holes in Jacquard loom punched cards represent input data or program code? yes. Let me tell you a story. Somebody I used to work with many years ago was flying into the USA (or it might have been Britain from the USA) with some half inch tapes containing the source code for a Cobol program. Because he was carrying the tapes separately to his luggage,...


41

Plain DOS executables, in either COM or MZ format, don’t provide this information in their headers (when there is one — COM format doesn’t have a header). The only reliable way to determine whether a program requires a given CPU is to try running it on some less capable system (or emulation, e.g. with PCem which has accurate emulations of different x86 ...


39

A formatted disk contains markers which identify the start of each track and the start of each sector within the track. These markers are fixed magnetic sequences that are picked up by the drive electronics so that it knows where the sectors are. On a full format, a completely blank disk has these markers written. This takes time as the drive must apply ...


30

The Amiga disk format stores 512 bytes per sector, 11 sectors per track (a track is one side of a cylinder), double sided (i. e. 2 tracks per cylinder) with 80 cylinders per disk, which makes 80 * 2 * 11 * 512 = 901120 bytes = 901.12 kB = 880 KiB raw block data. The IBM-PC format also stores 512 bytes per sector, but only 9 sectors per track (on a Double ...


30

The main thing is that there is no such thing as a "quick format" - That term is entirely misleading terminology invented by Microsoft. Quick Format doesn't "format" anything. What MS calls a "Quick format" is rather a "wipe directory" - It marks all sectors as unused and rewrites only the FAT and root directory. That process visits only a very limited ...


30

Most large files (over 64KiB) with a .COM extension are really MZ executables; the DOS loader doesn’t care whether the extension is .EXE or .COM, it uses the MZ signature to identify the format. This is the only documented way for a .COM file larger than 64KiB to work, so it’s the only approach which can be relied upon. However it is possible to build a ....


28

According to Google Scholar, Huffman’s 1952 paper had 326 citations by 1979, which given the volume of publication at the time means it was well-known, as far as can be determined now. Most compression-related papers published around that time refer to Huffman’s paper, either because they use Huffman coding in some way, or to explain why they don’t! Given ...


26

The problem with uuencode is that the format was not robust in the face of some of the really crufty mail software and gateways into and out of proprietary non-SMTP and non-ASCII mail systems of the day. Just to liven things up further, there were multiple EBCDIC variants which had different code points for some ASCII characters used by uuencode, opening up ...


25

Well, in fact, a closely related question has been asked (and answered) few years ago: What is the history of data compression tools on personal computers? From that question, and its answer, it transpires that several implementations of Huffman algorithms were in use by the early 1980s. Specifically, Unix "pack" command implements a standard Huffman ...


23

For a standard screen, compatible with ZX Spectrum, a SCREEN$ file is 6912 bytes. It's just a dump of the screen memory. The first 6144 bytes store the screen bitmap: 256x192 pixels, 1 bit per pixel (on or off). The layout is not linear. The screen bitmap is divided horizontally into three thirds: each one is 2048 bytes and store 8 text rows of 32 column ...


20

The a_midmag field contains a machine identifier, which can be used on platforms which support that field. a_midmag is a 32-bit value stored in host byte-order (fun already), and bits 16 to 23 give the machine type. The most comprehensive list of machine identifiers I’ve found so far is the list used by libbfd, which shows that the field has been used for ...


20

C64 Basic used a CR as EOL for disk files. (source: Commodore SX-64 User's Guide, page 22: “CR stands for the CHR$ code 13, the carriage return, which is automatically PRINTed at the end of ever PRINT or PRINT# statement … ”, and verified by hex dump of disk image showing 0x0d at line end.)


18

I discovered the answer on my own. Turns out PSVIEW requires GhostScript, PDFTOPS, and LXPIC to be installed on the hard drive in order to run. GhostScript must be placed in 'C:\gs'. PDFTOPS and LXPIC must be in a directory mentioned in the path environment variable set in 'AUTOEXEC.BAT'.


17

From some quick research, WinUAE (a popular Amiga emulator) supports reading a DMS file just like an ADF. So you could probably mount it and then save it back as ADF. Also, according to the ADF Opus tool site, they can read DMS also.


17

Program code for modern CPUs, in practice, consists of opcodes which tell the CPU what operation to perform, and operands which provide data to operate on. In RISC CPUs these are necessarily both encoded into the same instruction word, while in CISC CPUs the two usually live in separate bytes, with the operands following each opcode. However there are ...


17

There is no easy way. The original DOS "MZ" type executable header do not contain such information about what kind of code it contains or what CPU type it needs. It just contains a binary image that is loaded to memory and information about how to start it in real mode, so there are no separate 16-bit or 32-bit binaries. The binary image may ...


16

The HFS filesystem stores file metadata in a single large file called the "catalog file", with one record for each file or directory. Creation and modification times are stored as 32-bit unsigned integers representing a count of seconds since midnight, January 1, 1904. (Source: Inside Macintosh: Files)


16

The short answer is: early Unix systems did not bother to track which architecture an executable was for. In general, the architecture an executable was for, was the one the executable was found on. If you're on a PDP-11, /bin will contain PDP-11 executables. If you're on a VAX, /bin will contain VAX executables. Multiple architectures all trying to ...


15

All code is data. But not all data is code. For example, you can take a digital photo and the numbers represent light intensity across a 2D rectangle. Nobody would dispute that this is data but not code. Code is a special kind of data which controls behaviour. ... but it's not that simple. Arguably the digital photo controls the behaviour of whatever ...


13

Base64 is slightly more compact as it does not use a character indicating line length at the beginning of each line: % dd bs=1k count=1024 < /dev/urandom | uuencode /dev/stdout | wc -с 1444736 % dd bs=1k count=1024 < /dev/urandom | uuencode -m /dev/stdout | wc -c 1421440 Overall, Base64 is about 1.5% better.


13

A little more background on the formats... When IBM is involved, it's all about history. IBM's first PC floppy disk format was single sided, 5-1/4", 160K on a single-sided drive. (40 tracks, 8 sectors per track, 512 byte sectors). This started as "double density" but was otherwise a conservative design, typical for IBM. Double-sided floppies were 320K, ...


13

If you actually look at how the Z-Machine compresses texts, it does the following (from memory, it's been a while): There's a list of frequently appearing words (like "the", "and") which are directly encoded by an index. It uses "shift" codes like in the teletypes to switch between different modes. This makes it simple to write a fast decoding routine that ...


13

@raffzahn describes object files, which are not executable. They need to be read into the linkage editor, which produces a load module. That is what CSV (the newer name of the component that loads modules and relocates addresses) loads, and then the operating system eventually branches to the entry point (not always the first byte). What you are looking for ...


12

Grace Hopper invented a kind of linking loader in 1951 for the Univac, as part of the A-0 "compiler" (not a compiler like we understand it today). One must keep in mind that memory was extremely limited on those very early computers, so what today would be an object module with many routines was equivalent to handling a single subroutine at that time. Also, ...


12

The .z80 format comes from the Z80 emulator by Gerton Lunter. He released some documentation about the file formats used in it, and regarding offsets 11 and 12, this is what the manual says: .Z80 FILES: ----------- The old .Z80 snapshot format (for version 1.45 and below) looks like this: Offset Length Description 0 1 A register ...


12

These are OMF libraries; you can analyse them with Agner Fog’s object file converter. It probably only makes sense to work with those libraries if you intend to build software with Microsoft C 5.1, in which case you’d use the tools provided with the compiler (LIB.EXE in particular). The OMF format is described in detail in OMF: Relocatable Object Module ...


12

The V1 Unix B manpage uses .s as the extension for intermediate assembly files used during the build. This is the earliest use of .s that I can find, and would correspond to November 1971 at the latest. There were assemblers on systems with file systems before Unix, but none that I’m aware of used .s. Some like DECsys don’t appear to have extensions; other ...


11

Tar stood for 'tape archiver' so there is no real doubt where the 'tar' name itself came from. The V7 papers and manual pages are fairly explicit on it's origin replacing v6 tp. The other problem with the idea is that 'tarball' appears to be relatively modern as a term. I can't find a book reference before 1997 that uses the word 'tarball' - possibly not ...


11

For most parts it's code. Well, code is a quite sloppy term, it covers a huge list of uses, from card scratching to encryption. So more correctly, it's a program (*1), as it defines a sequence of action to be taken by the machine - interpreted when the loom runs the cards. If at all, then thread is data. It is input from spools, processed by the loom ...


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