You do that.
Tell them to make a version of DBT_DEVICEARRIVAL that doesn't require you to have a window handle to get the callback to the message pump so that you don't have to poll using PeekMessage().
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.
The notifications need to be able to go to windowless services.
Yes, agree. But they can. It is right there in the documentation.
Then tell them that RegisterDeviceNotification() is useless for detecting new iPod/iPhone/iPad devices because it require matching a GUID that has not been defined at the time that the service was written, and that having to update the service by having to update iTunes each time you buy a new device before the plugged in device is recognized as launching iTunes because you don't get a broadcast notification in that case, which you can then use to open up the device temporarily to probe it further ("Hi, USB device, are you an Apple Device?") rather than using a stinking GUID.
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.
Then you can call up Motorola, and tell them so they can update their PhoneTools Software, because they have the same problem.
I wasn't aware that they are eating CPU like iTunes. Citation?
... the DataPilot folks, who have no idea in heck what the phone GUID would be when you plug in your stupid random phone, particularly if you are using their DataPilot Universal PRO Kit, which connect up to almost all the phones from Apple, Motorola, LG, Samsung, Sanyo,
Sony Ericsson, and Audiovox.
I have more concrete examples, but I think you get the point.
not really, no. Do they eat CPU cycles polling like the crApple software?
The current Microsoft APIs do not solve this general problem; they require either an open application window, or they require a service which polls.
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:
And worse? Some of the documentation specifically says they want it that way! On purpose!
[HAL] it's a nightmare of convoluted and badly-documented objects and methods. I won't go as far as to say whoever decided to go with polling instead of event-driven made a great design choice, but I can understand how, after days and days of pouring over bad documentation, he decided it was either ritualistic suicide or go with the better-documented interface...
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?
but I can understand how, after days and days of pouring over bad documentation, he decided it was either ritualistic suicide or go with the better-documented interface...
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
Microsoft's hardware abstraction layer is a terrible, horrible, implimentation that makes every access from userspace terribly expensive
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...
somelabel: if(something_happened() process_it(); wait_until_next_event_is_ready(); goto somelabel;
This would have close to zero latency, and would eat precisely zero processor time when idle.
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.
But on the flip, Microsoft's hardware abstraction layer is a terrible, horrible, implimentation that makes every access from userspace terribly expensive.
And worse? Some of the documentation specifically says they want it that way! On purpose!
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:
So which part of the documentation did you read?
Everytime I have to work with HAL I'm filled with a strong urge to strip all my clothes off, burn them, then take a cold shower while shivering up in the corner, scrubbing my skin raw, chanting "must...wash...away...the sin..."
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.
So the minimum requirement is that you can delete all the keys.
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.
"If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system is operating in Setup Mode with SecureBoot turned off."
So when you delete the keys, SecureBoot is turned off.
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.
There's also an option to always put the Microsoft key back in place. But that's it.
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."
At no point does it guarantee that you can enter an arbitrary key and keep secure mode on.
And you are wrong. The PK (Platform Key) is the "owner" key. You can enter your own key if you like.
Which is basically what I said.
But you were mistaken.
And "possible" can be provided by means of, say, a supplied disk available at extra cost from the manufacturer that has to be inserted for such action to be taken at all.
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.
I thought the "embedded" Flash of IE is similar to Chrome's embedded Flash. Meaning Microsoft maintains its own build of Flash like Google maintains its own Flash. So it's up to Microsoft to fix any security issues and not rely on Adobe to release a patch to the consumer. So it could be a good thing like Chrome or a terrible thing like IE6.
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.