[deleted]
Hosting a Public Website on MS-DOS (2022)
11–20 of 54 posts
Re: Hosting a Public Website on MS-DOS (2022)
#12> That's because DOS webservers can only keep track of 8- or 16-ish concurrent requests Is that because of the lack of official 'forking'/threading, or due to the limitations of whatever TCP stack is being used for the listen() / accept() calls? (or something else?)
I wrote a web server for CP/M, the issue there was that the C library could only hold the state of a small number of FILE* at a time, because they were allocated statically.
For DOS, "FILES=nn" in CONFIG.SYS controls the number of data structures it allocates for open file handles: https://pcdosretro.github.io/config.htm#FILES
But I'm not sure if accepted sockets fall into this category.
Re: Hosting a Public Website on MS-DOS (2022)
#13> Your server will be secure because it's obscure. But it's still very likely to become a target for autistic geniuses.
Ah, delving into the abyss of ancient servers, are we? Well, if there's one thing that tickles the fancy of the 'Atypical Geniuses Club,' it's a relic from the digital crypt. Count us in, presently inspecting the code armed with nothing but floppy disks and a dial-up connection!
Re: Hosting a Public Website on MS-DOS (2022)
#14> That's because DOS webservers can only keep track of 8- or 16-ish concurrent requests Is that because of the lack of official 'forking'/threading, or due to the limitations of whatever TCP stack is being used for the listen() / accept() calls? (or something else?)
ought to be enough for anybody ... :-p
I was surprised to find out there is a TCP/IP stack for DOS, I remember still having to depend on non-MS software as late as Win 3.1 to connect to the internet [1], never heard of "LAN manager" [2] but apparently it did have (some?) support.
Btw, according to its author, "mTCP is a hobby project that I started in 2005." [3]
--
1: https://en.wikipedia.org/wiki/Trumpet_Winsock
Re: Hosting a Public Website on MS-DOS (2022)
#15> That's because DOS webservers can only keep track of 8- or 16-ish concurrent requests Is that because of the lack of official 'forking'/threading, or due to the limitations of whatever TCP stack is being used for the listen() / accept() calls? (or something else?)
ought to be enough for anybody ... :-p I was surprised to find out there is a TCP/IP stack for DOS, I remember still having to depend on non-MS software as late as Win 3.1 to connect to the internet [1], never heard of "LAN manager" [2] but apparently it did have (some?) support. Btw, according to its author, "mTCP is a hobby project that I started in 2005." [3] -- 1: https://en.wikipedia.org/wiki/Trumpet_Winsock 2:…
You could get all kinds of network stacks for msdos. Net ware, 3Com XNS, a weird proto Microsoft network I can’t recall the name of, banyan vines, decnet . Weird stuff for ibm token ring networks. And yep TCP as well. When lan manager was released you could run it over a choice of networks TCP included, because the original lan manager ran on Unix as well as OS/2 as the server.
Re: Hosting a Public Website on MS-DOS (2022)
#16> That's because DOS webservers can only keep track of 8- or 16-ish concurrent requests Is that because of the lack of official 'forking'/threading, or due to the limitations of whatever TCP stack is being used for the listen() / accept() calls? (or something else?)
I wrote a web server for CP/M, the issue there was that the C library could only hold the state of a small number of FILE* at a time, because they were allocated statically.
I was thinking about cpm online software too! what hardware do you run it on? any links?
Re: Hosting a Public Website on MS-DOS (2022)
#17Earlier quoted context omitted.
I wrote a web server for CP/M, the issue there was that the C library could only hold the state of a small number of FILE* at a time, because they were allocated statically.
For DOS, "FILES=nn" in CONFIG.SYS controls the number of data structures it allocates for open file handles: https://pcdosretro.github.io/config.htm#FILES But I'm not sure if accepted sockets fall into this category.
> But I'm not sure if accepted sockets fall into this category.
For the HTTP server in this article, no. It contains an embedded TCP/IP stack (linked into the HTTP server executable), which expects to talk to a network card driver TSR using the "Packet Driver" API (normally INT 0x60, but the interrupt to use is configurable). Network connections completely bypass the files subsystem in the DOS kernel
Nowadays, the vast majority of people doing TCP/IP on DOS [0] use Packet Driver, and what I just said is true for anyone using that. However, historically there were a huge array of DOS TCP/IP stacks, all implemented differently. It would be (somewhat surprising) news to me if any of them represented individual network connections as files in the DOS kernel, but not having looked at them all, I can't confidently say.
[0] which is almost all hobbyist/retrocomputing: I'm sure there are a few embedded systems running DOS surviving, but most of those likely don't do networking, and many of the few that do may be running something other than TCP/IP, so any remaining production TCP/IP use under DOS is likely quite rare
Re: Hosting a Public Website on MS-DOS (2022)
#18> That's because DOS webservers can only keep track of 8- or 16-ish concurrent requests Is that because of the lack of official 'forking'/threading, or due to the limitations of whatever TCP stack is being used for the listen() / accept() calls? (or something else?)
It could he hardware limits, but I doubt it. Plenty of microcontrollers are running HTTP servers right now, and those are happy enough.
Re: Hosting a Public Website on MS-DOS (2022)
#19I discovered Felix a couple months ago. It's a shame he has disappeared since making this blog post.
Re: Hosting a Public Website on MS-DOS (2022)
#20> Your server will be secure because it's obscure. But it's still very likely to become a target for autistic geniuses. I legit laughed out loud.
I was gonna be worried for a second, then I remembered that kind of person almost never lives a terminally-online, hacking-obsessed life.
Phew.
gets back to trying to convince his bank to send his data over plain FTP