kliu0x52

Just use the MD5 functions exported by cryptdll.dll. I assume that your aversion to external DLLs is because you don't want to bother with bundling the DLL, which should not be an issue since cryptdll.dll is a system DLL that comes with Windows. They're optimized and fast.

Where would such a checkmark go? Because HashCheck supports multiple files, the concept of a single match or non-match in the file properties dialog does not make a lot of sense. This is why there is no compare hash function in the file properties dialog--there is instead a search function, where you can paste in a hash, and if none of the files have a hash that matches it, it will report not found, otherwise it will find every file that has a matching hash (there might be more than one). A checkmark does not make sense in this multi-file context. If you are suggesting that a checkmark be placed in the results text box, that is not feasible because it is a regular text box, and not a "rich text" box, and there are performance implications to using "rich text", if there are thousands of files hashed and displayed. In the HashVerify window, there is no graphical icon because of performance (for people who hash and verify large directory structures with tens of thousands of files, the use of graphics like that has a negative impact on UI performance and footprint) and because graphics are non-scalable and thus look rather ugly for users with a high DPI. No, it's not. A lot of care has gone into HashCheck's performance and to make sure that it is at least as fast as all of the common checksumming utilities (HashTab, QuickSFV, md5sum, etc.). In my personal experience, the two are about the same in speed in most situations, with HashCheck being slightly faster than HashTab; I've never seen HC work noticeably slower than HT. It should be noted that the most important factor in determining speed is disk access. If a file that HashCheck is working on is fully cached in memory, it can process the file at several hundred MB per second. If the file is not cached in memory, then it's limited by the disk access speed, which is usually around 30-100MB/s, depending on factors like disk speed, fragmentation, where on the disk the file is located, etc. In most use cases, HashCheck's worker thread is idle, waiting for the disk to give it data. HashCheck also uses a very large read buffer to minimize the effect of disk access overhead (this is especially apparent when comparing HashCheck against most other hashing utilities with data over a high-latency network drive; in certain exceptional situations, HashCheck can be over twice as fast than some other checksumming utilities). Because the disk is the bottleneck in most cases, it is very hard to do direct comparisons because if you hash a file with HashCheck and then hash the same file again with HashTab, then HashTab will win because that file would have been covered by the file system cache the second time through. To ensure a fair comparison, one has to fully read the file, and then hash with HC and HT so that they both benefit from the file being in the cache. Or one has to do a lot of other disk access to try to force the file out of the file system cache (which, depending on the size of your system memory, may be several hundred MB in size) before each hash operation to try to ensure that neither HC or HT get the benefit of the file being in the cache (this may not always work, esp. if you also have secondary non-FIFO caching like SuperFetch). Or hash two different files with similar sizes, fragmentation, and physical location on disk (which is hard to control).

Well, "Open Command Prompt" and "Open Elevated Command Prompt" are two separate options. OCP will never have an icon; only OECP will have the shield icon. The OECP menu option (and the associated shield icon) is shown only if you are using NT6+ and UAC is enabled (the EnableLUA registry key is non-zero) (also, if the registry key to disable the OECP menu item has not been set). So if you have disabled UAC, then you will not see the OECP option and its icon, which is the intended behavior.

If UAC is disabled, the entire "Open elevated command prompt" option should be hidden. The regular "Open command prompt" option does not carry an icon...

It's there so that a 32-bit process can make use of it. For example, if you run Firefox (a 32-bit app) and in the Save File dialog (which is just a miniature Explorer instance), you right-click, then you will be loading the 32-bit DLL (since the host process in this case is 32-bit). Most people will not end up using it, but it's there for the sake of completeness. It's the same reason Windows installs a 32-bit copy of every system DLL. Hmm. Really? The shield icon is a system resource, so it should always be available on NT6+. I see it on Vista and W7RC1 (both x64 and x86). Unless you have altered your system in some unusual way, I can't see what circumstances would cause this system resource to not load... Do you see this problem on a fresh install of Windows? And if you do not see this problem on a fresh install of Windows, would you happen to know what you changed/installed to make this break? Well, CmdOpen is definitely not the first command prompt shell extension; of all the ones that I am aware of, it's the last one to enter the game. The reason is that I share your sentiment: I prefer a minimally invasive method whenever possible, and so I very stubbornly stuck to using a registry tweak during all those years. But eventually, I got tired of the shortcomings, so I decided to look at the shell extension route. If you call CmdOpen a sledgehammer, then the others would be a wrecking ball. I couldn't bring myself to use a 100KB shell extension to replace a registry tweak, so I rolled my own for a small fraction of the footprint and with as little invasiveness as possible.

...IF the simple tweak can accomplish the same thing. Which in this case, it cannot. I didn't go from using a "simple tweak" using "software" just for the fun of it; I got sick of the shortcomings of the "simple tweak" and decided to address them. If you are okay with the shortcomings (and you have made it abundantly clear that you are), then sure, it doesn't make sense to pick this over the registry method. But that's just your personal opinion. Similarly, it is my view that the shortcomings of the old registry method were too annoying.

*sigh* If you look back at post #3 in this thread, you will find that I had already addressed the use of the "runas" verb. Yes, there's a way to do this without a shell extension using only the registry. This option has always existed since the days when the first powertoy showed us the way over a decade ago, and it's a well-documented method (there's even an article on Technet on using "runas" to elevate a command prompt). In fact, I've used the registry method for years and years. But the whole point is that it's not a perfect method. This addresses the various shortcomings of the registry method. Nobody's forcing you to use the shell extension method; if you think that the simplicity of the registry outweighs its shortcomings, then you are certainly free to do this with the registry.

Uh, unless you also have UAC disabled (in which case there is no concept of elevation), no, it does not work.

Yea, you just got rid of the shift. But that doesn't cover elevation, which is more important (esp. since, at least for me, command prompts are often used for administrative tasks). "But what about the runas verb?", you ask. First, runas can't be used on the background folder and second, runas is an exclusive verb, which means that if you assign runas to open a command prompt, you can't use it to perform any other elevation tasks on that object.

CmdOpen This is like the built-in command window here feature found in Vista and Win7, except that it supports UAC elevation and you don't have to hold down the Shift key to get it. Tiny, free, and open-source shell extension that supports both x86-32 and x86-64.