You make some good points, but I feel that perhaps you've picked the wrong words, or else you simply have some inaccuracies in there: such as G5s running under "software emulation". Also "subversion PC program" -- I have absolutely no idea to what you're referring there, although I'd be intrigued to find out.
Worth pointing out here is that the PowerPC spec has always inclued 64-bit instructions alongside the 32-bit instructions, and has always included support for both 32-bit and 64-bit addressing modes. The G5 was the first processor in the series to actually implement those, but they've been part of the standard for a while now.
What this meant was that, when the G5 first came out, it mostly computed 32-bit memory addresses. The compilers were available, however, to make use of the 64-bit mathematic instructions available in the new processor, and those could be used from OS X 10.2.7 (the first version available on the G5) onwards. Well, on any OS really, they're just CPU instructions, they're not dependant on the OS.
OS X 10.4 has support for 64-bit addressing at the core. The software can also handle 32-bit addressing: it just promotes the 32-bit value from the 32-bit-oriented client process to a 64-bit value internally when it needs to get at a real (64-bit) memory address for mapping purposes. The kernel handles this all internally. Also, from what I've seen (in the Darwin source code) anything that would benefit from a ppc64-specific implementation gets it. Note that in C code, not much needs to change: the 'long long' 64-bit datatype is available under both ppc32 and ppc64 architectures, it's jus that ppc64 can fit such a value into a single register, while ppc32 uses two adjacent ones. The only potential problem is that the 'long' datatype is 64-bit on a G5, since OS X uses the LP64 model (Longs & Pointers are 64-bit).
Beyond those two things (CPU math instructions with 64-bit operands, 64-bit memory addressing), what else is there to expect? Those that think '64-bit-ness' translates to a performance gain for anything other than 64-bit datatypes are going to be disappointed; 32-bit instructions don't get executed two-at-a-time or anything like that.
Why should they be forced to buy two computers just so that they can preserve their "entire Mac experience"?
I wouldn't say forced exactly, but having the games on a separate computer makes it really easy to browse GameFAQs' and Gamespot's walkthroughs without having to exit the game altogether.
Worth pointing out here: iCal, and iWeb both work without.Mac, as does Backup, with the exception that Backup is part of the.Mac bundle in the first place, not a separate product. iCal uses the same format as the Mozilla calendar. Backup can backup to folders, CDs, DVDs, etc. In terms of software capability, they all have non-.mac features.
iCal can publish calendars (and subscribe to them) without.Mac. It's a standard file format, you just publish it to a different URL: the two available options are '.Mac' and 'Private Server'. Needless to say, the 'Private Server' option requires that you enter some more details than the '.Mac' one.
iWeb will publish to other servers, although rather than building in the full FTP client, webdav client, etc., you just publish to 'a folder'. You can then upload that folder using your tool of choice (you could even edit the output pages yourself if you wanted); or alternatively, you could have it mounted on the desktop (perhaps via WebDAV, like the iDisk) and publish to that 'folder'.
I'll agree with you on the sync though; sync to another computer via Rendezvous, erm, Bonjour, would be a very nice feature, especially for those of us who have laptops. I'd love to hit a button in my laptop that just replaces my stuff with versions from the desktop before I go on holiday, that would be *so* useful-- and I actually *have* a.Mac account.
"Apple doesn't want to see ads for Dell or Victoria's Secret on.Mac."
It's also well worth noting that with the tight integration with iLife, especially now that iWeb is available to replace the online HomePage site builder, that people who buy.mac don't even really need to visit the actual www.mac.com site anyway. I know I don't except when I want to check some settings somewhere, like the split between Mail & Web space from my available 1GB.
When I put up a site on.mac, I could potentially use advertising on it. I choose not to, for all sorts of reasons (such as: who the fuck ever visits my site in the first place, except my parents and a couple of friends?), so I'd be really kinda narked if they dropped the price by adding advertising-- since that advertising would most likely be appearing on my homepage, since let's face it, the homepages would get many more hits than the.mac interface itself.
As to the value of.mac, I'm happy to pay for it, as is my wife, even if just for the email. However, we also have our calendars on there, which we publish so that, for instance, I can look at my iCal application to see what time she finishes work tonight (when I have to collect her). We also put some photos up there for the folks (since the Atlantic Ocean separates us from *both* our families), and I kinda want to do a blog, even though I know it'd be highly uninteresting to most folks (I just want to see if it helps me become a more thought-organised person, I guess). But the email is the main thing, and I'm happy to pay for it.
In a reply both to the parent and the GP, it's probably worth noting that Creative wasn't exactly the first to implement this sort of thing either: arguably it's actually a NeXTStep thing.
In any case, even if Creative's patent is on the first use of that 15-year-old (at the time of the Nomad, 11-year-old) browsing method on an MP3 Player, then -- all talk of meritless/obvious patents aside -- I think Apple should get the benefit of the doubt since their interface for the iPod is so obviously the same column view used in the Finder on OS X, and in NextStep before it.
I mean, it's patently obvious that the interface from the iPod is nothing but a port to an MP3 player of the existing interface to their computers. I mean, that's got to count for something, even if only to illustrate that the Creative patent shouldn't have passed the non-obviousness filter. I mean, if I can file a patent today which uses someone else's idea on a new device, and then use that to stop said company using *their own idea* on a similar device, then...
Shit, I don't even have the words. And I know lots of words.
To Creative:
It looks like you lost the MP3 player war. Sorry, but that's the way it goes. I had a Nomad when they first came out. Nice piece of kit, although it used to take a hell of a long time to start up, and a long time to go through the library putting things into the 'current playlist' so I could play them. It was okay, though, and I liked it. However, the iPod beat you. It was fluid, simple, and fast. It looked nice, and rested in my hand nicely. It was the form & function that was needed for the type of device it was, and you didn't think of it first.
So, stop kicking your legs in the air and screaming, and get up of the floor. Mummy isn't going to buy you sweets. In this case, Mummy is more likely to take away what sweets you have, and give you a round thrashing in the process.
However, you make good sound cards (although I've not used them since my last Windows PC got stolen five years ago, but they were good then, and I'd assume they still are now). So, what I'd suggest is that you take that expertise and you make a rackmount wireless music receiver, so I can stream music to my hifi stack. Make it so that the rack jobbie can browse my music collection remotely, too. While you're there, you could do a remote, the size of the iPod nano, with a little screen so I can navigate through said music comfortably from my chair. There's not been a lot of good consumer-level activity on that front, so you've got a chance to really shine there. You can do good things. Just concentrate, expend some effort, and off you go.
Lying on the floor kicking and screaming won't do it though. You'll just stand up eventually to find you've been left behind. Take it from someone who knows -- I kicked, and I screamed, and my mum just got into the habit of walking off. I'd follow, then lie down and scream a bit more. She'd just carry on without me. All the fuss just made sure I wouldn't ever get what I wanted. Don't make the same mistake.
The GP wasn't referring to Vax or Unix machines of 20 years ago with regard to their simplicity. It referred to the fact that security was a solved problem on those machines. You yourself go on to say:
Now that's not to say they couldn't be doing a better job. OS X is a great example of how asking for the admin password every time a modification of the central system is requested makes worms all but impossible and trojans much more difficult.
The thing really worth noting in your statement is that OS X uses a >20-year-old security system. It's using Unix permissions, straight from the BSD core of the system. The same BSD core used in the NeXTStep operating system a little under 20 years ago (albeit slightly upgraded since then).
Individual software packages, particularly those designed to listen for commands from the network and execute things locally (ssh, etc.) can have the sort of issues you decribe in your last paragraph; As they get more complex, the task of maintaining security does potentially also become more complex. But on an operating system level, there have been sufficient rules in effect for a long long time now. For instance, just saying "this can only be done with root privileges" and "root privileges can only be gained interactively, and on a one-shot basis" will cover a vast amount of potential issues, and is pretty much what OS X does, as you describe (albeit with slight timeouts to root privileges, rather than pure one-shot operation -- although that timeout is user-configurable).
At the end of the day, MS-DOS, QDOS, and such, left that out in the interests of expediency, size, and (maybe) end-user perceived complexity/ease-of-use. It then became a standard. I like to quote my boss on this one:
He tells me that, having worked with Unix/BSD/Vax -level machines in the late seventies, when the IBM PC came out, he and his cohorts were interested to see it. They took one look and put it down as a failure -- a joke, even -- because it lacked so much of what they saw in their current machines. Unfortunately, it became the standard, in the process setting back the state of the art by many years.
Not least is the point that Unix/Vax systems were inherently multi-user systems, and they needed a robust way of preventing one user from destroying another's data. So this was built in from the very start. MS-DOS and QDOS didn't have this capability, so the standard became that any program had full access to just about anything. The only high security implemented was in the CPU itself, where a system trap was needed to get access to 'Ring 0' (privileged) instructions. On top of this, the somewhat limited nature of the system itself led many programmers -- used to working on a more capable OS -- to make modifications to the core system, to help their stuff work. That required privileged access to the system, in order to install hooks, drivers, and so on.
Of course, once this became a standard, it was hard to change that behaviour, and it never was changed because 'backwards compatibility' was the highest goal. So when mutli-user functionality was built into Windows 9x/NT, privileged operation became the norm. People logged in as an administrator, because their programs were designed needing full access to the system, and little or no provision was made for interactive temporary privilege escalation within the OS itself. Unlike Unix/BSD, you couldn't just ask the user for an admin user & pass to get the privs needed to put some file somewhere special, and then lay down those privileges when you were done with them.
As a result, you get the horrible mess we're talking about: An IM program that can corrupt the core operating system and ultimately gain access to privileged-mode CPU cycles? WTF? A game that can modify the system kernel, or the boot sector of the hard disk? They can only do that because the system lets them, or because the system won't let them do some small operation without high privileges, and requires that the entire process runs with those privileges as a result.
Obviously iTunes MP3 encoding, and a lot of the other things they mention, are going to be optimized for the x86 -- it seems silly to complain about that today.
Also, especially silly since iTunes is the one app installed with OS X on Intel that *isn't* compiled for Intel. It's the token Rosetta application, and everything else is built for Intel. This means that it doesn't use things like AltiVec (or, on Intel, SSE) for encoding/decoding; Rosetta emulates a G3 (PPC750 I think).
Isn't your IPv6 address tied to your Mac address? Will Microsoft be able to track you based on this fixed IPv6 address?
Simple: just go on holiday & buy a network card abroad, then bring it home & install it. That'll really fox 'em, they'll think you're in another country !
The MAC address isn't traceable to a geographic point now-- at least, no more so than is an IPv4 address, and possibly less (since IIRC it's only actively used when indentifying & targeting machines on the local loop). Each hardwware card has a nearly-unique address, but there are possible clashes. It'll take a long time to find one, however.
The only things really detectable through a MAC address are the vendor (there's a vendor ID in there) and *possibly* the geographic locale in which it was produced. But that's ultimately up to the vendor, it could be just a random string of bytes.
The cards/chips are sent all over the world, so it's not like anyone's watching where they go.
"Ah, that card was went to the second shelf from the top, third row from the left, front of the pile, at CompUSA, downtown Washington. It was purchased by Vernon MacArseTrumpet, of Apartment 192, 1800 Q St. Washington DC. Now we can watch everything he does!"
Probably not going to happen. It'd just take too much work watching 'em go round. It's not like local ISPs who get blocks of IP addresses to hand out, which can be traced from origin, to ISP, to branch, to house. No-one's keeping an eye on the 5000 boxed ethernet chips which leave the warehouse at 4am in each of 8 trucks bound for umpteen different places. It's just too much work.
Apple is not just talking transition, they are shipping code, and anybody can see that they could do it again without breaking stride.
What you fail to take into account is that the underlying system has been Intel compatible for a very long time. Significant parts of the Carbon API are usable on Windows (it's used in QuickTime, I believe), and the remainder of OS X is basically an updated NeXTStep operating system, which has been compiled for 68k, PowerPC, and i386 for a long time now -- over ten years.
Also, there's the little point made during the announcement: Mac OS X's 'secret double life'. All the Apple stuff has been kept Intel-compatible since at least the year 2000. As such, if Apple wanted to move to (say) the Transmeta Crusoe, or the Intel Itanium, they would have significantly more work to do, since they would actually be starting from scratch.
Of course, the fact that the OS is based on BSD/mach, which is written primarily in C, makes it fairly portable. The kernel can be recompiled to run on any processor of choice, just about. A few things need to be changed to cope with register sizes and availability, and some assembler code would need to be rewritten. But for the kernel, that's about it. Then you just have everything else, which could potentially require a lot of going over lots of existing code making sure it doesn't make any silly assumptions about the host architecture. That's the bit that'll take the time, and the only reason it's do-able in the 12-month timeframe currently allotted is because they've been doing it for a long time now already.
You do mean that all you have to do is show the upgrade your old windows CD, right? You don't even have to have the old windows installed.
It gets better than that, even:
A few years back I was installing Office 2000 Pro onto my new Win2k machine at work. It was an upgrade copy, and we used an old Word 5 floppy disk when asked to present the previous version. To my horror, however, I found that the really rather old floppy was unreadable, and therefore I had no way to install the new software.
After many attempts to get at the data on the floppy disk, I was about to give up; before that, however, I tried one last trick, which I naturally expected to fail. When asked to insert the installation disk for my previous copy of Word/Excel/Office, I decided just to point it at the CD from which I was installing Office 2000. Wouldn't work anyway, so where's the harm?
Universal Binaries aren't two executables concatenated into one big file. They are separate files that are sitting in a special kind of folder (a package) that the Finder presents as one file. On the filesystem level, they are most definately separate.
Oh, I'm afraid they're most definitely single files.
I'm an OS X developer, and I know whereof I speak because I deal with these things all the time. Not only do I write system-level software which at certain points involves scanning binary files to locate symbols, sections, and the like, but I also have access to a DTK, and can see first hand that the ppc/i386 binaries are formatted in exactly the same way as ppc/ppc64 (or ppc/ppc64/i386) binaries are when building for 64-bit support on OS X 10.3.
GUI applications are bundles (usually -- I've written command-line apps that show a UI before now); frameworks are (kinda, they don't have the 'bundle bit' set in their top-level folders, so they appear as a folder, not a file); plugins are (if they have the bundle bit set); and kernel extensions are. Lots of things are indeed bundles.
Command-line tools, however, are not bundles, yet they are (or can be) Universal Binaries.
However, go into the Finder, do Cmd-Shift-G, and type '/usr/bin' into the field, then click 'Go'. See all those files? They're not bundles. If you right-click or control-click on them, there is no 'show package contents' option: that's because they're not a package. And yet, these are exactly the type of files which use the universal/fat binary format to gain 64-bit support (since that's only available for non-GUI apps which link only against the system & c libraries).
In the Terminal, type file/usr/lib/libSystem.B.dylib and press enter. You'll see two (or on a DTK, three) architectures listed. Now do ls -ld/usr/lib/libSystem.B.dylib and press enter again. Look at the leftmost character. Notice how it's a hyphen, not a 'd'? That means it's a file, not a folder. Now do the same thing for an application bundle (e.g. ls -ld/Applications/Calculator.app). See how the leftmost character here is a 'd'? That's because it's a folder, with (possibly) the bundle bit set, although that last doesn't matter since the Finder has special handling of the.app suffix anyway.
Universal binaries are created by compiling separate binary files, one for each target architecture. These binaries are then passed to the lipo tool to concatenate them into a single binary file; here's the manual page for lipo.
Also, you can see here some instructions on how to build a universal binary from a configure-style project (i.e. not using Xcode). Scroll down particularly to the Merging Multiple Builds section, taking especial note of the bit about using the file command to verify the contents of the single file that was output.
For further information, please refer to the following:
Posting here just for 'completeness', for the potential enlightenment & edification of anyone following this particular thread.
Universal binaries are 'fat' binaries. I know this for a fact, because I'm an OS X developer and I've worked with them. Both for compiling 32/64-bit ppc apps, and while compiling stuff on a DTK (about which I obviously can't go into too much detail).
Details will go to another reply (who was more obnoxious in his incorrectness), but I've written programs that parse these things; they are just fat binaries, in a single file. You can download BBEdit 8.2.3 and take a look for yourself if you like, that's a universal binary.
It has been the case for quite a while that a Mac OS X application built against a particular set of headers and stub libs will only run against those libs or newer. This means that if you build against the 10.3.9 headers (either by building against the system headers under 10.3.9 or against the 10.3.9 SDK), your code will not run in 10.3.8.
Incorrect.
The dynamic linker in OS X makes the actual location of functions & other symbols in a linked library irrelevant, since the addresses are computed at run time by the dynamic loader -- the compiler inserts a 'stub' routine and a dummy address. The dummy address is first initialised to the address of a compiled-in function called _dyld_stub_binding_helper, which calls the relevant dyld library APIs to find the real function. The real address is then written over the dummy address, so future invocations will jump straight to the target routine.
I compile apps on OS X 10.4. Most things I compile using gcc 3.3 (because gcc 4.0 auto-links against a library that isn't present in 10.2.x), but I've never had the slightest problem running an app on an earlier version of the operating system. Unless I actually attempt to use a symbol that actually isn't there, nothing goes wrong.
Also, OS X has had weak-linking since 10.2. That means that the stub binding routine can happily return a symbol address of zero, meaning that I can link against somelib.dylib, including somefunc() which only exists in 10.4 & later, and -- at runtime -- I can simply do if (somefunc != 0) to see if the function is available. On 10.4, the function will be there. On earlier systems, the symbol value will just be zero.
Y'know, you should actually read the links you post, for instance, on the page you linked you'll find this useful nugget of information:
You can build a target for a range of operating system versions, so that it can still launch in older versions, but can take advantage of features in newer ones. This allows you to deliver software that provides new value to customers who have upgraded to a new system version, but still runs for those who haven't.
...you seem to imply that you're a programmer, so I'd recommend looking at <AvailabilityMacros.h> for further enlightenment.
So no, this isn't "just how Xcode works". Xcode (read: gcc & dyld) work in precisely the opposite way, and for a good reason. What's really happening is that some part of the binary file format has been changed, implemented, or created for the benefit of the Mach-O/dyld runtime.
Maybe it's something new for the Intel machines; maybe it's something that has been available for PPC, but just wasn't implemented in the Intel build of OS X 10.4.1; maybe the latest Intel build of dyld has some performance enhancements which are mirrored by a slight re-ordering of the data/text section format & flags. It doesn't really matter, since even now-- and this seems to be an important yet frequently ignored point so I'll make it very clear --
OS X for Intel is NOT FINISHED YET
Apple can and will make changes. That's part of the reason why folks like me have Developer Transition Kits. So we & they can find things that don't work so well, and would do better if they were changed slightly. This is just work in progress, and things can be changed, removed, added. It's Just Normal.
You cannot support 10.2.x, because they didn't have universal binary support from what I remember.
They should do. I've just looked at the SDK for 10.1.5 and <mach-o/fat.h> is right there. Makes sense, too, since the support for it comes from NeXTStep.
I'm also pretty sure that I've run a Universal Binary on 10.2 personally. Although I'd have to double-check that once I get back to work tomorrow.
Anyone with 10.2 out there care to launch the latest versions of either BBEdit or Mathematica for us? They're both fat/universal binaries (ppc/i386 and ppc/ppc64 respectively).
Yes, but this isn't 'planned obsolescence'. This is an Unfinished Product. If I write a program, and at the start I put in Feature X, then later on remove Feature X to make way for Feature Y, before I've even released it as a product, then nothing becomes obsolete. There's no-one using Feature X, because the product hasn't been released. Now, I may have sent copies to some people to test, but that's all they'd be doing with it. Testing. Just like we are with the Apple DTKs, and the Intel builds of OS X.
Now, if OS X 10.4.1 for Intel were actually shipping, I'd agree. But it isn't. It's an unfinished product that is only available to paid-up developers -- the reason for which is very likely to filter out hobbyists and people who would sign up & 'buy' an Intel-based Mac for general use. The Developer Transition Kits are not ready for the prime time. They aren't finished. They are a work-in-progress.
OS X for Intel isn't finished. Its entire user base is made up of people who know that, and who have no trouble whatsoever updating to the latest version of the pre-release software. There are no legitimate users of OS X 10.4.1 for Intel processors who do not have access to the 10.4.2 install DVD, and there are none who have any reason not to install it.
Yes, binaries built with 10.4.1/intel still work on 10.4.2/intel. However, that's not really something that anyone should concern themselves with. Everyone who legitimately has access to the intel version of OS X also has access to the latest OS upgrade for it, for free. So there are no excuses for not using the latest version to build applications.
I haven't looked into it at all, but I'd guess that the dynamic loader has had new features added (or maybe just implemented, since there's no guarantee that 10.4.1 implemented everything), and therefore binaries use this. Something like certain flags within the symbol table, or the indirect symbol table, that sort of thing. If 10.4.1 doesn't have an implementation of the associated feature, it'll not work.
ADC Select membership gets us access to any & all pre-release software. No matter what that may be. There are no additional costs involved in downloading the latest pre-release iteration of any piece of software, and that includes OS X for intel.
All Apple beta software (with a few minor exceptions) is available only to ADC Select members. That's what ADC Select membership is. The fee doesn't pay for the software, it pays for technical support, and goes towards the salaries of Apple DTS, who have to work with all of us who use the beta software.
But there's not much incentive to upgrade if your 'universal' binaries won't work on the previous developer system.
Erm-- This is a developer system. It's not finished. This isn't The Thing That'll Be Released Next Year, it's something cobbled together so that folks like me can make sure my software will work on the processor/hardware. It's not a live system that's being 'bugfixed', it's a development system that's actively being developed. That means it'll change. Binary file formats, linker specifics, etc. etc. We're not so much 'upgrading', we're keeping our aim focusssed on a moving target.
...also, having re-read your comment: where do you get the idea that anyone wants to maintain any sort of compatibility with the original 10.4.1 DTK? I mean, it's not like it's been released to the public or anything. Compatibility with the intel build of OS X 10.4.1 is not required; compatibility with the intel build of OS X 10.2 will also have been broken, but you don't seem concerned about that...? Or do you think we should all maintain compatibility with the pirated copies of OS Xi 10.4.1?
(For the record, intel apps built under 10.4.1 still work using 10.4.2; I'd guess that new capabilities/functions were added to the intel dynamic linker, which gcc 4.0.1 uses)
Does anyone else think that the whole universal binaries idea is a waste of time? Sure its handy where writing two versions is next to impossible, but realistically, thats not very often.
Again, you seem to be labouring under a misapprehension here. Universal Binaries are what are technically known as 'fat' binaries. In other words, they are a file which contains more than one executable file concatenated together. In this case, it's a file which has the i386 binary and the ppc binary within it, padded to fit the encapsulated 'files' on filesystem block boundaries (4096 bytes) and with a header up front that says where they are.
I can't believe I'm having to say this on Slashdot of all places, but universal binaries are not some weird magical thing which runs the same binary code on two different processors. They're not like the bytecode generated for the Java Virtual Machine. They're just a way of storing the binary code & data for different architectures within a single file. That's all.
Oh, and want to see a shipping application compiled as a universal binary? Try BBEdit 8.2.3 (here are the release notes).
Firstly, the latest version of 10.3 is 10.3.9, and it'll run anything built with gcc 4.0, including things which use the C++ dynamic library. [/pedant]
Secondly, compiling with gcc 4 doesn't completely prevent apps working on earlier OS versions, except in a couple of cases:
gcc 4 uses a dynamic library version of the C++ runtime, so anything which uses the C++ stl would only run on 10.3.9 and later, unless you bundled the stl yourself.
If you use C, or Objective-C, then your gcc 4 application will run quite happily on any version of OS X 10.3. However, 10.2 support is likely out since gcc 4 now links everything against libmx, which wasn't shipped with 10.2 (I think).
Thirdly, it's entirely possible to build two applications (using two targets within Xcode, one building ppc, one building intel) & throw the binaries at the lipo command-line tool to generate a fat binary (read: universal binary) from the two of them.
Lastly, it looks like Xcode 2.2 includes options to set compiler, linker, deployment target, etc. seperately for each compiled architecture. So in the next version of Xcode you won't even need to bother with the second step, you just let it use gcc 4.0, and you set something like 'GCC_VERSION_ppc=3.3' and 'GCC_VERSION_i386=4.0' in the build settings. Voila.
I mean, did you really, honestly think this wouldn't ever be possible? Universal binaries are just two binary files concatenated at 4096-byte (fs block size) offsets, with a header at the beginning saying what's in the file & where it is. Only a portion of the file gets mapped into memory, and that's the bit specified by the entry in the Fat header. Look at <mach-o/fat.h> and <mach-o/loader.h>; that's really all there is to it.
The Register had a story on this earlier in the day, complete with a clarification from FSF Europe president Georg Greve:
Reuters quoted him as saying that anyone who patented software would be prevented from using free software. Greve says this is not quite what he was getting at:
"The basic idea is that if someone uses software patents against a Free Software program under the GPL, he might lose the right to distribute that particular software, to use it for their products. We have no interest in restricting the way people can use and develop software."
So, not "companies using software patents lose rights to GPL software," more like "if a company uses patents to attack $GPL_SOFT_PACKAGE, they forfeit rights to $GPL_SOFT_PACKAGE". Sounds fairly reasonable to me. If you want to use the software, agree that you won't use patents to kill it off, whilst internally nabbing the copyrighted code for your own (redistributed) products.
Actually, the graphics routines in Mac OS X are all C. Check out Quartz 2D for the raw graphics APIs, and the Human Interface Toolbox, particularly HIView and the base class (and methods for designing/registering your own classes), HIObject.
Windows are created using the Carbon Window Manager, and then you use the Quartz-based HIToolbox methods to manage and manipulate UI objects themselves. Documentation for all this (along with a porting guide from Mac Toolbox to HIToolbox) is available here.
On top of all this, the HIToolbox APIs are built around the model-view-controller architecture, so are well-suited for use in a segregated UI layer within a cross-platform application -- such as Inkscape.
I'm sure that there are people running 10.4 on 500MHz or lower G4 machines.
As a Mac developer, I can tell you now that I'm developing using Tiger on a 533MHz PowerMac G4, and that other (testing & personal) machines in the office are running Tiger on 450MHz PowerMacs. I've got a 450MHz Cube that's been running anything I throw at it since I bought the thing in September 2000 (although the GPU died recently). Oh, and the testing machine on my desk is a 350MHz G3 iMac, which also runs Tiger happily.
Granted, they don't show all the funky graphical CoreImage/CoreVideo stuff in Tiger, but they're five year old machines, or more importantly, they're using five-year-old graphics cards. I could update the GPUs to get that stuff working.
Macs keep going quite a long time. And while there are certain features of new Mac OS X versions which benefit from newer, faster hardware, the majority of the new features are just software, which will pretty much run everywhere. Being able to type a function name into Spotlight and have it give me a list of all headers, source files, PDF & HTML documentation files relating to that function within ten seconds is marvellous, especially since it'll rank the results by relevance. New hardware doe sthe same thing in under a second, but that's just added convenience. Getting the list at all is the important bit, regardless of the amount of time.
-Q
Re:My iBook died two months ago...
on
New Apples Next Week
·
· Score: 5, Informative
I can absolutely confirm this (dammit, I leave Slashdot one day & folks are already posting the answer *I* wanted to give).
As a Mac developer writing software that's in the hands of a not inconsequential number of people, I have on my desk one of the Intel-based Developer Transition Kits. The reason I have this is not because I'm now going to be building Intel-only applications from now on, but because in a year's time, when a client buys a new Mac an it's running on an Intel processor, they will still want to use my software.
As a result, I compile everything as a 'Universal Binary' -- which, to the uninitiated, is a new name for the 'Fat Binary' of yore; in other words, it's got the Intel and the PowerPC binary files concatenated together, with a little table of contents up front.
When I first fired it up, it took me one day to get a quite a few programs (components of one software product) to build & perform perfectly on Intel (one little problem - ntohl() modifying the source operand on Intel processors - caused 80% of the delay, due to it being a bitch to track down) and PowerPC. They even generate various files which can be passed between one another with nary a glitch.
And before people start whinging about applications doubling in size, take a look at the size of the actual program binary itself. Delicious Library is 908Kb. Final Cut Pro is 4.7Mb. Things like Photoshop will undoubtedly be larger, and will therefore be candidates for seperate Intel/PowerPC binaries (i.e. the installer detects what system is running, and installs the appropriate binary). It's worth noting, though, that applications which make heavy use of the OS X frameworks will be smaller, and much more palatable as universal binaries.
In short, as an Apple developer, whose software is installed on hundreds of thousands of Macs, it's actually more work for me to make my software work on intel only - after all, for that I would need to:
Convert apps to little-endian compatibility (no copying 32-bit values to byte streams with *((unsigned int*) charPtr)).
Turn on Intel compilation.
Turn off PowerPC compilation.
...maybe I'm just lazy, but it seems to me that it's easier just to let it compile both.
Slashdot Mirror
You make some good points, but I feel that perhaps you've picked the wrong words, or else you simply have some inaccuracies in there: such as G5s running under "software emulation". Also "subversion PC program" -- I have absolutely no idea to what you're referring there, although I'd be intrigued to find out.
Worth pointing out here is that the PowerPC spec has always inclued 64-bit instructions alongside the 32-bit instructions, and has always included support for both 32-bit and 64-bit addressing modes. The G5 was the first processor in the series to actually implement those, but they've been part of the standard for a while now.
What this meant was that, when the G5 first came out, it mostly computed 32-bit memory addresses. The compilers were available, however, to make use of the 64-bit mathematic instructions available in the new processor, and those could be used from OS X 10.2.7 (the first version available on the G5) onwards. Well, on any OS really, they're just CPU instructions, they're not dependant on the OS.
OS X 10.4 has support for 64-bit addressing at the core. The software can also handle 32-bit addressing: it just promotes the 32-bit value from the 32-bit-oriented client process to a 64-bit value internally when it needs to get at a real (64-bit) memory address for mapping purposes. The kernel handles this all internally. Also, from what I've seen (in the Darwin source code) anything that would benefit from a ppc64-specific implementation gets it. Note that in C code, not much needs to change: the 'long long' 64-bit datatype is available under both ppc32 and ppc64 architectures, it's jus that ppc64 can fit such a value into a single register, while ppc32 uses two adjacent ones. The only potential problem is that the 'long' datatype is 64-bit on a G5, since OS X uses the LP64 model (Longs & Pointers are 64-bit).
Beyond those two things (CPU math instructions with 64-bit operands, 64-bit memory addressing), what else is there to expect? Those that think '64-bit-ness' translates to a performance gain for anything other than 64-bit datatypes are going to be disappointed; 32-bit instructions don't get executed two-at-a-time or anything like that.
-Q
I wouldn't say forced exactly, but having the games on a separate computer makes it really easy to browse GameFAQs' and Gamespot's walkthroughs without having to exit the game altogether.
.
.
.
.
.
-Q
Worth pointing out here: iCal, and iWeb both work without .Mac, as does Backup, with the exception that Backup is part of the .Mac bundle in the first place, not a separate product. iCal uses the same format as the Mozilla calendar. Backup can backup to folders, CDs, DVDs, etc. In terms of software capability, they all have non-.mac features.
iCal can publish calendars (and subscribe to them) without .Mac. It's a standard file format, you just publish it to a different URL: the two available options are '.Mac' and 'Private Server'. Needless to say, the 'Private Server' option requires that you enter some more details than the '.Mac' one.
iWeb will publish to other servers, although rather than building in the full FTP client, webdav client, etc., you just publish to 'a folder'. You can then upload that folder using your tool of choice (you could even edit the output pages yourself if you wanted); or alternatively, you could have it mounted on the desktop (perhaps via WebDAV, like the iDisk) and publish to that 'folder'.
I'll agree with you on the sync though; sync to another computer via Rendezvous, erm, Bonjour, would be a very nice feature, especially for those of us who have laptops. I'd love to hit a button in my laptop that just replaces my stuff with versions from the desktop before I go on holiday, that would be *so* useful-- and I actually *have* a .Mac account.
-Q
It's also well worth noting that with the tight integration with iLife, especially now that iWeb is available to replace the online HomePage site builder, that people who buy .mac don't even really need to visit the actual www.mac.com site anyway. I know I don't except when I want to check some settings somewhere, like the split between Mail & Web space from my available 1GB.
When I put up a site on .mac, I could potentially use advertising on it. I choose not to, for all sorts of reasons (such as: who the fuck ever visits my site in the first place, except my parents and a couple of friends?), so I'd be really kinda narked if they dropped the price by adding advertising-- since that advertising would most likely be appearing on my homepage, since let's face it, the homepages would get many more hits than the .mac interface itself.
As to the value of .mac, I'm happy to pay for it, as is my wife, even if just for the email. However, we also have our calendars on there, which we publish so that, for instance, I can look at my iCal application to see what time she finishes work tonight (when I have to collect her). We also put some photos up there for the folks (since the Atlantic Ocean separates us from *both* our families), and I kinda want to do a blog, even though I know it'd be highly uninteresting to most folks (I just want to see if it helps me become a more thought-organised person, I guess). But the email is the main thing, and I'm happy to pay for it.
-Q
Wow. I guess you learn something new every day, huh? (Well, I do, it seems).
Thanks for the correction, much appreciated; makes the main point even more concrete.
-Q
In a reply both to the parent and the GP, it's probably worth noting that Creative wasn't exactly the first to implement this sort of thing either: arguably it's actually a NeXTStep thing.
In any case, even if Creative's patent is on the first use of that 15-year-old (at the time of the Nomad, 11-year-old) browsing method on an MP3 Player, then -- all talk of meritless/obvious patents aside -- I think Apple should get the benefit of the doubt since their interface for the iPod is so obviously the same column view used in the Finder on OS X, and in NextStep before it.
I mean, it's patently obvious that the interface from the iPod is nothing but a port to an MP3 player of the existing interface to their computers. I mean, that's got to count for something, even if only to illustrate that the Creative patent shouldn't have passed the non-obviousness filter. I mean, if I can file a patent today which uses someone else's idea on a new device, and then use that to stop said company using *their own idea* on a similar device, then ...
Shit, I don't even have the words. And I know lots of words.
To Creative:
-Q
The GP wasn't referring to Vax or Unix machines of 20 years ago with regard to their simplicity. It referred to the fact that security was a solved problem on those machines. You yourself go on to say:
The thing really worth noting in your statement is that OS X uses a >20-year-old security system. It's using Unix permissions, straight from the BSD core of the system. The same BSD core used in the NeXTStep operating system a little under 20 years ago (albeit slightly upgraded since then).
Individual software packages, particularly those designed to listen for commands from the network and execute things locally (ssh, etc.) can have the sort of issues you decribe in your last paragraph; As they get more complex, the task of maintaining security does potentially also become more complex. But on an operating system level, there have been sufficient rules in effect for a long long time now. For instance, just saying "this can only be done with root privileges" and "root privileges can only be gained interactively, and on a one-shot basis" will cover a vast amount of potential issues, and is pretty much what OS X does, as you describe (albeit with slight timeouts to root privileges, rather than pure one-shot operation -- although that timeout is user-configurable).
At the end of the day, MS-DOS, QDOS, and such, left that out in the interests of expediency, size, and (maybe) end-user perceived complexity/ease-of-use. It then became a standard. I like to quote my boss on this one:
He tells me that, having worked with Unix/BSD/Vax -level machines in the late seventies, when the IBM PC came out, he and his cohorts were interested to see it. They took one look and put it down as a failure -- a joke, even -- because it lacked so much of what they saw in their current machines. Unfortunately, it became the standard, in the process setting back the state of the art by many years.
Not least is the point that Unix/Vax systems were inherently multi-user systems, and they needed a robust way of preventing one user from destroying another's data. So this was built in from the very start. MS-DOS and QDOS didn't have this capability, so the standard became that any program had full access to just about anything. The only high security implemented was in the CPU itself, where a system trap was needed to get access to 'Ring 0' (privileged) instructions. On top of this, the somewhat limited nature of the system itself led many programmers -- used to working on a more capable OS -- to make modifications to the core system, to help their stuff work. That required privileged access to the system, in order to install hooks, drivers, and so on.
Of course, once this became a standard, it was hard to change that behaviour, and it never was changed because 'backwards compatibility' was the highest goal. So when mutli-user functionality was built into Windows 9x/NT, privileged operation became the norm. People logged in as an administrator, because their programs were designed needing full access to the system, and little or no provision was made for interactive temporary privilege escalation within the OS itself. Unlike Unix/BSD, you couldn't just ask the user for an admin user & pass to get the privs needed to put some file somewhere special, and then lay down those privileges when you were done with them.
As a result, you get the horrible mess we're talking about: An IM program that can corrupt the core operating system and ultimately gain access to privileged-mode CPU cycles? WTF? A game that can modify the system kernel, or the boot sector of the hard disk? They can only do that because the system lets them, or because the system won't let them do some small operation without high privileges, and requires that the entire process runs with those privileges as a result.
-Q
Also, especially silly since iTunes is the one app installed with OS X on Intel that *isn't* compiled for Intel. It's the token Rosetta application, and everything else is built for Intel. This means that it doesn't use things like AltiVec (or, on Intel, SSE) for encoding/decoding; Rosetta emulates a G3 (PPC750 I think).
-Q
Simple: just go on holiday & buy a network card abroad, then bring it home & install it. That'll really fox 'em, they'll think you're in another country !
The MAC address isn't traceable to a geographic point now-- at least, no more so than is an IPv4 address, and possibly less (since IIRC it's only actively used when indentifying & targeting machines on the local loop). Each hardwware card has a nearly-unique address, but there are possible clashes. It'll take a long time to find one, however.
The only things really detectable through a MAC address are the vendor (there's a vendor ID in there) and *possibly* the geographic locale in which it was produced. But that's ultimately up to the vendor, it could be just a random string of bytes.
The cards/chips are sent all over the world, so it's not like anyone's watching where they go.
"Ah, that card was went to the second shelf from the top, third row from the left, front of the pile, at CompUSA, downtown Washington. It was purchased by Vernon MacArseTrumpet, of Apartment 192, 1800 Q St. Washington DC. Now we can watch everything he does!"
Probably not going to happen. It'd just take too much work watching 'em go round. It's not like local ISPs who get blocks of IP addresses to hand out, which can be traced from origin, to ISP, to branch, to house. No-one's keeping an eye on the 5000 boxed ethernet chips which leave the warehouse at 4am in each of 8 trucks bound for umpteen different places. It's just too much work.
-Q
What you fail to take into account is that the underlying system has been Intel compatible for a very long time. Significant parts of the Carbon API are usable on Windows (it's used in QuickTime, I believe), and the remainder of OS X is basically an updated NeXTStep operating system, which has been compiled for 68k, PowerPC, and i386 for a long time now -- over ten years.
Also, there's the little point made during the announcement: Mac OS X's 'secret double life'. All the Apple stuff has been kept Intel-compatible since at least the year 2000. As such, if Apple wanted to move to (say) the Transmeta Crusoe, or the Intel Itanium, they would have significantly more work to do, since they would actually be starting from scratch.
Of course, the fact that the OS is based on BSD/mach, which is written primarily in C, makes it fairly portable. The kernel can be recompiled to run on any processor of choice, just about. A few things need to be changed to cope with register sizes and availability, and some assembler code would need to be rewritten. But for the kernel, that's about it. Then you just have everything else, which could potentially require a lot of going over lots of existing code making sure it doesn't make any silly assumptions about the host architecture. That's the bit that'll take the time, and the only reason it's do-able in the 12-month timeframe currently allotted is because they've been doing it for a long time now already.
-Q
It gets better than that, even:
A few years back I was installing Office 2000 Pro onto my new Win2k machine at work. It was an upgrade copy, and we used an old Word 5 floppy disk when asked to present the previous version. To my horror, however, I found that the really rather old floppy was unreadable, and therefore I had no way to install the new software.
After many attempts to get at the data on the floppy disk, I was about to give up; before that, however, I tried one last trick, which I naturally expected to fail. When asked to insert the installation disk for my previous copy of Word/Excel/Office, I decided just to point it at the CD from which I was installing Office 2000. Wouldn't work anyway, so where's the harm?
Worked like a charm.
-Q
Oh, I'm afraid they're most definitely single files.
I'm an OS X developer, and I know whereof I speak because I deal with these things all the time. Not only do I write system-level software which at certain points involves scanning binary files to locate symbols, sections, and the like, but I also have access to a DTK, and can see first hand that the ppc/i386 binaries are formatted in exactly the same way as ppc/ppc64 (or ppc/ppc64/i386) binaries are when building for 64-bit support on OS X 10.3.
GUI applications are bundles (usually -- I've written command-line apps that show a UI before now); frameworks are (kinda, they don't have the 'bundle bit' set in their top-level folders, so they appear as a folder, not a file); plugins are (if they have the bundle bit set); and kernel extensions are. Lots of things are indeed bundles.
Command-line tools, however, are not bundles, yet they are (or can be) Universal Binaries.
However, go into the Finder, do Cmd-Shift-G, and type '/usr/bin' into the field, then click 'Go'. See all those files? They're not bundles. If you right-click or control-click on them, there is no 'show package contents' option: that's because they're not a package. And yet, these are exactly the type of files which use the universal/fat binary format to gain 64-bit support (since that's only available for non-GUI apps which link only against the system & c libraries).
In the Terminal, type file /usr/lib/libSystem.B.dylib and press enter. You'll see two (or on a DTK, three) architectures listed. Now do ls -ld /usr/lib/libSystem.B.dylib and press enter again. Look at the leftmost character. Notice how it's a hyphen, not a 'd'? That means it's a file, not a folder. Now do the same thing for an application bundle (e.g. ls -ld /Applications/Calculator.app). See how the leftmost character here is a 'd'? That's because it's a folder, with (possibly) the bundle bit set, although that last doesn't matter since the Finder has special handling of the .app suffix anyway.
Universal binaries are created by compiling separate binary files, one for each target architecture. These binaries are then passed to the lipo tool to concatenate them into a single binary file; here's the manual page for lipo.
Also, you can see here some instructions on how to build a universal binary from a configure-style project (i.e. not using Xcode). Scroll down particularly to the Merging Multiple Builds section, taking especial note of the bit about using the file command to verify the contents of the single file that was output.
For further information, please refer to the following:
Posting here just for 'completeness', for the potential enlightenment & edification of anyone following this particular thread.
Universal binaries are 'fat' binaries. I know this for a fact, because I'm an OS X developer and I've worked with them. Both for compiling 32/64-bit ppc apps, and while compiling stuff on a DTK (about which I obviously can't go into too much detail).
Details will go to another reply (who was more obnoxious in his incorrectness), but I've written programs that parse these things; they are just fat binaries, in a single file. You can download BBEdit 8.2.3 and take a look for yourself if you like, that's a universal binary.
-Q
Incorrect.
The dynamic linker in OS X makes the actual location of functions & other symbols in a linked library irrelevant, since the addresses are computed at run time by the dynamic loader -- the compiler inserts a 'stub' routine and a dummy address. The dummy address is first initialised to the address of a compiled-in function called _dyld_stub_binding_helper, which calls the relevant dyld library APIs to find the real function. The real address is then written over the dummy address, so future invocations will jump straight to the target routine.
I compile apps on OS X 10.4. Most things I compile using gcc 3.3 (because gcc 4.0 auto-links against a library that isn't present in 10.2.x), but I've never had the slightest problem running an app on an earlier version of the operating system. Unless I actually attempt to use a symbol that actually isn't there, nothing goes wrong.
Also, OS X has had weak-linking since 10.2. That means that the stub binding routine can happily return a symbol address of zero, meaning that I can link against somelib.dylib, including somefunc() which only exists in 10.4 & later, and -- at runtime -- I can simply do if (somefunc != 0) to see if the function is available. On 10.4, the function will be there. On earlier systems, the symbol value will just be zero.
Y'know, you should actually read the links you post, for instance, on the page you linked you'll find this useful nugget of information:
...you seem to imply that you're a programmer, so I'd recommend looking at <AvailabilityMacros.h> for further enlightenment.
So no, this isn't "just how Xcode works". Xcode (read: gcc & dyld) work in precisely the opposite way, and for a good reason. What's really happening is that some part of the binary file format has been changed, implemented, or created for the benefit of the Mach-O/dyld runtime.
Maybe it's something new for the Intel machines; maybe it's something that has been available for PPC, but just wasn't implemented in the Intel build of OS X 10.4.1; maybe the latest Intel build of dyld has some performance enhancements which are mirrored by a slight re-ordering of the data/text section format & flags. It doesn't really matter, since even now-- and this seems to be an important yet frequently ignored point so I'll make it very clear --
OS X for Intel is NOT FINISHED YET
Apple can and will make changes. That's part of the reason why folks like me have Developer Transition Kits. So we & they can find things that don't work so well, and would do better if they were changed slightly. This is just work in progress, and things can be changed, removed, added. It's Just Normal.
-Q
They should do. I've just looked at the SDK for 10.1.5 and <mach-o/fat.h> is right there. Makes sense, too, since the support for it comes from NeXTStep.
I'm also pretty sure that I've run a Universal Binary on 10.2 personally. Although I'd have to double-check that once I get back to work tomorrow.
Anyone with 10.2 out there care to launch the latest versions of either BBEdit or Mathematica for us? They're both fat/universal binaries (ppc/i386 and ppc/ppc64 respectively).
-Q
Yes, but this isn't 'planned obsolescence'. This is an Unfinished Product. If I write a program, and at the start I put in Feature X, then later on remove Feature X to make way for Feature Y, before I've even released it as a product, then nothing becomes obsolete. There's no-one using Feature X, because the product hasn't been released. Now, I may have sent copies to some people to test, but that's all they'd be doing with it. Testing. Just like we are with the Apple DTKs, and the Intel builds of OS X.
Now, if OS X 10.4.1 for Intel were actually shipping, I'd agree. But it isn't. It's an unfinished product that is only available to paid-up developers -- the reason for which is very likely to filter out hobbyists and people who would sign up & 'buy' an Intel-based Mac for general use. The Developer Transition Kits are not ready for the prime time. They aren't finished. They are a work-in-progress.
OS X for Intel isn't finished. Its entire user base is made up of people who know that, and who have no trouble whatsoever updating to the latest version of the pre-release software. There are no legitimate users of OS X 10.4.1 for Intel processors who do not have access to the 10.4.2 install DVD, and there are none who have any reason not to install it.
-Q
Yes, binaries built with 10.4.1/intel still work on 10.4.2/intel. However, that's not really something that anyone should concern themselves with. Everyone who legitimately has access to the intel version of OS X also has access to the latest OS upgrade for it, for free. So there are no excuses for not using the latest version to build applications.
I haven't looked into it at all, but I'd guess that the dynamic loader has had new features added (or maybe just implemented, since there's no guarantee that 10.4.1 implemented everything), and therefore binaries use this. Something like certain flags within the symbol table, or the indirect symbol table, that sort of thing. If 10.4.1 doesn't have an implementation of the associated feature, it'll not work.
-Q
ADC Select membership gets us access to any & all pre-release software. No matter what that may be. There are no additional costs involved in downloading the latest pre-release iteration of any piece of software, and that includes OS X for intel.
All Apple beta software (with a few minor exceptions) is available only to ADC Select members. That's what ADC Select membership is. The fee doesn't pay for the software, it pays for technical support, and goes towards the salaries of Apple DTS, who have to work with all of us who use the beta software.
-Q
Erm-- This is a developer system. It's not finished. This isn't The Thing That'll Be Released Next Year, it's something cobbled together so that folks like me can make sure my software will work on the processor/hardware. It's not a live system that's being 'bugfixed', it's a development system that's actively being developed. That means it'll change. Binary file formats, linker specifics, etc. etc. We're not so much 'upgrading', we're keeping our aim focusssed on a moving target.
...also, having re-read your comment: where do you get the idea that anyone wants to maintain any sort of compatibility with the original 10.4.1 DTK? I mean, it's not like it's been released to the public or anything. Compatibility with the intel build of OS X 10.4.1 is not required; compatibility with the intel build of OS X 10.2 will also have been broken, but you don't seem concerned about that...? Or do you think we should all maintain compatibility with the pirated copies of OS Xi 10.4.1?
(For the record, intel apps built under 10.4.1 still work using 10.4.2; I'd guess that new capabilities/functions were added to the intel dynamic linker, which gcc 4.0.1 uses)
Again, you seem to be labouring under a misapprehension here. Universal Binaries are what are technically known as 'fat' binaries. In other words, they are a file which contains more than one executable file concatenated together. In this case, it's a file which has the i386 binary and the ppc binary within it, padded to fit the encapsulated 'files' on filesystem block boundaries (4096 bytes) and with a header up front that says where they are.
I can't believe I'm having to say this on Slashdot of all places, but universal binaries are not some weird magical thing which runs the same binary code on two different processors. They're not like the bytecode generated for the Java Virtual Machine. They're just a way of storing the binary code & data for different architectures within a single file. That's all.
Oh, and want to see a shipping application compiled as a universal binary? Try BBEdit 8.2.3 (here are the release notes).
Firstly, the latest version of 10.3 is 10.3.9, and it'll run anything built with gcc 4.0, including things which use the C++ dynamic library. [/pedant]
Secondly, compiling with gcc 4 doesn't completely prevent apps working on earlier OS versions, except in a couple of cases:
Thirdly, it's entirely possible to build two applications (using two targets within Xcode, one building ppc, one building intel) & throw the binaries at the lipo command-line tool to generate a fat binary (read: universal binary) from the two of them.
Lastly, it looks like Xcode 2.2 includes options to set compiler, linker, deployment target, etc. seperately for each compiled architecture. So in the next version of Xcode you won't even need to bother with the second step, you just let it use gcc 4.0, and you set something like 'GCC_VERSION_ppc=3.3' and 'GCC_VERSION_i386=4.0' in the build settings. Voila.
I mean, did you really, honestly think this wouldn't ever be possible? Universal binaries are just two binary files concatenated at 4096-byte (fs block size) offsets, with a header at the beginning saying what's in the file & where it is. Only a portion of the file gets mapped into memory, and that's the bit specified by the entry in the Fat header. Look at <mach-o/fat.h> and <mach-o/loader.h>; that's really all there is to it.
-Q
The Register had a story on this earlier in the day, complete with a clarification from FSF Europe president Georg Greve:
So, not "companies using software patents lose rights to GPL software," more like "if a company uses patents to attack $GPL_SOFT_PACKAGE, they forfeit rights to $GPL_SOFT_PACKAGE". Sounds fairly reasonable to me. If you want to use the software, agree that you won't use patents to kill it off, whilst internally nabbing the copyrighted code for your own (redistributed) products.
-Q
...that I'm really glad my wife works approximately thirty seconds away from the Apple Store at Yorkdale :o)
-Q
PS: Check whether it's in stock at your local Apple store here.
Actually, the graphics routines in Mac OS X are all C. Check out Quartz 2D for the raw graphics APIs, and the Human Interface Toolbox, particularly HIView and the base class (and methods for designing/registering your own classes), HIObject.
Windows are created using the Carbon Window Manager, and then you use the Quartz-based HIToolbox methods to manage and manipulate UI objects themselves. Documentation for all this (along with a porting guide from Mac Toolbox to HIToolbox) is available here.
On top of all this, the HIToolbox APIs are built around the model-view-controller architecture, so are well-suited for use in a segregated UI layer within a cross-platform application -- such as Inkscape.
-Q
As a Mac developer, I can tell you now that I'm developing using Tiger on a 533MHz PowerMac G4, and that other (testing & personal) machines in the office are running Tiger on 450MHz PowerMacs. I've got a 450MHz Cube that's been running anything I throw at it since I bought the thing in September 2000 (although the GPU died recently). Oh, and the testing machine on my desk is a 350MHz G3 iMac, which also runs Tiger happily.
Granted, they don't show all the funky graphical CoreImage/CoreVideo stuff in Tiger, but they're five year old machines, or more importantly, they're using five-year-old graphics cards. I could update the GPUs to get that stuff working.
Macs keep going quite a long time. And while there are certain features of new Mac OS X versions which benefit from newer, faster hardware, the majority of the new features are just software, which will pretty much run everywhere. Being able to type a function name into Spotlight and have it give me a list of all headers, source files, PDF & HTML documentation files relating to that function within ten seconds is marvellous, especially since it'll rank the results by relevance. New hardware doe sthe same thing in under a second, but that's just added convenience. Getting the list at all is the important bit, regardless of the amount of time.
-Q
I can absolutely confirm this (dammit, I leave Slashdot one day & folks are already posting the answer *I* wanted to give).
As a Mac developer writing software that's in the hands of a not inconsequential number of people, I have on my desk one of the Intel-based Developer Transition Kits. The reason I have this is not because I'm now going to be building Intel-only applications from now on, but because in a year's time, when a client buys a new Mac an it's running on an Intel processor, they will still want to use my software.
As a result, I compile everything as a 'Universal Binary' -- which, to the uninitiated, is a new name for the 'Fat Binary' of yore; in other words, it's got the Intel and the PowerPC binary files concatenated together, with a little table of contents up front.
When I first fired it up, it took me one day to get a quite a few programs (components of one software product) to build & perform perfectly on Intel (one little problem - ntohl() modifying the source operand on Intel processors - caused 80% of the delay, due to it being a bitch to track down) and PowerPC. They even generate various files which can be passed between one another with nary a glitch.
And before people start whinging about applications doubling in size, take a look at the size of the actual program binary itself. Delicious Library is 908Kb. Final Cut Pro is 4.7Mb. Things like Photoshop will undoubtedly be larger, and will therefore be candidates for seperate Intel/PowerPC binaries (i.e. the installer detects what system is running, and installs the appropriate binary). It's worth noting, though, that applications which make heavy use of the OS X frameworks will be smaller, and much more palatable as universal binaries.
In short, as an Apple developer, whose software is installed on hundreds of thousands of Macs, it's actually more work for me to make my software work on intel only - after all, for that I would need to:
-Q