[jimohalloranau]

Am I the only one struggling with the "Controllers" folder not being an 8.3 filename, and therefore couldn't actually exist on MSDOS?

To use "Controllers" you'd need a file system with support for Long File Names (LFN) which for most people didn't happen until Windows 95 (maybe WInNT 3 had it too, I dunno, never used NT 3.x).

So "WinDOS on Dope"?

Still pretty cool nonetheless.

[LeonB]

Valid point.

If I just changed any mention of "Controllers" to "CONTRO~1" (both in the tutorial and in the code) -- it would work just fine. Maybe after 10+ years it's time for a patch. But not today.

[ranit]

It would work, but still not “credible”, too “forward thinking” :) Who in the DOS era would come up with such folder name ….

[pavlov]

NT 3.x already had the NTFS file system.

But yes, it’s not DOS-credible if the paths aren’t like C:\DOPE\CTRL …

[skissane]

I think the author is using "DOS" to mean "Windows Command Prompt" (cmd.exe and Win32 Console subsystem)

Incorrect terminology, but an error I've heard people make again and again and again, pretty much constantly ever since Windows XP came out. In Windows 3.x/9x/Me, the command prompt actually was MS-DOS. In NT/XP/Vista/7/8/10/11, it is not DOS any more, unless you actually run command.com under NTVDM (only possible in 32-bit Windows, support for which is gone in Windows 11)

[jaclaz]

BTW - to nitpick - batches intended to run in cmd.exe should be .cmd not .bat, nowadays it makes no difference, but .bat are executed under both command.com and cmd.exe, whilst .cmd only run in cmd.exe.

[LeonB]

In dos on dope, .bat files are handlers for http GET and .cmd files are handlers for http POST.

[rascul]

From what I recall, Windows 95 and 98 shipped with MS-DOS 7.0, which was not released separately but was easily extracted and could run on its own. It included support for long file names.

[badsectoracula]

Windows 9x supported long filenames by overriding DOS instruction to provide it, so they only worked while Windows was running. If you rebooted the PC in MS-DOS-only mode LFN wouldn't work.

There were a bunch of TSRs that added support though. Here is one i used recently on a retro PC to install Free Pascal for DOS (which, despite being for DOS, requires long filename support to install - though depending on which units you use, it can work without it afterwards):

http://adoxa.altervista.org/doslfn/

[ravel-bar-foo]

In Win98, support for long filenames was kind of a hack: the DOS name of "longfilename.txt" was "LONGFI~1.TXT"

[glandium]

20-some years later, those names still exist. See https://docs.microsoft.com/en-us/windows/win32/api/fileapi/n...

[JonathonW]

IIRC they don’t have to exist on modern Windows on NTFS (there’s a switch somewhere that turns them off), but they’re still on by default for compatibility reasons (Windows 10 can still run DOS and 16-bit Windows programs, after all).

On FAT filesystems (still used on things like SD cards, although ExFAT’s starting to take over), 8.3 names can never go away.

[p_l]

NTFS is a bit funnier in that aspect than most people realise.

Effectively, you can have multiple "name" attributes on the FILE structure (which describes any kind of object in NTFS), and those names have associated "namespace" to them (or "kind"). I think ntfs.sys enforces that there's only one name per namespace, but I do not remember offhand if it was made impossible in the structure itself.

The namespaces available include at least 3 - native WinNT (16-bit Unicode, long file name), DOS-compatible (8.3 - this is where compatible names with tildes are put when generated), and POSIX (different set of allowed characters, generally 8bit with encoding ignored iirc, long file names). If you handcraft the file, you can generate one that has all three completely different, resulting in different file names seen by different APIs

[TheGoddessInari]

> IIRC they don’t have to exist on modern Windows on NTFS (there’s a switch somewhere that turns them off), but they’re still on by default for compatibility reasons (Windows 10 can still run DOS and 16-bit Windows programs, after all).

You can disable it, but realistically it won't make a performance or efficiency difference (only reason go mess with it really), and lots of things still break if 8.3 compatibility is disabled or stripped. On occasion, this had included weird first-party errors, too.

In theory, there are tons of things that shouldn't matter any more either, like spaces in filenames, or variables like PATH being longer than 2047 characters, but it all still ends up somehow breaking various things over time.

[glandium]

You remember correctly. See paragraphs and table before examples in the doc I linked.