David has it right. The configuration that you want to use will depend a lot on how your various programs use shared memory space. You also need the 106 kernel from eCS 2.2 b2, which has a couple of fixes for loading and unloading, DLLs in high shared memory space. Unfortunately, it seems that there is still a problem with that. Somebody is working on it, but there are no results, yet.
There are a few things that a user can do to help:
Add the line
dllbasing=off
near the top of CONFIG.SYS. This lets the system make more efficient use of shared memory space, at the expense of a very slight reduction in performance (you might notice it if you are running on a 486-SX processor).
Close, and/or don't use, unnecessary programs.
If you use X(e)Center, remove any DLLs that you don't use. Years ago, I found that WinList kept on using more, and more, shared memory space, even if I didn't use it. That may have been fixed, but I find that LSwitcher works much better.
Keep the number of tabs in Firefox (or Seamonkey) to a minimum. Each one adds a little more.
You can try adjusting VIRTUALADDRESSLIMIT=xxxx in CONFIG.SYS. Some say that 1024 is a good number. Others say that 2048 is good. The collected wisdom says that 1536 is generally the best. Personally, I find that 1536 works best, for me, and I start to have more problems if I increase, or decrease it. YMMV. Unfortunately, I still have problems from both sides, if I don't try to keep usage under control.
Now, for the big one (IMO). Programmers need to start using more static linking, to eliminate the use of DLLs. For some reason, they seem to be very reluctant to do that, but huge packages, like AOO, and Firefox, are eating up large amounts of shared memory space. Using high shared memory space is a partial fix, but it still has problems (the system can crash when the DLLs are unloaded). Running large programs, that use a lot of shared memory space is not a problem when the user only runs one program, but it becomes a large problem when somebody wants to run AOO and Seamonkey at the same time, along with a dozen other programs. It isn't possible to modify a lot of the older programs to use high shared memory, or even stop them from using DLLs (we don't have the source). Other programs, like the CLAM Antivirus daemon (CLAMD.EXE), use large amounts of shared memory space. The older versions used low shared memory space, while the latest (only available with RPM/YUM AFAIK) seems to be using upper shared memory space. That change makes it usable again, but there is still a limited amount of upper shared memory space available. The other option is to use it without the daemon. That is okay, but then it takes about 1 minute to load the database, before it can run the scan, which can take less than a second.
Some of these problems will be slightly easier to manage, when Arca Noae gets their Package Manager (ANPM - previously called Yumie) released. The program itself is working great, but getting it properly installed is turning into a nightmare because of the complexity of YUM itself, and even worse, because users have tried to outsmart the existing systems, or RPM/YUM has not been properly used in the past. RPM/YUM is a terrible choice for managing packages, but that is what we are presented with. ANPM is a user friendly front end for YUM, but it still uses YUM in the background, so it depends on YUM doing the right thing (and all too often, it screws up). It will probably take a bit of work to get it all sorted out, but managing the whole thing should be easier in the end. It will be even better, if the WarpIn interface gets added so it can manage both install methods.