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

Add support for CoreFoundation-like libraries #556

Open
madsmtm opened this issue Jan 14, 2024 · 7 comments
Open

Add support for CoreFoundation-like libraries #556

madsmtm opened this issue Jan 14, 2024 · 7 comments
Labels
A-framework Affects the framework crates and the translator for them enhancement New feature or request

Comments

@madsmtm
Copy link
Owner

madsmtm commented Jan 14, 2024

CoreFoundation, CoreServices and similar frameworks have memory management properties that I'm yet unsure of how we should handle.

Should we introduce a new wrapper type, similar to Id? Or should they manage it internally?

Prior art:

@madsmtm madsmtm added the enhancement New feature or request label Jan 14, 2024
@madsmtm
Copy link
Owner Author

madsmtm commented Jan 16, 2024

Related: How should casting / "toll-free bridging" between Objective-C and CoreFoundation-like types work?

@madsmtm madsmtm changed the title Handle memory management for CoreFoundation-like libraries Add support for CoreFoundation-like libraries May 17, 2024
@madsmtm madsmtm added the A-framework Affects the framework crates and the translator for them label May 17, 2024
@PaulDance
Copy link
Contributor

Hi! Thanks for starting such a sub-project.

I am indeed looking to use NetworkExtension and objc2 currently seems the most promising lead towards this as I couldn't find anything else akin to security-framework. Adding the necessary bits and pieces for this would therefore be nice.

However, the dependency graph runs somewhat deep. From what I could gather by rashly grep+cut+sorting the Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/$fw_name.framework/Headers files to look for #import and #includes of stuff/things.h, it looks something like this:

  • NetworkExtension
    • Foundation
      • has its own abyssal dependency graph.
    • Network
      • CoreFoundation
      • Foundation
      • Security
        • CoreFoundation
    • Security

CoreFoundation therefore seems like a good starting candidate, hence my coming here. From my current understanding, getting Foundation more complete should be next, so adding CoreServices, CFNetwork, Security, and such. Then the rest, which could hopefully be easier.

I am definitely ready to help in achieving all of this, as it is a fundamental (pun intended) requirement of the project I have recently started. I have for example started fiddling with header-translator but quickly ran into dependency issues, which is what lead me here, truth be told. Note, however, that I am completely new to this whole "developing under Apple" thing, so it might take me some time before I can be of help. Regarding the mentioned issues still left to solve, I will next look into them and try to come up with something viable.

@madsmtm
Copy link
Owner Author

madsmtm commented May 18, 2024

Frameworks that consist of Objective-C classes usually only depend on CoreFoundation-like libraries in very few places, so we can get a lot of the way there by just skipping over those, I've done so for NetworkExtensions in e507a74 (the only manually authored file in that commit was translation-config.toml).

What I mostly need help with in this issue is figuring out the rules for how methods taking and giving pointers to CoreFoundation-like types (e.g. finding and reading links like this), and figuring how we can succinctly express those rules in Rust.

@madsmtm
Copy link
Owner Author

madsmtm commented May 18, 2024

(I'm aware that the difference between e.g. CoreFoundation and NetworkExtension must feel a bit arbitrary to the uninitiated, but it basically boils down to whether the framework uses Objective-C classes or not (because if it does, then it's likely to be written in a way that header-translator can currently handle). To you, or others reading this, don't hesitate to ask if there's a framework you'd like support for, and are unsure which category it falls in).

@PaulDance
Copy link
Contributor

Frameworks that consist of Objective-C classes usually only depend on CoreFoundation-like libraries in very few places, so we can get a lot of the way there by just skipping over those.

Yeah, I saw that there was this possibility, but I didn't exactly know what I needed from NetworkExtension yet, so I wanted to try getting the maximum before moving onto figuring out how to use the API.

I've done so for NetworkExtensions in e507a74

Yes, I can see that, thank you! However, I see that Network is skipped and things like NEFilterPacketHandler might be needed for what I have to do, but I still have to figure out the API.

the only manually authored file in that commit was translation-config.toml

Yes, I was able to get that going too. I think I should be able to port Network like this in order to get the few missing elements, but do you already know if Network is CoreFoundation-like as well, depends on it too strongly, or should be translatable by also skipping Security?

@madsmtm
Copy link
Owner Author

madsmtm commented May 18, 2024

things like NEFilterPacketHandler might be needed for what I have to do

If you do end up needing it, you can always write a manual binding using msg_send!.

I think I should be able to port Network like this in order to get the few missing elements, but do you already know if Network is CoreFoundation-like as well, depends on it too strongly, or should be translatable by also skipping Security?

I think Network is closer to CoreFoundation in nature, it has it's own retain/release functions, and while the types are technically protocols (OS_nw_*), everything is still defined as plain functions (not methods). But feel free to try!

@madsmtm
Copy link
Owner Author

madsmtm commented Jun 28, 2024

Note: I just read that Swift considers core-foundation types as root objects. So we'll have to ensure that they work with the things that we (currently) expect root objects to work with (like weak, and possibly isKindOfClass: in the future).

Also, Swift seems to retain and release these with objc_retain and objc_release, indicating that we might not need a separate type from Retained / to do anything special to support them here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-framework Affects the framework crates and the translator for them enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants