Slashdot Mirror
Mac OS X Intel Build Addresses Pirating
aardwolf64 writes "ThinkSecret has an article up detailing information about the newest Mac OS X 10.4.3 builds (which is currently said to fix almost 500 bugs with 10.4.2.) What is more interesting is the release of 10.4.2 (Intel) to developers. Universal binaries built with the new version (and apparently all subsequent versions) will not work on systems running the older version of the OS."
Mac OS X 10.4.3 build 8F23 includes about 75 new bug fixes to the OS, fast bringing the total number of specific improvements the update will deliver to nearly 500.
Looks like 75 bugs and 500 improvements.Bradley Holt
Agreed, there is absolutely no reason for them to keep binary compatibility. Especially since all the people that have legal access to the DevKit can't release any of their stuff to consumers yet and are actively working on getting their application working on the Mactels so a simple recompile to them means nothing.
Most cracks are extremely simple, crackers are simply looking for a conditional and unconditional jump instruction, that's it! Then it's all about stepping into the code step by step and having break points.
if ( !condition ) { error_message(); }
http://www.unixwiz.net/techtips/x86-jumps.html
So, one easy way is as simple as by passing the checks by renaming JZ into JNZ, JE into JNE, JO into JNO, or similar when the serial number is checked.
This way any invalid serial is now actually valid...
You might have to add a NOP to make the instruction the same length.
Other serials are simply generated by having the serial key code compare being blindly copied into another program to create a keygen.
if ( input_key != calculated_key ) { error(); }
Another way is to run it in debug mode and then see the content of the register having calculated_key.
The only product scheme which are more difficult to crack is those which they *seems* to be cracked, but fail unexpectively after a period of time which is very far apart the actual "test".
Days or weeks is a good delay.
And for products which prevent "debug mode" utilities, well, there exist other products to go around this issue by simply masquerading the WinIce/SoftIce application, so it doesn't get detected and prevented from running in "debug mode".
That's all I can tell.
Some of course are encrypted, but even then the code must be "decrypted" before being run so...
it's still possible to analyze it, just a bit harder.
In the end, the best way for a product is to be good, useful, have nice manuals and have a proper support at the right price, then the majority of people will buy it, especially if it's bundled with good hardware, since it wouldn't make sense otherwise.
It means that people that still have the older pirated version of OS X will not be able to run any programs that are created after yesterday.
The previous developer release was an early-release alpha built for a completely new architecture that was intended to help developers get a jumpstart on porting apps to the new platform. I'd say it's natural to have flaws, even somewhat major ones. I don't think they're worried enough about people finding out that it might have bugs to "hide" it under the guise of stopping a handful of hobbyists (several thousand is still a handful) from running the OS as easily.
HP??? You are kidding right. They make great printers but I don't think HP support or the quality of their computers are good at all. We used to have a contract with HP and now they are out
Consumer Report June 2003: Desktop computers Readers report, surveying 39,000 readers ...etc. Then for Technical Support it was Apple, Dell, Gateway, Sony, HP...etc.
Shows Apple with the highest ratings for Repairs. Followed in order by Dell, HP, IBM
Now in June 2005. Consumer Reports Tech support: Desktops & laptops survey shows for Dekstops it was Apple, Dell, Gateway, HP, Sony ...etc. And for laptops Apple, IBM, Toshiba, Dell, Gateway, HP ...etc.
Based on my own experiences the data above is more or less correct, although I've felt Dell slide in the past two years. Dell used to have better support, but lacked testing their products thoroughly sometimes when the slap together components from five different suppliers. Which brings me to the issue of finger pointing.
We've had to fight PC manufacturers many times when our computers don't work, when the sound card driver causes a BSOD, PNY graphics board genlock doesn't work, when the OEM isn't able to control the OS enough to fix problems. Its frustrating as a customer. As for Sun we've had good experience with them so far. Although one black mark I can recall is for their flagship enterprise servers where having major problems two year ago. Sun traced the problem to memory chips from IBM and tried to differ the blame on IBM. Sun's corporate customers where unimpressed and just wanted the damn enterprise servers fixed. So even Sun can have issues, but less so in my experience.
The Apple software/hardware solution tends to work better and there are less people for them to blame, so I don't get the run around as a customer. They provide the whole solution and the buck stops with them when I have a problem, unlike other vendors that make me run around.
If Apple does come up with products that don't honor the warranty, which I have not experienced yet. I'm glad that those lawyers are out there to keep the company "honest" when there are legitimate issues with the product. However, your recommendation hasn't convinced me I would experience less problems from another vendor and the data I provided above speaks to that fact.
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
You might want to consider ADDING MEMORY to that machine. With OS X being UNIX based, it either uses memory, or goes to a swap file (look these terms up, if they sound weird to you). Swap is bad, as it's dog slow... Your PowerBook is most likely in Swap Hell.
OS X makes a dramatic speed jump once a system goes above 512mb of RAM - 768 mb is the sweet spot. So, if you have one 256mb SO-DIMM in there, add another 512mb, and you should notice a significant speed increase.
Also, bear in mind tha such an old machine has an equally old hard drive - read: slow hard drive, which translates into further slowness.
I still kept my old Pismo at 500MHz - and with a fast 5400rpm hard drive, and 1 gig of RAM, it runs OS X Tiger just fine, and, in fact, pretty much flies for most operations.
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
Wait. You're comparing Apple's consumer products to HP, IBM and Sun non-PC big iron Unix enterprise support? i.e. These companies more expensive custom RISC hardware \ flavor of Unix support with their much more expensive service contract compared to Apple's standard consumer AppleCare Protection Plan(APP) ? Isn't that a tad bit unfair or am I the only one here?
If you're going to do that sort of comparison with big iron Unix enterprise system, then you should be comparing
- Xserve, Xserve RAID and XSan along with
- AppleCare Premium Service and Support plan with AppleCare Service Parts Kit for Xserve
- with any Mac OS X Server Software Support: level Select \ Preferred \ Alliance
compared to solutions from Sun, HP and IBM. I think your earlier post on Apple support been not as good, was certainly not comparing two alike products. If fact you are comparing two different markets altogether.I happen to be quite pleased with SGI when it comes to their servers with NUMALink and ccNUMA single image systems. In fact they are the best I've come across, but we are phasing out SGI because their hardware is too expensive and even though their support and response times are excellent. SGI's service contracts cost way too much. So if you are comparing similar Unix enterprise vendors to Apple's consumer level products and service + support you have to ask how much are you paying for your premium Unix enterprise support? I'm baffled by your comparison.
apple's support went into the shitter bigtime in the mid 90's and never recovered
I do not think you have been using Apple hardware since the mid-90's and your evaluation would be 10 years old. My experiences with Apple, Wintel, SGI, Sun, HP hardware is current, since I run all the systems to this very day. Now if you have real data to show Apple's enterprise service support is poor, then you have an argument. However, since Apple's recent foray into the server market is still too early. I doubt you would have any real numbers to show that their support and service is poor compared to the other Unix vendors.
To reiterate my point. I feel Apple's consumer support is quite good and as for their enterprise server market its too soon to tell. Comparing Apple consumer iBooks and iPods (as you did) to Sun Solaris, HP-UX and IBM AIX workstations is ridiculous in my opinion.
Apple took a $795 user operating system ($1295 with the development system), moderized it, added new technologies (many of which were open sourced) and open sourced the core OS.
They now sell it commerically (with the development system) for ~$120.
Meanwhile, they are giving away:
-Darwin
-QuickTime streaming server
-Webkit
-Launchd
-Netinfo
-I/O Kit
Nobody in the open source community really asked for any of those things, Apple just opened them.
Then again, the things that people want from Apple has never been part of "a free operating system" that Apple benefitted from:
- QuickTime (particularly the commercial codecs)
- OpenStep / Cocoa / Carbon APIs
- Quartz compositor, Q. Extreme
- Core Image, Video, etc; Core Data
So mentioning the GPL isn't applicable at all. Apple has borrowed from and contributed things back using BSD style licenses.
Trying for force people to share isn't freedom.
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