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).
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.
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)
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.
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.
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):
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.
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
> 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.
Every time I see 'DOS' tutorials like this, I realise that I'm in a minority that uses .cmd as [Windows]DOS batch file extensions and not .bat
The reason for this (for those that don't know) is that when 32-bit Windows arrived, the DOS 32-bit shell (cmd.exe) was introduced alongside the traditional command.com and with it added a bunch of new shell commands and options. To call cmd.exe instead of command.com you would use .cmd as your batch file extension instead of .bat.
This was done to ensure ongoing 100% compatibility of legacy .bat files with command.com
Even after Microsoft killed off command.com and remapped .bat to cmd.exe I still used .cmd as the file extension and still do to this day.
Seeing people use .bat makes me realise that a lot of people never went through this transition and are probably unaware of the .cmd extension.
Odd, I lived through the same period, and don't recall a situation where .cmd vs .bat ever made a difference to the interpreter.
On DOS-based Windows (i.e. up to 3.1, and then 95/98/ME) only COMMAND.COM was available, so certainly that was always used as the interpreter.
The native Windows 32-bit cmd.exe was introduced on NT-based Windows (i.e. 3.1/3.5(1)/4/2000, then XP and all following mainstream Windows). A virtualised form of DOS was available on the NT line so in principle you could also run your batch files through the old COMMAND.COM. This is where I'm least confident, but I thought that the extension wouldn't make that choice though - it would use the 32-bit cmd.exe even if the extension was .bat, unless you explicitly started a DOS instance and ran it through that. After all, one of the design goals of cmd.exe was to be a drop-in replacement for the old DOS interpreter.
Those articles match my understanding, but it's a bit different to your previous comment (but maybe I misunderstood your previous comment).
I thought you were saying that there was at least one version of Windows where .cmd would run in cmd.exe while .bat would run on COMMAND.COM.
Whereas I think the actual situation is that: on Win95 .bat would run on COMMAND.COM whereas .cmd wouldn't run at all; on NT .bat and .cmd would both run on cmd.exe. As a result, if you used .cmd you could be sure that it would never run on COMMAND.COM, so you could use the new command extensions in cmd.exe without worrying about it causing a confusing error.
"So far I haven't run into any performance problems. Whenever I've opened up a DoD website to several users, my hard drive tends to get wiped long before I discover performance issues."
"So far I haven't run into any performance problems. Whenever I've opened up a DoD website to several users, my hard drive tends to get wiped long before I discover performance issues."
Had to laugh at this in the FAQ. My first thought was of the Tubes "White Punks on Dope." I think that is the performance you are seeking.
> In DoD we embrace the NoSQL movement and jump straight to the data-store of the future: a CSV file.
> If you can't trust public visitors from the internet, who can you trust? Executing user input as commands inside the operating system is the most direct way to get things done, and that's what matters most.
...wow do batch files still use this stuff seriously? I remember learning that trick from the PC Mag MS-DOS Bible in the early 90s...that one alone made me feel like I had learned to write executables rather than simple command lists. Funny to see this project, really cool too.
I would love to get the time to learn PowerShell, but it never quite materilises. I still know how to make a basic batch file though. I suspect that many are in the same position. (Except that probably most don't feel so bad about it as I do!)
My evidence is purely anecdotal, for example both Chocolatey and Scoop package managers use PowerShell internally. Also modern Windows versions replaced "open command line" in the Start right click menu with "open PowerShell".
There are many things PowerShell can do and batch files can't, starting with piping output between commands.
For longer and more complex scripts, probably. For something short, I'd probably use "copy file1 file2" rather than "Copy-Item -Path file1 -Destination file2".
Batch files are used way more than PowerShell - i barely see .ps1 files out there but .bat files are everywhere.
Hell, even with .ps1 files, sometimes see them alongside a .bat file that all it does is to launch .ps1 with -ExecutionPolicy Bypass (or whatever is called).
> That editor with the blue background must be the new TextMate-killer for the PC :)
It could and should be. Subjectively, according to my taste, all modern text-mode editors are either ugly or unintuitive or both. MS Edit (edit.com) was both nice-looking and intuitive but lacked modern features like extensibility, code completion, regex search, multi-cursor, UTF-8 support etc. I really wish there were modern MS Edit clones (for whatever OSes the developers would be interested in, I'm interested in many) implementing modern features I've mentioned.
I found that (even back in 2010!) “edlin” wasn’t available on my laptop. And since I was coding this on the bus (without internet) I couldn’t download/find some legacy way of running edlin.
I opted to gave an example of “copy con” and ^Z instead.
Wordstar has very different keys to EDIT.COM, which was basically a tiny program to launch QBASIC.EXE with the /EDIT (or /EDITOR) parameter that disabled the BASIC bits. QBASIC's keys are the same as those used in Windows.
I sorta don’t get it. Is there such a thing a corny meta humor? There’s corny regular humor. Can meta humor be corny too? Is this meta corny? There’s gotta be corny people at every layer, right?
This is kinda corny. It’s still edgy to make fun of model view controller?
Oh, in that case, my comment is actually the thing that’s out of date. It’s not corny if you make fun of the thing when it’s not cool to make fun of it.
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.