January 22, 2001
By Karen Kenworthy
IN THIS ISSUE
My mom says Hi! Over the last two weeks she's received over 200 messages from people around the world. Retired folks, youngsters, long-time computer professionals, computer newbies, men and women, all welcomed her to the Internet. One man even wrote and asked her out (sorry, my dad says she's not available). Several of you also wrote to explain what I do for a living. I don't know what you said, but she's been extra proud of me lately. :)
She asked me to tell everyone she's overwhelmed by the response to my request. She's trying to reply to as many messages as possible, but may not get to them all. But she's read each one and is very touched by your kindness.
Stacks
Despite my Mom's flood of messages, she doesn't hold the record. Windows, and the programs that run under it, spend a lot of their time passing information back and forth. When programs are running on your computer, it's not uncommon for Windows to respond to over 1,000 requests each second.
Every keystroke, mouse movement, and screen update requires Windows's intervention. Disk reads and disk writes need Windows's help too. Windows also gets involved when you communicate over the Internet or access a local area network.
In a very real sense, Windows applications require the assistance of Windows to do almost anything. Even access to your CPU and memory is monitored by Windows. If Windows detects any uses of these circuits it doesn't approve, it interrupts your program, re-takes control of your computer, and evicts the offending program.
To handle all this communication, Windows needs something faster, and more reliable than e-mail. Instead, most communication between Windows and programs takes place in small regions of memory called "stacks." In an electronic ritual repeated over and over, a program stores information within its stack, signals Windows, then returns to the stack to retrieve the information it requested, or discover the result of an action it asked Windows to perform.
Those of us with propellers on our beanies sometimes call stacks LIFO (Last In, First Out) queues. But this technical distinction only explains how information is arranged within the stack. For most purposes, it's sufficient to think of a stack as a small (usually only a few thousand bytes) scratchpad, shared between Windows and a program. Each program has a stack. And only the program that owns a stack, and Windows itself, can write data there, or read the data stored in the stack.
Pointers
Often, the amount of information that flows between a program and Windows is small -- as few as 32-bits or four bytes. A program might ask Windows the width, in pixels, of the screen attached to the computer. The result, a 32-bit number, is stored in the program's stack.
A 32-bit number is more than large enough to contain this information. After all, 16,777,215 (the largest 24-bit binary number) pixel-wide monitors are still quite expensive. And 4,294,967,295 (the largest 32-bit binary number) pixel-wide monitors are almost impossible to find. :)
Not all computer conversations are so concise, however. Often, hundreds and even thousands of bytes must be exchanged. Stacks can handle small amounts of binary chitchat. But they can't cope with these more elaborate conversations.
For one thing, stacks are relatively small. Sure, more RAM could be set aside for each program's stack. But that would waste RAM in those cases where the additional stack space was never needed.
What's worse, data stored in a stack is often a copy of data stored elsewhere. Duplicating large amounts of data, once in a program's normal memory space, and again inside its stack so it can be shared with Windows, wastes valuable CPU power and RAM.
To save time and memory, programs and Windows often don't share data directly. Instead, they exchange "pointers." A pointer is simply a small number. But the number doesn't represent actual data to be passed between Windows and a program. Instead, the number is the memory address of the data -- the location within the computer's RAM where the data can be found.
Suppose a program has composed a 10,000-character document, for example. Within the memory allocated to the program, the document occupies bytes 1,000,001 through 1,010,000. Now the program wants to write the document to disk.
Instead of copying the document's 10,000 characters to its stack, the program simply stores the document's memory address, 1,000,001. Using 32-bit binary numbers, this pointer only occupies four bytes. The program then tells Windows it wishes to write data to disk. Windows retrieves the pointer from the program's stack, and copies the document from the program's memory to a disk file.
Pointers are also used when receiving large amounts of data from Windows. First, a program will set aside a portion of its own memory, large enough hold the expected data. This region of memory is often called a "buffer." Next, the program stores a pointer to the buffer, the buffer's memory address, in the program's stack. Finally, the program signals Windows, passing along its request. Windows responds, copying its reply to the buffer the program provided.
Bad Pointers
Pointers work well, most of the time. But there are times when they can fail in spectacular ways. Like most computer errors, the problem really can't be blamed on the pointers themselves, but on the programmers who use them.
What happens if a pointer's value is set incorrectly? It may inadvertently point to memory used by another program, or Windows itself. If so, information needed by the other software may be unexpectedly changed in unpredictable ways when the pointer is used to access memory.
Even if a pointer contains a memory address belonging to the right program, it still might point to the wrong location in memory. For example, suppose a program allocates a buffer at memory location 1,000. But instead of storing the number 1,000 in its stack, the program incorrectly stores the number 100. Windows will obediently copy the data the program requests to location 100, overwriting whatever data or program instructions are stored there.
A pointer might also contain a non-existent address, an address where there is no RAM. Think of it as the street address of an empty lot. It can easily happen. Most pointers are 32-bit binary numbers, allowing them to refer any memory location from zero to 4,294,967,295, a little over 4GB. But few computers have even one gigabyte of RAM, let alone four.
At one time or another, we've all seen the effects of mangled pointers. Ever see a message like "General Protection Fault," "Cannot Read Memory," or "Exception Error?" More than likely, a bad pointer was the cause. Bogus pointers are also the leading cause of "bit rot," the tendency of computers to become less and less stable, the longer they run. Over time, the amount of data corrupted by bad pointers grows, until the computer is rebooted, the affected program ends, or the program or Windows crash.
The hazards of pointers became real just last week, here at the secluded Power Tools workshop. That was when a few readers reported the new Winmag.com Computer Profiler died, when asked to describe the ports found on their PCs. When asked for information about a port, a certain driver declined to answer. It did so by returning a pointer containing the value zero.
The Profiler didn't expect this response, and attempted to read memory location zero instead. Unfortunately, memory location zero is protected by Windows, and any attempt to access it causes the offending program to fail.
If you're a programmer, pointer errors are usually easy to fix, though not so easy to find. And that's exactly what I did when I created Profiler version 1.4. In addition side-stepping the bad pointer, the new version also displays additional information about your computer's settings that help the hearing- impaired. The program also better detects older Pentium CPUs, and avoids a bug in Windows that causes it to report incorrect data about a CD-ROM or DVD drive that has no disc.
If you'd like to try Profiler 1.4, let me point you to the program's home page at https://www.karenware.com/powertools/ptprofile. Programmers, folks who take apart clocks to see what makes them tick, and other curious folks can also download the program's Visual Basic source. As always, it's all free.
As for me, I think I'll write my mom a note. If there's someone important in your life, you might want to drop them a line too. And if you see my mom or me on the 'Net this week, be sure to wave and say "Hi!"
More than 6000 downloads monthly
Received $93.84 this month* — Thanks!
License for Work
A license is required to use any or all of these tools for your work. You only need one per lifetime. If you make money with Karen's software, read her license agreement.
Power Tools Newsletter
- What is Karen's QR Code Talker?
- What is a QR code?
- What is a Code Talker?
24840 Verified Subscribers
Subscribe to receive new issues of the newsletter about Karen and her free Power Tools.
Click here to SubscribeDecember Revenue* $93.84
*Licenses + Donations - PayPal Fees
Nov $341 Oct $211 Sep $166 Aug $173 Jul $225 Jun $324 May $200 Apr $700 Mar $273 Feb $405 Jan $56 (2023) Dec $349 Nov $546 Oct $253 Sep $232 Aug $189 Jul $379 Jun $188 May $484 Apr $212 Mar $519 Feb $89 Jan $462 (2022) Dec $1088 Nov $151 Oct $133 USD — Thanks again!