I need to determinate which agents and daemons are disabled on my OSX. Each process has plist file with parameters. I assume "Disabled" key is responsible for that. But not all agents/daemons has this value. So if property list doesn't contain this paramater it means it's disabled or enabled? I didn't find any info regarding default value for this item.
Please provide a reference to apple's documentation which proof it.
The "Disabled" keys in each LaunchDaemon file can be overridden by an entry in /private/var/db/launchd.db/com.apple.launchd/overrides.plist, and there's a similar system for LaunchAgents in /private/var/db/launchd.db/com.apple.launchd.peruser.userID/overrides.plist. I don't think Apple has documented this anywhere, which means that you are not expected to interact directly with these files, just use launchctl. It also means they're subject to change (i.e. it didn't always work this way and might change without notice in a later version of OS X). Also, the file for LaunchDaemons is only readable by root.
Related
I'm doing some wrapper job with Vulkan, to make the API more safe, and I wondered if I can create an instance or device first, and enable extensions or features later.
First, according to the spec:
VUID-VkDeviceCreateInfo-pProperties-04451
If the VK_KHR_portability_subset extension is included in pProperties of
vkEnumerateDeviceExtensionProperties, ppEnabledExtensionNames must
include "VK_KHR_portability_subset"
This looks fine, but notice that to enable VK_KHR_portability_subset extension on a device, you must enable its dependency VK_KHR_get_physical_device_properties2, which is an instance extension. This makes the fact that an instance must enable VK_KHR_get_physical_device_properties2 anyway in case the 04451 will check when a device is creating.
Secondly, it will be convenient to enable features later, for example if a user passed some parameter in, which requires some features, I can implicitly enable them for this user.
Features and extensions are specified at creation time. They're an innate part of the instance or device from that point forward. They cannot be modified later.
You can create new instances or devices. But you can't change existing ones.
I built a virtual filesystem (not a namespace extension) for Windows which acts as a frontend of our document management server consisting of files and folders. In order to be able to display some metadata of the DMS objects in Windows Explorer as additional selectable columns, I successfully provided properties to the Windows Property System by implementing a COM Property Handler. Wheras normal property handlers focus on specific file types for which they feel responsible, my Property Handler adds properties to all files regardless of their type. Because Property Handlers can only be registered on the file type level, I registered my handler for about 30 types under
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\PropertySystem\PropertyHandlers\<.Extension>
However, I did not manage to register the Property Handler for folder objects. Since all objects in our file system are virtual I build the property store (IPropertyStore) by implementing IInitializeWithFile instead of IInitializeWithStream. The properties are requested from our DMS with the path of IInitializeWithFile acting as key and were not read from an objects content. This concept would work for folders as well.
For getting called on folders I tried to associate the handler by registering under different well known identifiers like Folder, Directory, AllFileSystemObjects and * instead of the file extension without success.
I also didn’t find anything in the MSDN documentation regarding this aspect.
Is there a way to register a Windows Property Handler on folders? Or is there some other way to add custom columns to folders in Windows Explorer?
I'm not sure if it is possible to do this.
Property handlers are clearly not the right approach, they are system wide and there can only be one per file extension. They should only be implemented by the software that "owns" the file extension and can parse the file to extract properties.
The old column handlers would have been your best bet (IMHO) but they are officially dead and you already said you can't use them.
Have you considered creating a namespace extension? Either as a root item somewhere (Desktop or My Computer) the way My Documents used to work in 2000/XP or maybe something more along the lines of how OneDrive works?
I'm not sure if desktop.ini files work in the root of a drive but it might be worth looking into. You would then find yourself in the poorly documented land of [.ShellClassInfo] and its CLSID, CLSID2 and UICLSID members. The general idea would be to act as a IShellFolder proxy on top of the "real" IShellFolder so you could create a multiplex property store. I think there are some (undocumented?) property keys you can override to change the folders default columns and tooltips as well.
There is also something called a delegated folder that allows you to play with nested PIDLs but the documentation is once again pretty useless so I'm not sure if this is something worth looking into.
A 3rd option is to pretend to be a cloud storage provider. I don't know if this gets you any closer to your goal and you would still have to implement some NSE bits to get to the point where you can layer yourself on top of the underlying IShellFolder. This feature is rather new and only documented to work on Windows 10.
The inner workings of how Explorer/IShellBrowser is connected to the IShellFolder/IShellView is one of the least documented parts of Windows. There are hundreds of undocumented interfaces. Explorer gives DefView special treatment leaving other 3rd-party implementations out in the cold.
My feeling is that there is no clean solution to implement this on top of a drive letter but you might get lucky, if Raymond Chen drops by he might have some tips for you...
EDIT: See end of post for more information.
I am trying to to get plugins created via the Firebreath framework (1.7.0) to load. I am on Windows 8 in Desktop Mode using Internet Explorer 10. I've reproduced this with the built-in test FBTtestPlugin that comes with Firebreath. The failure is silent in that the object element is created, but fails to have any properties specified by the plugin. How does one go about debugging this? The Microsoft Internet Explorer Compatibility Tool reports that the plugin is failing to load.
(The FBTtestPlugin loads three plugins, hence the three errors.)
I've got other (non-FB) plugins working on the same settings (e.g. the example here: http://msdn.microsoft.com/en-us/library/dd565667(v=vs.85).aspx works fine as do all the examples from this site http://ie.microsoft.com/testdrive/browser/activexfiltering/Default.html ).
I've tried a huge combination of security settings, but here's the most relaxed set I have so far follows:
Tools / Safety / ActiveX Filtering: is unchecked
Internet Options / Security / Internet: "Enable Protected Mode" is unchecked
Internet Options / Security / Internet: is at Custom Level. Under ActiveX everything is "enabled" except restrictive properties such as "Allow ActiveX Filtering"
All sorts of security warnings are visible based on these settings.
Note: I don't intend to keep these settings. I just want to get the plugin working, then work backwards re-enabling security settings.
UPDATE
I figured this out partly and can now run the FB test FBTestPlugin. To make debugging easier for IE, I defined the registry key HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\TabProcGrowth as 0 to limit the browser to use one process. Unfortunately, with IE10 both iexplore.exe in Program Files and Program Files (x86) direct to the 64-bit version of IE. This prevents 32-bit plugins from running (see http://support.microsoft.com/kb/2716529 ), and the symptom is silent failure.
However, my plugin still fails to load in IE and the retitled question above is otherwise still open. The problem is still silent load failure. However, I think it may have something to do with plugin configuration. The CLSID listed in the Compatibility Test Tool (like the example shown above) is listed as all 0's instead of a valid GUID. Moreover the registry looks funky: The key HKCR\Company.Name exists as does HKCR\Company.Name.1, but both are empty (instead of having a CLSID child as in normally working plugins). The expected GUID does exist, but under a bogus name "applications.'". I am now digging into the code that gets called when regsvr32 is run.
Thanks all!
I am providing this answer in the hopes that someone can use the result.
IE was not loading the plugin for two reasons.
1) The TabProcGrowth registry key and the 32/64 bit issue with IE 10. ( http://support.microsoft.com/kb/2716529 )
Don't define this key.
2) My plugin description used an apostrophe (e.g. "Gluttco's Plugin") and this messed up the registration of the component.
DETAILS ON 2):
I traced through the DllRegisterServer code and found that the phoney registry entries are due to the fact that my plugin description contained an apostrophe. E.g. "Joe's plugin". The generator (fbgen.py/cmake), generated a malformed FBControls.rgs file (it't didn't escape the quotes and thus contained a string literal such as (s 'Joe's cool plugin'). The DllRegisterServer code (called from regsvr32) used the contents of this file (embedded?) when (deep in atlbase.h). Oddly, the parser did not detect the error (or somehow erroneously recovered). From Process Monitor I could see a bunch of bogus keys being added, before it started adding good registry keys again.
For now Firebreath plugin descriptions should not contain apostrophes (probably other characters are illegal too). It might be sensible to make fbgen.py check for these characters and possibly escape, reject, or replace them.
Searching found this: http://msdn.microsoft.com/en-us/library/dd565667(v=vs.85).aspx
Do you have any group policies in place that could affect it? I don't think this is related directly to FireBreath, rather to the activex configuration...
I also found http://social.technet.microsoft.com/Forums/windows/en-US/90c3202c-448b-42b7-acf7-dab8dba7b000/one-or-more-activex-controls-could-not-be-displayed-because-either which has a few things you could try.
Is there an API or way to programmatically turn off an individual, external monitor via Objective-C on a Mac?
I'm looking to write a small menubar application that can control a secondary display (without a physical power button), but still keep the primary monitor in use.
Hunting around the API documentation, I can't seem to find anything, other then reading states. So hoping someone else might have an idea.
You can't "programmatically turn off an individual monitor", it's not physically possible. The most you can do is tell the OS to not use the monitor, but I don't think you can change system-wide settings like that, especially not at the level you're working on (Obj-C).
Looking at the Core Graphics API mentioned in #Halley's comment, try starting with the CGBeginDisplayConfiguration method and see if you can set a display configuration to your liking.
EDIT: Alternatively, you could also use CGDisplayCapture(displayID), which by default fills the captured display with black. You can then
call CGDisplayRelease(displayID) when you want to turn it back on.
It seems to be possible to sleep display so by I/O Kit:
https://web.archive.org/web/20161106204726/http://www.cocoabuilder.com/archive/cocoa/191807-sleep-display.html
http://explanatorygap.net/2009/01/31/a-screensaver-to-send-your-display-to-sleep/
But I am not sure whether it can control single monitors.
I’m trying to patch an application that resizes windows using the accessibility API.
I need to maintain a dictionary with the previous sizes of windows. The key needs to identify the currently active window. At the moment, this active window is retrieved via NSAccessibilityFocusedWindowAttribute upon the press of a hotkey.
However, every time this method is called, the returned AXUIElementRef which identifies the window is different! This of course means that I cannot use it as a dictionary key – the dictionary won’t find the corresponding entry.
The following code reproduces the problem:
-(IBAction)testWindowIdentification:(id)sender{
AXUIElementRef focusedApp;
AXUIElementRef focusedWindow;
AXUIElementCopyAttributeValue(_systemWideElement,
(CFStringRef) kAXFocusedApplicationAttribute,
(CFTypeRef*) &focusedApp);
AXUIElementCopyAttributeValue((AXUIElementRef) focusedApp,
(CFStringRef) NSAccessibilityFocusedWindowAttribute,
(CFTypeRef*) &focusedWindow);
CFShow(focusedWindow);
}
_systemWideElement has been initialised in the init method using a call to AXUIElementCreateSystemWide().
The CFShow statement clearly shows different IDs every time the method is called (even though the same window is active), which is useless for me:
<AXUIElement 0x47e850> {pid=42463}
<AXUIElement 0x47e890> {pid=42463}
<AXUIElement 0x47e2c0> {pid=42463}
…
The documentation on AXUIElement shows no method that retrieves a unique attribute for the UI element, and neither does that of the NSAccessibility protocol.
The unique PID is not enough for me, since a process can have multiple windows.
How can I retrieve some unique identifier of the active window in Cocoa?
(By the way, the real code is checking the return codes in the above calls; there is no error, the calls succeed.)
Rob Keniger has the right strategy with his answer here. The only thing missing from this answer (and indeed, the reason for the bounty placement) is a workable implementation that takes the current active window and translates it into a unique key suitable for indexing in the context of the current working application.
Rob's solution sketches this out through use of the CGWindowID given in the context of Quartz Window Services. It is, of course, strongly implied that this window reference is only useful for your current application.
Getting this window reference is tricky, because no strong guarantees exist between the Accessibility API and Quartz Window Services. However, you can work around this in the following ways:
Use extern "C" AXError _AXUIElementGetWindow(AXUIElementRef, CGWindowID* out);, as documented here. This isn't guaranteed to work, but it works as a ground-floor test to get things started if it works in your version of OSX.
Get the CGWindowID directly, using, for example, HIWindowGetCGWindowID(). More details about selecting the active window and extracting the ID can be found in the reference manual for the Carbon Window Manager (warning: large PDF).
Catalog your CGWindowID set using something like CGWindowListCreateDescriptionFromArray, exactly as Rob suggested. The goal here is then to find some scheme for bridging the Accessibility API and Quartz, but this is conceivable by utilizing, for example, a callback bound to the context of your current active window. I honestly don't know an optimal example of this that's properly future-proofed, however.
Of the options, I recommend going with 2. for your current needs, if you're unable to create some other decorator for your windows to uniquely identify them. It's currently defined in the legacy code base, but it will do what you desire.
Best of luck with your application.
I think you might be able to use the Quartz Window Services functions, specifically CGWindowListCreateDescriptionFromArray to enumerate the currently active windows in a particular app.
This call is lower-level than AppKit and isn't going to tell you which is the active window, but it will give you window IDs that are unique for the current user session. It's not a great solution, but you could compare the window bounds information with what you receive from the accessibility APIs to associate windows with their real IDs.