site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Mar 12, 2009, at 6:10 AM, Terry Lambert wrote: FWIW: -- Terry - Jim _______________________________________________ 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... On Mar 12, 2009, at 5:54 AM, Jim Correia <jim.correia@pobox.com> wrote: The place where this would be important today is on a machine capable of running 64 bit Intel binaries, but for which only the system framework is available, and not other frameworks. Since we changed the 64 bit binary cpu type number by adding a "has 64 bit frameworks bit" to it, when we added framework support, if you link a new binary, the 386 version of the binary is going to be preferred by the older version of the OS anyway, so you'd be solving a problem that doesn't exist in the first place. The other place it could be important is if you ported over your 32 bit KEXT or daemon that talked to it, and decide, for whatever reason that you wanted to still communicate ponter and long values between it and user space instead of using sized types. The other place where I wanted to control this is where my GUI app, which runs as a 32-bit process on Leopard (which can be influenced by LSMinimumSystemVersionByArchitecture), launches a helper (today via exec), and I'd like to run the helper as 32-bit on Leopard too, mainly because I don't want to be the reason the 64-bit frameworks are loaded in. For a drag and drop type install, LIPO isn't an option. If it knows enough to know that it wants to exec a lower graded binary slice of itself, it could lipo and exec just as easily as it could do the specific exec of the lower graded slice from the higher graded slice. Another alternative is a small helper program that is pointed to by the plist that repoints it at either the 32 or 64 bit binary rather than itself the first time it's run, thus avoing the overhead on subsequent runs. The only place a first-time-you-run approach isn't appropriate is if you are loading off network storage shared between systems with conflicting requirements (unlikely for KEXTs, but possible). A small helper binary that sticks around rather than repointing things and execs daemon32 or daemon64 as appropriate still works for that case, though. But you could also LIPO at install time with your install tool or the binary itself when it saw the results of the uname(2) system call, or you could also write a small script to wrap the use of the arch(1) command, or you could use the posix_spawn(2) extensions documented in posix_spawnattr_setbinpref_np(2) to reexec yourself, if you didn't mind running the 64 bit binary, saying "whoops! I should be 32 bit!" and restarting yourself with a different preference. It looks like using posix_spawn solves the problem. (Previously I was using fork/exec because the code was originally written to target 10.4.x.) This email sent to site_archiver@lists.apple.com