Sfor

It looks like you have some problems with bindings in the PROTOCOL.INI file. Here is mine for the reference. [ndishlp$]DriverName=ndishlp$Bindings=ATL2$[protman$]DriverName=protman$priority=ndishlp$[data]version=v4.10.2222netcards=ATL2$,ATHEROSL2[NETBEUI$]sessions=10ncbs=12DriverName=NETBEUI$Lanabase=6Bindings=ATL2$[ATL2$]DriverName=ATL2$

Well. I did use the Microsoft Networking in plain DOS, before. While using 16bit DOS drivers it was possible to boot just to the DOS, run the net start, and there was the DOS networking without the GUI. It worked with Windows 95, as far as I remember.

I just remembered something. Windows 98 does driver file copying every time something is changed in the protocols or bindings in the network settings dialog. So, the drivers do not have to be copied during network adaprter adding, sice they will be copied after bindings with network protocols are made.

No, I do not. But Windows loads it by itself, anyways.

There is nothing network related in my Config.sys file. Also. It should be possible to boot just to the DOS prompt, then to start the DOS drivers with net start command. By doing so it should be possible to see all DOS driver related error messages.

There is a significant difference here: devdir=1:E1000.dosdevdir=?:l2.dosThe both INF files seem to have a different syntax. I see no meaning in the [PCI] section, as it was not defined earlier. Are you sure it is a proper Ndis2 driver? In my case the package contains 4 files: ATHEROSL2.NIF l2.dos OEMSETUP.INF PROTOCOL.INI

Here is how my .INF file looks like: ;ATHEROSL2 OEMSETUP.INF File:[netcard]ATHEROSL2="Atheros L2 Fast Ethernet Adapter",000,ndis,ethernet,real,ATHEROSL2,ATHEROSL2_nif[ATHEROSL2]devdir=?:l2.dosdevice=l2.dos,@devdir\l2.dos[ATHEROSL2_nif]drivername=ATL2$param=ETHERID,"Node Address",chars,13,"@000000000000",0x02

In case of my Eee PC device manager there is a disabled entry with "PCI Ethernet Controller" that should stay disabled. This one is the detected by Windows PCI device. It is not used, since the NDIS2 driver is used instead. The NDIS2 driver entry says "Atheros L2 Fast Ethernet Adapter".

Well, the driver files for a Ndis2 network adapter are mostly in DOS mode. The Device Manager can only show NDIS.VXD, as there are no more related 32 bit files. In order to check if the 16 bit DOS mode drivers are present it is necesary to use "mem /c /p" command. There should be PROTMAN, NDISHLP and Ndis2 driver modules on the list. If the binding went well, there should be an an information in the properties of the network adapter in device manager. Something like "this device is working correctly". If some device drivers reported an error condition, an exclamation mark should appear and a message saying "it is not possible to load device driver" (or something like that). That said, everything will work like I said if the bindings in the protocol.ini file are correct. If the bindings were not made properly, and there are no drivers listed there, they will not be loaded, and there will be no error message in the device manager. Since the NET start command was missing, it is possible something went wrong with the protocol.ini file parsing. Also, all the network adapter settings are made through the protocol.ini file entries. It could be a MAC setting, hardware address, IRQ or link speed.

First of all there is no need to edit the autoexec.bat or config.sys files, when adding a ndis 16bit network driver in the Windows 98 OS. Windows will do all by itself. But to be more specific only autoexec.bat will get added a "C:\WINDOWS\net start" line. The rest will do the net command. The way to get a NDIS 16bit driver added is: (I will have to translate from Polish Windows 98 to English, so there could be some differences. Well, it should be something like manually adding a network adapter.) 1) Open network neigbourhood parameters/settings? 2) Click Add 3) Select Nework Adapter/Card and click Add 4) In the first list (Manufacturer) it should be a second line from top, I think (recognized driver or something), in second list (Network Adapters) there should be just two entries a Ndis2 driver related entry and ODI related entry. Select the one for NDIS and click "From Disk" button. 5) Now is the time to show where is OEMSETUP.INF file located. 6) Then Windows should copy the drivers then modify it's config files by itself. All the network drivers are loaded with the "C:\WINDOWS\net start" from autoexec.bat. The protman and other Ndis2 drivers will be loaded by the net command according to the PROTMAN.INI file bindings.

I bought a VERITAS Backup Exec CD on Ebay. It was distributed by Dell, apparently. There are Seagate Backup Exec for Windows 95/98/NT 4.01b (SRS) and Veritas Backup Exec for Windows 2000 4.4 (NDR) on the CD. I did install the Veritas Backup Exec from the disk, but the Windows 2000 died after the reboot. --------------------------------------------------------- After restoring the system from a copy, I was able to install the software. Everything seems to be working fine, now. I did experiment with other tape software and UURollup on the deceased system copy. So, there could be some sort of a conflict. In any case, it is wise to be careful, when installing Veritas Backup Exec, apparently.

I did some research. It appears, the Veritas sold Backup Exec Desktop to Stompsoft, which was renamed to Backup My PC. With Backup My PC 5.0 the compatibility with backups made by older versions was broken. So, the best choice would be some version of Veritas Backup Exec Desktop, or Stomp Backup My PC version below 5.0. Now the biggest problem is, both Veritas and Stomp are gone. How one can obtain this particular software?

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.