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.
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.
It would work, but still not ācredibleā, too āforward thinkingā :) Who in the DOS era would come up with such folder name ā¦.
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 ā¦
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.
In dos on dope, .bat files are handlers for http GET and .cmd files are handlers for http POST.
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):
In Win98, support for long filenames was kind of a hack: the DOS name of "longfilename.txt" was "LONGFI~1.TXT"
20-some years later, those names still exist. See https://docs.microsoft.com/en-us/windows/win32/api/fileapi/n...
This a war crime of a software project, and I love it.
Why not COBOL of Wheelchair?
Or indeed COBOL on COGS http://www.coboloncogs.org/INDEX.HTM
The one true web framework for serious business applications.
cmd.exe is a Windows (NT) console application and has nothing whatsoever to do with DOS.
The verdict: Sentenced to using PC-DOS 1.0 for 6 month' straight. No probation.
"cmd.exe on coke" didn't test well with our target demographic. (author here)
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.
Wikipedia link on the differences:
https://en.wikipedia.org/wiki/Batch_file#Filename_extensions
Which also links to:
http://waynes-world-it.blogspot.com/2008/08/difference-betwe...
There used to be a microsoft.com page on it too, but that's been lost to time.
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.
Hmm, same here, I've never known any difference. I do use `.cmd` instead of `.bat`, but only through personal preference, nothing more.
Author here.
In dos on dope, .bat files are used for actions that handle http GET, and .cmd files are used for actions that handle http POST.
Btw I did live through that transition. (?)
Yeah, I remember this, having used DOS since 5, but never used advanced enough stuff to justify forcing cmd.exe
There is also .ba1 which I have no idea what is.
"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."
lol :)
"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.
It is full of choice quotes. More:
> 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.
> copy con About.bat
Holy smokes, what a flashback...
> @echo off
...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.
They do, but nobody uses batchfiles nowadays. PowerShell is the thing.
Citation needed.
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".
You could use "cp file1 file2" which is an alias for Copy-Item ;-)
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).
Technology doesn't get old. Its users do.
Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.