Backporting of these headers to vitasdk.
bythos14 opened this issue · comments
I understand you are open to having these headers added to other projects. I wish to have some of the headers and their NIDs added to the vita-headers repository. The only issue on my end is that adding them will require re-licensing the code to the MIT license from GPLv3. Hopefully that is okay with you, if it is then if a pull request is made to the vita-headers repository I will only need you to state your permission to the code being re-licensed. Full credit will be given to you of course for all the headers and NIDs.
The NIDs for the libraries are not included in this repository. Would I have to take it from the DolceSDK headers repo, or would you be willing to supply them directly yourself?
Some adjustments would have to be made to the code to meet with the code style of the VitaSDK headers, if that is okay with you. I will handle that myself, full credit will still go to you.
Thank you for your work. I hope to hear from you soon.
You can add headers contained in this repository to vita-headers under the following conditions:
- Credit me (link this repository)
- This permission is only valid for header files (.h) and not for the code PoC files (.c)
- This permission is only valid for current (20.09.20) state of this repository. All future commits are not permissioned unless stated otherwise in the future.
As for the NIDs, you can copy NIDs for following libraries from DolceSDK: SceNotificationUtil, SceBgAppUtil. All other NIDs are contained in headers of this repository as comments after functions.
So you're okay with the re-licensing? I just want to make sure.
This repository is not licensed under GPLv3. You are only allowed to use headers from this repository in it's current state by obtaining my personal permission, which I gave you. You can license them under MIT if you wish so.
Also, I'm only just noticing that while the ini_file_processor.h header in DolceSDK is a C++ header, the copy of the header in this repository is a C header. Am I only entitled to the version within this repository?
Yes. C++ header was not my work.
Okay. Thank you.
Sorry for reopening the issue, but with the permission that I have now, could I perhaps write my own C++ header for SceIniFileProcessor using your C header as a basis? All credits would still go to you.
Sure, as long as it is truly yours and how you did it with SCE Json library.
Great, thanks. Also, would you like me to send a link here to the finalised version of the headers, before submitting the pull request? In case you'd like to see my changes first.
Sure.
As I look at it, it does seem like the IniFileProcessor library is really a C++ library. 'context' Is just the this instance of the class. Create Context is the constructor, Create context 2 is the second constructor. And Free Context 1 and 2 are the Destructors. Makes alot of sense now as I look at it.
Would it be okay if I were to split up the submission of the headers? I want to spend more time looking through the IniFileProcessor library.
Yes. SceIniFileProcessor is C++ library for sure, I wrote C header because it suited better for me considering context I was going to use it in.
Woah nice, that means all three of the vita's file processors are C++ libraries, neat. Now all that's left is SceLibXml.
I assume it's okay if I rename functions and their arguments? I'd like to have the Ini library API seem similar to the Json library's.
Sure, you can do that.
This is the commit I plan on submitting in the pull request. I'll submit SceIniFileProcessor at a later date, I'll be sure to send that link then.
bythos14/vita-headers@b8e4f12
So what do you think of it?
Looks good to me.
Great. I'll make the pull request then.
Oh and by the way, are you sure that context is 6 bytes? With the vtable pointer plus the pointer to the internal implementation instance, it would come up to 8 bytes.
I could've made a mistake there. Now that I look at the module code, it is probably 8 bytes, yes.
Another question, is the pMem argument for sceIniFileProcessorGetIniFileMemoryBlock really a void*? If it's being output as an address, shouldn't it be void**? Please correct me if I'm wrong.
I didn't check some of the SceIniFileProcessor functions since I didn't really needed them. And yes, I'm pretty it should be void**.