The main difference in OS5 was the addition of "PNOlets", chunks of native ARM code. Chapter 14.
It's still tricky. When I ported Palm's OS4 emulator to Android, I had to do some library coding and tracking down sample source code was... nontrivial. Definitely look for open-source Palm programs, like pssh, and learn from them.
What the FUDGE are you doing in the woods where you want a Cell phone on all the time?
Staying available in case my wife or any of my kids who aren't on the trip have a medical emergency? I apologize for having purposes that don't meet up with your approval, or enjoying myself in ways that you frown upon. I will re-evaluate all my life choices in light of your preferences immediately.
Feature phones work better in areas of sketchy cell service. Their battery life is very long. The battery requires less power.
I agree. But that means I have to have multiple cell phones for different purposes. Which brings us back to... Modern phones do a lot more, and a lot faster, than older tech... but I admit I miss the battery life of the old Palms. One month on a couple of triple-As. Not having to charge my phone every single night would be pleasant. Wise words indeed.
Solar battery takes care of the problem.
Not in Michigan woods. Not even in the middle of summer, with several days of clear skies, using this. And yes, I speak from experience. Especially when you're in areas with poor signal that drain the battery faster.
Leaving aside issues of unexpectedly not being near your chargers for too long even in day-to-day life, etc.
Clearly you're happy with your battery life. Congratulations, felicitations, mazel tov, and so forth. That doesn't mean that people who are not satisfied are wrong, however.
Because setting a phone down on a charging mat next to the bed is oh so hard.
In a tent - yeah, it is.
My own 486 had extremely dissappointing performance when compared to a even mere 68000 until RAM prices became low enough to adequately equip a PC.
True. I was astonished when I invested a decent chunk of change and bumped my 100MHz 486 from 16MB to 64MB of RAM. Multitasking actually became practical, especially running Mozilla alongside something else. Of course, the 68K Macs of the day weren't that much better at supporting 'a browser and something else'. The cooperative multitasking of the Mac OS helped reduce overhead, but it still took RAM.
And the 68k platform seemed to be neglected by Motorola.
It sure seems like the M68k architecture could have been pushed forward more. Yeah, it was CISC, not RISC, but it was a very clean CISC. Modern x86 chips are really RISC machines internally, they just have a bunch of translation from the CISC instruction set to the 'real' ISA inside. If nothing else, that approach could have worked for M68k, right? Probably better, since the basic M68k ISA isn't so crufty and ugly like x86.
Though I do agree that JNI is a serious pain. On the other hand, I've developed for Netware and Palm OS, so my standards for pain are probably artificially high.
So the core of the app, the 'engine', is in C++ and must be natively compiled, while the UI and such is in Java. Naturally, the binary's compiled for ARM first. This actually runs on a lot of Intel Android tablets because they have ARM emulators. But, thanks to a user finally asking, I put in some time and now I can make an Intel version. (Heck, the original source was written for Intel anyway, so it wasn't a big stretch.) The existing tools are sufficient for my purposes. And it runs dramatically faster now on Intel.
However, for the developer it's mildly painful. The main issue is that you have a choice to make, with drawbacks no matter which way you go. You can include native libraries for multiple platforms, but that makes the APK larger - and according to a Google dev video I saw, users tend to uninstall larger apps first. In my case, it'd nearly double the size. So instead I'm putting together multiple APKs, so that ARM users get the ARM version and Intel users get the Intel version - but only Google Play supports that, not third-party app stores. I haven't looked into other app stores, and now it's less likely I will.
Note that native development can be important to apps for a non-technical reason: preventing piracy. An app written purely in Java is relatively easy to decompile and analyze, and pirates have a lot of techniques for removing or disabling licensing code. Adding a native component makes the app much harder to reverse-engineer, at least delaying the day that your app appears on pirate sites.
I wish you luck.
This doesn't necessarily mean that he disagrees with evolution and mutation as a mechanism for change or that there is common DNA across a large number of species.
BTW, I couldn't let this one go. It's not just 'a large number'. It's the same DNA code across all organisms we know of. There are a couple of exceptions - but they edit the code back to the 'standard' one before the proteins are transcribed.
And the pattern of 'common DNA' confirms common descent to a ridonkulous degree.
Books used to be copied by scribes, and (despite a lot of care) sometimes typos would be introduced. Later scribes, making copies of copies, would introduce other typos. It's possible to look at the existing copies and put them into a 'family tree'. "These copies have this typo, but not that one; this other group has yet another typo, though three of them have a newer typo as well, not seen elsewhere..." This is not controversial at all when dealing with books, including the Bible.
Now, this process of copy-with-modification naturally produces 'family trees', nested groups. When we look at life, we find such nested groups. No lizards with fur or nipples, no mammals with feathers, etc. Living things (at least, multicellular ones, see below) fit into a grouped hierarchy. This has been solidly recognized for over a thousand years, and systematized for centuries. It was one of the clues that led Darwin to propose evolution. (Little-known fact: Linnaeus, who invented the "kingdom, phyla, genus, species, etc." classification scheme for living things, tried to do the same thing for minerals. But minerals don't form from copy-with-modification, and a 'nested hierarchy' just didn't work and never caught on.)
Today, more than a century later, we find another tree, one Darwin never suspected - that of DNA. This really is a 'text' being copied with rare typos. And, as expected, it also forms a family tree, a nested hierarchy. And, with very very few surprises, it's the same tree that was derived from looking at physical traits.
It didn't have to be that way. Even very critical genes for life - like that of cytochrome C - have a few neutral variations, minor mutations that don't affect its function. (Genetic sequences for cytochrome C differ by up to 60% across species.) Wheat engineered to use the mouse form of cytochrome C grows just fine. But we find a tree of mutations that fits evolution precisely, instead of some other tree. (Imagine if a tree derived from bookbinding technology - "this guy used this kind of glue, but this other bookbinder used a different glue..." - conflicted with a tree that was derived from typos in the text of the books. We'd know at least one tree and maybe both were wrong.)
The details of these trees are very specific and very, very numerous. There are billions of quadrillions of possible trees... and yet the two that we see (DNA and morphology) happen to very precisely match. This is either a staggering coincidence, or a Creator deliberately arranged it in a misleading manner, or... universal common ancestry is actually true.
(Single-celled organisms are much more 'promiscuous' in their reproduction and spread genes willy-nilly without respect for straightforward inheritance. With single-celled creatures, it looks more like a 'web' of life than a 'tree'. But even if the tree of life has tangled roots, it's still very definitely a tree when it comes to multicellular life. Which is the area that people opposed to evolution most worry about anyway.)