Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't introspect various symbols (e.g. require('objc').NSTitledWindowMask) #45

Open
shirakaba opened this issue Jan 5, 2023 · 0 comments

Comments

@shirakaba
Copy link

shirakaba commented Jan 5, 2023

Although we can introspect various Obj-C symbols via the Obj-C runtime helpers e.g. objc_getClass, C functions, enums, and other symbols are not introspectable at runtime, as I found in #43 (you can see in the comments various symbol lookups that failed - NSTitledWindowMask is one of them).

I believe the root of the problem is that bundle.load(), used here:

return bundle.load();

... does not load any C symbols for the dynamic linker to find. Well, my reasoning may be wrong, but either way, they're not being found in this call (we're throwing an error):

objc/src/runtime.js

Lines 48 to 58 in cc4d6f0

const getSymbol = name => new ffi.DynamicLibrary().get(name);
const getSymbolAsId = name => {
try {
const symbol = getSymbol(name);
symbol.type = ref.refType(ref.refType(ref.types.void));
return symbol.deref();
} catch (err) {
return null;
}
};

I believe we'd have more success by adopting the approach used by NodObjc to look up symbols, which involves loading the BridgeSupport files, which were specifically designed for use by Objective-C bridges like RubyCocoa and PyObjC.

Alternatively, we may be able to get further on the back of the existing approach by importing Core Foundation and introducing calls to CFBundleGetDataPointerForName and CFBundleGetFunctionPointerForName, but this would turn things into an O(2N) lookup as more and more frameworks are imported (check the data pointer and then the function pointer for each framework we've imported during the app's lifespan), and unlike the BridgeSupport approach, it's not yet tried-and-tested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant