The Old New Thing

The extern "C" specifier disables C++ mangling, but that doesn't mean it disables mangling

Raymond Chen - MSFT — Fri, 25 May 2012 14:00:00 GMT

The MSDN documentation on dllexport contains the following enigmatic paragraph, or at least did at the time I wrote this article:

dllexport of a C++ function will expose the function with C++ name mangling. If C++ name mangling is not desired, either use a .def file (EXPORTS keyword) or declare the function as extern "C".

I've seen this sentence misinterpreted as follows:

dllexport of a C++ function will expose the function with C++ name mangling. To disable name mangling either use a .def file (EXPORTS keyword) or declare the function as extern "C".

This is an understandable misinterpretation, but it is still a misinterpretation.

The root cause of the misinterpretation is that the author of this documentation was wearing C++-colored glasses. In the author's mind, there are only two interesting cases:

C++ name mangling, where all the cool people are, and
everything else, for all the lamers.

Here is a precise formulation of the paragraph:

dllexport of a C++ function will expose the function with C++ name mangling. If C++ name mangling is not desired, either use a .def file (EXPORTS keyword), which will expose the name without mangling, or declare the function as extern "C", which will expose the name with C mangling.

Here's a version of the paragraph that tries to take away the C++-colored glasses.

dllexport exposes the function as it is decorated by the compiler. For example, if the function is a C++ function, it will be exposed with C++ name mangling. If the function is a C function, or has been declared as extern "C", it will be exposed with C name mangling. To expose the function under its unmangled name (or to expose it via an alternate name), use use a .def file (EXPORTS keyword).

Behind the scenes: To forestall nitpickers, I had to go back to my copy of the C++ standard to make sure I filled in the blank in "The extern "C" _________" correctly. Officially, extern "C" is a storage class specifier.

How do I prevent unchecked checkboxes in my listview control from disappearing?

Raymond Chen - MSFT — Thu, 24 May 2012 14:00:00 GMT

A customer asked, "I have a listview control in report view with the LVS_EX_CHECKBOXES extended style. I noticed that unchecked checkboxes are not visible until I hover over the corresponding item. Is it possible to get the checkboxes to be visible all the time?"

I was kind of puzzled by this question because the default behavior of the list view control is to show the checkboxes all the time. I could have sat down and written a test program to prove it, but that would have taken too much time, and it wouldn't have advanced the story any. (The customer would merely have written back, "Well, that's not what I'm seeing.")

This appeared to be a case of a customer providing incomplete information, forcing me to invoke my psychic powers to fill them in.

"My psychic powers tell me that you have also set the LVS_EX_AUTOCHECKSELECT extended style. When LVS_EX_AUTOCHECKSELECT is set, then unchecked checkboxes are hidden."

Remember, when you ask a question about a component and you have done any customization to that component, please remember to mention that when you ask your question. Otherwise nobody will be able to reproduce your problem, because they will assume you left everything at the defaults.

It's like calling the Ikea customer service line, saying "My Ikea Frusträt rolling cabinet doesn't roll properly on my hardwood floor when I put more than about 25 pounds of stuff on it." The person on the phone looks up the specifications for the rolling cabinet and sees that that is well within the design limits. "I paid for you guys to assemble and install it, so it can't be an assembly or installation error." The person on the other end scratches their head for a while. And then you mention, "Oh, but I didn't like the color of the wheels, so I replaced them with some other wheels I bought at Home Depot."

Oh, yeah, thanks for not mentioning that.

GUIDs are designed to be unique, not random

Raymond Chen - MSFT — Wed, 23 May 2012 14:00:00 GMT

A customer liaison asked, "My customer is looking for information on the GUID generation algorithm. They need to select N items randomly from a pool of M (jury selection), and their proposed algorithm is to assign each item a GUID, then sort the items by GUID and take the first N." (I've seen similar questions regarding using GUIDs for things like passwords or other situations where the programmer is looking for a way to generate a value that cannot be predicted.)

The GUID generation algorithm was designed for uniqueness. It was not designed for randomness or for unpredictability. Indeed, if you look at an earlier discussion, you can see that so-called Algorithm 1 is non-random and totally predictable. If you use an Algorithm 1 GUID generator to assign GUIDs to candidates, you'll find that the GUIDs are assigned in numerically ascending order (because the timestamp increases). The customer's proposed algorithm would most likely end up choosing for jury duty the first N people entered into the system after a 32-bit timer rollover. Definitely not random.

Similarly, the person who wanted to use a GUID for password generation would find that the passwords are totally predictable if you know what time the GUID was generated and which computer generated the GUID (which you can get by looking at the final six bytes from some other password-GUID). Totally-predictable passwords are probably not a good idea.

Even the Version 4 GUID algorithm (which basically says "set the version to 4 and fill everything else with random or pseudo-random numbers") is not guaranteed to be unpredictable, because the algorithm does not specify the quality of the random number generator. The Wikipedia article for GUID contains primary research which suggests that future and previous GUIDs can be predicted based on knowledge of the random number generator state, since the generator is not cryptographically strong.

If you want a random number generator, then use a random number generator.

Bonus reading: Eric Lippert's GUID Guide, part 1, part 2, and part 3.

Why is the Close button in the upper right corner?

Raymond Chen - MSFT — Tue, 22 May 2012 14:00:00 GMT

Chris wants to know how the close button ended up to the right of the minimize and maximize/restore buttons. "In OS/2, it is on the left, which left the two other buttons in place."

I don't know why the Close button went to the upper right instead of going to the left of the other buttons, but I'm going to guess. (That's what I do around here most of the time anyway; I just don't usually call it out.)

Two words: Fitts's Law.

The corners of the screen are very valuable, because users can target them with very little effort. You just slam the mouse in the direction you want, and the cursor goes into the corner. And since closing a window is a much more common operation than minimizing, maximizing, and restoring it, it seems a natural choice to give the close button the preferred location.

Besides, maximizing and restoring a window already have very large targets, namely the entire caption. You can double-click the caption to maximize, and double-click again to restore. The restore even gets you a little bit of Fitt's Law action because the top of the screen makes the height of the caption bar effectively infinite.

What was the registry like in 16-bit Windows?

Raymond Chen - MSFT — Mon, 21 May 2012 14:00:00 GMT

Commenter Niels wonders when and how the registry was introduced to 16-bit Windows and how much of it carried over to Windows 95.

The 16-bit registry was extremely simple. There were just keys, no values. The only hive was HKEY_CLASSES_ROOT. All it was used for was COM objects and file associations. The registry was stored in the REG.DAT file, and its maximum size was 64KB.

It is my recollection that the registry was introduced in Windows 3.1, but Niels says it's not in a plain vanilla install, so I guess my memory is faulty.

None of the 16-bit registry code was carried over to Windows 95. Windows 95 extended the registry into kernel mode, added support for values and non-string data types, increased the maximum registry size (though if some people are to be believed, not by enough), and added a bunch of other hives, like added the HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, and the HKEY_DYN_DATA, The old 16-bit registry code was woefully inadequate for all these new requirements (especially the kernel mode part), so it was all thrown out and a brand new registry written.

In the early days of the Windows 95 registry, the in-memory signature value to identify the data structures which represent an open registry key were four bytes which corresponded to the ASCII values for the initials of the two programmers who wrote it.

How to view the stack of threads that were terminated as part of process teardown from user mode

Raymond Chen - MSFT — Fri, 18 May 2012 14:00:00 GMT

Last time we saw how to view the stack of threads that were terminated as part of process teardown from the kernel debugger. You can do the same thing from a user-mode debugger, and it's actually a bit easier there. (The user-mode debugger I'm using is the one that comes with the Debugging Tools for Windows, the debugging engine that goes by a number of different front-ends, such as ntsd, cdb, and windbg.)

A direct translation of the kernel-mode technique from last time would involve using the !vadump command and picking through for the memory blocks with candidate size and attributes. But there's an easier way.

Now would be a good point for me to remind you that this information is for debugging purposes only. The structures and offsets are all implementation details which can change from release to release.

Recall that the TEB begins with some pointers which bound the stack, and the seventh pointer is a self-pointer. What's even more useful is the thirteenth pointer (offset 0x30 for 32-bit TEBs, offset 0x60 for 64-bit TEBs), because that is where the PEB is stored.

Each process has a single global PEB, so all the TEBs will have the same PEB value at offset 0x30/0x60. And you can figure out the address of the current process's PEB either by using the !peb command or by simply looking at the TEB you already have.

0:000> dd fs:30 l1
0053:00000030  7efde000

Now you can search through memory looking for that value. If you see any hits at offset 0x30/0x60, then that's a candidate TEB.

The debugger normally limits memory scans to 256MB.

0:001> s 00000000 L 80000000 00 e0 fd 7e
                           ^ Range error in 's 00000000 l 80000000 00 e0 fd 7e'

Therefore, you have to issue the search eight times (for 32-bit processes) to cover the 2GB user-mode address space.

0:001> s 00000000 L 10000000 00 e0 fd 7e
0009e01c  00 e0 fd 7e 00 d0 fd 7e-44 e0 09 00 7b ef 17 77  ...~...~D...{..w
0009fdc0  00 e0 fd 7e 44 00 00 00-f0 ee 3a 00 10 ef 3a 00  ...~D.....:...:.
0009fe34  00 e0 fd 7e 78 fe 09 00-02 9f 18 77 00 e0 fd 7e  ...~x......w...~
0:001> s 10000000 L 10000000 00 e0 fd 7e
0:001> s 20000000 L 10000000 00 e0 fd 7e
0:001> s 30000000 L 10000000 00 e0 fd 7e
0:001> s 40000000 L 10000000 00 e0 fd 7e
0:001> s 50000000 L 10000000 00 e0 fd 7e
0:001> s 60000000 L 10000000 00 e0 fd 7e
0:001> s 70000000 L 10000000 00 e0 fd 7e
7486af70  00 e0 fd 7e 00 00 00 00-b8 00 16 77 28 00 16 77  ...~.......w(..w
7efda030  00 e0 fd 7e 00 00 00 00-00 00 00 00 00 00 00 00  ...~............
7efdd030  00 e0 fd 7e 00 00 00 00-00 00 00 00 00 00 00 00  ...~............

Alternatively, you can use the "length sanity check override" by inserting a question mark after the L:

0:001> s 00000000 L?80000000 00 e0 fd 7e
0009e01c  00 e0 fd 7e 00 d0 fd 7e-44 e0 09 00 7b ef 17 77  ...~...~D...{..w
0009fdc0  00 e0 fd 7e 44 00 00 00-f0 ee 3a 00 10 ef 3a 00  ...~D.....:...:.
0009fe34  00 e0 fd 7e 78 fe 09 00-02 9f 18 77 00 e0 fd 7e  ...~x......w...~
7486af70  00 e0 fd 7e 00 00 00 00-b8 00 16 77 28 00 16 77  ...~.......w(..w
7efda030  00 e0 fd 7e 00 00 00 00-00 00 00 00 00 00 00 00  ...~............
7efdd030  00 e0 fd 7e 00 00 00 00-00 00 00 00 00 00 00 00  ...~............

From the above output, we see that we can quickly reject all but the last two entries because the offset within the page is not the magic value 0x30. (This is a 32-bit process.) Hooray, two debugger commands reduce the search space to just two pages!

At this point, you can continue with the debugging technique from last time, looking at each candidate TEB to see if there's a valid stack in there.

Charles Petzold is back with another edition of Programming Windows

Raymond Chen - MSFT — Thu, 17 May 2012 14:00:01 GMT

Back in the day (and perhaps still true today), Charles Petzold's Programming Windows was the definitive source for learning to program Windows. The book is so old that even I used it to learn Windows programming, back when everything was 16-bit and uphill both ways. The most recent edition is Programming Windows, 5th Edition, which was published way back in 1998. What has he been doing since then? My guess would have been "sitting on a beach in Hawaiʻi," but apparently he's been writing books on C# and Windows Forms and WPF and Silverlight. Hey, I could still be right: Maybe he writes the books while sitting on a beach in Hawaiʻi.

It appears that Windows 8 has brought Mr. Petzold back to the topic of Windows progarmming, and despite his earlier claims that he has no plans to write a sixth edition of Programming Windows, it turns out that he's writing a sixth edition of Programming Windows specifically for Windows 8. (Perhaps he could subtitle his book The New Old Thing.)

Here's where it gets interesting.

Before the book officially releases (target date November 15), there will be two pre-release versions in eBook form, one based on the Consumer Preview of Windows 8 and one based on the Release Preview.

Now it gets really interesting: If you order the Consumer Preview eBook, it comes with free upgrades to the Release Preview eBook as well as the final eBook. (If you order the Release Preview eBook, then it comes with a free upgrade to the final eBook.)

Can it get even more interesting than that? You bet! Because the price of getting in on the action increases the longer you wait. Act now, and you can get the Consumer Preview eBook (and all the free upgrades that come with it) for just $10. Wait a few weeks, and it'll cost you $20. Wait another few months, and it'll cost you $30; after another few weeks the price goes up to $40, and if you are a lazy bum and wait until the final eBook to be released, it'll cost you $50.

But in order to take advantage of this offer, you have to follow the instructions on this blog entry from Microsoft Press (and read the mandatory legal mumbo-jumbo, because the lawyers always get their say).

Bonus chatter: One publisher asked me if I wanted to write a book on programming Windows 8, but I told them that I was too busy shipping Windows 8 to have any extra time to write a book about it. And it's a good thing I turned them down, because imagine if I decided to write the book and found that Charles Petzold was coming out of retirement to write his own book. My book would have done even worse than my first book, which didn't even have any competition!

Bonus disclaimer: Charles Petzold did not pay me to write this, nor did he offer me a cut of his royalties for shilling his book. But that doesn't mean I won't accept it! (Are you listening, Charles?)

How to view the stack of threads that were terminated as part of process teardown from the kernel debugger

Raymond Chen - MSFT — Thu, 17 May 2012 14:00:00 GMT

As we saw some time ago, process shutdown is a multi-phase affair. After you call ExitProcess, all the threads are forcibly terminated. After that's done, each DLL is sent a DLL_PROCESS_DETACH notification. You may be debugging a problem with DLL_PROCESS_DETACH handling that suggests that some of those threads were not cleaned up properly. For example, you might assert that a reference count is zero, and you find during process shutdown that this assertion sometimes fires. Maybe you terminated a thread before it got a chance to release its reference? How can you test this theory if the thread is already gone?

It so happens that when all the threads are terminated during the early phase of process shutdown, the kernel is a bit lazy and doesn't free their stacks. It figures, hey, the entire process is going away soon, so the stack memory is going to be cleaned up as part of process termination. (It's sort of the kernel equivalent of not bothering to sweep the floor of a building that's about to be demolished.) You can use this to your advantage by grovelling the stacks that were left behind.

Hey, this is why you get called in to debug the hard stuff, right?

Before continuing, I need to emphasize that this information is for debugging purposes only. The structures and offsets are all implementation details which can change from release to release.

The first step is to identify where all the stacks are. The direct approach is difficult because the stacks can be all different sizes, so it's not easy to pick them out of a line-up. But one thing does come in a consistent size: The TEB.

From the kernel debugger, use the !process command to dump the process you are interested in, and from the header information, extract the VadRoot.

1: kd> !process -1
PROCESS 8731bd40  SessionId: 1  Cid: 0748    Peb: 7ffda000  ParentCid: 0620
    DirBase: 4247b000  ObjectTable: 96f66de0  HandleCount: 104.
    Image: oopsie.exe
    VadRoot 893de570 Vads 124 Clone 0 Private 518. Modified 643. Locked 0.
    DeviceMap 995628c0

Dump this VAD root with the !vad command, and pay attention only to the entries which say 1 Private READWRITE.

1: kd> !vad 893de570
VAD     level      start      end    commit
... ignore everything except "1 Private READWRITE" ...
8730a5f0 ( 6)         50       50         1 Private      READWRITE
9ab0cb40 ( 5)         60       7f         1 Private      READWRITE
893978b0 ( 6)         80       9f         1 Private      READWRITE
87302d30 ( 5)        110      110         1 Private      READWRITE
889693f8 ( 6)        120      121         1 Private      READWRITE
872f3fb8 ( 6)        170      170         1 Private      READWRITE
87089a80 ( 6)        1a0      1a0         1 Private      READWRITE
8cbf1cb0 ( 5)        1c0      1df         1 Private      READWRITE
88c079d0 ( 6)        1e0      1e0         1 Private      READWRITE
9abc33e0 ( 6)        410      48f         1 Private      READWRITE
873173b0 ( 7)        970      970         1 Private      READWRITE
8ca1c158 ( 7)      7ffd5    7ffd5         1 Private      READWRITE
88c02a78 ( 6)      7ffd6    7ffd6         1 Private      READWRITE
872f9298 ( 5)      7ffd7    7ffd7         1 Private      READWRITE
8750d210 ( 7)      7ffd8    7ffd8         1 Private      READWRITE
87075ce8 ( 6)      7ffda    7ffda         1 Private      READWRITE
87215da0 ( 4)      7ffdc    7ffdc         1 Private      READWRITE
872f2200 ( 6)      7ffdd    7ffdd         1 Private      READWRITE
8730a670 ( 5)      7ffdf    7ffdf         1 Private      READWRITE

(If you are debugging from user mode, then you can use !vadump but the output format is different.)

Each of these is a candidate TEB. In practice, TEBs tend to be allocated at the high end of memory, so the ones with a low start value are probably red herrings. Therefore, you should investigate these candidates in reverse order.

For each candidate, take the start address and append three zeroes. (Each page on x86 is 4KB, which conveniently maps to 1000 in hex.) Dump the first seven pointers of the TEB with the dp xxxxx000 L7 command.

1: kd> dp 7ffdf000 L7
7ffdf000  0016fbb0 00170000 0016b000 00000000
7ffdf010  00001e00 00000000 7ffdf000 ← hit

If the TEB is valid, then the seventh pointer points back to the start of the TEB. In a valid TEB, the second and third values are the stack limits; in this case, the candidate stack lives between 0016b000 and 00170000. (As a double-check, you can verify that the upper limit of the stack, 00170000 in this case, matches up with the end of a VAD allocation in the !vad output above.)

Now that you know where the stack is, you can dps it and look for EBP frames. (I usually start about two to four pages below the upper limit of the stack.) Test out each candidate EBP frame with the k= command until you find one that seems to be solid. Record this candidate stack trace in a text file for further study.

Repeat for each candidate TEB, and you will eventually reconstruct what each thread in the process was doing at the moment it was terminated. If you're really lucky, you might even see the code that incremented the reference count but was terminated before it could release it.

The above discussion also applies to debugging 64-bit processes. However, instead of looking for 1 Private READWRITE pages, you want to look for 2 Private READWRITE pages. As an additional wrinkle, if you are debugging ia64, then converting a page frame to a linear address is sadly not as simple as appending three zeroes. Pages on ia64 are 8KB, not 4KB, so you need to shift the value left by 25 bits: Add three zeroes and then multiply by two.

And finally, if you are debugging a 32-bit process on x64, then you want to look for 3 Private READWRITE pages, but add 2 before appending the three zeroes. That's because the TEB for a 32-bit process on x64 is really two TEBs glued together: A 64-bit TEB followed by a 32-bit TEB.

Note: I did not come up with this debugging technique on my own. I learned it from an even greater debugging genius.

Next time, we'll look at debugging this issue from a user-mode debugger.

Trivia: The informal term for these terminated-but-not-yet-completely-destroyed threads is ghost threads. The term was coined by the Exchange support team, because they often have to study server failures that require them to do this type of investigation, and they needed a cute name for it.

Sure, we do that: Context menu edition

Raymond Chen - MSFT — Wed, 16 May 2012 14:00:00 GMT

A customer reported a problem that occurred only when they installed a particular application. If they uninstalled it, then the problem went away. After installing the application, the "Run As" context menu option stopped working. The customer didn't provide any other details, but we were able to make an educated guess as to what was going on.

A common programming error in context menu extensions occurs in extensions which add only one menu item. These extensions ignore the parameters to the IContextMenu::InvokeCommand and simply assume that the only reason the method can be called is if the user selected their menu item. After all, if you have only one invokable item, there's no need to figure out which one the user selected, because you have only one to begin with!

The problem is that a context menu extension can be invoked not because the user selected an item under its control but because a verb is being invoked programmatically, and each handler is being asked, "Do you know how to do this?"

The result is that the context menu host calls the extension to say, "If you know how to do runas, then please do so," and the the extension says "Sure, we do that" and starts doing its thing. If you are unlucky and the grabby extension is asked the question before the actual runas extension, the runas command winds up being hijacked by the grabby extension.

(This is the same mistake that causes the Copy To and Move To commands to behave strangely if you add them to the context menu: They assume that the only reason they are invoked is that the user invoked their command, because they weren't designed to be hosted by context menus to begin with! They were designed to go into the toolbar, and the toolbar hosting code never invoked commands by name. It's like taking a ladder and using it as a bridge between two tall buildings. Sure, you can now cross from one building to another, but you also run a serious risk of falling to your death.)

A variation on the initial problem is "I found that after installing a particular program, I can't run anything from the Start menu." I know of at least two programs which install context menu extensions which steal the "open" command on executables.

This problem is sufficiently prevalent that there is a special compatibility flag that can be set on a shell extension to say, "This is a grabby shell extension that steals commands. Never ask it if it supports anything, because it will always say yes!"

Notice that the "MoveTo CopyTo Context Menu" is on the list, which I find interesting because MoveTo/CopyTo was never meant to go on the context menu in the first place. Going back to our analogy, it'd be as if the ladder company issued a safety bulletin to warn people of problems that can occur if you use it as a bridge between two tall buildings!

Microspeak: The parking lot

Raymond Chen - MSFT — Tue, 15 May 2012 14:00:00 GMT

Mike Dunn wonders what the Microspeak term parking lot means.

I'm not familiar with this term either, and the first document I turned up during my search was a PowerPoint presentation that said "Avoid using Microsoft jargon terms, such as parking lot and dogfood."

Yeah, that wasn't much help.

From what I can gather, the term parking lot started out as a term used during brainstorming sessions. You've got a bunch of people in a conference room tossing out all sorts of ideas. The traditional way of organizing the ideas is to write each one on a Post-It® note and stick it on the whiteboard. As more and more notes appear, you start to organize them by grouping together similar ideas.

Every so often, you'll run into an idea that, while good, isn't really relevant to the problem you're trying to solve. You don't want to throw it away, so instead, you designate a corner of the whiteboard to be the place to "park" those ideas for later consideration. That corner of the whiteboard is nicknamed the parking lot.

The term parking lot then began to be applied to the document that collected all of these "parked" ideas, so they could be circulated to a more appropriate audience.

The term then expanded to refer to any document which served as the official repository of assorted suggestions for future work or discussion. (Known to some people simply as The List.) For example, there is a SharePoint List titled Active Issues and the subtitle parking lot for discussion topics in weekly XYZ meeting. Each item on the list is assigned to a particular person and assigned a priority.

I can't find any citations for parking lot being used as a way to say something like "we'll talk about this after the meeting is over," but I can see how it could be related to the sense of parking lot I was able to turn up: The parking lot is the list of things that aren't really relevant to the topic at hand but which are still worth discussing. We just won't discuss them here.

What is the historical reason for MulDiv(1, -0x80000000, -0x80000000) returning 2?

Raymond Chen - MSFT — Mon, 14 May 2012 14:00:00 GMT

Commenter rs asks, "Why does Windows (historically) return 2 for MulDiv(1, -0x80000000, -0x80000000) while Wine returns zero?"

The MulDiv function multiplies the first two parameters and divides by the third. Therefore, the mathematically correct answer for MulDiv(1, -0x80000000, -0x80000000) is 1, because a × b ÷ b = a for all nonzero b.

So both Windows and Wine get it wrong. I don't know why Wine gets it wrong, but I dug through the archives to figure out what happened to Windows.

First, some background. What's the point of the MulDiv function anyway?

Back in the days of 16-bit Windows, floating point was very expensive. Most people did not have math coprocessors, so floating point was performed via software emulation. And the software emulation was slow. First, you issued a floating point operation on the assumption that you had a float point coprocessor. If you didn't, then a coprocessor not available exception was raised. This exception handler had a lot of work to do.

It decoded the instruction that caused the exception and then emulated the operation. For example, if the bytes at the point of the exception were d9 45 08, the exception handler would have to figure out that the instruction was fld dword ptr ds:[di][8]. It then had to simulate the operation of that instruction. In this case, it would retrieve the caller's di register, add 8 to that value, load four bytes from that address (relative to the caller's ds register), expand them from 32-bit floating point to 80-bit floating point, and push them onto a pretend floating point stack. Then it advanced the instruction pointer three bytes and resumed execution.

This took an instruction that with a coprocessor would take around 40 cycles (already slow) and ballooned its total execution time to a few hundred, probably thousand cycles. (I didn't bother counting. Those who are offended by this horrific laziness on my part can apply for a refund.)

It was in this sort of floating point-hostile environment that Windows was originally developed. As a result, Windows has historically avoided using floating point and preferred to use integers. And one of the things you often have to do with integers is scale them by some ratio. For example, a horizontal dialog unit is ¼ of the average character width, and a vertical dialog unit is 1/8 of the average character height. If you have a value of, say, 15 horizontal dlu, the corresponding number of pixels is 15 × average character width ÷ 4. This multiply-then-divide operation is quite common, and that's the model that the MulDiv function is designed to help out with.

In particular, MulDiv took care of three things that a simple a × b ÷ c didn't. (And remember, we're in 16-bit Windows, so a, b and c are all 16-bit signed values.)

The intermediate product a × b was computed as a 32-bit value, thereby avoiding overflow.
The result was rounded to the nearest integer instead of truncated toward zero
If c = 0 or if the result did not fit in a signed 16-bit integer, it returned INT_MAX or INT_MIN as appropriate.

The MulDiv function was written in assembly language, as was most of GDI at the time. Oh right, the MulDiv function was exported by GDI in 16-bit Windows. Why? Probably because they were the people who needed the function first, so they ended up writing it.

Anyway, after I studied the assembly language for the function, I found the bug. A shr instruction was accidentally coded as sar. The problem manifests itself only for the denominator −0x8000, because that's the only one whose absolute value has the high bit set.

The purpose of the sar instruction was to divide the denominator by two, so it can get the appropriate rounding behavior when there is a remainder. Reverse-compiling back into C, the function goes like this:

int16 MulDiv(int16 a, int16 b, int16 c)
{
 int16 sign = a ^ b ^ c; // sign of result

 // make everything positive; we will apply sign at the end
 if (a < 0) a = -a;
 if (b < 0) b = -b;
 if (c < 0) c = -c;

 //  add half the denominator to get rounding behavior
 uint32 prod = UInt16x16To32(a, b) + c / 2;
 if (HIWORD(prod) >= c) goto overflow;
 int16 result = UInt32Div16To16(prod, c);
 if (result < 0) goto overflow;
 if (sign < 0) result = -result;
 return result;

overflow:
 return sign < 0 ? INT_MIN : INT_MAX;
}

Given that I've already told you where the bug is, it should be pretty easy to spot in the code above.

Anyway, when this assembly language function was ported to Win32, it was ported as, well, an assembly language function. And the port was so successful, it even preserved (probably by accident) the sign extension bug.

Mind you, it's a bug with amazing seniority.

Warum deine Mutter Deutsch spricht

Raymond Chen - MSFT — Fri, 11 May 2012 14:00:01 GMT

This upcoming Sunday is Mother's Day in the United States. In recognition of the holiday last year, a local church displayed the following message on its message board: "God couldn't be / everywhere / so God made mothers / German speaking."

This explains why your mother speaks German.

POIDH

The church in question has an evening German-language service, and the advertisement for that service juxtaposed against the Jewish proverb produced an unexpected result.

When you crash on a mov ebx, eax instruction, there aren't too many obvious explanations, so just try what you can

Raymond Chen - MSFT — Fri, 11 May 2012 14:00:00 GMT

A computer running some tests encountered a mysterious crash:

eax=ffffffff ebx=00000000 ecx=038ef548 edx=17b060b4 esi=00000000 edi=038ef6f0
eip=14ae1b77 esp=038ef56c ebp=038ef574 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202
FOO!CFrameWnd::GetAssociatedWidget+0x47:
14ae1b77 8bd8            mov     ebx,eax

A colleague of mine quickly diagnosed the proximate cause.

*Something* marked the code page PAGE_READWRITE, instead of PAGE_EXECUTE_READ. I suspect a bug in a driver. FOO is just a victim here.
0:002> !vprot 14ae1b77 
BaseAddress:       14ae1000
AllocationBase:    14ae0000
AllocationProtect: 00000080  PAGE_EXECUTE_WRITECOPY
RegionSize:        00001000
State:             00001000  MEM_COMMIT
Protect:           00000004  PAGE_READWRITE
Type:              01000000  MEM_IMAGE

This diagnosis was met with astonishment. "Wow! What made you think to check the protection on the code page?"

Well, let's see. We're crashing on a mov ebx, eax instruction. This does not access memory; it's a register-to-register operation. There's no way a properly functioning CPU can raise an exception on this instruction.

At this point, what possibilities remain?

NX, which prevents the CPU from executing data.
Overclocking, which will cause all sorts of "impossible" things.
A root kit.

(Note that the second and third options involve rejecting the assumption that the CPU is behaving properly.)

These are in increasing order of paranoia, so you naturally start with the least paranoid possibility.

Then, of course, there's the non-psychic solution: Ask the debugger for the exception record.

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 14ae1b77 (FOO!CFrameWnd::GetAssociatedWidget+0x00000047)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000008
   Parameter[1]: 14ae1b77
Attempt to execute non-executable address 14ae1b77

That last line pretty much hands it to you on a silver platter.

Cheap amusement: Searching for spelling errors in the registry

Raymond Chen - MSFT — Thu, 10 May 2012 14:00:00 GMT

One source of cheap amusement is searching for spelling errors in the registry. For example, one program tried to register a new file extension, or at least they tried, except that they spelled Extension wrong.

And they wonder why that feature never worked.

My discovery was that my registry contained the mysterious key HKEY_CURRENT_USER\S. After some debugging, I finally found the culprit. There was a program on my computer that did the equivalent of this:

RegCreateKeyA(HKEY_CURRENT_USER, (PCSTR)L"Software\\...", &hk);

One of my colleagues remarked, "With enough force, any peg will fit in any hole."

I suspect that the code was not that aggressively wrong. It was probably something more subtle.

How do I hide a window without blocking on it?

Raymond Chen - MSFT — Wed, 09 May 2012 14:00:00 GMT

A customer was working on improving their application startup performance. They found that if their application was launched immediately after a fresh boot, the act of dismissing their splash screen was taking over 5% of their boot time. Their code removed the splash screen by calling ShowWindow(hwndSplash, SW_HIDE). They suspect that the splash screen thread has, for some reason, stopped responding to messages, and while an investigation into that avenue was undertaken, a parallel investigation into reducing the cost of hiding the splash screen was also begun.

One of the things they tried was to remove the WS_EX_TOOLWINDOW style and call ITaskbarList::DeleteTab(hwndSplash) but they found that it wasn't helping.

The reason it wasn't helping is that editing the window style generates WM_STYLECHANGING/WM_STYLECHANGED messages to the target window, and now you're back where you started.

A better way is to use ShowWindowAsync(hwndSplash, SW_HIDE). The -Async version of the ShowWindow function is the SendNotifyMessage version of ShowWindow: If the window belongs to another thread group, then it schedules the operation but does not wait for it to complete.

Why can't I use the file sharing wizard if I exclude inheritable permissions from a folder's parent?

Raymond Chen - MSFT — Tue, 08 May 2012 14:00:00 GMT

In Windows Vista and Windows Server 2008, if you go to a the advanced security settings for a directory and uncheck "include inheritable permissions from this object's parent", then go back to the Sharing tab, you'll find that the "Share" button is disabled. Why is this? We don't see this behavior on Windows 7 or Windows Server 2008 R2.

(Yes, a customer actually noticed and asked the question.)

The sharing wizard in Windows Vista and Windows Server 2008 does not support folders with the SE_DACL_PROTECTED security descriptor control bit because it isn't sure that it can restore the ACL afterward.

And as the customer noted, this restriction was lifted in Windows 7 and Windows Server 2008 R2.

Why are the Windows 7 system notification icons colorless?

Raymond Chen - MSFT — Mon, 07 May 2012 14:00:00 GMT

Mike wondered why the system notification icons went colorless in Windows 7 and why they went back to regular tooltips instead of the custom tooltips.

I don't know either, so I asked Larry Osterman, who was in charge of the Volume icon.

And he didn't know either. He was merely given new icons by the design team.

But that doesn't stop me from guessing. (Which is what I do most of the time here, I just don't explicitly say that I'm guessing.)

My guess is that the design team looked at the new Windows 7 taskbar and noticed that all the system-provided pieces were subdued and unobtrusive, with two exceptions: The Start button itself and the notification icons. The Start button kept its bright colors because, well, it's the Start button. But the notification icons? They are peripheral elements; why do they stand out on an otherwise neutral-looking taskbar? Isn't that just drawing the user's attention to something that doesn't deserve attention?

So boom, make them monochromatic to fit with the other taskbar elements. The clock is monochromatic. The Show Desktop button is monochromatic. The taskbar itself is monochromatic. Hooray, aesthetic unity is restored.

As for the return to standard tooltips, that's easy: The custom tooltip was a violation of the user interface guidelines.

The old Windows Vista custom tooltip did not provide any useful information beyond the standard tooltip, so you paid the cost of developing and maintaining a custom tooltip for very little benefit. In the volume tooltip's case, the developers were spending effort fixing little bugs here and there (for example, there were painting glitches under certain accessibility conditions), effort that was detracting from other work that could be done, and switching to the standard tooltip made all the problems go away.

How does the MultiByteToWideChar function treat invalid characters?

Raymond Chen - MSFT — Fri, 04 May 2012 14:00:00 GMT

The MB_ERR_INVALID_CHARS flag controls how the MultiByteToWideChar function treats invalid characters. Some people claim that the following sentences in the documentation are contradictory:

"Starting with Windows Vista, the function does not drop illegal code points if the application does not set the flag."
"Windows XP: If this flag is not set, the function silently drops illegal code points."
"The function fails if MB_ERR_INVALID_CHARS is set and an invalid character is encountered in the source string."

Actually, the three sentences are talking about different cases. The first two talk about what happens if you omit the flag; the third talks about what happens if you include the flag.

Since people seem to like tables, here's a description of the MB_ERR_INVALID_CHARS flag in tabular form:

`MB_ERR_INVALID_CHARS` set?	Operating system	Treatment of invalid character
Yes	Any	Function fails
No	XP and earlier	Character is dropped
No	Vista and later	Character is not dropped

Here's a sample program that illustrates the possibilities:

#include <windows.h>
#include <ole2.h>
#include <windowsx.h>
#include <commctrl.h>
#include <strsafe.h>
#include <uxtheme.h>

void MB2WCTest(DWORD flags)
{
 WCHAR szOut[256];
 int cch = MultiByteToWideChar(CP_UTF8, flags,
                               "\xC0\x41\x42", 3, szOut, 256);
 printf("Called with flags %d\n", flags);
 printf("Return value is %d\n", cch);
 for (int i = 0; i < cch; i++) {
  printf("value[%d] = %d\n", i, szOut[i]);
 }
 printf("-----\n");
}

int __cdecl main(int argc, char **argv)
{
 MB2WCTest(0);
 MB2WCTest(MB_ERR_INVALID_CHARS);
 return 0;
}

If you run this on Windows XP, you get

Called with flags 0
Return value is 2
Value[0] = 65
Value[1] = 66
-----
Called with flags 8
Return value is 0
-----

This demonstrates that passing the MB_ERR_INVALID_CHARS flag causes the function to fail, and omitting it causes the invalid character \xC0 to be dropped.

If you run this on Windows Vista, you get

Called with flags 0
Return value is 3
Value[0] = 65533
Value[1] = 65
Value[2] = 66
-----
Called with flags 8
Return value is 0
-----

This demonstrates again that passing the MB_ERR_INVALID_CHARS flag causes the function to fail, but this time, if you omit the flag, the invalid character \xC0 is converted to U+FFFD, which is REPLACEMENT CHARACTER. (Note that it does not appear to be documented precisely what happens to invalid characters, aside from the fact that they are not dropped. Perhaps code pages other than CP_UTF8 convert them to some other default character.)

How does Explorer calculate the folder size information in the folder tooltip?

Raymond Chen - MSFT — Thu, 03 May 2012 14:00:00 GMT

This information is accurate as of Windows 7; the algorithm may change for future versions of Windows. The information is being provided for the edification of computer network administrators, who are curious about random stuff like this since it can affect their network load.

When you hover over a folder, Explorer shows an infotip (a special type of tooltip) which contains information about the directory, and the information that concerns network administrators is the "Size". How does Explorer calculate the size?

Explorer calculates the size by performing a naïve recursive listing of the directory and adding up the sizes of all the files it finds. If the enumeration takes longer than three seconds, then Explorer gives up after three seconds and reports the size as "larger than X" where X was the size it managed to calculate so far.

If you don't want Explorer to do this calculation, you can disable it from the Folder Options control panel by unchecking the box labeled Display file size information in folder tips.

Why is there sometimes a long delay between pressing a hotkey for a shortcut and opening the shortcut?

Raymond Chen - MSFT — Wed, 02 May 2012 14:00:00 GMT

Via a customer liaison, we received a problem report from a customer.

The customer is facing issues with delayed desponses to opening a .lnk file by pressing its keyboard shortcut hotkey. This delay does not appear when the shortcut is double-clicked.

For example, the customer has created a shortcut to Notepad and assigned it the shortcut Ctrl+Alt+X. Pressing the keyboard combination sometimes takes 5 or 6 seconds for Notepad to open. As noted above, double-clicking on the shortcut causes Notepad to open without delay.

This issue is not consistently reproducible, but it appears to be independent of the shortcut file itself. Any shortcut with a hotkey exhibits this problem.

All the shortcuts in question are on the desktop.

The short answer is "There is a program running on your machine that occasionally stops responding to messages. If you press a shortcut hotkey during those moments, you will experience this problem. Identify the program that stops responding to messages and fix it."

Okay, that sort of cuts to the chase, but the interesting part is the journey, not the destination.

First, observe that if you associate a hotkey with a shortcut to say Notepad, and you press the hotkey twice, you do not get two copies of Notepad. The first time you press the hotkey, Notepad launches, but the second time you press the hotkey, focus is put on the existing copy of Notepad. This is one of those things that's so natural you may not even realize that it's happening.

When you press the hotkey assigned to a shortcut, Explorer receives the hotkey and needs to decide what to do about it. Before it can launch the shortcut, it needs to see if the shortcut target already has a window open, in which case it should just switch to that window.

Finding out whether a window has a hotkey is done by sending the window the WM_GETHOTKEY message. When you press a hotkey that is assigned to a shortcut, Explorer goes to all the windows already on the screen and asks each one, "Hey, what's your hotkey?" If any window says, "My hotkey is Ctrl+Alt+X," then Explorer says, "Oh, sorry to step on your toes. The user pressed your hotkey, so here, go ahead and take focus."

If no window cops to having Ctrl+Alt+X as its hotkey, Explorer says, "Okay, well, then I guess I have to make one." It launches Notepad and tells it, "Oh, and your hotkey is Ctrl+Alt+X."

If there is a window that is not responding to messages, then when Explorer asks it, "Hey, what's your hotkey?", the window just sits there and doesn't answer. After about three seconds, Explorer gives up. "Yeesh, I was just asking a question. Don't have to give me the silent treatment."

And that petulant window is the source of the 3-second delay. It takes Explorer 3 seconds before it finally gives up and says, "Forget it. Even if that was somebody's hotkey, they're being a jerk, so I'm just going to pretend they didn't have a hotkey. Let me open a new window instead and just deal with the hotkey conflict."

What happened to the Summary information created on Windows 2000 and Windows XP?

Raymond Chen - MSFT — Tue, 01 May 2012 14:00:00 GMT

In Windows 2000 and Windows XP, you could add Summary information on the Details property page to files of all types. Text files, image files, some crazy file your grandmother sent you in a file format you don't know how to open. If Windows supports storing the Summary information in the file itself (for example, in EXIF tags or in Structure Storage properties), then the information gets stored there. Otherwise, Windows stashes the information in an alternate data stream. Windows Vista dropped support for storing Summary information in alternate data streams. What happened?

Support for storing Summary information in an alternate data stream was dropped in Windows Vista because alternate data streams were found to be too fragile. If you back up the file to a CD-ROM or email it to a friend or copy it to a thumb drive or upload it to a Web site or store it in a ZIP file, the alternate data stream ends up lost. It was determined that it was better simple not to allow users to create data that was so easy to destroy accidentally.

When you don't speak a language, don't sound like you speak the language

Raymond Chen - MSFT — Mon, 30 Apr 2012 14:00:01 GMT

I appreciate the help from Christoph and Voo in refining my German. But that reminds me of a story about a friend of a friend.

She was in Japan to visit some friends. Although she speaks English and Mandarin fluently, she doesn't know any Japanese, so her friends taught her how to say "Sorry, I don't speak Japanese." She managed to say this sentence quite well despite learning it purely phonetically.

One day they were walking down the street as a group, and a gentleman approached and asked her for directions. She responded with the only sentence she knew: "Sorry, I don't speak Japanese."

The gentleman was offended by this response and began scolding her for her rudeness. "Look, if you don't want to talk to me, just say so. Don't pretend like you don't speak Japanese." Since he was scolding her in Japanese, all she could do was stand there bewildered while this guy yelled at her.

Fortunately, her friends intervened and explained to the gentleman, "No really, she doesn't speak any Japanese. We just taught her that one sentence."

The lesson I took from this story was that when you don't speak a language, it's important to sound like you don't speak the language. In a way, it's a good thing that my German is a little bit off. That way, the person I'm talking with knows that my German is not all that great.

Examples: During a trip to Germany, I discovered that when I asked a simple question, people would answer in rapid-fire German, overflowing my internal parsing buffer. During my trip to Sweden, I applied the lesson from this article, and found that people switched to simpler Swedish and spoke more slowly. As a result, I had little difficulty understanding what people were saying to me. (Of course, it didn't help me understand what they were saying to each other.)

What were the tests that WinG did to evaluate video cards?

Raymond Chen - MSFT — Mon, 30 Apr 2012 14:00:00 GMT

Georg Rottensteiner was curious about the weird things that WinG performed on installation to evaluate video cards. "What did it do actually and what for?"

I don't actually know, since I was not involved in the WinG project, but I remember chatting with one of the developers who was working on video card benchmarks.

He says that video card benchmarks are really hard to develop, not just because video cards are complicated, but also because video drivers cheat like a Mississippi riverboat card sharp on a boat full of blind tourists.

He discovered all sorts of crazy shenanigans. Like a video driver which compares the string you ask it to display with the text "The quick brown fox jumps over the lazy dog." If the string matches exactly, then it returns without drawing anything three quarters of the time. The reason: Benchmarks often use that sample string to evaluate text rendering performance. The driver vendors realized that the fastest code is code that doesn't run, so by ignoring three quarters of the "draw this string" requests, they could improve their text rendering performance numbers fourfold.

That was the only one of the sneaky tricks I remember from that conversation. (I didn't realize there was going to be a quiz 17 years later or I'd have taken notes.) Another example of benchmark cheating was a driver which checked if the program name was TUNNEL.EXE and if so, enabled a collection of benchmark-specific optimizations.

Anyway, I suspect that the weird things that the WinG installer did were specifically chosen to be things that no video card driver had figured out a way to cheat, at least at the time he wrote the test. I wouldn't be surprised if fifteen seconds after WinG was released, video driver vendors started studying it to see how they could cheat the WinG benchmark...

A process shutdown puzzle, Episode 2

Raymond Chen - MSFT — Fri, 27 Apr 2012 14:00:00 GMT

A customer reported that their program would very sporadically crash in the function CloseThreadpoolCleanupGroupMembers. The customer was kind enough to provide a stack trace at the point of the crash:

ntdll!RtlUnhandledExceptionFilter2+0x31e
KERNELBASE!UnhandledExceptionFilter+0x175
ntdll!RtlUserThreadStart$filt$0+0x3f
ntdll!__C_specific_handler+0x8f
ntdll!RtlpExecuteHandlerForException+0xd
ntdll!RtlDispatchException+0x3a6
ntdll!RtlRaiseException+0x223
ntdll!TppRaiseInvalidParameter+0x48
ntdll!TpReleaseCleanupGroupMembers+0x246
litware!CThreadPool::UnInitialize+0x22
litware!_CRT_INIT+0xbf
litware!__DllMainCRTStartup+0x18b
ntdll!LdrpCallInitRoutine+0x3f
ntdll!LdrShutdownProcess+0x205
ntdll!RtlExitUserProcess+0x90
kernel32!ExitProcessImplementation+0xa
contoso!wmain+0x193
contoso!__wmainCRTStartup+0x13d
kernel32!BaseThreadInitThunk+0xd
ntdll!RtlUserThreadStart+0x1d

The customer wondered, "Could the problem be that my cleanup group does not have a callback? MSDN seems to suggest that this is okay."

The exception being thrown is STATUS_INVALID_PARAMETER, but that doesn't really say much.

But that's okay, because the smoking gun isn't the exception being raised. It's in the stack.

Do you see it?

The code is calling CloseThreadpoolCleanupGroupMembers from inside DllMain while handling the DLL_PROCESS_DETACH notification. Looking further up the stack, you can see this was triggered by a call to ExitProcess, and now all the stuff you know about how processes exit kicks in.

For example, that the first thing that happens is that all threads are forcibly terminated.

That's your next clue.

Observe that the customer's DLL is trying to communicate with the thread pool during process termination. But wait, all the threads have already been terminated. It's trying to communicate with a nonexistent thread pool.

The thread pool realizes, "Hey, like I've already been destroyed. I can't do what you ask because there is no thread pool any more. You want me to block until all currently executing callback functions finish, but those callback functions will never finish (if they even exist at all) because the threads hosting their thread pool got destroyed. Not that I can tell whether they are executing or not, because I am already destroyed. The only options are to hang or crash. I think I'll crash."

The customer needs to restructure the program so that it either cleans up its thread pool work before the ExitProcess, or it can simply skip all thread pool operations when the reason for the DLL_PROCESS_DETACH is process termination.

Shortcut properties are in the shortcut, so if they can read the shortcut, they can read the properties

Raymond Chen - MSFT — Thu, 26 Apr 2012 14:00:00 GMT

A customer wanted to know if "there was a way to hide the properties of a shortcut."

We asked for an explanation of the problem they were trying to solve, so we could understand what their question meant. The customer liaison explained:

The customer is insisting on this, even though I think it's really the wrong approach. They want to put a password into the parameters of a shortcut, but they don't want their employees to see the password when they right-click the shortcut and select Properties. We're trying to convince them of better ways of doing this, but right now they want to see if they can solve it by marking the field as "hidden" somehow.

If the password is anywhere in the shortcut file, the employees can dig it out. After all, the shell needs to dig it out, and since the shell runs with the user's privileges, in order for the shell to see it, the user must be able to see it. In other words, you can't hide anything in a shortcut because the user can just open the shortcut in Notepad and see all your "hidden" data. Or they can go to Task Manager and ask to see the command line. Or they can connect a debugger to Explorer and set a breakpoint on the CreateProcess function.

It's like saying, "I want my employees to be able to bake cakes, but I don't want them to have access to an oven. To block access to the oven, I put a combination lock on the oven controls. On the other hand, I want to write a cake recipe that lets the employees bake cakes in the oven. Therefore, the recipe says Step 5: Go to the oven and press 1234. But now the employee can just read the recipe and find out the combination to the oven! Is there a way I can write a cake recipe that lets them bake a cake without revealing the oven combination?"

The recipe executes with the privileges of the employee. If you want the employee to be able to bake a cake by following the recipe, then they need to be able to perform the steps in the recipe, and that means being able to go to the oven and press 1234.

The oven analogy does provide some ideas on how you can solve the problem. For example, if you simply don't want employees to be able to email the oven combination to their friends with the subject line Here's the combination to the oven!, then change the way access to the oven is managed. Instead of putting a combination lock on the oven, put an employee ID card scanner on the oven that enables the oven controls if the employee has oven privileges.

For the original problem, this means changing your database so that instead of using a single password to control access and trusting each client to use it wisely, it uses the security identity of the client to control access. (I'm assuming that the password on the command line is a database password.)

On the other hand, if your goal is to prevent employees from using the oven to do anything other than bake at 350°F for one hour, you can change the employee ID card scanner so that it checks the employee for cake-baking privileges, and if so, sets the oven to bake for 350°F for one hour and locks the controls (except perhaps for a cancel button). If you have multiple recipes—say, cakes and cookies—the ID card scanner checks which recipes the employees are allowed to use and lets them choose which preset they want to activate.

For the original problem, this means changing your database so that the user identity selects which operations are permitted on the database. Some users have permission to see only records for active clients, whereas others have permission to see all records, and still others have modify permission.

If your goal is to prevent employees from doing anything other than baking cakes according to this specific recipe, then you need to move even more actions "behind the counter", because you have no way of knowing that "that pan full of batter" was created according to your walnut cake recipe, or whether it's some unauthorized recipe with extra cinnamon. If you don't trust your employees to follow recipes, then you need to take the recipe out of their hands. The instructions are now Step 1: Order a walnut cake from the cafeteria.

For the original problem, this means changing your database so that instead of letting the employee access records directly, the employee submits the action to the database ("change client 23 address to 123 Main Street"), and the database verifies that the employee has "change a client address" permission, and if so, performs the record update.

Of course, if you want to ignore all the security guidance and "just hide the password in the shortcut file, why won't you answer my question?", you can just put the password somewhere other than the shortcut file. You could, say, have the shortcut run a batch file, and the batch file has the password.