Hi, you can use QEMM v7 or higher, for example. Or the Himem.sys file from Windows 9x. There's also HimemX, or how it was called.

I think if you use a modern HIMEM replacement, such as XMGR, HIMEMX (as well as JEMMEX), you would be able to access all the RAM. This applies to PC-DOS 7.0/2000 as well.

As for QEMM (9.x), apparently it uses its own XMS manager and that appeared to have a soft limit of about 64MB and a hard limit of about 256MB. The soft limit is what the MEM command could display in the total RAM column, while the hard limit is the maximum amount of EMS/XMS QEMM can access (in that case the Used column would display a ? mark). Although the soft limit might be just a limitation imposed by the MEM command of those DOS versions, and you might actually be able to get the correct RAM status with FreeDOS' MEM command.

For OP's use case (256MB) those QEMM limits should not be a problem. Sadly that QEMM limit cannot be easily worked around as you can't use your own XMS manager in its place by normal means.

The suggestions are good, but I don't understand the rationale behind the original request.

1. Disabling the Windows logo at startup is as easy as adding Logo=0 to MSDOS.SYS
2. DOS6.22 does not give you more space - it limits you to 2GB partitions, and <8GB drives, and for 2GB partition the FAT cluster size is so huge, it ends up wasting tons of space if you have a lot of small files. Yes, the Windows directory itself takes up space, but if you really need the system for DOS only, you can delete it, or just install one of the hacked DOS 7.1 installations, decoupled from Windows, like the one from "China DOS Union".
3. No commercial DOS program, that I'm aware of, can use more than 64MB of RAM anyways. Unless you plan on running those recent Sonic remakes... 😀

dr_st wrote on 2021-02-23, 06:46:

The suggestions are good, but I don't understand the rationale behind the original request. […]
Show full quote

The suggestions are good, but I don't understand the rationale behind the original request.

1. Disabling the Windows logo at startup is as easy as adding Logo=0 to MSDOS.SYS
2. DOS6.22 does not give you more space - it limits you to 2GB partitions, and <8GB drives, and for 8GB partition the FAT cluster size is so huge, it ends up wasting tons of space if you have a lot of small files. Yes, the Windows directory itself takes up space, but if you really need the system for DOS only, you can delete it, or just install one of the hacked DOS 7.1 installations, decoupled from Windows, like the one from "China DOS Union".
3. No commercial DOS program, that I'm aware of, can use more than 64MB of RAM anyways. Unless you plan on running those recent Sonic remakes... 😀

On top of that, what does the OS have to do with a modern LCD being very slow to update the screen? That sounds like a hardware incompatibility...

A lot of modern LCD take a few seconds to sync to mode changes. Unlike CRT screens which are typically a few hundred milliseconds.

No commercial DOS program, that I'm aware of, can use more than 64MB of RAM anyways. Unless you plan on running those recent Sonic remakes... 😀

I'm breaking limits. I'm making my own advanced web server and already I'm learning at a fast pace all about the TCP/IP stack. I tried trumpet NTCPDRV with rubbermallet's WEBSERV.BAS but it only handles 1 connection at a time. Multiple connections done at once causes the target computer to crash. I looked at mTCP network stack but it doesn't allow me to run my own EXE files as if it was a CGI script, so I'm rolling my own and I'm about halfway done.

This is where the need of high memory comes in.

If I want to accept a large number of requests with a large number of file uploads per request, then I'd either have to use RAM, or I'd have to do disk accesses. Despite the target computer having a flash drive, I still think disk accesses are slightly slower than ram accesses.

Now here's the sadder part. I'm trying to see how much ram I can have access to in a DOSBOX environment and I changed memsize to 96 (MB) and when I tested DOSBOX, the max I could allocate is 64MB despite me calling the XMS 3.0 query free extended memory function.

dr_st wrote on 2021-02-23, 06:46:

Disabling the Windows logo at startup is as easy as adding Logo=0 to MSDOS.SYS

Doesn't pressing Esc also cause the Windows logo to go away? It's been a while.

mike_canada wrote on 2021-02-23, 18:36:

If I want to accept a large number of requests with a large number of file uploads per request, then I'd either have to use RAM, or I'd have to do disk accesses. Despite the target computer having a flash drive, I still think disk accesses are slightly slower than ram accesses.

Have you considered using a RAM disk instead?

Now here's the sadder part. I'm trying to see how much ram I can have access to in a DOSBOX environment and I changed memsize to 96 (MB) and when I tested DOSBOX, the max I could allocate is 64MB despite me calling the XMS 3.0 query free extended memory function.

Yes, standard DOSBox has limits on the amount of RAM since, as noted, no commercial DOS program requires more RAM than that and compatibility problems can start cropping up when there is too much RAM. But the limit is removed in forks like DOSBox-ECE.

mTCP HTTPSERV doesn't have CGIBIN type capability because there is no guarantee that the program you call out to will return quickly enough to avoid dropped packets. If you have one or two connections open and active and one of them calls out to an EXE program, you are going to kill the other connection.

Really the only way around that is to limit the length of time EXE programs can run for to tiny fractions of a second, or to implement some sort of background processing to keep all of the TCP connections active while the EXE is working. And by active that means receiving and buffering new incoming data, and that's going to be error prone in the background.

I'm afraid that a lot of memory makes this easier, but it doesnt' solve the fundamental problem - DOS is very single threaded, and there are limits to what you can do in a TSR or by hooking interrupts.

At some point I'm going to build a BASIC interpreter into the HTTP server. That will allow me to keep everything "in process" and sidestep the problem. It will also be faster for small requests, as shelling out to EXE programs is expensive.

Jorpho wrote on 2021-02-23, 18:51:

dr_st wrote on 2021-02-23, 06:46:

Disabling the Windows logo at startup is as easy as adding Logo=0 to MSDOS.SYS

Doesn't pressing Esc also cause the Windows logo to go away? It's been a while.

It sure does.

You're writing a web server for Dos - it's going to be single threaded, doing one thing at a time; it can only ever respond to one request at a time.

I don't see the point of writing multiple request handlers and allocating buffers etc for each one since you can only ever service one of them at a time. If you genuinely need more than 64MB to do that, then something has gone horribly wrong.

If you're going to expose this thing to the internet at all I'd also suggest you don't try to implement cgi - you may as well put an open telnet connection to the PC with a sign up saying "don't do anything bad - we trust you". The lack of file access control, user or group permissions means that any request to an executable is potentially inviting someone to instead run "deltree c:\*.*" or something equally as bad. Don't even think about trying to filter out nefarious requests - you won't win that arms race.

You mention "a large number of file uploads per request" - I don't quite get what you mean from that; do you mean the web server will return many files per page, or that your web client is going to be uploading many files to your Dos webserver?

If it's the former, then that's not how a web server works - it serves the HTML back, then it's up to your client to then make additional requests for each additional element in the page... again, because this is Dos you can only ever service each of those requests in serial, in the order they come in. So having one request handler / file reader thread/buffer/IO pool shouldn't be a bottleneck.

If it's the latter is this something bespoke you are going to implement? Normally the web server would only be able to do anything with a POST containing file data if you had something like PHP, Perl, Python or some other server side scripting langauge to accept the request and then write it out to disk.

I don't think CGI is that much of a security problem. The EXE that gets called is pre-registered ahead of time. And it should be passed a 'context' object, so that it can make the appropriate decision about permissions and security. It's not anywhere near as bad as running Telnet to access your checking account. 😉

But yes, it's still a single threaded OS and creating the illusion of multi-tasking is difficult. Calling arbitrary EXE files will make the HTTP program stop servicing the TCP/IP sockets, and that's going to be a bad time.

mbbrutman wrote on 2021-02-23, 21:02:

I don't think CGI is that much of a security problem. The EXE that gets called is pre-registered ahead of time. And it should be passed a 'context' object, so that it can make the appropriate decision about permissions and security. It's not anywhere near as bad as running Telnet to access your checking account. 😉

Certainly never have any mechanism for a page to directly pass parameters to one of your exe/cgi helpers. That way lies disaster.

Again, this is all under the presumption that it will be connected to the internet at some point. If not, and it's purely for fun on a local LAN, go ahead, go mad with crazy features 😀 but don't connect it to the internet and expect it to survive for any length of time.