site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On 28 Jan 2008, at 17:30, Jonas Maebe wrote: Jonas _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... c) I concluded from this that that I should libc instead as a system interface, and that it would be just as stable (if not more so) since Apple is a commercial company The fact that even this interface may not remain backward compatible is disappointing however. When I first learned about the concept of frameworks, I (naively) assumed this meant that breaking backwards library compatibility would no longer be required, since you could just bump the compatibility version so all older programs could transparently keep using the older version of the framework. Obviously, for something like libSystem this is not a solution "for free" since you'd still have to keep patching the old version to keep running on the new syscall interfaces if older syscalls are removed/changed. Actually, it seems I misread the comments about vfork being deprecated, as the man page states: This system call will be eliminated when proper system sharing mechanisms are implemented. Users should not depend on the memory sharing semantics of vfork as it will, in that case, be made synonymous to fork. So as long the symbol remains exported from libSystem (synonymous to fork at some point or not), it doesn't matter to me (from a backwards binary compatibility standpoint). This email sent to site_archiver@lists.apple.com