CompuServe Thread

Greg – I'm able to answer the first part. If you use the -dem switch, then the .EXE is demand paged loaded from the disk at start up. This means that more and more of 3DS will be sucked into memory as you use various portions of the program. My tests show about 60% of the 3DS code is loaded at startup, so using the -dem switch may help reduce load times a little. Now, the rest depends on other switches. If you are over a net and 3DS is on the server, you SHOULD NOT use the -dem switch, but should use the -nopgexp switch. This causes all of 3DS code to be read into memory, and then written to the swap file if it needs to be paged out (which better be on the local drive by using the -swapdir switch!) If running locally, there is no reason to use the -nopgexp switch unless you have a faster drive for swaping. If 3DS needs to swap out code, unless the -nopgexp switch is used, the code is NOT written to the swap file. It is simple marked as missing. When it is later needed, it is simply read from the .EXE file again. I recommand using the -nur switch along with the -noswfg switches. The -noswfg helps keeps the swap file smaller but may cause some swapping operations to take a little longer. Fast harddisk and a small diskcache will basically remove the overhead. The -nur switch tends to give a better use of memory when heavy swapping occurs. If you are swapping extensivly, reducing the -vscan value will help the VMM make a better decision. Try -vscan 10000 or -vscan 8000. A little known trick is to set the environment variable DOSX to one or more of these values, much faster than reconfiguring each time. For example: SET DOSX=-vscan 8000 -nur -noswfg -nopgexp -swapdir c:\swap The DOSX environment variable overrides any Phar Lap setting in the software set by cfig386. Good luck – Jack Bayt – Vibrant