Main text
DOS-Box and Win-OS/2
1. Memory setup
The settings EMS_MEMORY_LIMIT, XMS_MEMORY_LIMIT and DPMI_MEMORY_LIMIT directly determine the maximum amount of memory available to a session. However maximum doesn't mean that the specified amount will be used automatically. Instead the session will only use it if a program actually requests it. So it won't be of any use to restrict memory usage to e.g. 1MB if you know that the program never uses more. This setting is especially of interest if certain programs automatically allocate most or all memory that is available, but are also able to work well with less.
Windows software doesn't need EMS memory to run. So you can safely decrease EMS_MEMORY_LIMIT to zero and set EMS_FRAME_LOCATION to NONE. Turning off EMS support saves a small amount of RAM.
2. Separated versus shared sessions
With Win-OS/2 it is possible to run several programs either in a shared or in separate sessions. Both modes have specific advantages and disadvantages.
When one uses separate, sessions a complete Win-OS/2 environment is started for
each session. Of course memory consumption is much higher than with shared sessions. On the other
hand a crash of one Win-OS/2 program won't lead to the others in the same session following
and crashing, too. In addition you can specify different settings for each of the separate sessions. This way it is
possible to run programs that require mutually exclusive settings at the same time.
3. Fonts
As for fonts recommendations for Win-OS/2 are basically the same as for "normal" OS/2.
Font management has been kept separate for OS/2 and Win-OS/2. So fonts that are registered to both systems are loaded again for every Win-OS/2 session and consume additional memory. On the other hand this offers the opportunity of installing only those fonts that are needed.
The Win-OS/2 settings also contain a WIN_ATM option that determines if the Adobe Type1 Font Manager (ATM) and thereby Adobe Type1 fonts will be available to a session. If WIN_ATM is set to ON, ATM and all registered Adobe Type1 fonts will be loaded upon start of the Win-OS/2 session. This is done again for each separate session! So if you e.g. use Aldus Pagemaker for DTP, a good idea is to only register additional Adobe Type1 fonts and to de-activate ATM for all programs that don't need the fonts, thus reducing memory footprint.
4. High CPU loads
One of the most pesky problems with many DOS and several Windows applications is that you can see CPU utilization go up to about 100% as soon as the program is started. This happens because DOS programs never had to share resources in the singletasking DOS environment and therefore the developers used constant polling for input, i.e. the software constantly asks the keyboard, the mouse and other devices "Do you have something for me? Do you have something for me?". In just a few seconds between key strokes, a program may poll the keyboard hundreds or even thousands of times. Then if you enter something and the application actually does work instead of waiting for input the CPU load drops and returns to 100% when the polling starts again. This effect can also be observed with badly written Windows applications like MS Money 2.0. Now you might ask "So what? What's the impact on the system?". Well, depending on the polling application it takes away CPU time from other processes, especially those running at idle priority, e.g. the SETI@home client or PMView's loading routine. This can lead to a situation where other programs won't be executed at all.
So what can be done about it? Well, this is a bit complicated since there are several methods and each one does work only with some applications. Some things can be adjusted by the session's settings.
There are two connected options called IDLE_SECONDS and IDLE_SENSITIVITY. After a program issues a request for input, OS/2 waits IDLE_SECONDS before it begins idle time detection. The standard value is zero, i.e. detection begins immediately. The second option specifies a threshold OS/2 uses to determine if a program is idle or not. If the application polls with a higher frequency than specified (in percent) OS/2 will consider it idle, reduce its CPU time and give it to other programs. So by lowering the threshold you should be able to take away some unused CPU time from polling applications.
You can also apply some brute force by setting DOS_BACKGROUND_EXECUTION to OFF. Now, as soon as you take focus away from the offending application and switch to another it is stopped and will only receive CPU time if brought to the foreground again. Of course it won't be able to do calculations for you in the background this way and the problem with taking away resources from background processes while the application is in the foreground still persist.
If the above doesn't work for you there is still some hope. Some people have written TSRs that can release CPU time from the session they run in. They are loaded by adding them to your AUTOEXEC.BAT file. Hobbes' /pub/dos directory and Peter Norloff's OS/2 BBS hold several of these helpers. Most have been written only for a specific application, but the ones called OS/2 Time Slice Releaser (OSTSR), F4_35_CA and TAME provide general services.
OSTSR only is of use for programs that are aware of DesqView, an old DOS multitasking extension software. OSTSR works by fooling DesqView-aware programs into thinking that they are running under Desqview. When such a program makes a request to return the rest of its timeslice to Desqview, the call is intercepted by OSTSR and is turned into a similar request to OS/2. You can specify the amount of CPU time that's released. Try using OSTSR 8. OSTSR is freeware.
F4_35_CA is a freeware tool by Veit Kannegieser. Try adding it to your AUTOEXEC.BAT file and start a DOS or Win-OS/2 application. If the scrolllock LED is turned on F4_35_CA can free some CPU time. See the accompanied file entpack.eng for documentation.
TAME does something different and is more like the OS/2 scheduler itself. It monitors the activity of a program running in its session. Upon detection of idle time, it releases CPU time to other sessions. Additionally, the next time its session gets CPU it will be less tolerant. TAME has lots of options, also containing some that can help to to determine the best settings. Documenting this is far beyond the scope of this article. You may however want to try invoking TAME by adding TAME /TINY /I 9 /TS OS/2 to your AUTOEXEC.BAT file. According to the documentation TAME is shareware (US$20). The last version I was able to find was 3.33 (the 3.34 I found contained the same files) from 1996, so I don't know if it still can be registered.
The programs can be used together. Also remember that you can specify different startup files for sessions using the DOS_AUTOEXEC option if you need different parameters for OSTSR or TAME.