AddDevice routine is used by device drivers to be notified when their device arrives at the bus (e.g. an USB bus).

But if you read the documentation for the RegisterDeviceNotification function carefully, you should notice this:

Services can use the RegisterDeviceNotification function to register to receive device notifications. If a service specifies a window handle in the hRecipient parameter, the notifications are sent to the window procedure. If hRecipient is a service status handle, SERVICE_CONTROL_DEVICEEVENT notifications are sent to the service control handler. For more information about the service control handler, see HandlerEx.

Really!

Yes, agree. But they can. It is right there in the documentation.

That's the thing with GUIDs: It is perfectly safe to choose them during *development*. Generating a guid for a device or an event virtually guarantees that no other device or event will use the same ID. The main problem with GUIDs is that such "well-known" guids needs to be documented. But if Apple writes the device driver that broadcasts the event, surely they can find a way to use the clipboard and use the same GUID during notification registration.

I wasn't aware that they are eating CPU like iTunes. Citation?

not really, no. Do they eat CPU cycles polling like the crApple software?

Wrong. Read the documentation. I linked to it and quoted it above. It really is not that difficult.

You still have not told us where Microsoft recommends polling, as per your claim:

Windows device driver development has an entire site devoted to it. In there there is architectural guides, tools, development kits, samples, articles, process guidelines and best-practices. I really don't know what you'd expect? Would the source code be better documentation and provide better guidance?

I can't

1. iPhone connects over USB. Which means that Windows already has a bus driver in place which will notity the PnP manager about device arrivals on the USB bus. What one would need to create is probably a Function Driver. If iPhone used some standard protocol one could probably do with a built-in driver, but I suspect that some proprietary protocol are at work - so therefore a function driver.

2. The PnP manager will activate and notify the function driver upon device arrival. It will do so through the AddDevice message.

3. From the looks of it, what the iPhone requires is probably aptly covered by a user mode driver. Which flies in the face of your previous assertion that

What exactly is it you feel is not documented? What is the documentation you are missing? You did download the Windows Driver Kit, right?

Still waiting for citation for Microsoft recommendation of polling...

Still bad. You are tying up precious resources such as processes, threads and memory. In general it is better to:

1. Register for events, e.g by filling a jump table and register it with the OS. Each item in the jump table represents a well-known function such as "device arrived", "system goes to battery power", "device removed" or "system shutting down".

2. return and relinquish any resources such as process, threads, memory, handles.

3. When a routine is invoked by the OS then perform the function as quick as possible and return. Don't tie up resources.

Citation needed.

Windows actually has a rather sophisticated driver model which allows many drivers to be implemented in user mode or at least be divided so that big parts can run in user mode. This improves both stability and security. A relevant type of drivers in this context is bus drivers, specifically bus drivers for USB. These drivers will discover new devices on the USB bus *regardless* of their make, capability etc. The bus driver til inform *your* driver when a device arrives. No need to scan or poll for devices. If you do it right you can just sit there and wait to be informed. No need to poll, no need to even tie up a thread in waiting state.

That is all in the documentation:

Types of WDM Drivers
Function drivers
An example

So which part of the documentation did you read?

Maybe you should find another line of work?

It knocks both DRM and Windows in one sentence. Which is popular on slashdot.

Facts don't matter, accuracy doesn't matter. Comments can be outright lies (like this one) and still achieve the highest ranking as *informative* just because it plays to a popular myth.

No, games are *not* run with admin rights. No they do *not* need to run with admin privileges, not even to use DRM. Especially not the online DRM variety that steam uses.

Wrong. There is no requirement that you *explicitly* can enter UEFI Setup Mode. The system vendor MAY allow such an explicit option, but the MINIMUM requirement is that he MUST allow Setup Mode to be entered by deleting all keys.

Read what you quoted again, please:
1) It SHALL be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK.
2) This MAY be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx), WHICH puts the system into setup mode.

So the owner of the system can ALWAYS enter setup mode. He may have some direct way to do that, but he can ALWAYS delete the key databases, which will cause the system to go into UEFI Setup Mode.

Correction: When you delete the keys the system enters Setup Mode. If you choose to exit the automatically invoked setup mode WITHOUT entering a new platform key, THEN secure boot is turned off. Which makes perfect sense as there are now no keys in the firmware which could validate anything.

No, you can enter ANY key into the Platform Key database. From http://lwn.net/Articles/447381/ : "Before a PK is loaded into the firmware, UEFI is considered to be in "setup" mode, which allows anyone to write a PK to the firmware. Writing the PK switches the firmware into "user" mode. Once in user mode, PKs and KEKs can only be written if they are signed using the private portion of the PK, though KEKs can be freely written during setup mode. Essentially, the PK is meant to authenticate the platform "owner", while the KEKs are used to authenticate other components, like operating systems."

And you are wrong. The PK (Platform Key) is the "owner" key. You can enter your own key if you like.

But you were mistaken.

So, basically you are spreading FUD: *Fear* that it may incur extra costs, *uncertainty* because you choose to disregard facts and present your own speculation and conjecture as facts, and finally *doubt* as to the "real" intentions behind secure boot.

They are similar. It is still Adobe developing Flash, but they coordinate releases with both Google (for Chrome) and Microsoft (for IE) so that vulnerabilities are not implicitly revealed through one version where an attacker could version compare and reverse engineer to figure out the vulnerability.

Both browsers sandbox the Flash plugin. In the case of IE the Flash process runs under low integrity mode (protected mode).

On top of that, the "embedded" Flash is only available to a Microsoft-controlled white-list of sites. An attacker cannot simply set up a fake site with Flash attack code. IE will refuse launch the embedded Flash for all but the white-listed sites.

On Windows 8 the "embedded" Flash is only available in the Metro^h^h^h^h^hModern version of IE. The desktop version still require explicit installation of Flash if you want to use it. This latter is the situation with IE10 on Windows 7 as well.