Re: Are runtimes of system objects dynamic/SDK dependent/whatever?
Option 2 is pretty much what happens. In addition, the behavior of doCoolStuff might change in 11.0 versus 10.15; the system framework will pick between the two by checking which SDK you were linked against. > On Jun 14, 2022, at 12:30, Aandi Inston via Cocoa-dev > wrote: > > I'm trying to understand how Mac OS X actually implements the predefined > objects like NSApplication. Not in detail by function, but where the code > lives. This is by way of understanding what happens if the SDK version > doesn't match the system version. Let's suppose I would like to use an > imaginary method [NSApplication doCoolStuff] which was added in Mac OS > 10.15, but I'm linking with the 10.14 SDK. > > So, where does doCoolStuff actually exist? I can think of several > possibilities. > > 1. The code for NSApplication and its methods is linked entirely into my > application. This makes it self contained, though it might depend on system > calls and external services. So NSApplication exists inside my application, > and it runs the version written as part of the SDK I link with (10.14). > There is no way for me to call [NSApplication doCoolStuff] , because it > doesn't exist in the NSApplication I am using (10.14 runtime). > > 2. The code for NSApplication is dynamically linked from system-provided > shared code of some kind, using the same code regardless of the SDK version > used. The shared code may include some differences according to info it has > on the SDK used to build the current app. In this case perhaps I could call > [NSApplication doCoolStuff], though not by coding that; something involving > NSSelectorFromString. > > 3. The code for NSApplication is dynamically linked from system-provided > shared code of some kind, using code dependent on the SDK version used. The > methods provided will depend on the SDK version used. This would imply > that, like case 1, is no way for me to call [NSApplication doCoolStuff] , > because it doesn't exist in the NSApplication runtime I am using. > > 4. The code for NSApplication is a stub to some other kind of external > interface I never heard of... > > Thanks in advance! > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/saagar%40saagarjha.com > > This email sent to saa...@saagarjha.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Are runtimes of system objects dynamic/SDK dependent/whatever?
/System/Library/Frameworks/AppKit.framework On 6/14/22 3:29 PM, Aandi Inston via Cocoa-dev wrote: I'm trying to understand how Mac OS X actually implements the predefined objects like NSApplication. Not in detail by function, but where the code lives. This is by way of understanding what happens if the SDK version doesn't match the system version. Let's suppose I would like to use an imaginary method [NSApplication doCoolStuff] which was added in Mac OS 10.15, but I'm linking with the 10.14 SDK. So, where does doCoolStuff actually exist? I can think of several possibilities. 1. The code for NSApplication and its methods is linked entirely into my application. This makes it self contained, though it might depend on system calls and external services. So NSApplication exists inside my application, and it runs the version written as part of the SDK I link with (10.14). There is no way for me to call [NSApplication doCoolStuff] , because it doesn't exist in the NSApplication I am using (10.14 runtime). 2. The code for NSApplication is dynamically linked from system-provided shared code of some kind, using the same code regardless of the SDK version used. The shared code may include some differences according to info it has on the SDK used to build the current app. In this case perhaps I could call [NSApplication doCoolStuff], though not by coding that; something involving NSSelectorFromString. 3. The code for NSApplication is dynamically linked from system-provided shared code of some kind, using code dependent on the SDK version used. The methods provided will depend on the SDK version used. This would imply that, like case 1, is no way for me to call [NSApplication doCoolStuff] , because it doesn't exist in the NSApplication runtime I am using. 4. The code for NSApplication is a stub to some other kind of external interface I never heard of... Thanks in advance! ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/fde101%40fjrhome.net This email sent to fde...@fjrhome.net ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Are runtimes of system objects dynamic/SDK dependent/whatever?
I'm trying to understand how Mac OS X actually implements the predefined objects like NSApplication. Not in detail by function, but where the code lives. This is by way of understanding what happens if the SDK version doesn't match the system version. Let's suppose I would like to use an imaginary method [NSApplication doCoolStuff] which was added in Mac OS 10.15, but I'm linking with the 10.14 SDK. So, where does doCoolStuff actually exist? I can think of several possibilities. 1. The code for NSApplication and its methods is linked entirely into my application. This makes it self contained, though it might depend on system calls and external services. So NSApplication exists inside my application, and it runs the version written as part of the SDK I link with (10.14). There is no way for me to call [NSApplication doCoolStuff] , because it doesn't exist in the NSApplication I am using (10.14 runtime). 2. The code for NSApplication is dynamically linked from system-provided shared code of some kind, using the same code regardless of the SDK version used. The shared code may include some differences according to info it has on the SDK used to build the current app. In this case perhaps I could call [NSApplication doCoolStuff], though not by coding that; something involving NSSelectorFromString. 3. The code for NSApplication is dynamically linked from system-provided shared code of some kind, using code dependent on the SDK version used. The methods provided will depend on the SDK version used. This would imply that, like case 1, is no way for me to call [NSApplication doCoolStuff] , because it doesn't exist in the NSApplication runtime I am using. 4. The code for NSApplication is a stub to some other kind of external interface I never heard of... Thanks in advance! ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
