SuperCharger Boosts Browsing Speeds Up To 3,000 Times Faster?



Environment: Internet, Network, VC++


Since at least the early 1990s, people have been using the “hosts” file on their computer to dramatically speed up Internet browsing and to very effectively block not only pop-up ads but ads in Web pages as well.

The hosts file is unusual in that it has NO extension as most files do. The IP address of a domain can be resolve either by looking in the hosts file or by sending out a DNS request to a Domain Name Server. Browsers typically send out 200 UDP packets, for redundancy, to determine the IP address of a single URL you type in, such as “” All computer platforms look in the “hosts” file first before asking a DNS name server to resolve it to an IP address. The file has a simple format, an IP address followed by the name(s) associated with it, and comments. For example: localhost # Goes to localmachine # Fantastic website!

The IP address means the “host computer itself.” Anything sent to this address never sends a packet on the network; it is handled internally and this technique for blocking domains by pointing them to the localhost goes back to the early 1990s, if not earlier. I have sold my Windows & Internet SuperChargerTM since 1996; it used a Hook into Winsock to find DNS lookups of ad sources, and it included a custom hosts file that was added to a user’s machine that includes the worst ad sites. And, you have been able to find literally dozens of programs providing custom hosts files to prevent pop-up ads and speed up browsing since the early 1990s.

The idea, not invented by me, but in use for over a decade is to add the domain names to the hosts file with the address of Your browser will attempt to connect to a Web server at port 80 on the local machine, and unless you are running a proxy server on that port, that Web address will be instantly blocked. The following describes HOSTS file entries:

  • A single entry consists of an IP address corresponding to one or more host names.
  • Entries are case-sensitive. Always assign multiple host names with different cases.

For example, to connect to the UNIX host ARCHIVE.RESEARCH.COM at the IP address, make two entries in the HOSTS file:  ARCHIVE.RESEARCH.COM

This way, a user can connect to ARCHIVE using a utility, whether or not the CAPS LOCK is enabled. A HOSTS file must reside on each system. By default, the host name localhost is an entry in the HOSTS file with the loopback address The HOSTS file is parsed whenever a host name is referenced. Names are read in a linear fashion. The most commonly used names should be near the beginning of the file. HOST file entries do not replace or interact with Windows-based NetBIOS computer names in any way. Our editor allows you to easily make entriesinto your Local Hosts File which you should re-install weekly to keep it properly updated.

Can It Boost Your Browsing Speed Up to 3,000 Faster?

If you believe this at face value, I have a bridge in Brooklyn to sell you! The average user will never get any speed increase even close to this! However, it is possible to create a Web page filled with a hundred ad sources pulling very large image files that will actually give you this much of an increase for such a page if you remove the ad sources. My background is MARKETING and I am world famous for writing some of the most famous and successful ads and television commercials in the world. My approach to writing software has always been to write the AD FIRST and then write the code for the program to legally justify the ad claims.

How to Find URLs of Ad Sources

In my original program many years ago, I wrote a Winsock Hook to find DNS lookups of ad sources then. But, for this article and demo I thought I would illustrate a more modern approach. Recently I saw an article called “Speeding up Internet Browsing” by Bill Nolde, in which he created a packet sniffer snooping for DNS lookups only to find the URLs of annoying ad sources. His Winsock code was excellent, but his samples require manual manipulation of the hosts file that would be difficult for a non-programer to do. This article and sample project incorporate the code by Bill Nolde that I modified and other enhancements to make an application that is more user-friendly.

The Winsock code presented in Bill Nolde’s sample used here employs raw sockets and Microsoft TCP/IP extensions to create what is basically a packet sniffer for DNS lookup packets. A raw socket is created that does implement setsockopt (IP_HDRINCL) to tell the system the IP header will be included in any sends or receives and binds this socket to a local IP address that is a necessary system with more than one ethernet adapter. The receive can only be done on one adapter, which one is determined by the IP address associated with it and specified in the bind system call. The WSAIoctl system call with SIO_RCVALL enables all packets received by an adapter to be read by an application. A separate thread is created to read and filter the packets with blocking recvfrom.

I modified Bill Nolde’s approach and added some additional features to create a program that a non-programmer can use. My first approach was to add a list control that would load the hosts file and I quickly learned how difficult a task this would be and eventually decided against it. I tested all of the samples of list controls on this and other Web sites; all of them plainly sucked at loading large amounts of data. As it turns out, a typical hosts file to block unwanted ads will have over 10,000 lines. That’s over 10,000 different sources of ads in one hosts file (see the default hosts file included with this project that has over 13,000 lines, or 13,000 ad sources to block!).

All of the samples of code for list controls on this website and other programmer’s sites completey sucked at loading 10,000 lines from a hosts file! I was able to find one person who wrote an article and actually solved this problem; his approach was literally 100 times faster than ever other posted sample of loading lists! His article was called “Virtualizing List Views to Handle Large Amounts of Data,” by Scott Driscoll. He used the LVS_OWNERDATA style that tells the CListCtrl that we are in charge of all memory handling. So, you never call CListCtrl::InsertItem() when this style is set. Every time the control needs to paint or display text, Windows will ask you for the text located at item, subitem (in the form of a LVN_GETDISPINFO message), which you supply. His implementation of this could load 13,000 lines of text in about 1/100 of a second while every other sample of code posted took well over 1 dsecond to accomplish this. You can use his technique to expand my sample here and allow users to edit the hosts file in a list.

I finally decided that it is not necessary to load over 10,000 lines of a large hosts file into the List Control. I initially tested the use of plain vanilla vector and host data structure as follows:

//Host struct
typedef struct _HostData {
  std::string sLine;
  std::string sDomain;
} HostData;
//Our vector of host data
typedef std::vector<HostData> HostVector;

But, this added complexity was too slow and unnecessary and I finally decided on using a “deque.” A deque is like a vector; it is a sequence that supports random access to elements, constant time insertion and removal of elements at the end of the sequence, and linear time insertion and removal of elements in the middle. The deque loads large host files significantly faster; I used it in this program as follows:

//Our deque
typedef std::deque<std::string> HostVector;

This approach gave the greatest speed and simplified the coding greatly.

Registry Adjustments

WARNING: Before using this software to make Registry changes, MAKE A BACKUP of your Registry’s original settings. The Windows CD comes with a free Registry backup utility.

The Internet SuperChargerTM makes it easy to “Tweak” your Dial-Up Network setting (DUN) by simply pressing the APPLY DUN SETTINGS button to install the Registry changes that are recommend AFTER you have made a backup of your registry! Reboot your computer for the changes to take effect.

The Registry in Windows is a structured file that stores indexed information describing the system’s hardware, user preferences, and other configuration information. The Windows Registry is a centralized database for information inserted by both the operating system and by applications. Physically, the Registry is a pair of binary files named USER.DAT and SYSTEM.DAT located in the Windows directory. USER.DAT contains user preferences for each person on the system. SYSTEM.DAT holds global system settings, such as a list of installed hardware devices. Both files have hidden, system, and read-only attributes to protect them.

Following is an explanation of the Options that you can set:

MaxMTU (Maximum Transmision Unit)

This is the default packet size that Windows uses to negotiate. When a connection is opened between two computers, they must agree on an MTU. This is done by comparing MTUs and selecting the smaller of the two. If the MTU is set too large for routers that are between the computers, these routers then fragment this information into a packet size that the router can handle. This fragmentation can double the amount of time it takes to send a single packet. Windows 95 has a built-in MTU Discovery that will adjust for this by sending out a packet that is marked as “Not Fragmentable.” Then, the router sends back an error to the computer saying that the packet was too large, and Windows 95 then lowers the MTU until there are no more errors. If your ISP uses an MTU of 576, every time you start a connection, Windows 95 must adjust down to this value. Even though Windows 95 automatically adjusts the packet size, it still takes it time to negotiate an acceptable MTU. By setting this value manually, you greatly reduce the amount of work that Windows must do to negotiate. NOTE: Negotiation always adjusts downwards the value you have set, never upwards. The Windows 95 default is 1500.

RWIN (TCP Recieve Window)

This parameter determines the maximum TCP receive window size offered by the system. The receive window specifies the number of bytes a sender may transmit without receiving an acknowledgment. In general, larger receive windows will improve performance over high delay, high bandwidth networks. For greatest efficiency, the receive window should be an even multiple of the TCP Maximum Segment Size (MSS). The TCP Receive Window size is the amount of receive data (in bytes) that can be buffered at one time on a connection. The sending host can send only that amount of data before waiting for an acknowledgment and window update from the receiving host. Matching the receive window to even increments of the MSS increases the percentage of full-sized TCP segments utilized during bulk data transmission. MSS is the MaxMTU—40 bytes for TCP and IP headers.

The RWIN default is 8192 bytes rounded up to the nearest MSS increment for the connection. If that isn’t at least 4 times the MSS, then it’s adjusted to 4 * MSS, with a maximum size of 64 Kb. With the Windows 95 default MaxMTU of 1500, the default RWIN is rounded up to 8760 (1460 * 6). You can greatly improve performance by setting this to a lower value such as 4 times your MSS (MTU-40). The idea is to bring it to a value below 8192. Many people have better success with 6, 8, or even 10* MSS. In some cases, however, manually setting the RWIN may decrease performance because it takes the control away from windows, and if the MTU is negotiated to a different value, the size of the RWIN is no longer a whole integer multiple. For this to be effective, you must make sure your MTU is set where it will not be negotiated to a lower value.

TTL (Time To Live)

Specifies the default Time To Live (TTL) value set in the header of outgoing IP packets. The TTL determines the maximum amount of time an IP packet may live in the network without reaching its destination. It is effectively a limit on the number of routers an IP packet may pass through before being discarded. TTL is a field in the IP that which indicates how long a packet should be allowed to survive before it is discarded. TTL essentially determines the maximum number of hops permitted. The Windows 95 default is 32, but with the Internet growing larger all the time, it is worth changing it to the larger setting of 64.

Session Keep Alive

Specifies how often to send session keep alive packets on active sessions. This will keep connections that have stalled during a particular download session from timing out. The minimum is 1 minute. The default is 60 minutes.

Local Domain Name Lookup

We expand the range of DNS lookup automatically for you when you use our Internet SuperCharger!

Auto Discovery

What are the AUTO settings? PMTU (Path Maximum Transmission Unit) Discovery is detailed in RFC 1191. It is a method for allowing two hosts to negotiate the size of the MTU by exchanging their Maximum Segment Size (MSS) values. MTU = MSS +40. Selecting this option causes TCP to attempt to discover the Maximum Transmission Unit (MTU or largest packet size) over the path to a remote host. By discovering the Path MTU and limiting TCP segments to this size, TCP can eliminate fragmentation at routers along the path that connect networks with different MTUs. Fragmentation adversely affects TCP throughput and network congestion. Setting this parameter to 0 causes an MTU of 576 bytes to be used for all connections that are not to machines on the local subnet. Enabling this setting causes TCP to attempt to discover the Maximum Transmission Unit (MTU or largest packet size) over the path to a remote host.

By discovering the Path MTU and limiting TCP segments to this size, TCP is supposed to be able to eliminate fragmentation at routers along the path that connect networks with different MTUs. This requires implementation of the corresponding server side algorithm, however, and presupposes all of the servers on the entire Internet only running MSFT server software with server-side optimization features accessible from MSFT Web-browser client software. Needless to say, this is rather unlikely. Nevertheless, it is not recommended to disable this setting as it would then cause an MTU of 576 bytes to be used for all connections that are not to machines on the local subnet. Disabling this setting can cause severe performance degradation because fragmentation may not be compensated for. PMTU Auto Discovery is enabled by default.

Black Hole Detect

Selecting this parameter causes TCP to try to detect “Black Hole” routers while doing Path MTU Discovery. A “Black Hole” router does not return ICMP Destination Unreachable messages when it needs to fragment an IP datagram with the Don’t Fragment bit set. TCP depends on receiving these messages to perform Path MTU Discovery. With this feature enabled, TCP will try to send segments without the Don’t Fragment bit set if several re-transmissions of a segment go unacknowledged. If the segment is acknowledged as a result, the MSS will be decreased and the Don’t Fragment bit will be set in future packets on the connection. Enabling black hole detection increases the maximum number of re-transmissions performed for a given segment. This specifies whether the stack will attempt to detect Maximum Transmission Unit (MTU) routers that do not send back ICMP fragmentation-needed messages. ICMP (Internet Control Message Protocol) is defined in STD5, RFC 792.

With this feature enabled, TCP will try to send segments without the Don’t Fragment bit set if several re-transmissions of a segment go unacknowledged. If the segment is acknowledged as a result, the MTU will be decreased and the Don’t Fragment bit will be set in future packets on the connection. Enabling black hole detection increases the maximum number of re-transmissions performed for a given segment. Setting this parameter when it is not needed can cause performance degradation. However, if the router is not sending back the ICMP messages, then PMTU Discovery will not work. This can cause an even greater loss of performance. PMTU Black Hole Detect is disabled by default.


The parameter controls how often TCP attempts to verify that an idle connection is still intact by sending a keep alive packet. If the remote system is still reachable and functioning, it will acknowledge the keep alive transmission. Keep alive packets are not sent by default. This feature may be enabled on a connection by an application.


This parameter determines the interval between keep alive re-transmissions until a response is received. After a response is received, the delay until the next keep alive transmission is again controlled by the value of KeepAliveTime. The connection will be aborted after the number of re-transmissions specified by TcpMaxDataRetransmissions have gone unanswered.

Note: The author’s company, William SerGio & Co., Inc., owns all rights, including trademarks and copyrights to the artwork in this article and demo and to the names Windows & Internet SuperChargerTM, SuperChargerTM, and SpeedDTM. You may NOT use or distribute these copyrights and trademarks in any way or form without the express written consent of William SerGio &Co., Inc. Further, the author does NOT warranty that this code or software is fit for any purpose or use whatsoever, and does NOT make any claims of any kind for this code or software.

If you have any questions about this article or source code, please feel free to contact me. I have over 100 commercial software programs that you can purchase the source code for, as well as numerous systems for displaying advertising, with the user’s full, informed consent, on millions of computers.

Download Latest Version of SuperCharger from my own Web site.

Bill SerGio, The Infomercial KingTM
[email protected]
[email protected]


Download source code and demo project – 271 Kb

More by Author

Must Read