FILE_ID.DIZ Description (1994) | Hacker News Reader

FILE_ID.DIZ Description (1994)

pcmicro.com

251 pointsLammy86 comments

Open articleView on HN

> (The extension of "DIZ" actually stands for "Description In Zip")

Ah, finally, another puzzlement from my childhood explained.

As a kid, I always assumed that it was "description" but in some other language which I was unfamiliar with.

Leetspeak. As a kid, you should have known leetspeak.

Um, I think you mean 1337

not to be mistaken with 31337 ;-)

Oh, hi there! ;^)

Yes, but which color book was this term first used? Then we'll establish how l337 you are or are not

https://www.youtube.com/watch?v=4U9MI0u2VIE

https://retrocomputing.stackexchange.com/questions/10997/wer...

great scene.

I’m the biggest fan of Hackers but that scene has always irked me.

They’re all so impressed with Dade’s knowledge yet he simply appears to be reading the cover title of each book as it gets passed.

Someone please give me a meta explanation that justifies this so that my inner fanboy can sleep better at night. I’ve probably watched Hackers 100s of times. Best love story ever.

The nicknames given to each book is what he's being tested on.

"The dragoon book", "That ugly red book that wont sit on the shelf" and so on.

physical books weren't just given away to anyone who asked back then, so getting a copy of one is an achievement in the first place so the assumption is if you got it, you read it and by reading the title out loud he's saying I know what's in those books, like the anarchist cookbook

I think .diz preceeded leetspeak by a couple of years.

FWIW, leetspeak is just a calligraphic flourish away from feetspeak.

I assumed it was short for "distribution", stylised.

I thought it was leetspeak for "this", so FILE_ID.DIZ was "file to identify this"

Same here. This is the first thing I looked up when I saw the article.

Indeed!

I was under the impression the DIZ was because it first appeared on a BBS called DiZZYboard iirc

I assumed it was because "diz" was "zip" rotated 180°.

"Description In Zip" seems like it could be a backronym.

I remember those as far back as filesystems were 8.3 all caps, so D would not rotate to P though.

I think the way it was conceived is orthogonal to the way it is encoded or displayed.

I have seen thousands and thousands of those files and until now it never clicked that you could kinda rotate 180° that. Thank you!

i just thought it was "this" shortened to DOS standards.

Same, and still makes the most sense to me.

"Description In Zip" has the typical clunkiness of a backronym and the 180° theory suffers from the fact that filenames (as lloeki rightfully pointed out) were usually presented in all uppercase (even when lowercase was available) in that era.

Phonetically shortening stuff on the other hand was almost a requirement in the scene, even if you had the space.

EDIT: Thinking about it "identify this" is well in line with "read me".

Singular of "deez"

Lol, when I was seeing them around as a teenager I was thinking to DIZ as "dizionario" in Italian (dictionary)... of course, had I thought a bit more, I could have figured out that it was probably not Italian.

The whole history of shareware was badly neglected along my path into the industry, as if all those people set sail sometime in the 1990s and were never heard from again. In fact they continued in parallel, and still show very obvious influence in many niches of software. I think that was just hard to see while I was at uni.

I can strongly recommend Richard Moss' Shareware Heroes book for those interested in remedial reading, and not just for those devoted to games.

If there are any computer history grad students lurking, an integrative history of early software distribution models and industry orgs is still a big, gaping hole in the lit, as far as I know.

Essentially it was a parallel track in the BBS world. And it ended up dying/morphing into the sort of trial-ware etc. that the "true" shareware movement was largely against. The whole thing just sort of fizzled out as open source was becoming more prominent but, even as someone who was a part of it, it's not totally clear to me how that transition came about.

With a few exceptions like Jason Scott's BBS documentary, the non-Unix/Internet history of early personal computing is not very well-covered at all.

This made me chuckle:

> Please don't be tempted to use fancy graphic or ANSI sequences in the FILE_ID.DIZ file, as most BBS software will not allow this, and will render your FILE_ID.DIZ file useless.

Everyone was doing exactly that and even I did something like +hundred artsy file_id.diz headers for the scene groups or my own groups. When "releases" started to be from 5 to 15 disks (packages), many sysops started to clearing the art away from the file lists and just leaving an oneliner of the title visible, like:

   The Name of The Release       Disk: [03/12]

Interesting too that as niche as they are today, they are still being made. The last ones I did was in 2015.

When "releases" started to be from 5 to 15 disks

I can remember this, scrolling through page after page of the same release since only 3 or 4 big "PWA" or "FLT" logos could fit on a page. I remember more or less the same visual style as graffiti from the era. I had no idea this stuff was still happening in 2015.

This stuff is still happening even today :-)

http://janeway.exotica.org.uk/release.php?id=107478 for example this 2024 release, if you scroll to the end of the page.

Hehe. Here's a cool FILE_ID.DIZ collection: http://www.roysac.com/fileid_col.html

Real nice ascii art collection!

I was adult years old when I realized all those big walls of gibberish I saw in my youth was intended to be elaborate graphics, but my computer had the wrong charset to show them.

Huh! Which system you were using? Notepad in Windows or Linux?

I would guess MS-DOS. Back then, there was no UTF-8, and the character encoding depended on your language. People using English normally were using CP437 (https://en.wikipedia.org/wiki/CP437), while people using other languages would be using something like CP850 (https://en.wikipedia.org/wiki/CP850). Take a look at the encoding tables in these two articles, and notice that CP437 has lots of line and box drawing characters in the high half, while CP850 replaces many of them with accented letters.

If the file was written on a system using CP437, and used these line/box drawing characters, then someone on a system using CP850 would see random letters where the author intended fancy boxes around their text.

(This was due to a limitation of the text modes used to run MS-DOS: each character on the 80x25 fixed-size grid shown on the screen was described in memory by a single byte which was a index into the font table, plus another byte for attributes like color and intensity. That means there could be at most 256 distinct characters, and no way to combine separate characters into one. To add all the accented letters necessary for many languages, something had to be removed; and what was removed were the less important line and box drawing characters. That is very different from the graphical modes common nowadays, which store the color of each pixel separately in memory, and allow infinite variation on the character shapes.)

Dos and later Windows. Unsure which code pages were used but this was in Sweden.

> Unsure which code pages were used but this was in Sweden.

Interesting. Every PC I ever used in Finland (home, school, friend's, etc.) were always using https://en.wikipedia.org/wiki/Code_page_437 and I would have assumed every PC in Sweden did too. Maybe your did have cp850 or something uncommon.

Pedantic note: This appears to be a text file that was improperly converted to HTML. The body contains text in angle brackets that is not visible when viewing in a web browser, mainly the <ASP> mark for the Association of Shareware Professionals. You can properly see the original text by viewing the page source.

Perhaps the eminently useful <PLAINTEXT> tag hadn't been invented in 1994 :-)

The file self-describes (in the first line) as being HTML, so not using characters that don't work in HTML seems like a sensible requirement. Strange that nobody noticed and fixed it, earlier.

Perhaps browsers of yore (heh, I was there so that sounds strange) did render the elements in question since they were less strict?

HTML1.1, HTML2, etc weren't less strict, if anything they were more. They only consumed tags that could be rendered, since there wasn't a concept of a DOM tree or anything like that. They just worked forward rendering as they went. CSS and JavaScript introduced the need for a DOM tree and mutable state, in which case HTML renderers treated HTML docs more like XML descriptor files than SGML.

In a world where we increasingly don't own software but we rent it, is hard to imagine that shareware even existed.

As a kid I remember playing only first level of Doom, because it was distributed as a shareware and didn't have money to buy the game.

I remember saving money and buying computer magazines and then installing all the shareware they had on floppy disks, out of curiosity. For me the discovery process was fascinating.

Bah.. we just don't call it shareware anymore, but freemium.

And mission disks are called DLC.

Which also work with DRM free content. DRM and renting feels like short term gain to me.

I've bought one mobile app in my life. It was a tower defense game. The first few levels were completely free. After that, the game sends monsters that are too tough to destroy with the towers in the free content of the game. You could pay $2.50 for more towers, $2.50 for more more towers, $2.50 for more levels, $2.50 for something I don't remember, as in-app transactions.

I thought two things: "this game is fun enough to be worth $10," and "this is a really stupid way to do shareware."

That's not shareware. At least not in the spirit. That's pay to win.

Shareware is about more features /content and a clean cut out of them in the free version.

Then you must be misremembering... the shareware version was the first episode, which was around a quarter of the final game. This practice was started by Apogee (who published, amongst others, Wolfenstein 3D) and then continued by id software for Doom and Quake.

What I remember is a title ascii screen (yellow letters against a red background or something the like) stating 'if you copy Doom, you will go to hell'. I'm pretty sure I got a copy of the complete game. I guess a lot of people will be going to hell.

If you played Doom, you were already in Hell.

That's why I later bought a boxed copy of Quake to atone for my sins...

I totally like their example, let me cite it here:

  -------
  MY PROGRAM v1.23  - A program which will
  do anything for anybody. Will run in only 2k
  of memory. Can be run from the command line,
  or installed as a TSR. Completely menu-
  driven. Version 1.23 reduces the previous 4k
  memory requirements, and adds an enhanced
  graphical user interface. Also, MY PROGRAM 
  now contains Windows and DESQview support. 
  Coming soon - an OS/2 version.
  From Do-It-All Software, Inc. $15.00

Just $15.00 for such a software gem with 2k mem requirements. I would surely pay for an OS/2 version. :)

> A program which will do anything for anybody...$15.00

Such a bargain!

I love the burn about OS/2’s lack of software, where a fictional developer has done all of those things including DESQview support of all things but still hasn’t supported OS/2.

I would love to peek for a moment into parallel Universe where OS/2 took place of nowadays Linux.

> A user file (such as README.1ST), which should explain how to use the install utility, what the user should expect during the installation, and any preparation that the user should make prior to the installation. This file might also contain a brief description of your program

> might

There's times where I find a random codebase and the README talks about how to install it without first giving some idea on what it is. I guess that's not new.

I saw plenty of FILE_ID.DIZ's back in the day. Interesting bit of history to find out more! (Even decades after it's become irrelevant)

Didn't know these had Shareware origin, always thought it was a Warez thing.

These were a hassle when unzipping and you always got the question if you wanted to overwrite or not.

Still actively used for releases in the demoscene.

I completely forgot this was a thing, but its existence was etched in my brain. I wasn't aware that anybody read those files. The name would fly by when extracting a zip, but that's it.

I did. Before the internet, I read just about everything I could find - there might valuable information in it !

Well, their whole point was to be read and displayed by BBS software (and later by some early download websites I guess) to help users decide what to download in the first place, so they were indeed not expected to be opened by the user after downloading.

That's actually a different feature of (PK-)ZIP, but often the same file. It was a command line switch in pkzip to add a file to display when extracting the contents. FILE_ID.DIZ was mostly about auto-importing file descriptions with BBS software. Especially helpful with message networks that included distributed file areas, like FidoNet.

lots and LOTS of these and more can be enjoyed at https://defacto2.net/home

along with much more retro underground history.

On second thought and too late to edit, a direct link to a relevant search https://defacto2.net/search/result?search=all&query=file_id....

There are also zip files with collections of .diz files, etc

It has been many years since I've seen a Compuserve ID.

if you go look in the source code of the html you can see some <ASP> tags probably not rendered by the browser so in order to READ this document you have to view-source (it doesn't look that different, but it makes more sense).

I also recall DESCRIPT.ION files back in the day.

I thought only 4DOS/DR-DOS used that?

It also was a zip description for a short while, at least among a few large midwest BBS’s, until FILE_ID.DIZ won out.

Some file managers (e.g. Volkov Commander) used that too. Actually still do: Total Commander[0] can use to show a short description for each file.

I used it in a game i wrote for an MSDOS game jam a few years ago[1][2] to add some era relevant flavor (and also dirinfo for Norton Commander and clones).

[0] https://www.ghisler.com/

[1] https://bad-sector.itch.io/post-apocalyptic-petra

[2] https://codeberg.org/badsector/PetraEngine/src/commit/bc6531...

I still involuntarily expect GitHub to show a description of each file instead of the last commit message.

I had a tool, which extracted all FILE_ID.DIZ files from the archives (zip, rar, arj, lha, ...) in the directory and created DESCRIPT.ION files from those DIZ contents for those archives. Using 4DOS was joy when going through archives.

Here is a collection of 1.1 MILLION FILE_ID.DIZ files from back in the day: https://discmaster.textfiles.com/search?q=FILE_ID.DIZ&qfield...

Was there a standard filename for the little ANSI art file?

Remember reading this text file so long ago

.NFO[0] files?

[0]: https://en.wikipedia.org/wiki/.nfo

That is what I was thinking of

ANSI art was usually separate IIRC, nfos had ASCII art headers but I don't remember ever seeing color in them

A lot of these had ASCII art in them.

Sometimes there'd be a bunch because BBSes the zip passed through would add an nfo or .bbs

The original .DS_Store

For what it's worth...

  echo ".DS_Store\n" >> ~/.gitignore
  git config --global core.excludesFile "~/.gitignore"

Pcmicro was a noted RemoteAccess BBS support site back in the BBS heyday http://pcmicro.com/ra/

> MULTIPLE DISK INFO

Wow, that brings back memories. Always worrying that one of the many floppies will have a read error, and there goes the whole application :-(

I wrote a article on the history of this stuff a while back you may enjoy: https://l33t.codes/2020/12/10/Retro-standards-part-1-file-de...

I think some of my old Amos MaxsBBS Doors are still on Aminet archives. Used to love the ASCII art and the cRAZY cASING used in DIZ files.

i love the textured background , just needs some work-in-progress.gif

Reply on news.ycombinator.com