Someone sent the following screen shot to one of our internal troubleshooting aliases. They wanted to know what the "Name Not Available" slider meant.
The audio system on Vista keeps track of the apps that are playing sounds (it has to, to be able to display the information on what apps are playing sounds :)). It keeps this information around for a period of time after the application has made the sound to enable the scenario where your computer makes a weird sound and you want to find out which application made the noise.
The system only keeps track of the PID for each application, it's the responsibility of the volume mixer to convert the PID to a reasonable name (the audio service can't track this information because of session 0 isolation).
This works great, but there's one possible problem: If an application exits between the time when the application made a noise and the system times out the fact that it played the noise, then the volume mixer has no way of knowing what the name of the application that made the noise was. In that case, it uses the "Name Not Available" text to give the user some information.
Andre: OpenProcess takes a PID
You're right, OpenProcess() takes the PID, but that's the only function. The mapping from the PID to the handle doesn't have to be sophisticated high performance code. A simple iteration over the running processes should be fine.
Windows users don't need the PID anywhere, so there is no need to keep the PID small.
just to add to the onslaught of commentry....
what a crap name.... "name not available". This is describing your problem as a programmer rather than telling anyone anything useful.
Keith: What text would you prefer to "Name not available"?
We want to display the slider because the user has context that we don't (they know what apps they ran previously, we don't).
Maybe something like "Recently closed application"?
Here are a couple of stories about reuse of things like PIDs and handles.
In early releases of the predecessor of WNT, when OpenVMS was still known as VMS, PIDs were 32 bits long, but no practical system was going to run more than around 65536 processes at once. So someone had the brilliant idea of using 16 bits for the actual PID number and another 16 bits for a kind of serial number or password. When the first 16 bits were going to be reused, the other 16 bits would get incremented. If some poorly written app wanted to attack some innocent new process that happened to get a reused number, then the odds would be pretty low of getting the entire 32 bits to match. Of course "one in a million is two minutes from now" but still there would be a high probability of the errant attacker getting caught, so programmers would get some assistance in debugging.
Later versions of VMS no longer did that.
One former employer, making embedded systems with no memory protection, had lots of problems with poorly written processes overwriting structures in the memory manager, freeing stack variables onto the heap, and various other bugs that would crash the system. I copied an idea from what I'd seen in old VMS. My memory manager returned handles, aligned blocks on 8-byte boundaries, and used the low-order 3 bits of a handle as a kind of serial number or password. A really poorly written process could still smash my structures, but the average poorly written client would just pass me a handle that had already been freed. I had an 87.5% chance of catching their bugs.
Later versions stopped doing that. My colleages didn't want to be informed of their bugs, and didn't want to fix them.
Hey Larry, no reply?
Andre: What's to reply?
> Andre: What's to reply?
Uh, yeah. If the path from suggester to listener was recently closed, then maybe "topic not available" is better than "recently closed discussion". Otherwise, I thought Andre's suggestion would be more understandable by users outside of Microsoft.
I would also be great if you could comment why you are not using the process creation time to figure out if a handle/PID has been reused.
I find this whole sound 'volume per app' ridiculous. I can't think of any useful application for it, except for eye candy and pleasing lazy users. I wish all this effort was put into filesystem (sorry Larry, didn't mean to underestimate your work), or fixing stupid bugs like file copy and poor network performance, which are essential for an OS.
Another thing, this just increases the amount of 'user tracking' or 'instrumentation'. Without going into privacy issues, just think about the performance hit. On XP for example (I'm not touching Vista anytime soon) registry items like ShellNoRoam, MenuOrder, TrayNotify & PastIconsStreams get written and rewritten all the time, whether one wants their 'services' or not. I assume there are many similar (additional) things in Vista which, when added up, make the concept that is associatied with it - bloat.
Grigi: Interesting. Our studies of XP customers showed pretty clearly that they were extremely annoyed that some applications (Certain media players were particular offenders) would change the master volume of the system instead of changing their own volume. The per-application volume feature came out of that.
The reality is that every feature in Windows has people who like it and people who hate it. When my wife's riding instructor learned that she could control the volume of system sounds independantly from the volume of other applications, she was ecstatic.
The extra "overhead" associated with per-application volume is negligable - there's a string that internally identifies an "application" (which is persisted in the registry, and rewritten 2 seconds after an application changes the volume), and a structure that tracks the volume of the application (and a number of other things, including all the audio streams for the application).
Then the applications should have been forced to behave. I know, I know, it's always perceived as Microsoft's fault... maybe ban that behaviour and introduce a new 'proper' api... (hm... breaking compatibility - no win here). Or just keeping the old api, but nonfuctional (i.e. it doesn't change the volume)? Plenty of possibilities there... But I'm no programmer, just ordinary user who gets p****d off by the bloat creeping in every new version of windows...
Grigi: How do we "force" applications to behave? It's 3rd party code, we can't control it.
What we CAN do is what we did - reset the system-wide behavior and make it local. Which is what you're complaining about.