Mark Minasi's Windows Networking Tech Page
Issue #67 February 2008

Document copyright 2008 Mark Minasi; please see below for info on subscribing, unsubscribing or copying portions of this text.

What's Inside

  • News
    • New Installing, Managing and Troubleshooting Windows Server 2008 seminar is coming to DC, Chicago and Dallas in March
    • I've got six sessions at TechEd US 2008
    • The scoop on the three upcoming Mastering Windows Server 2008 books
  • Tech Section
    • A Quick Look at Your Vista SP1 Install Options
    • Vista and 2008's New TCP Windows
  • Conferences
  • Bring a Seminar to Your Site
  • Special Discount for European On-Site Clients
  • To Subscribe, Unsubscribe, Read Old Newsletters or Change Your Email Address


Hi all —

In the process of preparing some material on Server 2008, I got a chance to look at what Microsoft's done to TCP -- and I think you'll find it interesting.  In this newsletter, I'll shine some light on what has been a somewhat cloudily-lit subject and help you figure out if the new Vista/2008 stack can improve your networking.  But first, a word from our sponsor...

New Installing, Managing and Troubleshooting Windows Server 2008 seminar is coming to DC, Chicago and Dallas in March

After a five year wait, Microsoft ships Windows Server 2008 on 27 February 2008.  It's the biggest version of Server ever (which, I realize, is pretty much "by definition" for any new version of Server, granted) and it brings lots of changes... so it's time to learn about it!   Whether you intend to roll out Server 2008 immediately or in three years, you need to know exactly what benefits, challenges, and opportunities this latest version of Server offers.  You could download a small mountain of white papers (mostly written based on Beta 3 and thus are only partially correct), and spend a few weeks testing it to discover the hundreds of changes that 2008 brings... or you could come spend a couple of days with me.  I'll tell you and show you what's changed from Server 2003 to Server 2008 — the good, the bad, the wonderful and the awful ... with a chuckle or two thrown in.  I'll be in Dallas (well, Plano, actually) on March 6 and 7, the Washington, DC area March 11 and 12, and Chicago (near O'Hare) March 27 and 28.  You can get all the scoop at   I hope to see some of you there!

I've Got Six Sessions at TechEd US 2008

As usual I pitched the TechEd folks a lot of sessions and feared that I'd only get one... but I got lucky and am delivering six sessions:

  • Understanding IPv6:  A Guide for the Reluctant
  • CompletePC, Inside Out:  Using Vista and 2008's Disaster Recovery Tool
  • Windows Logons Revealed:  Everything You Must Know About Kerberos
  • Vista's SP1, from A to Z
  • Going Cold Turkey on the GUI:  Server Core Step By Step
  • DNS 2008 Style: Name Resolution with Server 2008

If you'll be in Orlando this June, please consider attending a few (or all) of my sessions!

The Scoop on the Three Upcoming Mastering Windows Server 2008 books

Many of you have asked me about what's going on with my Mastering Windows Server 2008 books — and yes, it's "books," three of them.  They're coming, I promise, and you can read more about them at  

Watch My "Living the Longhorn Life" Presentation in  Barcelona

One of the last times I did my 2008 overview talk was at TechEd Europe, and Microsoft recorded it and put it up on their site.  You can see it at:

They claim that you may have to sign up for it (I didn't when I tried the link), but if so, it's free.

Tech Section

One quick note on your SP1 options and an in-depth look at the new TCP stack changes in Vista and 2008.

A Quick Look at Your Vista SP1 Install Options

You may know that Vista SP1 is finally out. What may be confusing is that it's got more installation flavors than Baskin-Robbins has ice cream.  As I understand it, everyone on the planet will be able to download it as of 27 February but I got mine a few days early because I'd beta tested SP1.  Here's what I've found about the different ways to install SP1.

First, there's the Windows Update route.  If you've got a Vista box that gets its updates either from Windows Server Update Services (WSUS) or from Windows Update/Microsoft Update, then your system will get SP1 automatically in the next few weeks.  If you can't wait, or if your systems aren't connected to the Internet, or if you just want to do things your way, then I found three different downloads, each with names that were somewhat less than useful and that all will allow you to apply SP1 without the need of an Internet connection.

"Windows Vista SP1 RC Refresh for X86 and X64 UPD 5 Languages" contains two downloadable EXEs, a 450 MB (the 32 bit SP1 installer) and a 750 MB one (the 64-bit installer). Run the appropriate EXE from your command line and SP1 installs. Just for chuckles, I disconnected my system from the Internet and the upgrade worked fine.  (I was also a bit worried that the random number generator in Windows Genuine Advantage would decide that my copy of Vista wasn't legal, but no problems in that department -- not a squawk from the licensing component.) The "RC" may not be in the name that you see when SP1's public, but it doesn't matter:  as it turns out the final release candidate was so clean that they didn't need to do anything to it other than mark it "final" and release it.

"Windows Vista SP1 RTM Standalone ISO for x86 and x64 Five Languages" is the same two EXE files, but packaged as a DVD ISO. It adds an autorun.inf and setup.exe to spare you the complexity of knowing whether your system is 32 or 64 bit.<g>

"Windows Vista SP1 Client for X86 and X64 English and German" contains two 3+ GB ISOs. They are the 32 bit and 64 bit ISOs that replace the current Vista installation DVD images. These aren't for upgrading an existing image (although I suppose it's possible, given that Vista's always had an "upgrade" option) but instead for installing new Vistas with SP1 from the beginning.

Everything worked out fine in my SP1 install except a message that Windows couldn't use thunk_16.exe -- which is surprising, as it NEVER could in the first place. I hope this makes things easier for others installing SP1!

Vista and 2008's New TCP Windows

Nope, this isn't about IPv6 -- that's the new IP; I'm talking here about the new TCP.  How new?  Well, in some ways, not very new at all, as it implements a standard created in 1992.  But that's not to say that Microsoft hasn't been supporting that standard, and thereby hangs the tale...

TCP is the piece of the Internet networking software that takes care of what might be called the "conversations" in Internet communication.  For example, when my email server sent the notice of this newsletter to your email server, they first set up a sort of conversation, where they agreed about how to communicate with one another.  One of the things that the receiver and sender must agree upon is the size of the "TCP receive window."  That's a bit of RAM set aside on the receiver, a buffer where the receiver can hold onto data that it has received from the sender but hasn't yet had time to handle.  (Incoming data must be checked for transmission errors and then the data's got to be picked up by its destined application.  So, for example, if my email server were receiving a stream of TCP data, then that data's got to be checked for transmission errors -- the TCP software in Windows does that -- and then that data's got to be retrieved by the SMTP software on my email server.)  Every TCP connection has its own separate window, so you're allocating RAM every time you connect to a Web site, or when grab your email or the like and, similarly, you free up a bit of memory every time you close a connection.

But how much RAM to set aside for these TCP windows?  As I see it, there are four major factors that determine the TCP window sizing process.

  • RAM's not free:  first, of course, there's the matter of RAM and the amount you're willing to burn for each TCP connection, so TCP windows shouldn't be any larger than necessary. 
  • Line speed:  faster links mean that the sender can transfer more data more quickly across a noise-free, delay-free Internet connection.  But if you've got a small window, then that fast connection will cause the sender to fill up the the receiver's TCP window quickly.  The sender knows the size of the receiver's window, and so senders will stop transmitting once they calculate that they've filled up the receiver's window, waiting for the receiver to tell it, "I've cleaned out my TCP window, please send me more."  That sort of wait means precious Internet bandwidth goes to waste, and the concomitant bad Net karma can really stack up that way.  A bigger TCP window means that the sender can keep shooting that data down the line even if the receiver's too busy to respond for a second or two.  In short, a small TCP window can cause you to lose a lot of the benefits of a fast connection.
  • Application speed:  how fast is your downloading software?  If you're downloading some huge file like, say, Vista SP1, then Internet Explorer's going to busy watching your TCP receive window, waiting for your TCP software to perform error checks on the data so that IE can then grab that data out of the buffer and dump it onto the hard disk, clearing space in the buffer.  But IE competes for CPU time with other processes running on your system.  In other words, you'll transfer files over the Internet faster if you don't do anything on your computer but download files.  But that's silly — isn't the whole point of downloading big files to have an excuse to play a game for a couple of minutes?  Well, okay, maybe not the whole point, but seriously:  doing something else while downloading, whether it's opening a Word file, watching an already-downloaded video (educational, of course), or listening to a tune takes CPU power away from the target application (IE) whose job at the moment is to keep that TCP window empty so that your system doesn't have to tell the sending system, "hold on a minute while I catch up."  One way to make IE's job easier is, again, to only run IE.  Another way is to simply allocate a bigger TCP window, so that your system has a bit of slack for the occasional moments of high CPU utilization.  In short, big TCP windows mean less worrying about how much CPU your client application's getting in comparison to other processes.
  • Round-trip time (RTT) delay: the speed of every "conversation-oriented" type of communication (like TCP) is, of course, largely determined by the line speed — everyone knows that downloading a file on DSL is faster than downloading it on dial-up, right?  Well, not always.  Any time one computer asks another computer a question and awaits a response, there are always delays.  For example, if the receiving computer said to the sender, "okay, I'm ready for the next block of data," then the sender might have go get that data from its hard disk, and that's a delay that has nothing to do with line speeds.  Or the traffic between receiver and sender might have to go through a few high-traffic, overworked routers who slow things down a bit.  Or there's always the speed of light as a limitation.  For example, if a client talks to a server over a geosynchronous satellite link, then the client's request has to travel 22,300 miles up to the satellite, and then down 22,3000 miles to the server.  Then, when the server sends back its response, that response has to make that 22,300 miles up / 22,3000 miles down trip.  Thus, that communication traveled over electromagnetic waves for at least 89,200 miles.  The speed of light is only 186,000 miles per second, meaning that there's a round-trip delay on a satellite line of about a half-second, on top of any line speed issues.  When round trip delays get big, then you'll want bigger TCP window sizes... but that'll require some more explanation.

TCP Window Sizes Pre-Vista/2008

When DARPA first invented TCP/IP, the standard specified that a TCP receive window could be no larger than 64K.  In a day where most of the Internet ran on 56K leased lines with the really big traffic running over T1s, 64K did the job just fine... but that day didn't last very long. In 1992, RFC 1323 modified the rules for TCP/IP, expanding the maximum window size by adding the notion of a "scale factor."  Or, more specifically...

Pre-RFC 1323 TCP stacks had 16 bits set aside to declare their desired TCP window size. Two to the 16th power is 64K, and that's why pre-RFC 1323 TCP windows couldn't exceed 64K.  RFC 1323 expanded the possibilities by adding another byte (I'm simplifying) to act as a "scaling factor."  The byte can contain any value from 0 to 14 like so:

  1. Start with the original 16-bit window size.  Call that "BaseWindowValue."
  2. Call the scale factor "ScaleFactor." (Why not, eh?)
  3. Compute another value "Multiplier" which equals two raised to the power "ScaleFactor."
  4. The requested TCP window size is then BaseWindowValue multiplied by the Multiplier.

For example, suppose BaseWindowValue is 1024, and ScaleFactor is 7.  What TCP window size does that mean we're requesting?  Well two to the 7th power (7 is the ScaleFactor, recall) is 128.  128 x 1024 = 131072.  Notice that ScaleFactor never gets larger than 14; two to the 14th is 16,384, and the maximum BaseWindowValue is 65,535.  16,384 x 65,536 = 1,073,725,440, a gigabyte.  Thus, RFC 1323 allows for TCP windows of up to a gigabyte... but given that TCP receive windows get carved out of my RAM, I don't think I'll be using values that big for some time.

The early (1994-ish) Microsoft TCP/IP stack, however, only supported TCP window sizes up to 64K.  If memory serves me right, Microsoft addressed that around 1998 in one of the service packs for NT 4, and also in Windows 98's TCP stack.  The new stack supported a pair of Registry entries named "TcpWindowSize" and "GlobalMaxTcpWindowSize" that let you instruct Windows to use a window larger than 64K.  Microsoft says that the late 90s TCP implementation also created larger-than-64K blocks based on line speed:  if TCP sensed high bits per second on a transfer, then it would try to make the window larger.  Windows 2000, XP and 2003 used the same arrangement for window sizing, a combination of the TcpWindowSize Registry parameter and the line speed.  (Before you ask, I have not seen the exact algorithm explained, sorry, and in truth my Network Monitor tests at the time never showed TCP windows larger than 64K without the Registry fiddling.) With Vista and 2008, things changed.  But in order to understand that, let's return to that RTT thing.

Round Trip Time Delays Examined

I said before that RTT could cause a DSL line to be almost as slow as dial-up.  What was I talking about?

On local area networks or on many WAN links inside North America, the round trip delays are small, usually under 50 thousandths of a second (50 ms).  On networks like that, RTTs don't figure heavily.  But communicating across satellites, borders, oceans or even some complex corporate networks can introduce RTTs in the hundreds of milliseconds.  So let's do a simple exercise to see how RTTs can affect throughput.  (It's an exaggerated example to make the math easy, but I think it'll be helpful nonetheless.)

Suppose we're communicating over a line with a 1000 ms RTT -- in other words, if my PC (call it MarkPC) sends a TCP packet to a distant machine (call it RemotePC), then from the time that RemotePC gets my data to the time that it responds to me is always one second.  Let's also assume that my link to RemotePC is one gigabit per second.  (Yes, you read that right.  You know what they say: reality is for people who can't handle fantasy.)  Finally, let's say that RemotePC and I have negotiated a TCP window size of 64K bytes.  Okay, here's the question:  what is the absolute best data transfer rate that I can accomplish?

We can keep the math easy by computing our throughput in kilobytes per second and by transmitting only 64K bytes.  Transmitting 64K bytes means transmitting 64 x 8 or 512 kilobits..  The line speed between me and RemotePC is 1,000,000,000 bits per second, and I'm transmitting about 500,000 bits, so that would take 500,000 divided by 1,000,000,000 seconds, or 0.0005 seconds.  Once the data's there, RemotePC has to think about it for a second before responding.  When it responds, it's just saying "it got through okay" or "it was damaged upon receipt, please re-send," and there are very few bytes in those acknowledgment messages, so we can skip the amount of time required to transmit them.  Result:  the time required to transmit 64K —  the most allowed by RemotePC's desired TCP window size -- is one second (RTT) plus 0.0005 second (time to transmit across the line), or 1.0005 seconds.  Thus, despite having an imaginary one gigabit-per-second link, our actual throughput was a mere 64K/1.0005 bytes/second or 64 Kbytes/second, rounded to the nearest K.

Now let's do the computation again at something more realistic, like a megabit per second.  Original transmit time is now 500,000 bytes transferred at about 1,000,000 bits per second which is 1/2 second, and round trip time is still one second for a total of 1.5 seconds.  TCP window's still 64K bytes, so the overall transfer rate is 64K/1.5 = 43 Kbytes/second.  Different, yes, but still pathetic.  As you can see, even having an infinite line speed would still net us no more than a data transfer rate of 64 Kbytes/second.  In this example, the binding constraint on throughput isn't the line speed, it's the size of the TCP window.  Nor is my example unreasonably exaggerated — again, transcontinental RTTs above 500 ms are not unusual and they are always the case on satellite links.  To exploit our imaginary high-speed, high RTT delay system to its maximum, then, we'd do best to increase the TCP window size.

The Vista/2008 Difference

The point of that calculation was to show that the approach taken by the late 90's TCP Windows software — to adjust the TCP window size based solely on line speed — wasn't very optimal.  That's why Vista and 2008 adjust their TCP window sizes based on three factors:

  • Line speed, as before: faster line speed leads to larger windows
  • RTT delay:  longer RTT delay leads to larger windows
  • Application delay:  if the application that the data is intended for is slow to empty the window, then Windows will create a larger window

But that's not all that the new window sizing algorithm does.  First of all, by default Vista/2008 will not allocate a TCP window size larger than 16 MB.  And, second, pre-Vista versions of Windows used the same TCP window size on all connections.  Given that (for example) many systems have both a wired Ethernet connection and a wireless network connection, and given that a wired Ethernet connection and a wireless connection would almost certainly have different line speed and RTT delays, it's a welcome change to hear that Vista and 2008 do separate TCP window size computations for each connection.

Controlling the Window Resize Algorithm

With Vista and Server 2008, the old TcpWindowSize and GlobalMaxTcpWindowSize Registry parameters are now ignored, but you can exert some control over how Vista/2008 choose their TCP window sizes.

First, you can tell Vista/2008 to fix the maximum TCP window size at 64K by opening an elevated command prompt and typing

netsh int tcp set global autotuninglevel=disable

Why would you do this?  Well, when TCP was first invented, its packet format had 16 bits assigned to hold the TCP window size.  (Recall that two to the 16th is 64K, which explains the 64K maximum TCP window.)  When RFC 1323 came out, it couldn't rearrange the format of the TCP headers — that would have created a compatibility nightmare — and so RFC 1323 added 24 bits (yes, binary values of 0 through 14 could have fit in one byte, but they needed the other two bytes to keep the TCP overhead data intelligible), but in a different location.  Because of backward compatibility concerns, the extra 16 bits isn't called "the rest of the TCP window size" but instead the "scale factor."  Thus, routers can look at TCP window negotiation requests and say "ah, no scale factor, so it's under 64K," or "ah, a scale factor larger than zero, so I'd better behave in an RFC 1323 mannner."

Now, you'd think that by now every router running in 1992 would have been replaced by now, but apparently that's not the case.  Once in a while, you'll see a router or firewall that sees that your system is trying to negotiate a TCP window larger than 64K by offering a window larger than 64K with a non-zero "scale factor."  The router or firewall agrees, saying, "sure, let's do that big window..." and then acts as if it doesn't understand any window sizes above 64K.  Thus, if you'd offered a TCP window with BaseWindowValue of 256 and a multiplier of 13, you'd be offering a window size of 256 times 8192 (two to the 13th is 8192), for a TCP window size of 2,097,152.  But then a dumb router would throw away the scaling factor and say "gosh, a TCP window of just 256 bytes?"  Well, that seems kinda small, but if that's what he wants, that's what I'll give him."  As you'd imagine, a TCP window of just 256 bytes would lead to truly, legendarily awful performance.  So, if you're in some strange network that's giving you really awful Internet performance, then try the above netsh command.  (I've run into the problem in hotel and airport wireless networks.)

To un-do that when you're back home, where the routers and firewalls are smart (you installed them, right?), open another elevated command prompt and type

netsh int tcp set global autotuninglevel=normal

And I can't be the only guy who's noticed that when it comes to this command, "disabled" is the opposite of "normal."  Sorta judgmental, wouldn't you say?  And by the way, I've run across several places in on the Internet where someone has claimed that this requires a reboot.  Not true, and I've proved it several times with Network Monitor 3.1:  connections that set up TCP windows of 65700 drop to 64200 immediately upon executing a "=disable," and return to 65700 after executing a "=normal." (Why is it so hard for so many Internet writers to actually check things before publishing advice about those things?)

Now, Microsoft is aware of the "dumb router" phenomenon, and so they offer a couple of options that tries to get you big windows without running afoul of dumb routers.  If you suspect that you've got a slow internet connection because your computer's fighting with some T-Mobile poorly configured wireless router in an airport, then you don't have to surrender and restrict yourself to 64K windows.  Instead, try typing

netsh int tcp set global autotuninglevel=restricted

or, if that doesn't work, then you can try one more setting:

netsh int tcp set global autotuninglevel=highlyrestricted

Microsoft hasn't documented exactly what these settings do, but apparently they increase the TCP window size slooowly.  Or perhaps they try to avoid the "dumb router" problem by always setting the BaseWindowSize value as large as possible, and the scaling factor as small as possible.  To see what I mean, consider the example I gave earlier of wanting a two megabyte window but getting a 256 byte window.  My system sought a two megabyte window and expressed it as window size=256, scaling factor=13, but it could just as easily expressed that desire as window size=65,535, scaling factor=5 — 64K x 32 yields the same value as 256 x 8192 — then the damage wrought by a dumb router would have been lessened.  Again, I don't know how Microsoft does it, that was just a guess.

Remember that in theory RFC 1323 TCP windows can grow to 1 GB, but by default Windows holds its TCP window sizes in check, never asking for a TCP window larger than 16 MB.  Ah, but what if you really want monster TCP windows?  You can have them... just open that elevated command prompt and type

netsh int tcp set global autotuninglevel=experimental

As far as I can see, all this does it raise the 16MB limit to 1 GB.  With this enabled, I've established TCP sessions with local machines where the window size increased to over 100 MB.  Not sure why I'd care, but I include this for completeness' sake.  I mean, how many of your friends have ever communicated with humongous TCP windows? 


I'm speaking at lots of conferences this spring and if you can't make to my March seminars, please join me at...

Windows Server Launch Event, Los Angeles 27 February 2008

Microsoft's doing a series of "launch events" to coincide with the releases of Server 2008, SQL Server 2008 and Visual Studio 2008.  The first one is in Los Angeles on 27 February and they've asked me to present the overview talk on Server 2008.  If you're thinking of attending the event, then please consider stopping by my session.  Info at

The Minasi Forum Meet 2008 in Virginia Beach April 19-23

If you read this newsletter then you probably already know that I've run an online forum at for the past five and a half years, and if you ever hang around the forum then you know that there are a lot of friendly and helpful people there.  For the third time in as many years, we're all getting together to learn from each other, put faces to those online names and have another great time.  This year we've got some great guest speakers, including group policy guru Jeremy Moskowitz, PowerShell maven Don Jones, our own deployment diva Rhonda Layfield, Mr. Cisco himself (Todd Lammle), and a bunch of other great speakers covering a variety of topics that may surprise you.  Find out more at; I hope to see you there.

TechTarget Vista Road Shows in Chicago, Denver, Raleigh, DC and Minneapolis

TechTarget has been kind enough to ask me back for some more of the one-day Vista road shows that have packed 'em in since Spring 2007.  The next few cities are Chicago, Denver, Raleigh, DC and Minneapolis in March, April, May, August and September.  It's free so how can you go wrong ... unless you don't sign up before all of the seats are gone?  More info at

TechMentor In San Francisco, Orlando, New York and Las Vegas

If you're looking for a Windows technical conference then you'll have plenty to choose from this year, as the TechMentor folks will be running four shows this year:  San Francisco on the week of March 30, Orlando on the week of May 12, New York (Brooklyn, actually) the week of 7 September, and Vegas on the week of 13 October.  I'm doing a bunch of new breakout sessions, some content on Server 2008 (of course) and more.  Info at

Windows Connections in Orlando the Week of 27 April

If it's spring, we must be in Orlando!  Once again, Penton -- the folks who put out the magazine that I write for -- has assembled their "mega-show" that co-locates their techie shows on Windows, Exchange, SharePoint, SQL, and all kinds of developer stuff, all in the same week.  The show is in the Hyatt Grand Cypress, the place they've run it the past few years and not a bad location.  I'll be keynoting and presenting technical sessions, including my new "What's IPv6 all about and why do you care?" talk.  Information at

The Netherlands in May!

I'll be visiting our Dutch friends in late May to do a short keynote and my two-day Server 2008 seminar (in English -- my Dutch doesn't extend very far past that variety of chocolate, unfortunately).  Visit for more information.

TechEd US Orlando 10-13 June

Microsoft gave me six talks this year at the "IT Pro" part of TechEd US 2008, so you know I'm looking forward to it! If you'll be at TechEd 2008, please come by for one or all of my talks.  I'm doing

  • Understanding IPv6:  A Guide for the Reluctant
  • CompletePC, Inside Out:  Using Vista and 2008's Disaster Recovery Tool
  • Windows Logons Revealed:  Everything You Must Know About Kerberos
  • Vista's SP1, from A to Z
  • Going Cold Turkey on the GUI:  Server Core Step By Step
  • DNS 2008 Style: Name Resolution with Server 2008

Bring Mark to Your Site to Teach

I'm keeping busy doing Vista seminars and writing, but I've still got time to visit your firm.  In just two days, I'll make your current NT techies into 2008, Vista, security, XP, Active Directory or 2003 experts.  (And better yet they won't have to sit through any Redmondian propaganda.)  To join the large educational, pharmaceutical, agricultural, aerospace, utility, banking, government, telecommunication, law enforcement, publishing, transportation, military and other organizations that I've assisted, either take a peek at the course outlines at, mail our assistant Jean Snead at, or call her at (757) 426-1431 (only between noon-5 Eastern time, weekdays, please).

Special European Discount for On-Site Clients!

Well, sort of,.  Since the dollar's currently so weak against the euro, why not hire me now, before things change?<g>

Until Next Month...

Have a quiet and safe month. 

Please share this newsletter; I hope that it is a useful source of Windows technical information.  Please forward it to any associates who might find it helpful, and accept my thanks.  We are now at over 45,000 subscribers and I hope to use this to get information to every one of my readers. Many, many thanks to the readers who have mailed me to offer suggestions, errata, and those kind reviews.  As always, I'm at and please join us at the Forum with technical questions at  Thanks for letting me visit with you, and take care. 

To Subscribe/Unsubscribe, Read Old Newsletters or Change Your Email Address

To subscribe, visit To change e-mail or other info, link to  To unsubscribe, link to Visit the Archives at Please do not reply to this mail; for comments, please link to

All contents copyright 2008 Mark Minasi. You are encouraged to quote this material, SO LONG as you include this entire document; thanks.