The pits in CherryOS

cherry osRecently I had some very, very disturbing news passed onto me regarding what's going on with the product known as CherryOS.

There's been a lot of buzz about Cherry OS lately -- since they started actually selling their product -- but there are some real pits in Cherry OS, and the people behind it (MXS), that aren't getting enough attention.

This isn't about nitpicking marketing claims, we're going to be breaking down some really uncool stuff involving taking GPL-based code from PearPC (among other projects) and completely false performance claims being used to get people to hand over their cash.

The claims of CherryOS
Updated 2005.03.31

More evidence is coming in all the time, and I'm trying to add it in while keeping things reasonably readable.

You'll be able to tell by the date above when its been updated, but be sure to check out the links I give as sources which often have more detail.

I've also posted several additional pieces explaining some of the specifics.

CherryOS surfaced as a PowerPC emulator for x86-compatible systems, specifically geared, and sold, to allow Windows users to use Apple's Mac OS X. This is actually kinda cool. Even though Apple Computer could sue your ass off because they have a clause in their EULA disallowing it, it's a really stupid clause and there are a whole host of reasons why someone might want to do this.

The company behind it really made waves by getting their press release materials picked up in MacWorld.com, where they claimed CherryOS could run OS X at 80% of the native speed of your Windows PC, and offered completely hardware translation (OS X in Cherry OS could see your modem and USB mouse, etc.), all for $50.

VirtualPC for the Mac ranges from $130 without an OS to $250 for a version that includes WindowsXP Pro. [The price was raised to $99 on 2005.03.29, added 2005.03.31]

They also claimed that one person had created CherryOS from scratch in four months, and listed a whole series of technical accomplishments that allowed them to reach their performance claims.

The hoax theory

No one had actually seen the product running, and the website only offered a streaming video of someone pointing a camera at an angle at a monitor while demonstrating it. Not exactly something to short Apple stock on, and after all extraordinary claims require puts the burden on you to give extraordinary proof. People were justifiably suspicious that this was a complete hoax, or at least not on the up-and-up.

There were some things that backed up the hoax-theory. Maui X-Stream, Inc. (MXS), the Hawaii-based company that said it developed Cherry OS, had zero history of any real software development, nor did anyone involved with the company, and these were really hard things to do. This company primarily acted as an ISP, and it didn't exactly fit their business model.

MXS was also trying to bring to market a video streaming solution called VX30. What better way to test how your product can handle load, along with having data to show off to clients you're trying to sell to, than to make an extraordinary claim and have the only demo be a streaming video using your solution.

On October 11th, they made it available for sale at $50, and available for download, except it turned out the software was never actually available for download even though they were taking orders. They claimed their site was being attacked by crackers and such, and changed the idea of 'orders' to 'pre-orders' with the promise of a release in a few days... again, this was October.

As of a few days ago they've started offering it for download, and for sale, so it's now not a hoax, but something you can actually run.

The PearPC theory

PearPCSix months before CherryOS was announced (not released) and started talking to the Mac press, another project, this one open source had created a PowerPC emulator for the x86 architecture: PearPC.

A few weeks later, PearPC had started some buzz when they showed Mac OS X running on x86 hardware, albeit slow as a dog. We're talking just achingly slow performance here, as in running OS X 500 times slower than the native speed of the computer. The JITC version runs around 15 times slower than the host.

The fact that it could boot OS X was more about showing just how complete their PowerPC emulator was -- there are other general emulators out there, but they are generally about emulating x86 or are very focused around an OS. So no one was expecting Mac sales to dry up overnight, but with PearPC, a Linux developer who didn't happen to have a Mac could debug and test for PowerPC distributions.

And, quite frankly, it's one hell of a hack.

It didn't take long for people to start to wonder if -- assuming CherryOS wasn't a hoax, it was actually PearPC with a new installer and different graphics and some extra thrown in.

There were some striking similarities between the projects. The minimum required hardware for CherryOS matched PearPC, as well as is capabilities, like hardware translation so that your USB peripherals would work in the virtual environment.

The evidence for stolen code mounts

As you can imagine, the people involved in PearPC, and those who use it, take what they do to heart -- and that CherryOS might be repackaging their code was just a theory. The people behind CherryOS categorically deny that they've done any such thing. They stated that to create CherryOS they wrote 36k lines of programming code, and that it was 'inspired' by PearPC, but wasn't in any way based on it.

However, they've been building a mounting body of evidence that is starting to become pretty damn damning:

  • There are PearPC graphics embedded inside the CherryOS executable. If you browse the CherryOS executable with a hexbrowser and go to 0xF9140 you'll find this graphic which you can see in this PearPC screenshot. This one is just beyond amusing. (Source)

  • When you take the CherryOS files Cherry IDE.dat, OSMAC.AXM, and CASE.EXM and concatenate them together (IE, like turn 3 files into 1) you end up with a file that is identical to PearPC's video.x file. (Source)

  • Throw the PearPC executable into the same folder as CherryOS.exe and run a program to run a comparison of the code, and you start finding all kinds of code matches, string matches (think english sentences), etc.

    1. Screenshot 01
    2. Screenshot 02
    3. Screenshot 03
    4. Screenshot 04
    5. Screenshot 05
    6. Screenshot 06
    7. Screenshot 07
    8. Screenshot 08
    9. Screenshot 09
    10. Screenshot 10
    11. Screenshot 11

    Some of these may not mean much to you if you aren't a programmer, but you should still be able to recognize the obvious string matches. (Source)

  • When it comes to something like this, comparing compiled code can be important, but strings are just obvious. Strings are basically just strings of characters. When you store text for any reason in an executable -- to display text on the screen, to a debugger, to a config file, etc. -- it's stored as a strong so it can be output.

    This forum thread has some of the most damning evidence, which which I'd urge you to check out, but I'll here's an example out of the many pages.

    From the CherryOS executable:

    slw_emit
slw_cr
slw_init_keymap
slw_update_keymap
slw_set_output_level
slw_spin_init
slw_spin
slw_pwd

    From the PearPC executable:

    slw_emit
slw_cr
slw_init_keymap
slw_update_keymap
slw_set_output_level
slw_spin_init
slw_spin
slw_pwd

    This is a mild example of what they're finding. It's pretty unbelievable stuff -- guys are finding their own debug messages from specific patches they've contributed to PearPC within the CherryOS executable, all while Maui-X Stream sits in Hawaii and claims they're all ignorant and misinformed and that they "never ever" copied code, even though you can check it out yourself.

  • The AstroAMatro file from CherryOS is identical to PearPC's configuration files, pci_rtl8139_mac and pci_3c90x_mac. (Source)

  • They -- again -- claimed to have developed CherryOS completely in-house, in fact (at least for awhile) they claimed it was one man's work, who did it in a span of four months. Interestingly enough, it turns out there's a reference to an off-shore coding house named COMSDEV within the code, which is a Pakistani-based company. Amusingly enough, the time-stamps on when the code was compiled in a time zone that certainly wasn't Hawaii or Pakistan. Not conclusive that they hired offshore help, but interesting. (Source 1) (Source 2)

  • CherryOS just happens to have many of the same bugs and errors that PearPC has. I.E., a developer has noted that CherryOS seems to have the same Mac I/O Sound Errors that his own code gives off, as well as his programming constants and debugging symbols... among other things. (Source 1) (Source 2) [updated 2005.03.12]

  • They appear to have also... incorporated... the functionality of HFVExplorer, a utility for dealing with the HFS-format (Macs use HFS and HFS+ for their disks) on Windows. If they aren't, they're going to have to explain why it looks exactly the same, the HFVExplorer icon is present, and the entry in Windows registry is the same. (Source 1) (Source 2) (Source 3) [updated 2005.03.12]

  • CherryOS's network driver appears to have been taken from OpenVPN's tap32 network driver, or at least they're completely identical. In fact, CherryOS 'accidently' outputs the original developer's GPL copyright notice, including his name. As you can probably guess the original developer -- James Yohan -- has never heard of them. (Source) (Source 2) [updated 2005.03.12]

  • It would appear as though CherryOS has started changing the build -- just about every day -- that you get when you download their software. Which means the CherryOS you download today may not be the CherryOS from yesterday, however they don't change the version numbers and mention no feature changes.

    Interestingly enough, the executables are actually getting smaller as more evidence comes out. Since it's release, the size of the executable has dropped by about 10%. You can do the math on this one, but it's probably a good idea to keep around the older builds for comparative analysis. I have. (Source) [updated 2005.03.18]

  • The emulated network adapter's MAC address (Media Access Control) is the same as PearPC's. Since there are about 281,474,976,710,656 potential MAC addresses out there, the statistical odds of this being a coincidence are about zero.

    Most networking protocols -- ethernet, Wi-Fi, Bluetooth, SCSI, Firewire etc. -- need a unique numerical identifier in order to function. This is your system's MAC address, and it's already set by the manufacturer when you buy your computer or router or other device. When you plug your computer into your cable modem, your ISP binds your connection to your MAC address before giving you an IP address. (Source) [added 2005.03.14]

  • It appears CherryOS is also including GPL'd code from the OSS project Cygwin.

    1. Screenshot

    Cygwin is a .DLL for Windows which allows developers to access Linux APIs, as well as a collection of tools. (Source) [added 2005.03.15]

  • 'Profiling' the code appears to show it does... exactly the same thing that PearPC's code does, even if they've changed some of the function names. If you stare at the below screenshots to see how things are connecting, you'll see it:

    1. CherryOS profile
    2. PearPC profile

    The above is just an example, there's more at the source listed, and I go into much larger explanation on what's happening here if you're confused. (Source) [added 2005.03.15]

  • On March 29, 2005, Maui-X released "version 1.2" of CherryOS. Some things have specifically changed in the version 1.2 release, so we'll go through those first.

    1. The price of CherryOOS has doubled from $49 to $99, while functionality was removed, and with no explanation being given.

    2. The file size of the CherryOS version 1.2 compressed executable is now 6.3MB, down from the 7.4MB version 1.0 executable released on March 08, 2005. They have removed a full 15% of the zipped executable since its 1.0 release. (Source)

    3. The 'shared drive browsing' functionality has been removed -- Maui-X says it has been disabled -- presumably along with the HFVExplorer code and graphics mentioned above. (Source)

    4. When it comes to the configuration file mentioned above, they seem to have taken the evidence to heart and tried to obfuscate it. Their method of doing so is to change all the variables to names starting with "cos", which presumable standards for CherryOS. As an example:

      • Prior CherryOS config variable:
        memory_size = 0x20000000
      • New CherryOS config variable:
        cosms = 0x20000000

      I know, you can't make this stuff up. (Source)

    CherryOS also claims a CPU performance increase of over 300%, along with an "overall system performance increase of over 300%", along with a core re-rewrite which improves stability. Interestingly enough, the PearPC team had just released a similar major update on PearPC about a week prior. I'll let you do the math on this one.

    I'll also leave it as an exercise to the reader how exactly a program that claims performance of 80% native speed on your x86 hardware can then improve that performance by 300%, while also telling you in their release notes that CherryOS is not an acceptable product for calculation-heavy use. [added 2005.03.31]

I don't think anyone with critical thinking skills above the level of a toaster wouldn't conclude that it's obvious that CherryOS is PearPC with some wrapper code to allow it to run in a way that it's less obvious that it's PearPC, along with piles of code from other open source projects.

One thing that hasn't added up was the fact that CherryOS was claiming performance equal to 80% of your native speed, while PearPC was claims a fraction of that...

The performance gaps

When it comes to emulation on the Mac, Microsoft's VirtualPC generally comes to mind which -- if you're lucky -- might give you 30% of your Mac's native speed while you're running Windows. This product has been around for years (It's on version 7), has been extensively optimized for the PowerPC and Windows, yet the idea of running Windows at 80% of a Mac's native speed is laughable.

Here's part of the deal -- the PowerPC is in some ways uniquely optimal when it comes to emulation of the x86 architecture. x86 processors, like the Pentium and offerings from AMD, are specifically horrible for emulating the PowerPC. A processor has things called registers -- think of these as slots in the CPU for storing data and instructions that are being worked on -- and relative to the PowerPC, the x86 architecture is starved for registers.

There's another issue going on; AltiVec. AltiVec is an SIMD engine bolted on to the G4 and G5 processors, similar to SSE and 3DNOW! on x86. Key word here is similar, as while SSE has improved greatly since it was initially birthed AltiVec is still very superior and much more capable. In some cases the actual performance difference is an order of magnitude, in some cases it isn't, but trying to translate AltiVec instructions into something SSE2 can handle is going to choke. Hard.

Mac OS X uses AltiVec everywhere in bits and pieces, and now that all of Apple's line includes at least a G4 you can bet it'll only become more prevalent. Of course, up until recently Apple sold a lot of G3-based machines, which didn't include AltiVec. For the purposes of this, let's just say Apple has found a workaround for that, which usually involves separate code paths and/or a way for altivec code to degrade down to code a G3 can run.

If you'll notice above, I said that PearPC generally runs 500 to 15 times slower than the native hardware, depending on whether or not you're using the Generic version or the version with the JITC (just-in-time-compiler). The really slow version (Generic) is sort of a reference platform that can go anywhere, like say the Xbox, while the JITC version includes an engine that is able to take PowerPC instructions, translate them, and then keep them around so it doesn't have to translate them again.

The real difference between the two is the inclusion of the x86-optimized JITC -- both versions emulate a G3. There's been work on an altivec-enabled G4-ish version, but it's nowhere near stable. Video corruption is a big problem, and while sound works it's very buggy.

PearPC has put some massive work into the JITC -- they're generating ~90% assembly code now -- and they've seen some real performance increases. However, it's nowhere near what CherryOS is claiming, the speed just isn't there, and won't be there. AltiVec support certainly won't do it, it just helps.

In terms of performance, the 'exciting' thing on the horizon for PearPC is support for 64-bit systems. PowerPC, in terms of speed, saw little benefit by going to 64-bit, but on x86 systems it's a different story. They've used it as an excuse to add in more registers (still much less than PowerPC) which not only speeds up performance per clock on CPUs like the Opteron, but the extra registers would help immensely in emulating the PowerPC.

It still won't be 80% of native speed -- let alone 90% -- I just don't think it's there for PPC to x86 using current technology.

There are rumors that Transitive has technology for ~80% native speed while emulating, which seems to work similarly to how the Transmeta chips worked, but I'm going to believe OS X running at 80%+ native on x86 hardware, even Opteron-class, when i see it... and Transitive has been talking about this since at least 2001, and is only now 'shipping' a product, but only to large companies.

I have a real hard time believing one guy created the whole damn thing in four months as they claim.

Yet, this is what a representative of Maui X-Stream had to say in a recent Mac Obvserver article:

Mr. Kartes said what he's most proud about the products initial release is its performance at 80% of the speed of the host PC and the ability to work a large number of Windows-based machines. "We've been able to increase the speed so that it emulates a Power PC G4 and that's light years ahead of our competition," he commented.

Which is a fairly interesting statement to make, when you consider that yes, PearPC does have AltiVec-enabled code in their CVS tree, and that a developer is finding debug messages from his AltiVec patches in CherryOS's code.

I talked to Charles Darvy of PearPC about the claims:

Arben's claim of 80% speed in 'The Mac Observer' article is simply untrue... I urge anyone to simply try it. Compare against PearPC... they are nearly identical and actually Cherry might be slower. It has been reported they are just increasing the refresh rate in our config file to make it appear as if it is running faster, but this can be easily seen.

Charles is talking about the redraw_interval_msec variable which can be set in PearPC's configuration file (which, as noted above, is identical to CherryOS's) is set higher by default in CherryOS which means it is redrawing the screen more often than PearPC by default, which can make it feel 'smoother'. (Source)

The 'direct download' which allows you to download the file without giving them your information (does this seem like a company you want to have your information?) keeps changing, but I'm trying to keep it updated as I'm told about it.
Still, I wanted to try it for myself, and CherryOS offers a free trial. Luckily I was given the direct link to the build so I didn't have to register to get it. I can tell you it wasn't 80% of the native speed on the machine I tested it on (2.4 GHz Pentium 4), but I doubt that will surprise any of you by this point.

There are other claims they're making which just aren't true about their product -- most of the features they hyped so heavily before its release as setting it apart from others aren't there -- but the speed claims are so patently false and easily verifiable that there's little point in going into the others now.

The license problem

The fact that we're talking about 'stolen code' when PearPC's code is out there free for anyone to download can still confuse people, so it's worth going over it again.

When a person writes some code and contributes it to an OSS project, like say under the GPL license, they are basically saying "I own the copyright to this, but I'm allowing you to use it as long as you follow these rules".

The person does still own the copyright, which is how the license can be enforced, but as long as you follow the rules in the license there's no problem in say, taking code from PearPC and including it in another GPL-licensed program. Since PearPC is licensed under the GPL, every developer contributing code is doing so under that license, which means if you are going to use it you have to abide by it or you are infringing on that developer's copyright.

In the case of the GPL, this means if you are going to release it publicly you need to release your changes back to the community and make the source code readily available. These people are contributing their time to write the code they have, and releasing it under that license, for a reason.

It isn't so another company can take their work, roll it up with a bow and sell it as their own.

What CherryOS says

The guys behind CherryOS have been questioned before about many of their claims. One that made some waves took place in a Wired story, where Wired took a pre-release copy of CherryOS given to them and gave it to a researcher who was pretty sure it was actually PearPC:

Dave Schroeder, senior systems engineer at the University of Wisconsin, examined a pre-release copy of CherryOS downloaded from Maui X-Stream by Wired News. Schroeder concluded CherryOS is likely PearPC wrapped in a different package.

Schroeder said he compared the names of various functions and variables in CherryOS and PearPC, and found they all matched. "This is pretty clear-cut," he said. "They are, in fact, using significant amounts of code from PearPC."

And, just because I remember this and found it terribly amusing at the time:

Sebastian Ballas, PearPC's lead developer, said a screenshot of CherryOS shows a variable named "SPIRO MULTIMAX 3000," a nonsensical term Ballas claims to have invented for use in PearPC.

The CherryOS representative's responses in the article are interesting to say the least:

When told that variables with the same names had been found in both CherryOS and PearPC, Kryeziu said programming logic often leads to variables and functions with similar, or identical, names.

"There are some functionalities that can only be done a certain way," he said. "Names are going to be similar or identical because there are only certain ways to do things."

The most amusing thing said in the article was:

Kryeziu said he's happy to supply the PearPC developers with the source code so they can see for themselves, and will do so when the first public release is ready, which will likely be in a few days.

"If it's based on PearPC, the PearPC developers will figure it out," he said. "I will provide the source code so they can compare it. I will give it to them to clear up the trash talk."

I think we can safely assume that's not likely to happen any time soon, which brings us back to the latest bit of press they've gotten themselves for the release of their product, a feature on the Mac Observer where they again reiterate -- with more colorful language -- that they "never ever" misappropriated code from PearPC, let alone other places:

Mr. Kartes denies accusations that Cherry OS is using code from a similar open-source, PowerPC architecture emulator known as PearPC, despite various developer forum postings allegedly showing evidence to the contrary.

"That is simply not true," he said. "They know not what they speak. This is an entirely different architecture and code from PearPC. That's why we're able to achieve such higher speeds than they have. These are simply a bunch of lies."

Mr. Kartes said his developers "never ever" copied code from PearPC and just because they introduced their code months before Maui-X Stream did "doesn't give them a claim on certain technical aspects of our product."

Like I said above, I think at this point it's pretty clear to anyone with critical thinking skills above a toaster that this isn't on the up and up, but what specifically worries me is that they seem to be targeting the Mac press outlets (large and small) to pimp their product, and when places spend all of one sentence on the evidence -- denigrating it to alleged rumors on some forums -- Maui-X doesn't exactly have to work very hard when they're being interviewed by Brad Gibson at MacObserver.com.

It makes sense in a way -- Mac users are most likely to have a copy of OS X lying around to take with them to work so they can use X favorite app, or on their secondary PC. They're also less likely to be technically inclined enough to realize they're being sold a river, and more likely to attribute it to the PC just sucking.

A scary proportion of them will probably end up on the forums talking about how slowly the PC runs OS X compared to their Mac... whatever their reasons, it needs to be stopped now and the story needs to not be about whether they might be and that they are.

Going forward

pearpcPearPC is only one of at least a few projects having their code 'incorporated' into CherryOS, but it's sure to be the one with the most lifted by its very nature.

It's not the first major blow the project has suffered -- back in July one of the lynchpins of the project (Stefan Weyergraf) passed away in a train accident -- but it's not harmless. According to Charles Darvy of PearPC, knowing that their code has been lifted for months has had a direct effect on the project:

I admit there has not been many updates in the last several months. Development seems to be picking back up, but when frauds such as CherryOS appear, it makes developers weary about contributing.

Which makes a hell of a lot of sense when you think about it. These are people coming home and working on this stuff in their free time -- for the love of it -- instead of using that time for other things or other projects. Knowing it's being taken and incorporated as soon as its checked in would be pretty detrimental to morale.

If you're curious as to why Maui X-Stream, Inc. isn't being forced to stop what they're doing, this is where things get a little tricky.

To my knowledge, the GPL has never been seriously tested in an American court -- at least partially because it's considered to be legally solid. It's certainly doubtful that IBM would be pushing it so heavily with their own intellectual property if it was full of holes. It isn't that open sourced code isn't misappropriated -- it is -- but usually not by large companies (unless they're insane), and with smaller companies there are some logistical nightmares involved.

A big stumbling block is that a bunch of guys contributing code in their spare time after work generally don't have the money necessary to launch a civil suit against a company to get an injunction, let alone one in another state, let alone one in another state that's a Pacific away. It gets worse when you realize not everyone is necessarily even in the United States.

Remember, these interstate civil intellectual property suits are pretty much the purview of corporations, not individuals. Unless someone else is able to step in and file suit on their behalf, or they are able to raise enough awareness that the company isn't able to continue doing what they're doing, their options are limited.

yummy alcohol posted button Posted by drunkenbatman
    March 11, 2005, at 07:00 AM


Comments (64)




Post a comment



Anonymous comments are allowed, but please enter something for a name.

And do endeavor to appear sane.









Remember personal info?