| Date: | December 29, 2006 / year-entry #430 |
| Tags: | non-computer |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20061229-03/?p=28553 |
| Comments: | 24 |
| Summary: | A few random links that I've collected. How to be an 31337 hax04 and send mail to a DL to which you don't have rights. Suggestions on what to do if you have only one day to visit Seattle. Original anchor article by the Seattle Times staff. Broken down by category. Reader feedback. More feedback.... |
A few random links that I've collected.
And then the obligatory plug for my column in TechNet Magazine:
And then the obligatory book plug: The electronic-only PDF version is now available for purchase, and it's cheaper than the dead tree edition. (Don't forget that the dead tree edition comes with 45 days of free access to the electronic edition.) My prediction? "Jim Allchin will retire on November 13, 2006." I was wrong. I based my prediction on the fact that Microsoft announced that Allchin "plans to retire at the end of calendar year 2006 following the commercial availability of Windows Vista." The year was set; the rest was trying to guess the day. I haven't seen any announcement saying that plans have changed, so I assume it's still operative. The year isn't over yet, but there's not much time left. (Then again, what is commercial availability? Apparently, the PR people think it means "the date the product is available to the general public at retail," but to me it means "the date the product can be purchased." So-called business availability was last month, and selling stuff to businesses is commerce, so that counts as commercial availability in my book. But apparently my interpretation of the English language doesn't count for anything, so I'm expecting to see Jim's letter of resignation on January 31st.) |
Comments (24)
Comments are closed. |
On the RunOnce key only being run when an admin logs on:
Not when installing MDAC, at least on 2K Pro, and probably also on XP. We’ve rolled out several MDAC upgrades with an updater program that lets us basically run custom EXEs, with controllable command-line arguments. These EXEs run as LocalSystem (the updater creates its own service to do the installation on the remote machine, so users don’t see any dialogs). The intent of the arguments is to put the installer into "silent" mode.
Anyway, when rolling out the MDAC 2.8 package, and later 2.8SP1, the setup program for MDAC put several subkeys under RunOnce, which were supposed to register the newly-installed MDAC DLLs so they could be used by programs using MDAC (in our case, the programs used ADO and OLEDB). The keys had the shell call the DllRegisterServer entry point in each DLL (they did not use regsvr32).
The old MDAC files were almost always in use (generally by some Office program), so they had to be replaced using the "Session Manager" key’s "PendingFileRenameOperations" multi-string value. Then they had to be registered with COM, so the setup program used RunOnce.
And the RunOnce stuff ALWAYS ran, no matter who was logged in. Almost all users got an error dialog saying that the DllRegisterServer call had failed, over and over again, until all the RunOnce subkey calls had happened. The values also didn’t get removed from the registry (because the user didn’t have permission to do so, as was written in the article), so on their next login, everything ran again.
We had to connect to each individual desktop, log in as a local admin, and let the DLLs register themselves, before everything would work right. (Actually we cheated; our remote control program has a "telnet" option that lets us run console programs, which run as LocalSystem on the remote machine. So I wrote a console program to inspect the RunOnce subkeys and call each DLL entry point referenced there, then remove the RunOnce subkey. Then we ran this with the telnet option on each machine. Still, it wasn’t automatic.)
Now as I’ve said, maybe this was only on 2K, but I don’t think so. Or maybe it was because MDAC setup used subkeys under RunOnce, and specified a DLL and entry point; maybe that’s handled differently from a program (in which case, MDAC setup needs to be fixed). But "RunOnce is only run when an admin logs on" isn’t true in every case; there are some exceptions.
I too enjoy Adams’ blog. I like the way he treats very controversial subjects by simply expressing his honest thoughts, without seeming like he’s just fanning the flames.
I’ve just read your “The Amazon commission is higher than the royalty”.
I suggest you to put such links to the front page of your blog, and also make equivalent links to other local Amazons (if it is possible for you). I mean amazon.co.uk, amazon.de, amazon.fr etc. Europeans who want to buy your book will prefer local Amazons for many good reasons.
Happy New Year.
A question you may want to answer in the future.
Why is thumbs.db an hidden system file ?
Deleting it is quite harmless, but it’s accompanied by a number of dire warnings.
Was a "safe-to-delete-I-am-just-redundant" attribute ever taken into consideration (for uses like this one, or VS browsing files or whatever other "cache" like file) ? If yes why it wasn’t implemented ? If no.. why ? :)
Happy new year
Raymond, any news about the Mobipocket / eReader version? (You said eMobipocket which apparently does not exist, so it should be one of them :) )
OK, so what is the Chinese/Japanese/Korean translation of "DLL Hell"? Of course, I don’t know any of those languages so I need to know what it would be in English.
I ask because it’s always interesting to see how little bits of word play are translated into other languages. This is of particular interest in far-East languages which don’t have the same notion of "Hell" that us Westerners do.
Elite hackoa?
j0o m15-5p3113d h4x0r, d00d!
14m3, r4`/M0n|), 14m3!
Re: Win32 I/O cancellation: is it just me, or is Windows borrowing a lot from UNIX lately? New directory enumeration mode that returns the inode along with other information. Keyed events ("sleepon locks"). I/O cancellation overhaul – thread affinity turns to process affinity, file object affinity is added, ability to cancel individual operations (like POSIX AIO always was). Full support for symbolic links. Finally, SRW locks, condition variables and initialize-once (taken straight from pthreads)
oh, almost forgot! prioritized wait queues (albeit undocumented, but nothing can hide from my hawk’s eye)
See http://www.norges-bank.no/nbim/pension_fund/ for more info about the Norwegian "cash cow".
Sometimes it feels like it gives us more problems then help, though, especially with regards to fear of overheating the economics. The best is that the "Progress Party" wanted to sellout the oil & gas rights for 10 bill. NOK in the 70’ies right after these resources where discovered. That would’ve been quite a bargain!
Regarding the "Program Files" vs. "Programs" system directory naming:
You may not be aware of the fact that localized versions of the "Program Files" directory (e.g. the German one, "Programme") are exactly opposite of the rationale behind described. The localization people apparently did not know enough of what the Windows designers were thinking of.
Marc people arent mind readers. No doubt they assumed what would be a logical alternative and went with it. I’m starting out with win32 and i find it very hard sometimes to find what Windows designers were thinking considering the mountain of post/forums/articles you have to go through.
P.S. Have a happy new year Raymond.
There’s a little typo in the "DLL Hell" article – an extra space between "C:Program FilesLitware IncInvoice" and ".exe.local"
(… prioritized I/O!)
I see the problems with making shortcuts work more like symlinks, yes. But I still think a better solution should have been possible than the one used, even if it is only a flag to CreateFile that says, "if this is a shortcut to a file, open its target not the shortcut" – along with the ability to use paths like c:somewhere.lnksomefile.ext when there’s a shortcut to a directory.
Jules, except that shortcuts are part of the shell and CreateFile() is in the kernel.
The biggest problem I’ve seen with shortcuts to folders is that dialog boxes don’t consider them to be directories. Thus your "choose a folder from a directory tree structure" doesn’t show them, and the illusion is broken. Since that dialog allows no keyboard input to type a path, only folders that natively show up in the tree are accessible to the user. Any path that is only accessible by shortcut (perhaps to a network share that doesn’t show up in NetHood) can not be used by a program that requires that stupid dialog to choose files to process.
Another problem is that Explorer doesn’t seem to have a way of disabling the behavior of always sorting folders above files. Since shortcuts to folders are files, they do not show up where you expect them to.
Gabe: I think a direct translation of "DLL 地獄" will do in Chinese. ("DLL" is actually named "動態連結程式庫" in Chinese, but I think it’s a bit too long for a common-term, an afterall, we computing people are used to Chinese-mixing-Engligh-acronyms terms. :P
I hadn’t spotted that you did Technet articles too. I particularly liked the context menu story. I have some sympathy with your position on maintaining compatibility for the sake of users, but having jumped through hoops to help your competitors customers I don’t think it would be unreasonable to name and shame them. Perhaps you should do a Daily WTF type site just for outing applications that use evil hacks and undocumented behaviour. Of course I can say this only because I never use evil hacks or undocumented behaviour in my own code.
Sometimes, one wonders who reviews these API changes.
I read the MSDN documentation about IO cancellation, and I’ve noted that they added two functions: with one, you can cancel I/O related to a file handle. Unless you provide an OVERLAPPED structure, it will cancel all I/O related to this handle from all threads. With the other function, one provides a handle to a thread. It will cancel all I/O for the given thread.
There is no way to specify both a file and a thread, so there are a lot of race conditions (which are discussed in the MSDN article): when using thread pools, when doing multiple operations on the file from multiple threads, etc.
Why didn’t the kernel developer provide a single function taking both a thread and a file handle, one of which could be omitted? Seems more flexible, reduces API entry points, and provides more accuracy as to what must be canceled.
Two more functions with subtle problems that will need to be dug in by Raymond in the future?
Pierre, the reason there are two entry points is that they are for entirely different purposes.
The reason you would want to cancel all I/O for a given thread is that the I/O is synchronous. Since that thread is waiting for the I/O to finish it cannot execute its own cancel operation. This is obviously something you would have to intentionally write into your code, so it’s not hard to make it avoid race conditions (set a flag before doing the Cancel; have the I/O thread check the Cancel flag after the I/O to make sure it is clear before proceeding). This is really the more important of the two functions because it makes long-running processes possible to exit.
The other new API, which provides the ability to cancel a specific I/O for a given file (as opposed to all of them) is really just a refinement on the already existing functionality. This makes it easier to cancel from thread pools and such.
Cheong: the important questions are:
What does the Chinese translation mean literally? How does a Chinese person understand Hell?
Does it rhyme? DLL Hell is so catchy because it rhymes. If it isn’t catchy, you may as well call it "DLL Problems".
Thursday, January 04, 2007 10:58 AM by Gabe
I’m not Cheong but I think I can answer that one for you. If you’re using Chinese as a nationality then consider how your country’s people understand Hell. If you’re using Chinese as a race then consider how your race’s people understand Hell. I think the answer depends more on a person’s religious beliefs than their country or race. Even in countries that have a national religion, even in countries where people can’t say aloud whether they believe it or not, their internal beliefs vary.
Again not being Cheong, I can’t answer about the Chinese literal meaning, I can only say what a dictionary gives as the Japanese literal meaning. (Japanese uses a lot of Chinese characters just like English uses a lot of Italian letters. Some English words have the same meanings as French words (e.g. "restaurant") but some are unrelated to identical-looking French words (e.g. "comment") or German words (e.g. "gift"). Same kinds of borrowing and non-borrowing.) Anyway, a Japanese-English dictionary gives the literal meaning as "Hell".
By the way the Japanese version of that MSDN article had "DLL Hell" written in English. In common practice the phrase "DLL" is sometimes translated and sometimes not translated, but apparently the phrase "DLL Hell" isn’t translated.
You don’t have to understand any religion to understand the meaning of "hell".
Your tech net (dll hell) article has a corrupt link. "The Requested Page Has Moved".