DOS on Dope (2010)(secretgeek.net)
secretgeek.net
DOS on Dope (2010)
https://secretgeek.net/dod_intro
68 comments
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.
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 …
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)
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):
http://adoxa.altervista.org/doslfn/
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/
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...
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.
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
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.
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.
You remember correctly. See paragraphs and table before examples in the doc I linked.
[deleted]
This a war crime of a software project, and I love it.
Why not COBOL of Wheelchair?
https://github.com/azac/cobol-on-wheelchair
https://github.com/azac/cobol-on-wheelchair
Or indeed COBOL on COGS http://www.coboloncogs.org/INDEX.HTM
The one true web framework for serious business applications.
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.
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.
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.
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.
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.
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.
Now you say it, I'm not sure either tbh. During that period I was principally an NT user, and I never really used 95/98.
When I get a mo, I might fire up an NT VM and see what actually happens.
Maybe.... .bat and .cmd DO both run cmd.exe, but the former disables the command extensions?
When I get a mo, I might fire up an NT VM and see what actually happens.
Maybe.... .bat and .cmd DO both run cmd.exe, but the former disables the command extensions?
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. (?)
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 :)
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.
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.
> 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.
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!)
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.
There are many things PowerShell can do and batch files can't, starting with piping output between commands.
Powershell actually pipes objects between commands. It's just that they often resemble output!
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).
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.
> 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.
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.
How about COBOL on CRACK?
There’s cobol on cogs… http://www.coboloncogs.org/INDEX.HTM
Ask yourself, what kind of operating system would it take to make this a safe thing to do?
Build that OS, we really need it.
A perfect, leak proof sandbox would be a very valuable thing to have available.
Build that OS, we really need it.
A perfect, leak proof sandbox would be a very valuable thing to have available.
In theory, on a modern machine you could almost spin up a brand new instance of this for each request. When it's done, delete it.
Pretty secure. Horrible, but secure.
Pretty secure. Horrible, but secure.
This reminded me of "Bash on balls" , a joke web "framework" written in bash. I think it might have pre-dated this a bit?
https://github.com/jneen/balls/tree/master/lib
https://github.com/jneen/balls/tree/master/lib
Cheers I haven’t seen or heard of “bash on balls” before.
From what I can tell Dos on Dope (Sept 2010) predates Bash on Balls (Jan 2011).
From what I can tell Dos on Dope (Sept 2010) predates Bash on Balls (Jan 2011).
Does it support Netscape Navigator or Mosiac? This could be perfect for when I go back to the early 90s
Love the little details: the text in the forms is exactly what DHH used in 2005 when famously introducing Rails at a conference.
https://m.youtube.com/watch?v=Gzj723LkRJY
https://m.youtube.com/watch?v=Gzj723LkRJY
That is some nice batch scripting kung-fu.
Anyone who knows the relationship between .BAT files and REXX scripts?
Um. None?
I suppose you could argue that the Amiga equivalent of a batch file was a Rexx script?
But on PC-DOS 7, 7.01 or 7.1 you get a Rexx interpreter thrown in. :-)
https://liam-on-linux.livejournal.com/59703.html
I suppose you could argue that the Amiga equivalent of a batch file was a Rexx script?
But on PC-DOS 7, 7.01 or 7.1 you get a Rexx interpreter thrown in. :-)
https://liam-on-linux.livejournal.com/59703.html
Rexx also runs on mainframes and is widely used. I find that to be like a parallell universe :)
yo that haskel on a horse link is poisoned...
Thank you! fixed in the blog post and the github repo's index.md.
No edlin?
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.
I opted to gave an example of “copy con” and ^Z instead.
Off topic but my favorite editor of all time was the DOS edit.
It was simple and straightforward with keys that made sense.
It was simple and straightforward with keys that made sense.
I've been a joe[0] user on Linux for nearly 30 years because it has similar keybindings to EDIT.COM (which they both owe, I believe, to Wordstar).
[0] http://en.wikipedia.org/wiki/Joe's_Own_Editor
[0] http://en.wikipedia.org/wiki/Joe's_Own_Editor
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.
Micro is just about is good, with a CUA interface, though is lacking the menu and dialogs.
Also, freedos has a similar editor that has a few new features.
Also, freedos has a similar editor that has a few new features.
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?
This is kinda corny. It’s still edgy to make fun of model view controller?
I don't know if it was ever "edgy" but I wrote it in 2010. And it wasn't so much a parody of MVC, but very specifically of Ruby on Rails.
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.