mjf@cunixb.cc.columbia.edu (Michael J Flory) (04/19/91)
Pardon me if I am discussing a question previously discussed; I have not followed this newsgroup up to this point, though given the problems I have suddenly begun to have with Windows, I think I will do so! (I have browsed the last 170+ messages, which are what's on our sys, and the FAQ.) I seem to have uncovered a serious problem in the shelling-out function of Win 3.0. I use Win 3 in 386/enhanced mode on a 386 with AMI BIOS, 4 MB RAM, and PC DOS 3.30. I have (and need) quite a few drivers that load from CONFIG.SYS, and I use the Windows HIMEM.SYS, SMARTDRIVE, and RAMDRIVE.SYS. I use a VGA monitor in 16-color normal-res mode. I use FASTOPEN. My shell is specified as COMMAND.COM, and my COMSPEC is set to it. I've expanded my environment to 1024 bytes. I load XTREE GOLD 2.0 automatically when I boot Windows. I first noted shelling problems when I tried to launch applications from within XTREE. I often was told that the app had violated system integrity, etc. I will confess that I did not usually exit windows, reboot, etc. But these apps ran fine under XTREE outside of Windows, and even ran well in Windows outside of XTREE. As you may have guessed, I don't like the File Manager. I especially dislike the disk-copy routine with its layers of "Are you sure?" messages. So I have made backup disks with DISKCOPY in a DOS shell. But as for some reason (probably related to the hordes of drivers) I only get about 256K with the DOS shell that is included in the Main window. So I set up a PIF with a request for 640K if available to call COMMAND.COM. I ran DISKCOPY within it. Yesterday I double-checked the directory of a backup disk and found files missing. I did a DISKCOMP and discovered a very regular pattern of errors in the disk made by DISKCOPY: four (or sometimes three) cylinders in a row would not compare, then all OK until 28 cylinders later, then the same pattern. But (here is the horror) DISKCOPY had reported nothing wrong, despite my setting of VERIFY to ON. I do not know how many bad backups I've made in the past few months! I stripped my system to the bone, loading just GRAPHICS from the AUTOEXEC and HIMEM, ANSI, and MOUSE from CONFIG.SYS. Then I started to experiment. I found that I had an old (Win 2) PIF for XTREE in the XTREE directory, and despite the fact that I listed a batch file in WIN.INI for loading XTREE, when the batch file called XTGOLD, Windows used the OLD XTGOLD.PIF. I up- dated the PIF, using the new one XTREE provides, and which asks for more memory. I stopped getting application-violation errors when shelling out from XTREE from within WINDOWS. Now I just get out-of-memory errors. :( This also caused the DISKCOPY problem to disappear. I reloaded the system. The DISKCOPY problem reappeared. I finally tried, out of desperation, cutting the winmemsize parameter to 512K (in the WIN.INI file). The DISKCOPY problem disappeared, finally, when I cut both the winmemsize parameter AND the amount of memory my COMMAND.PIF asked for. There seemed to be a maximum TOTAL memory that they could request -- around 900K or less. But of course the advantage to having all that DOS memory in the shell was eroding -- it now took 8 or 10 disk-swaps, not just 6, to copy a 1.44 Meg floppy. I noted that when I ran a memory check (CHKDSK, MEMTEST, whatever) I often got a total memory that was greater than the memory that my PIF had requested. So I am forced to conclude that (1) there is a difference between the amount of RAM that Windows allocates to a virtual 8086 process and the amount that it actually gives it (it gives it less, or some of the memory it is given is inadvertently shared with other processes); (2) DISKCOPY (or COMMAND.COM) does not check properly how much RAM really is available, and just uses all that it can (hence the cyclic error on the DISKCOMP: every time the top area of the memory used by DISKCOPY was hit, DISKCOPY went on blithely loading bits into the ether); (3) DISKCOPY ignores the setting of VERIFY; (4) The memory limit results from something about how much base memory is avail- able, as when I cut the SMARTDRIVE memory, etc., the problem persisted. Has anyone else encountered such problems? I should mention that I checked the integrity of DOS and Windows executables, scanned for viruses, etc. Thanks very much for any advice! Michael Flory (mjf@cunixb.cc.columbia.edu)