Question about GHI #508 - Do I understand this task correctly?

[reactive-firewall]

Originally miss-placed question from GH issue comment

sorry I saw the code-of-conduct a bit late, this is a re-post of a question I asked about GitHub Issue #508

---

TL;DR - is this just about the transparency part of the call?

We should not have to include a call to __NSInitializeProcess(argc, argv); in an app's main function when there isn't a nib file.

In regards to headless apps like an Objective-C CLI tool:

My reasoning (a sort-of Rationale)

While I'm confused by (the part around lines 205-207):

ravynos/Frameworks/Foundation/NSProcessInfo.m

Lines 202 to 225 in d9cd8da

	FOUNDATION_EXPORT void __NSInitializeProcess(int argc,const char *argv[]) {
	NSProcessInfoArgc=argc;
	NSProcessInfoArgv=argv;
	#if !defined(APPLE_RUNTIME_4) && !defined(__RAVYNOS__)
	OBJCInitializeProcess();
	#endif
	#if defined(__APPLE__) || defined(__RAVYNOS__)
	Class cls = objc_getClass("__builtin_NSString");
	memcpy(&__NSConstantStringClassReference, cls, sizeof(__NSConstantStringClassReference));
	#if __LP64__
	extern int __CFConstantStringClassReference[24];
	#else
	extern int __CFConstantStringClassReference[12];
	#endif
	cls = objc_getClass("NSDarwinString");
	memcpy(&__CFConstantStringClassReference, cls, sizeof(__CFConstantStringClassReference));
	// Override the compiler version of the class
	//objc_addClass(&_NSConstantStringClassReference);
	#endif
	}

which avoids calling initializing code for new process except for __apple__ and __ravynos__ beforehand, but if all this is doing is the bootstrap for the Darwinstrings we are basicly following CocoTron's example (or did they follow RavynOS 🤷) of separating out the darwin string stuff:

https://github.com/cjwl/cocotron/blob/9cda7d719428a8ff940b134e391e511104ee0b5d/Foundation/NSString/NSDarwinString.h#L1-L19

this is assuming the rest is just setting up the constant immutable/builtin/darwin strings for the app process? Or did I miss something big?

---

my assumptions

my understanding from CLI tools on Apple's implementation (e.g., where the most of my own Objective-C experience comes from) is that the main function of an app need only setup a release-pool (typically @autorelease these days) and then launch the program's process (often via appKit for nibs/GUI) and the Objective-C libraries (typically linked via Foundation or <objc/*.h>) e.g.,

https://github.com/kendrick-walls-work/XCMBuild/blob/3d767d2e5f0ffe031ff136970a493b162daba797/XCMBuild/XCMake/main.m#L46-L56

Which from the look of __ravynOS__ code in my neophyte 👀 (eyes) means the string stuff for constant strings of processes in memory (I guess for debuggers and inter-process stuff?) for nib-less apps should just be handled by importing the __ravynOS__ Foundation to leverage the libmain:

ravynos/Frameworks/Foundation/platform_bsd/libmain.m

Line 66 in d9cd8da

__NSInitializeProcess(argc,argv);

(which calls __NSInitializeProcess already)

Conclusion

Thus ensuring Foundation transparently calls its own libmain when the linking code (e.g., where it #import <NSFoundation/NSFoundation.h>) has no nib-file is enough; and this GHI's goal is about how that responsibility should be ensured by AppKit?

In summation: do I understand this issue correctly, or have I gone astray?

Important

I'm still unfamiliar with much of the RavynOS project and appreciate your efforts and patience. 🙇

---

[reactive-firewall]

cc @mszoek

[mszoek]

You understand it perfectly :) Our Foundation originated from Cocotron so it's very similar. I am not actually 100% sure this is a valid issue - it does not seem like __NSInitializeProcess (and therefore I guess libmain) are not being called in some cases, but I have yet to actually debug this. (Also I guess I never updated the copyrights on libmain.m LOL)

For the record, this kind of question about a proposed change is fine to go in an Issue. It's relevant. I just didn't want people opening Issues for things like "will ravynOS ever support X?", which was very common.

Also, you seem pretty competent in Cocoa and Mac development, despite the modesty... can I interest you in contributing to the project?

[reactive-firewall]

You understand it perfectly :) Our Foundation originated from Cocotron so it's very similar. I am not actually 100% sure this is a valid issue - it does not seem like __NSInitializeProcess (and therefore I guess libmain) are not being called in some cases, but I have yet to actually debug this. (Also I guess I never updated the copyrights on libmain.m LOL)

From the code I mentioned in libmain.m it is the reverse relation: libmain.m--[calls]-->__NSInitializeProcess (line 66)

not being 100% sure myself, it still follows that nib-less apps just need to ensure they are importing libmain (e.g. via linking to Foundation.framework and letting (dydl call](https://github.com/apple-oss-distributions/dyld/blob/main/dyld/Loader.h#L275C4-L277C76))
via an import to AppKit.framework which is already dependant on foundation:

ravynos/Frameworks/AppKit/AppKit.h

Line 9 in d9cd8da

#import <Foundation/Foundation.h>

so AppKit.framework just needs to ensure it transparently invokes the libmain from foundation.h when imported by the nibless applications' main.m.

but that is where I start to question if it really does even need to be invoked by the app or if it should be invoked by the code that spawns the nibbless process. 🤷

🤷 As for how, 🤔 I'd recommend some kinda [+load](the load style hook on (e.g., NSProcess, NSApplication, etc.) ... caveat: but I haven't quite thought that far yet.

Either way, thanks for responding to my question 🙇

For the record, this kind of question about a proposed change is fine to go in an Issue. It's relevant. I just didn't want people opening Issues for things like "will ravynOS ever support X?", which was very common.

That makes more sense, I'll keep these technical comments on the relevant issues then. 👍

Also, you seem pretty competent in Cocoa and Mac development, despite the modesty... can I interest you in contributing to the project?

TL;DR - to soon to tell

Well it is true, I'm comfortable with Mac development, (and *Foundation/Appkit, if not Cocoa) but I actually meant it when I said "I'm still unfamiliar with much of the RavynOS project" especially because I don't currently have a stable KVM rig (nor spare hardware) to run a BSD VM on at the moment, making it very hard to commit any meaningful (e.g., tested) contribution at this time.

So without making any promises I would say I am already interested; just not sure I can yet.

Once I'm more familiar with the project, and if I have managed to get a working test VM setup, I was hoping on starting with something small: e.g., perhaps the NextStep-like defaults CLI tool stub (e.g., get defaults to read/write ~/Library/Preferences/*.plist (XML-plist only at first)) ... unless that is already taken of-course. 🤷 just an idea from the roadmap.