3 ms·

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 allocate

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.

rzzzt 3y ago
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 https://pcdosretro.github.io/config.htm#FILES But I'm not sure if accepted sockets fall into this category.
- skissane 3y ago
  > 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
ikari_pl 3y ago
I was thinking about cpm online software too! what hardware do you run it on? any links?
- jstanley 3y ago
  Sure. I ran it on an RC2014. I have a blog post: https://incoherency.co.uk/blog/stories/rc2014-web-server.html https://incoherency.co.uk/blog/stories/rc2014-web-server.htm... And a github repo: https://github.com/jes/cpmhttpd https://github.com/jes/cpmhttpd
queuebert 3y ago
And even if heap allocated, there might be a static pointer array tracking them. In the DOS days, dynamic memory allocation was to be avoided if possible. Machines did not handle running out of memory gracefully. Often we'd unnecessarily fix the size of things to avoid run-time uncertainty. A scientific Fortran code I once saw allocated all of the memory it would need at the beginning of the code in an array called 'a'. Then from there it would dole out portions to other parts of the program using common blocks.
- pklausler 3y ago
  I suspect what you’re trying to describe was the use of blank COMMON as a dynamic storage pool. The anonymous COMMON block begins at the address after the last named block.

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.

rzzzt 3y ago

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 https://pcdosretro.github.io/config.htm#FILES But I'm not sure if accepted sockets fall into this category.

skissane 3y ago
> 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

ikari_pl 3y ago

I was thinking about cpm online software too! what hardware do you run it on? any links?

jstanley 3y ago
Sure. I ran it on an RC2014. I have a blog post: https://incoherency.co.uk/blog/stories/rc2014-web-server.html https://incoherency.co.uk/blog/stories/rc2014-web-server.htm... And a github repo: https://github.com/jes/cpmhttpd https://github.com/jes/cpmhttpd

queuebert 3y ago

And even if heap allocated, there might be a static pointer array tracking them. In the DOS days, dynamic memory allocation was to be avoided if possible. Machines did not handle running out of memory gracefully. Often we'd unnecessarily fix the size of things to avoid run-time uncertainty. A scientific Fortran code I once saw allocated all of the memory it would need at the beginning of the code in an array called 'a'. Then from there it would dole out portions to other parts of the program using common blocks.

pklausler 3y ago
I suspect what you’re trying to describe was the use of blank COMMON as a dynamic storage pool. The anonymous COMMON block begins at the address after the last named block.