Larry Osterman said:

Funny .  That's actually a bug in the v5 common controls.  If your app is manifested to use the v6 common controls it won't happen.

 

The problem is that a bug fix made during Windows XP wasn't included in Win2K3.  The Win2K3 code was used to create Windows Vista and when the teams merged the Windows XP bug fixes into Win2K3, they missed this bug fix. 

 

I found it early in the Win7 timeframe because someone reported that their windows forms app was misbehaving after they'd set the common control select sound to a value then removed the value.

 

Needless to say, it's fixed in Win7.

 

"Needless to say" ? Given that Microsoft hardly ever fix bugs like this I'd say it would be more accurate to say "Amazingly, it's fixed in Win7".

I've been having a weird problem with VC++ lately and was just wondering if anyone else had seen this and more importantly knew how to resolve it!

I have quite a large solution, with multiple projects (if that matters). I also have multithread building enabled. What has been happening lately is if, for example, I make a change to a single source file and then build the project, the compiler will be launched twice for the same file. This then causes an error because (unsurprisingly) the second instance of the compiler isn't able to write to the .sbr file while the first instance is, which causes the build to fall over.

Here's an example of what I see:

1>------ Build started: Project: testproject, Configuration: Debug x64 ------
1>Compiling...
1>testfile.cpp
1>testfile.cpp
1>.\testfile.cpp(1) : fatal error C1083: Cannot open compiler generated file: 'x64\Debug\testfile.sbr': Permission denied
1>Creating browse information file...
1>Microsoft Browse Information Maintenance Utility Version 9.00.21022
1>Copyright (C) Microsoft Corporation. All rights reserved.
1>Build Time 0:05
1>Build log was saved at "file://c:\Users\Jon\Documents\Visual Studio Projects\testproject\trunk\testproject\testproject\x64\Debug\BuildLog.htm"
1>testproject - 1 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 48 up-to-date, 0 skipped ==========

I've checked the obvious (that the source file isn't included in the project twice somehow) and it's definitely not. This seems to happen with all files in the project, not just one, and also doesn't seem to happen ALL the time (although it is very frequent).

Anyone got any ideas?

Thanks!

LeoDavidson said:

lol

Charles said:

jon_potter said:

*snip*

Actually, I think your metaphor is not entirely correct in this context. This entire argument is centered around the fact, and it is a fact regardless of vector, that code gets on your machine and it executes without you knowing (memory attack on some trusted program's memory management code from a remote source or the screensaver you thought was a screensaver is not a screensaver, but you downloaded and executed it anyway, ignoring, say, IE's warning that doing so may be a bad idea. But this isn't the issue here. We assume something is executing on your machine. That's the implicit fact here. Let's move on.).

Your metaphor is more precisely stated like this, in my opinion:

It's like saying that the my front door is a security feature when the robber is already in my living room (or basement or garage or kitchen).

UAC is the doorbell or the knock. You can choose to open or not, but what happens when you are unable to see or even guess who or what is at the door? Do you open the door under these circumstances? UAC tells you nothing that enables you to reason about what opening the door will manifest itself as when it walks in. So, either grandma walks in with a cake and some whiskey or a melancholy character with a keen desire to slice you into pieces enters. Does your front door protect you from harm if you open it when the doorbell rings? Does your front door provide you with useful and accurate information about the person or thing standing on the other side of it , his or her's intention once the door opens, that you can use to rationalize your action of either opening or not opening the door?

The notion that UAC will protect you from harm is not one that anybody is preaching. Not really. Right? It's stated goal is that of pushing developers to write code that runs in standard user mode which will then encourage users to create desktop sessions under a Standard User account (and in this scenario, this problem of silent elevation due to default prompt state is no longer a scenario to worry about).

Also, in keeping with the door analogy (which I like, by the way, so thank you for using it), if you ask the person knocking on your door "who's there?" and they do not answer, what do you do? If you ask "what do you want? why are you here?" and they don't answer, what do you do? How do you reason about what to do if you have no idea about intent?

Here's what everybody does know: UAC will not ship with an Always Notify prompt level in Windows 7. In fact, this is the crux of the problem here as far as I can tell. What UAC actually does and why, what problems UAC is designed to solve and why, these are problems that the Always Notify prompt setting does not solve.

A rainy Sunday. Somewhere in the Bronx. Early afternoon. A tea kettle whistles in the background. A young man is typing at his computer. A UAC Prompt happens. UAC engages the user in some rather shallow discourse:

UAC: "Warning. Application X needs your permission to run"

User: "Well, what is Application X trying to do?"

UAC: "Warning. Application X needs your permission to run"

User: "OK. What is Application X. I don't recognize it."

UAC: "Warning. Application X needs your permission to run"

User: "Fine. I have better things to do than play this game. Oh crap. The tea... Allow."

C

Let me rephrase the analogy then. Calling UAC a security feature is like saying the lock on my door is a security feature when there's a key to the lock hanging next to it on a piece of string.

Larry Osterman said:

LeoDavidson said:

*snip*

Leo: It is a security feature.  It's not a security barrier.  The two are very different.  It's a security feature because anything that is added to the operating system is a "feature".  For instance the stream switching logic added to Win7 is a "feature".  But it's not a security barrier - it can't be defended and doesn't materially enhance the security of the user when it's enabled.

While it's not a security boundary, UAC+IL IS a convenience feature - you can think of it as a modern version of the old "makemeadmin.cmd" tool (with the added "protections" of the IL feature which make it harder for malware to attack the elevated process.

UAC+IL has always been a defense-in-depth mechanism (like ASLR, /GS and DEP), but it's not a barrier.

Arguing the difference between the term "feature" and "boundary" (or "barrier") seems to me to be obscuring the real issue, which is the misuse of the term "security". I fail to see how UAC can now be described as a security feature when it offers no security whatsoever. It's like saying the lock on my door is a security feature when the door is made of paper.

Charles said:

AndyC said:

*snip*

Whatever. I'm finished with this topic.

C

"Whatever. I'm finished with this topic."

Is it only me that's reminded of a child putting their hands over their ears and shouting "I'M NOT LISTENING I'M NOT LISTENING"?