Holy cow, I wrote a book!
Some people are in an uproar over IE's dropping of support for @ notation in HTTP URLs. What people fail to note is that The @ notation was never legal for HTTP URLs in the first place. If you go to RFC 1738 section 3.3 (HTTP), it explicitly states:
An HTTP URL takes the form: http://<host>:<port>/<path>?<searchpart> where <host> and <port> are as described in Section 3.1. If :<port> is omitted, the port defaults to 80. No user name or password is allowed.
An HTTP URL takes the form:
http://<host>:<port>/<path>?<searchpart>
where <host> and <port> are as described in Section 3.1. If :<port> is omitted, the port defaults to 80. No user name or password is allowed.
(Emphasis mine.)
So there are now three sides to the argument:
Personally I think dropping support for @-notation was the right thing to do.
[Raymond is currently on vacation; this message was pre-recorded.]
The weird stuff about Japan you were afraid to ask about. The Seldom-Asked Questions are interesting, but what I find the most fascinating is the pictures of various Japanese subcultures.
class MyClass : public IDataObject, public IEnumFORMATETC, ... { ... HRESULT EnumFormatEtc(DWORD dwDirection, IEnumFORMATETC** ppenumOut) { _dwDirection = dwDirection; Reset(); *ppenumOut = this; AddRef(); return S_OK; } };
Why create a separate enumerator object when you can just be your own enumerator? It's so much easier.
And it's wrong.
Consider what happens if two people try to enumerate your formats at the same time: The two enumerators are really the same enumerator, so operations on one will interfere with the other. For example, consider this odd code fragment (error checking deleted for expository purposes) which looks to see if the data object exposes the same data under multiple aspects:
IDataObject *pdto = <MyClass instance>; // Obtain two enumerators since we will run // each one independently. IEnumFORMATETC* penum1; IEnumFORMATETC* penum2; pdto->EnumFormatEtc(DATADIR_GET, &penum1); pdto->EnumFormatEtc(DATADIR_GET, &penum2); FORMATETC fe1, fe2; while (penum1->Next(1, &fe1, NULL) == S_OK) { penum2->Reset(); // start a new pass while (penum2->Next(1, &fe2, NULL) == S_OK) { if (fe1.cfFormat == fe2.cfFormat && cf1.dwAspect != cf2.dwAspect) { // found it! } } } penum1->Release(); penum2->Release();
When the code does a penum2->Reset(), this also inadvertently resets the first enumerator. The loop runs through penum2 (which therefore also runs through penum1), and when it's done, the enumerator is left at the end of the list.
penum2->Reset()
Then we loop back and call penum1->Next(), which immediately returns failure since the inner loop ran it to completion.
penum1->Next()
I've ranted before about privacy policies and how they don't actually protect your privacy. (All they're required to do is disclose the policy; there is no requirement that the policy must be any good.)
Today I read MetLife's privacy policy and found to my surprise that it does not actively offend me. It's written in plain English, it's well-organized, and it actually explains and limits the scope of each exception.
I have noticed how the word "terrorism" has turned into a "magic word" of late. Anything distasteful you want to do, just say you're doing it to combat "terrorism" and people will give you the green light.
Something is wrong with the world when fark finds something "real" news organizations miss. (When I first learned about fark, I confused it with FARC, a different organization entirely. That's right, a terrorist organization has its own official web site. Gotta love the Internet.)
Anyway, fark has pointed out that the guy that Pakistani forces claim today to have surrounded along the border with Afghanistan, Ayman al-Zawahiri, was already reported to have been captured two years ago by The Grauniad. They never printed a correction (as far as I can tell) so I guess he cloned himself.
This is another leftover from 16-bit Windows.
Back in the Win16 days, string resources were also grouped into bundles of 16, but the strings were in ANSI, not Unicode, and the prefix was only an 8-bit value.
And 255 is the largest length you can encode in an 8-bit value.
If your 32-bit DLL contains strings longer than 255 characters, then 16-bit programs would be unable to read those strings.
It appears to be gone now. Good riddance.
So it happens that Opening Day of the baseball season coincides with Good Friday, a day of "fasting and abstinence" according to Catholic tradition. (Then again, after Vatican II, the definition of "fasting and abstinence" weakened significantly. All that most people remember any more is "no meat".)
Catholics in Boston have applied to the archdiocese for a special dispensation so they can have a hot dog at the game. The Church said "Nice try".
But at least you can still order a beer.
For the first time, a team of women is challenged to develop a car, and the car they come up with requires an oil change only every 50,000 kilometers and doesn't even have a hood, so you can't poke around the engine.
To me, a car has no user-serviceable parts inside. The only times I have opened the hood is when somebody else said, "Hey, let me take a look at the engine of your car." (I have a Toyota Prius.) On my previous car, the only time I opened the hood was to check the oil.
Sometimes the open-source folks ask, "Would you buy a car whose hood can't be opened?" It looks like that a lot of people (including me) would respond, "Yes."
If you go to the various internet protocol documents, such as RFC 0821 (SMTP), RFC 1939 (POP), RFC 2060 (IMAP), or RFC 2616 (HTTP), you'll see that they all specify CR+LF as the line termination sequence. So the the real question is not "Why do CP/M, MS-DOS, and Win32 use CR+LF as the line terminator?" but rather "Why did other people choose to differ from these standards documents and use some other line terminator?"
Unix adopted plain LF as the line termination sequence. If you look at the stty options, you'll see that the onlcr option specifies whether a LF should be changed into CR+LF. If you get this setting wrong, you get stairstep text, where
each line begins
The unix ancestry of the C language carried this convention into the C language standard, which requires only "\n" (which encodes LF) to terminate lines, putting the burden on the runtime libraries to convert raw file data into logical lines.
The C language also introduced the term "newline" to express the concept of "generic line terminator". I'm told that the ASCII committee changed the name of character 0x0A to "newline" around 1996, so the confusion level has been raised even higher.
Here's another discussion of the subject, from a unix perspective.
Chris Brumme's latest treatise contained the sentence "Servers must not page". That's because on a server, paging = death.
I had occasion to meet somebody from another division who told me this little story: They had a server that went into thrashing death every 10 hours, like clockwork, and had to be rebooted. To mask the problem, the server was converted to a cluster, so what really happened was that the machines in the cluster took turns being rebooted. The clients never noticed anything, but the server administrators were really frustrated. ("Hey Clancy, looks like number 2 needs to be rebooted. She's sucking mud.") [Link repaired, 8am.]
The reason for the server's death? Paging.
There was a four-bytes-per-request memory leak in one of the programs running on the server. Eventually, all the leakage filled available RAM and the server was forced to page. Paging means slower response, but of course the requests for service kept coming in at the normal rate. So the longer you take to turn a request around, the more requests pile up, and then it takes even longer to turn around the new requests, so even more pile up, and so on. The problem snowballed until the machine just plain keeled over.
After much searching, the leak was identified and plugged. Now the servers chug along without a hitch.
(And since the reason for the cluster was to cover for the constant crashes, I suspect they reduced the size of the cluster and saved a lot of money.)