Al is DDJ's senior contributing editor. He can be contacted at [email protected].
I recently had an online discussion about Hungarian notation with a bandleader. It all started when I posted a request for beta testers for a music education program on a mail list populated by players of traditional jazz. The bandleader, who would not be a candidate for this particular beta test program because he does not play an instrument (I think he sings and plays the kazoo), posted a lengthy public query about how the program is written. He would not, he said, be willing to beta test an application that had not been developed under certain programming standards to which he personally subscribes. The bandleader, as it turned out, is also an unemployed computer programmer. He warned the other potential testers that programs written by undisciplined programmers are not to be trusted and might even do serious damage to the testers' computers. He listed several policies and procedures that must be in place in the development environment before he would permit an application to run on his computer. Prominent on this list was the requirement that the application's code employ Hungarian notation.
This posting confused the other members of the list, most of whom don't know or care about how computer programming gets done, and it also caused some of them to wonder whether this expert was right and whether there might really be some vague and unspecified risk in being a beta tester. I had to reassure them that their PCs were safe running my software.
The bandleader maintains that programs need to use Hungarian notation, a convention for putting prefixes on identifiers to indicate what the identifier identifies. I'm not familiar with the formal specification, but the funny prefixes on some Windows things seem to adhere to this convention. A Google search on "hungarian notation" turns up many references for those who want to know more. It works something like this: An identifier such as m_pszFoobar tells you the thing it identifies is a data member pointer to a string or something like that.
I suppose such a convention is helpful in programs where identifiers are far removed from what they identify. But variable origins and types ought to be obvious in C++ programs that use namespaces and keep member functions small. Local variables are declared nearest their references. Parameter variables are just above in the parameter list. Since there are no global variables, you can assume that anything else unqualified by a scope resolution operator is a member variable of the class. If you can't infer a variable type from the context of its usage, a terse comment usually helps. I believe in identifiers that say what the variable is — orderquantity instead of oq, for example — but enforcement of naming conventions is unnecessary when programmers use reasonable coding practices. Such identifiers are a pain when the variable type changes during maintenance or development. I'd prefer that the name say something about the variable's purpose and meaning rather than its type, an attitude that reflects my object-oriented bias — abstract, encapsulate, hide the implementation, and expose a public interface.
Many respected programmers swear by naming conventions and cite experiences to back it up. My experience is different than theirs. But if something works for you, I'd be the last person to tell you not to do it. Similarly, I do not approve when someone tells me that I have to use some particular naming convention.
I was on a panel at a conference several years ago along with some C++ luminaries. The C++ infusion into the mainstream was relatively new then. Someone in the audience asked what to do when the boss insists that programmers use a naming convention. One of the panelists said, "Find another job." Later, when I asked if I could quote him, he agreed with the sentiment but did not remember saying it and did not think he ought to be giving such advice. I think his advice was appropriate, don't believe he forgot saying it, but respect his wish to remain off the record.
Wired
Yesterday, I completed one of the more difficult tasks in my checkered career. My house and office are now wired for the 21st century. Well, at least for this year. The task was difficult because it involved a modicum of physical labor, a punishment I usually manage to sidestep. It all started when the cable modem service named RoadRunner became available to us few inhabitants of this rural locale in the palmetto jungle of central eastern Florida. RoadRunner is a subsidiary of Time-Warner cable and now that Ted and Hanoi Jane have parted company, I don't mind throwing him a couple extra bucks every month as long as it doesn't go for alimony. Which is as close to a political statement as I'll get.
To me it's a financial wash. Canceling the second phone line and Judy's and my dialup accounts more than offsets the monthly nut for cable modem. But I need all our computers connected so we can share Internet access. We have a house and two outhouses — my office and workshop. So, last week your C Columnist spent his days digging trenches, laying underground conduit and cable, feeding cable up, down, and though walls, crawling around among the trusses and fiberglass insulation in what might be called an attic, threading cable from room to room, crimping connectors, installing outlet plates and configuring a router and a switch. This week I'm nursing the aches, cuts, scratches, bumps, and bruises that resulted from my foray into home improvement. But I'm also happily surfing at broadband speeds from any room in the house.
They tell me I could have saved all that labor by installing one of the new wireless router setups. But I'm not one to push the envelope. I don't live on the edge. I'm interested only in mature technology, things that are known to work because they've stood the test of time. Yeah, right. Read on.
The Lay of the LAN
Our computers consist of several PCs running XP Pro, XP Home, ME, 98se, and 95. I keep all these Windows operating systems going so I can test my software projects on each of them. I maintain them on a LAN to move files around more easily, share printers, and access web sites from everywhere. The cable guy who installed RoadRunner would install it only on the PC of my choice, disconnected from the LAN. He said getting it going on the LAN was my problem. I know now why he avoided that task. RoadRunner installation is free. I don't blame them for not wanting to undertake what took me several days to achieve.
Regular readers will remember this time last year when my computers were running Linux. (Judy's desktop was the only Windows holdout at the time.) My LAN worked just fine. When I connected a computer to the router, it was there, immediately visible to all the other computers. When I disconnected one, all the other computers knew immediately that it was gone. Of course they did. That's how it ought to work, isn't it? The initial setup was a bit arcane, what with all the Linux configuration text files I had to learn about and modify, but once it was in place, it all worked and I could forget about it. A new project and my own disillusionment with Linux as a serious desktop work environment caused my reluctant retreat to Windows late last year.
Things are not as smooth with Windows networking. In their effort to make it easier, the programmers at Redmond tried to do it all with a Network Setup Wizard program. XP users can build a diskette to run the Network Setup Wizard program on older versions of Windows that don't have a Wizard. The Wizard sets up the computer's access to the LAN and the Internet, enabling multiple computers on a LAN to share Internet access through one of the computers or through a router or hub.
But the Microsoft programmers neglected to test the Network Setup Wizard. It blows up every time on my primary desktop, a Dell that came with XP installed, making it impossible to configure that computer as the Internet host, which I wanted to do when my access was dialup only. The same program does not work on laptops that use PCMCIA network adaptors. It says it can't find the network hardware and refuses to continue with the setup. I cannot find an upgrade for this program. Could I be the only person who has these problems?
My LinkSys router implements a firewall between the cable modem Internet access and the PCs connected to the router. It also implements its own DHCP server, which dynamically assigns local IP addresses to the PCs when they connect. But the Network Setup Wizard also implements a software firewall by default, assuming the PC is connecting to the Internet directly. The software firewall effectively isolates the PC from the other computers on the LAN, thus defeating the reason for having a LAN in the first place. I understand the purpose for the software firewall, but it ought not be the default when you've just told the Wizard that you're connecting to the Internet through a router. At the very least, it ought to ask you whether the router has a firewall. When you turn off the option, a solution you have to figure out for yourself, the program sternly warns you that you are taking serious risks by granting access to your PC. It's the kind of warning that scares typical users away from doing the right thing. It almost made me change my mind, and I know better.
As it turns out, you don't need that flawed Network Setup Wizard. All it does is configure things that you can configure yourself with the Control Panel's Network applet. Tell each network adaptor to accept dynamically assigned IP addresses and a DNS server, turn off their software firewalls, enable file and printer sharing where appropriate, install the TCP/IP protocol, and your software is configured. Plug the PCs into the router, and your LAN is installed.
Now the fun begins. Having my desktops and main laptop all set up and connected to one another and the Internet via the router, I attached two 98se laptops to the new LAN. For some reason, neither one got automatic IP addresses. Instead, as I learned later, they got IP addresses in the range reserved for local networks that don't have DHCP or static IP addresses. Neither of the laptops could reach the Internet. Adding to the confusion, the laptops were in the LAN but only kind of. They could access some of the other computers but not all of them. Some, but not all, of the other computers could access the errant laptops. The ones the laptops could access and the ones that could access the laptops were not necessarily the same PCs. Access to and from the two laptops was not consistent, either. It was a mess.
Two coincidences added to the confusion. First, both laptops have PCMCIA network interfaces. Another laptop with an internal NIC worked with no problem. The earlier problem with the Wizard failing to recognize those interfaces cast a false shadow of suspicion on that architecture. Second, both laptops have Windows 98se. But one of the desktops has Windows 98se, too, so the operating system did not seem to be the culprit. But you can't be sure.
I called my own personal consultant — my daughter Sharon, who is an MCSE on the Windows platforms. When I described the symptoms, she was as puzzled as I was. And she does this kind of tech support every day. But she did say that the IP addresses assigned to the laptops indicated that they were in a network without a DHCP server. Which was not the case. The router has a DHCP server that works with all the other PCs. This evidence finally led me to the solution.
The first thing I learned was what caused the confusing maze of PCs that could and could not see one another in the Network Neighborhood or My Network Places, depending on which operating system is in use. Here's how it goes: If everything is properly in place, TCP/IP is the only network protocol any of the PCs should need for LAN and Internet access. All the PCs had TCP/IP installed. But some of them had IPX/SPX installed, too. It seems that if the Windows LAN system cannot locate a computer by using TCP/IP, it tries IPX/SPX if that protocol is installed. With one exception. Even though you can install IPX/SPX/Netbios on an XP computer, that computer cannot see nonXP computers that have IPX/SPX installed but are not available through TCP/IP. But the nonXP computers can see the XP computers. Whew.
The router setup is implemented as a web site built into the router. You enter its local IP address as the browser's URL, and its web pages step you through its setup. One of the options is the maximum number of PCs its DHCP server supports. Back in the Linux days I had set this maximum to an appropriate number and, in a relapse of recurring CRS, had forgotten about it. That old DHCP maximum was too low for this new configuration. When Sharon said the two PCs didn't think they were connected to a DHCP server, I opened the router's setup web site, and there it was. I raised the maximum and went from PC to PC, releasing and renewing the IP configurations of each network interface. When I was done, everything worked. At last.
This whole situation was exacerbated by Microsoft's need to constantly and artificially improve their products to get us to pay for upgrades. They keep changing the user interface. Each OS has a different way to configure the network and to access other computers and their shared resources. Running from computer to computer, changing things to see what happens, becomes a hair-pulling exercise.
People like my daughter actually do this for a living. I think I'd rather be a kazoo-playing bandleader.
Windows LANs have another annoying behavior. When you turn a computer on or connect it to the LAN, the other computers don't always see it. You can wait a long time before it shows up among the list of computers on the LAN. This behavior adds to the confusion when you're testing a network. You look at a vacant space where an icon ought to be and wonder, is it really gone or is it just not there yet? Then, when you remove a computer, the others think it's still there. You look at an icon and wonder, is it really there or is it just not gone yet?
The Microsoft docs say that Windows waits 48 hours before purging missing PCs from the My Network Places list. Forty-eight hours! Why in the world does it take that long to decide that a PC is gone? What in the name of Larry, Curly, and Moe is likely to happen in 48 hours to make a difference that won't happen in four seconds? If you've forgotten or never knew that the PC is gone and click on its icon from another computer, the Explorer window goes into an interminable hourglass mode while the system tries to figure out what's what. I learned early on to use the ping and ipconfig command-line tools for the tests, but in day-to-day operations you want to use Explorer windows to navigate the LAN and they just don't work intuitively or even properly.
Sometimes, when you turn a computer on, it takes a long time for it to recognize all the computers on the LAN. Wondering whether the missing computers are still running, I open a DOS box and ping them from the command line. Sure enough, they are there, but Windows itself might take as long as a half hour to update its display of computers in the network. The logic behind that escapes me.
Thinking it might be just me, I visited the news group at microsoft.public.windowsxp.network_web and found a host of messages from users worrying about not being able to get their LANs working and computers in the LAN not being able to see one another. This Windows LAN behavior is unnecessary and downright stupid.
Listen up, Mr. Gates. No doubt you have people who set up your personal network and ensure that it runs smoothly and you've never seen this kind of nonsense. But believe me, it's real and it stinks. I have a suggestion for the agenda of your next executive staff meeting. Identify everyone — managers, analysts, programmers, whatever — who had anything to do with building the Microsoft networking abomination, er, software. There must be a lot of them; only a big committee could come up with something that awful. Conduct your own version of the Saturday night massacre. Fire them all and throw out the code. Or, given the current job economy, reassign them to the Minesweeper project. Then hire the few unpaid open-source volunteers who built networking for Linux and let them do it right.
DDJ
