Talk:8.3 filename

unicode support?

if full Unicode support didn't come until Windows 2000, how exactly were Unicode long file names supported?—Kbolino 06:46, Apr 7, 2005 (UTC)

what do you mean by "full unicode support"? 98 had some unicode support though it didn't have all apis (i don't have 95 handy to try but it wouldn't surprise me if it had some degree of support). NT4 was natively unicode though i belive it only supported the basic multilingual plane. Even now unicode support is not without its quirks in most operating systems. Plugwash 20:21, 13 Jun 2005 (UTC)

Full Unicode support is still miles away, even though were getting closerMs dos mode (talk) 21:35, 22 June 2009 (UTC)

Windows 95+ supported two subsets of Unicode, defined by the system ANSI and OEM codepages. IFSMGR.VXD used UNICODE.BIN file to perform the required conversions. 178.49.152.66 (talk) 12:36, 20 December 2014 (UTC)

page name

this page used to be at "8.3 (computing)" imo a horrible and not very informative name.

vague rant who has never edited this page then moved it to just 8.3. which i belive is even worse since it gives very little idea of the articles subject.

if there are no objections here in a day or so. i'm going to move the page to the more discriptive name of 8.3 filename limitations. Plugwash 20:27, 13 Jun 2005 (UTC)

A more accurate title might be "8.3 FAT filename mapping" or "8.3 file naming scheme", but I don't see what's to be gained by moving. "8.3" is a moniker that the article has set out to explain, and it does that quite well. Another similar example might be 24/7.

—Ghakko 23:03, 13 Jun 2005 (UTC)

I'll point out that my page move was simply made because there was no need for disambiguation, since the article 8.3 did not exist. I didn't take into account whether there might be a better title, I was just removing unnecessary disambiguation. I've no issue with the page being moved somewhere else. I've likewise no issue with it staying here. I'm not fussy. - Vague | Rant 13:31, Jun 16, 2005 (UTC)

Naming Convention Speculation?

I've read theories about this, and usually discussions about this end up saying there's no real answer.

First one from http://www.mackido.com/Innovation/FileNames.html : Because to do things (like copy a file), you had to type in the entire file name (and path name), people used lots of abbreviations and concatenation to reduce typing. This is why CP/M (DOS) used 8.3 (8 charaters + a 3 character suffix).

Second: If you've come across with the name Gary Kildall during your research, count the letters in his name. This doesn't explain why it wasn't 7.4 though.

Third: 8.3, 8 + dot + 3 = 12 characters, compressed nicely with RAD50 into two words. However, CP/M does not compress filenames, and RAD50 was usually used to compress 6.3 or 9.3 filenames (some computers were 6-bit back then).

Fourth: It comes from the 12 rows on an 80 column card. One row for each letter, plus the 12th row for a data clock (based on the stereotypical IBM 029 keypunch). A single column was punched in each row to mark the letter from the character set, yielding up to 80 choices per character.

Fifth: There is evidence that Gary was one of those rare individuals with both DEC and IBM influences in his background. DEC had established the 3-character file extension as a standard on its systems, and IBM mainframes of the time had 8 characters as a common namespace size. Put the two together, and you get 8.3.

Sixth: DEC's RT-11 used 8.3 filenames, and CP/M was developed using it as a guideline. This doesn't explain where RT-11 got 8.3 though.

Seventh: Kildall chose 8.3 because he liked it.

http://www.techspot.com/vb/all/windows/t-10133-83-Naming-Convention-Why-was-it-chosen.html

I believe that the Mac OS X implementation of FAT32 uses a similar hashing step to the one listed as step 4 of the "algorithm" but I'm not completely sure about this. It may be worth mentioning if someone more knowledgable can verify this. 71.245.115.135 02:26, 21 January 2007 (UTC)

DOS 8.3

This is usually called DOS 8.3. If the article is not going to have that official name, it should certainly redirect to here from there, and should mention the term right at the start. *** The discussion of the dot should perhaps add some more tech background. The dot does not exist in the internal representation -- there is simply a place for the 8 letters and a place for the 3 letters. So, the dot is always implicitly present. And it is also misleading to say that 8.3 names are uppercase. Is a tech sense that may be true, but in another sense they are generally defined as caseless, and can be represented arbitrarily as uppercase or lowercase. All a source of endless potential problems. 69.87.203.84 19:26, 21 January 2007 (UTC)

more info needed

There are endless complications with DOS 8.3 / LFN. This is a core tech subject. It is pathetic that this article is so limited, and has no links to relevant external resources. 69.87.203.84 20:12, 21 January 2007 (UTC)

Move .. again

I'll agree with the discussion above that a simple title of "8.3" is vague. According to the MSDN documentation this is called a "8.3 file name" (spaces are intentional—although I could swing towards "filename" for constancy within Wikipedia). Could we agree to move it to either 8.3 file name or 8.3 filename? +mwtoews 17:38, 22 March 2007 (UTC)

Moved. I chose to use "filename" over "file name" as it appears Wikipedia has more consistency with that spelling.+mwtoews 21:58, 24 March 2007 (UTC)

Translating LFN to SFN

I don't understand "followed by 4 hexadecimal digits derived from an undocumented hash of the filename" how, exactly, does one determine those four digits on their own? Maybe it's my severe lack of understanding of Hexadecimals ...

TextFile.Mine = TE021F~1

OFFSET HEXADECIMAL REPRESENTATION  ; ASCII REPRESENTATION

00000000h: 54 65 78 74 46 69 6C 65 2E 4D 69 6E 65  ; TextFile.Mine

00000000h: 78 74 46 69 6C 65 2E 4D 69 6E 65  ; xtFile.Mine

00000000h: 54 65 78 74 46 69 6C 65 2E  ; TextFile

Jndrline (talk) 20:10, 16 July 2008 (UTC)

Hex is just a way of expressing a number. The number is determined by an algorithm which is undocumented. The algorithm varies by OS, version, and sometimes service pack. —EncMstr (talk) 21:22, 16 July 2008 (UTC)

I am sure I have seen such SFNs, but at the same time, I am certain I have also seen SFNs of the sort FOOBA~12.TXT (which uses less than 6 characters and more than one digit). The article does not mention that, nor anything useful about the 4-hex-digit variety. It is a little vague as it stands and needs some information about that/those. I guess I just got a new project. ಠ_ಠ Synetech (talk) 19:45, 21 August 2015 (UTC)

Windows NT systems use the checksum after FOOBAR~4.TXT, but pre-NT (I'm pretty sure that includes 95 but I don't know what the last non-NT system was) systems use FOOBAR~5.TXT, which can logically be extended to double-digit numbers (so FOOBA~12.TXT like you said)... Nameless6144 (talk) 12:58, 20 May 2018 (UTC)

Found a page about a successful reverse-engineering of this checksum... A Tale of Two File Names: Should it be included, or is it not encyclopedic to include information discovered through reverse-engineering? Either way, it's probably what Jndrline wanted, so I'll post it here. Nameless6144 (talk) 12:58, 20 May 2018 (UTC)

Wow Nameless6144! You answered a question I'd forgotten I ever asked. I think my original intent was writing cmd/bat files, and how can you predict an 8.3 file name in certain instances. What a great read! Thanks for sharing. Jndrline (talk) 19:16, 27 September 2018 (UTC)

185.24.13.202 (talk) 10:43, 3 August 2018 (UTC)

The example of a shortened filename 'OVI3KV~N' contains the character 'N', whereas the text below this clearly states that the character after the tilde is always a digit.