Sfor

I think I got lost somewhere. According to my research, the Backup Exec was first the property of Seagate (1998), then it went to Veritas (1999) and then to Symantec (2005). I do not know where the StompSoft fits in the time table. Well the whole takeover table looks like that: 1982 - Maynard Electronics started. Maynard's software is known as "MaynStream." 1989 - Maynard is acquired by Archive Corp. MaynStream is available for DOS, Windows, Macintosh, OS/2, and NetWare. 1991 - Quest Development Corporation is independently formed to develop backup software under contract for Symantec. 1993 - Conner Peripherals acquires Archive Corp. and renames the software "Backup Exec". 1993 - Quest acquired rights to FastBack for Macintosh, and hired its principal author, Tom Chappell, from Fifth Generation Systems. 1994 - Conner creates a subsidiary, Arcada Software, by acquiring Quest and merging it with their existing software division. 1995 - Arcada acquires the SyTron division from Rexon, including their OS/2 backup software. 1996 - Conner is acquired by Seagate Technology and Arcada is merged into its subsidiary Seagate Software. 1999 - VERITAS Software acquires Seagate Software's Network and Storage Management Group, which included Backup Exec. 2005 - Symantec acquires VERITAS, including both Backup Exec and NetBackup (a completely different backup-software package).

Well. What I need is the access to the tape drive, so a simple backup application will not do. It is true the old Seagate Backup Exec runs on Windows 2000. The problem is, it does not detect tape drives on NT based systems. The built in Windows 2000 NTBackup is Veritas made. I do not know if it is the same as Veritas Backup Exec, but it certainly is completely different from Seagate Backup Exec shipped with Windows 98. Right now I'm investigating Turbo Tape 2.0.

I do have a dual boot Windows 98/2000 computer with a DAT tape drive on it. So far, I was unable to find a software able to replicate tape managemnt functions available in old Seagate Backup Exec built in Windows 98. The old Backup Exec is able to append new backups to an existing tape and continue on another tape, if there is not enough space. When restoring, it is necesary to insert just the tapes with particular backup set. So, it is possible to create an endless chain of tapes. With the Windows 2000 built in tape backup it is necesary to create multi tape backup sets. While restoring it is necesary to insert all the tapes beginning at the first one. So, if the particular files are located on the last tape, it is necesary to insert all tapes from the set. If the backup set is appended with another set of files, all the tapes have to be inserted while restoring the appended files. So, after appending a few files to 20 tape backup set, it is necesary to use all 20 previous tapes while restoring the appended files. I found quite a few backup applications, but almost all of them do need windows XP or better. So, there was no point in testing them.

The download speed is going up. with 256960 1.7MBps with 385440 2.3MBps, and thats all my Internet connection can handle.

Finally. I can see some improvement. The download speed went up from 460 to 940kBps on Windows 2000.

Well I did try the GlobalMaxTcpWindowSize="256960" as suggested in the Microsoft article, but it seems it does not affect the download performance in any significant way. I'm starting to believe the Windows 2000 has a hardcoded limit for TCP window size.

I decided to try to tweak the Windows XP, and the results were significant. At the beginning the download speed was around 460kBps. After applying TcpWindowSize="256960" the download speed went up to 2MBps. So, the TCP window setting is very effective in Windows XP, but for some reason, it doesn't seem to work with Windows 2000.

I did test all of these registry changes, already. According to my predictions some applications should stop working, after applying the patch. Also my Internet services provides a low latency Ethernet 100 Mbit connection. So, I'm not in this particular patch target group. The biggest problem is the "Tcp1323Opts"=dword:00000001" line. For some reason it causes WGET and PopTray to be unable to connect to servers. The Firefox 12 can not download files from some servers, as well. Also the "TcpWindowSize"=dword:0003ebc0" is problematic. I found some Microsoft article about bugs in the Windows 2000. The work around was to use values lower than 64240 with it, or to use GlobalMaxTcpWindowSize instead.

Started the experiments with TCPWindowSize. Apparently it does not seem to change anything by itself. On the other hand, the Tcp1323Opts can prevent some applications from working properly. Apparently Large TCP Window support is not 100% compatible. I heard about the TcpIP patch in relation with the Windows XP limit of half open connections, but I see no relation to Windows 2000, what so ever. --------------------------------- After a thought. For some reason the connections with proxy server can get much higher data rate, than direct connections with HTTP server. But I had no opportunity to make any tests with a remote proxy server, as I have no access to a sufficiently fast one. ----------------------------------------- I did test the registry tweaks from "Recommended settings for Windows 2000 / XP". The result was no change, at all. But, after setting TCPWindowSize below 64240 the download speed went down about 10%. I was unable to test the benefits of the Tcp1323Opts=1 needed for large TCPWindowSize, as both Firefox 12 and WGET are not connecting at all in such a case.

I found an interesting issue while testing download speeds from different computers with and without proxy. I did use the same server and file on it and the same 20/4 Mbit Internet connection. From Windows 2000/XP I can get up to 497kb/s, while from Linux (CentOS) it goes to 1,4Mb/s. What's more interesting while downloading from Windows 2000 using proxy server on the same Linux computer I did get over 1MB/s as well. The best results were with WGET, but the similar differences were visible in Firefox, as well. There has to be something slowing down HTTP downloads in windows 2000/XP, since it is possible to get around it by using proxy server working on Linux computer. Using a proxy on Windows XP did not increase the download speed and the result was almost the same as direct download. I used 3proxy, as it is available on both Windows and Linux systems.

I did perform the tests of the CacheFolder 1.0.1, and it was exactly the same as the copy command. After initial filling the RAM with cached files it was no longer able to store files in the system cache. What's more: - I was unable to make the CacheFolder work from the command prompt. It did work from the context menu, however. - The CacheFolder was significantly slower when reading files than copy command. So, the CacheFolder works exactly the same as the "copy /b filename nul" command, but slower. Right after the system boot it fills unused RAM with files it reads, but once the free space is filled, all it does is reading data from disk without any effect on the cache. I did another observation, however. After the initial filling of the free RAM with cached files, the file reading does not seem to affect the cache. On the other hand, file writes do affect the cache contents. In the experiment I did copy a file between the disk drives. After that the source file was not cached, but the target one did. I did perform the same test on the Windows 2000 professional. The cache works exactly the same as it was in Windows 98, there. I mean after initial filling of the free RAM the readed files are cached, always. The older and less accessed files are removed to make space for new reads. It seems the Windows XP removes older files from the cache, but only to store writes, not reads.

I'm experimenting with video playback benchmarking. Right now I'm trying to exclude the disk IO operations from the equation. It is possible to use a ramdrive of some sort, but it will be much easier for me to use some script putting a file in a disk cache, instead. The computer has 2GB of RAM and I'm working with files exceeding 1GB. Copying a file from one HDD to another works, all right, but it would be better to just read the file leaving its copy just in the system disk cache. In theory, It should give me ability to get the whole file in the disk cache. I've been experimenting with "copy /b filename nul" command from the cmd.exe. While it is effective in checking if the whole file is in the disk cache, it is not affecting the disk cache by itself. I do not know why, but reading a file with this command does not put the file in the system disk cache, in the same time it is able to read from the same cache. For an example, I did the "copy /b filename nul" command with the same 200MB file a few times. It always reads the file from the HDD. But, after copying the file with the Windows Explorer the same command always reads the file from the cache, and the HDD LED is off, completely. Well, the above observations have one flaw, however. The "copy /b filename nul" acts differently in a freshly booted system. A few first files read with the copy command are stored in the system disk cache. When there are no more unused memory, the cache does not accept any more files from the copy command. It looks like the copy command can affect the contents of the system cache, when there are still unused memory space. After that copy reads directly from the HDD. It appears the Windows XP disk cache works in a very different way, from what I saw in Windows 98. It appears different applications are interacting with the system cache in different ways. And thats something new to me.

I'm navigating through files on one of my computers with a wireless keyboard, only. Since no mouse is used, and the distance to the screen is quite significant I had to increase the font size significantly. But as a side effect the amount of text displayed in the Windows Explorer status bars is quite small. So, if I could remove or reduce the security zone field on the status bar, I would be able to see much longer tool tip text messages. Since the Windows XP does not seem to be able to report the durations and resolutions of .mkv and .mp4 video files in tooltips, I had to add MediaInfo utility. The problem is, it is not possible to reformat the tooltips it generates to fit the small amount of display space, I have. So, I'm looking for a way to increase the length of tool tip text strings in the Windows Explorer status bar. It is possible to display the tool tips outside of the status bar, but it seems to be less convenient, for me.

The simplest system is to make copies of Windows and Program Files folders. Quite often I do keep such copies, but with different folder names. In case I do need to switch between main and saved windows copies all I have to do is: - Boot to clean DOS - start a DOS based LFN driver DOSLFNMS.COM - Rename the windows and program files folders to some other. - Rename the backup folders to windows and program files. - Reboot the system. It is possible to do it with DOS batch, as well. If the computer does have a different OS installed, it is simpler to switch between windows copies by renaming the folders using the other OS. I'm often keeping a few different versions of Windows 98 while experimenting with drivers applicactions or hardware.

HP D530 does have some serious problems with Windows 98. 1) To get the USB drivers installed it is necesary to disable BIOS USB support. (Advanced - PCI Devices - disable all entries for USB controllers) With the legacy USB support the Windows freezes while installing the driver. It is posible to reenable the BIOS support, after driver has been installed. 2) The Intel SATA controllers are working very slow. No fix available 3) Integrated Broadcom gigabit ethernet adapter causes system to freeze during reboot or shutdown. The fix is not to bind TCP/IP stack with Microsoft Networking. After careful examination of the HP D530 I decided to move to HP DC7100 (almost the same, but with the Intel 915 chipset). I'd rather fight with PCIE graphics than work with slow hard drives.

The partition table in the extended partition has the same structure as the one in the MBR. So up to 4 logical volumes are possible in a single extended partition table. Perhaps some operating systems are able to take advantage of the endless chain of the extended partition inside an extended partition idea, but DOS is not one of them. So, Windows 98 will not, as well. DOS is not able to use two primary partitions in the same time, either. To sum it up, a theoretical endless possibilities are tied up by compatibility issues. I saw no good and reliable RW NTFS compatibility for Windows 98 driver, so far. That's why I'm sticking to the FAT32.

This particular partition stores archive video data. So, there are significant amount of relatively large files. On the other hand my driver collection sits on a 16GB partition, as there are a lot of relatively small files. The more files on a partition, the more time it takes for scandisk to do its job. In case of a "bad shutdown" only used partitions are scanned, so it is good to have a few partitions separating actual work from archives. In any case dividing a 2TB hard drive to large amount of small partitions requires many drive letters to be used. Another problem is, the classical DOS derived hard drive partitioning allows just one primary one extended and four logical partitions, giving up to 5 drive letters. I do not know how DOS or Windows 98 would handle more of them. In my particular case I'm using 9 drive letters on two hard drives (1,5TB and 2TB). Bact to the big partitions. Currently I'm using 3 of them. 0,99 TB on the 1,5TB drive. 733GB and 681GB on the 2TB drive. It would be easier to make just one huge NTFS partition, but it would mean no compatibility with Windows 98.

I did englare a FAT32 681GB partition to 733GB. The initial cluster size was 16k, now it is 64k. So, the EaseUS Partition Master Home Edition did change the cluster size, indeed. There is more. The EaseUS Partition Master Home Edition does not allow the cluster size change. So, there is no controll over the cluster size, at all.

While browsing Google I've found a thread about EaseUS Partition Master. An user was able to shrink a 2TB FAT32 partition down by about 600GB. It ended well, however the EaseUS Partition Master was very slow while doing the job. So, I decided to use this application, as it appears there is a version free for noncommercial use. It did the job, correctly. However it needlessly moved the entire partition data during the process. So, it took several hours to englare 670GB partition with free space right behind it. In any case, the EaseUS Partition Master requires Windows 2000 or newer. So, it is not a perfect choice for a Windows 98 user. It is slow, but effective, apparently.

So far I was able to test these Partition Magic 7 - can not resize FAT32 partitions larger than 256GB - can not create FAT32 partitions larger than 256GB + safe to manipulate smaller than 256GB FAT32 partitions + allows to adjust the cluster size GParted - can not resize FAT32 partitions larger than 256GB + creates FAT32 partitions larger than 256GB correctly - there are problems with manipulating FAT32 partitions smaller than 256GB EaseUS Partition Master Home Edition + can resize big FAT32 partitions - requires Windows 2000 or newer - no controll over the cluster size The Windows version of the Partition Magic 7 does allow to grow an oversized FAT32 partition, but it ends with application fault, when it comes to the actual job. There were no data loss in such a case, however. It seems the Partition Magic 8 is no longer available on the market, there are also some informations mentioning it is compatible just with up to 160GB hard drives. GParted had many versions, apparently. Some of them were able to resize FAT32, but some were not. Still I found nothing about ability to resize larger than 256GB FAT32 partitions in any version. I have no possibility to safely test all the available partition resize software. So, I'm asking for the solutions proven to work correctly with growing oversized FAT32 partitions on 2TB hard drives.

No, it is not. There are quite a lot of problems with PCI-E Nvidia 6x00 cards. The official drivers do have just partial support for these cards. On the other hand the AGP versions are working much better. What do you mean by user made drivers? The unofficial driver releases in most cases do not solve the shutdown problems, or DOS application compatibility issues.

Well. I found significant problems with DOS applications, when using GeForce 6600 cards. Apparently Ati x600 works much better in this particular area. Also, there are significant issues with GeForce 6200, depending on the card version. The ones with Turbo cache function will not work well, for sure.

I was very pleased with Matrox Dual Head card, as well. But, when I started to play with linux (Ubutu) it appeared the linux drivers do not handle Matrox very well. I was unable to force them to use the other monitor output on boot. So, I had to move to a Nvidia, as Ati seems to have issues with DOS mode switching.

I think this is a good reference to what graphic cards one can use in Windows 98: Compatible Hardware with Windows 9x

I was able to perform the final testing. I did move the two hard drives with both operating systems from HP D530 82801EB to HP DC7100 with 82801FB controller. Now the HDD performance in both operating systems is almost the same. 6.7GB was copied in 2m 51s in Windows 98, while it took 2m 40s in Windows 2000. So, Windows 2000 seems to be a bit faster, but the difference is many times smaller. The question remains. Why the HP D530 is so slow. Is it the 82801EB fault, or perhaps there is some other problem with this computer model?