PPCGeeks - Alternatives to current development

PPCGeeks (http://forum.ppcgeeks.com/index.php)

- Android On TP2 (http://forum.ppcgeeks.com/forumdisplay.php?f=179)

- - Alternatives to current development (http://forum.ppcgeeks.com/showthread.php?t=143427)

Re: Alternatives to current development

Quote:

Originally Posted by AmeiseMike (Post 2097805)

If you cannot duplicate a single basic interface per day, then you aren't very good at what you do. pthreads itself has already been ported to the Windows API in the past, as have several other APIs. To be fair, however, that is not an API, it is a single API procedure, though the other pthread functions would be trivial to implement as well.

As per the 3-year concept... how long have you been trying to port Android onto the TP2, so far? A successful wrapping of the Android system around CE would allow any WinCE device to have 'droid, not just TP2.

arrrghhh - they don't need more programmers, they need people who can reverse engineer things. As per BT, GPS, Proximity, Ambient, etc, that would have been handled by the CE drivers. You'd need to implement the JNI wrappers in Android for them, though.

I know, I was teasing.

Indeed, people who are skilled at REing are always needed with this type of project - and hard to come by.

I guess I'll go back to what vinceweis said. Put up or shut up - either you help out, actually implement what you're talking about, or lurk and enjoy what the other developers are working very hard on. Your choice, I'm certainly not trying to discourage you from what you're doing - but from this angle and this stage in the game, it frankly seems counter-productive. If you think you can do it, then do it and prove us all wrong :D.

Re: Alternatives to current development

Quote:

Originally Posted by AmeiseMike (Post 2097805)

It's trivial to port pthreads for the trivial cases. There are no guarantees that the Android userland is only a trivial threads consumer though. (I don't know if it uses more exotic features or not, haven't looked.) And yes, I know the POSIX APIs have been ported, I've done it myself at least twice. (E.g. OpenLDAP Source Repository - openldap.git/tree - libraries/libldap_r/ I'm also a MinGW/MSYS developer, and the guy who figured out how to implement signals in Win32 without all the crap the Cygwin guys do. Re: Ctrl-Break handler? - ReadList.com )

Quote:

As per the 3-year concept... how long have you been trying to port Android onto the TP2, so far? A successful wrapping of the Android system around CE would allow any WinCE device to have 'droid, not just TP2.

That's not a fair question, I've only started working on the TP2 port since middle of March. I'm pretty sure I could port most of Android to WinCE in a few months, but I have no desire to use Windows, and the parts that are undocumented would still be missing and require reverse-engineering. In the meantime, I've fixed quite a few years-outstanding bugs in just a matter of weeks here.

Quote:

arrrghhh - they don't need more programmers, they need people who can reverse engineer things. As per BT, GPS, Proximity, Ambient, etc, that would have been handled by the CE drivers. You'd need to implement the JNI wrappers in Android for them, though.

You'd need documentation for them, otherwise you'd still just be reverse-engineering, on an even more hostile environment. At least on the Android/Linux side of things, you have the majority of the source code available so you can see where the gaps are.

Re: Alternatives to current development

Quote:

Originally Posted by arrrghhh (Post 2097818)

I guess I'll go back to what vinceweis said. Put up or shut up -

I am more diplomatic or subtle, but it was exactly what I was thinking.:laughing6:

Re: Alternatives to current development

I think AmeiseMike's idea is not so bad but it is so much hard to make it reality. The abstract layer is really flexible to make it usable most cross platform API like use .dll on Linux or .so on Windows but we can not implement all the JNI wrapper for each device, it is a very very big job and who know what's happen with them. Also Windows & Linux kernel is 2 kind of kernel and it all difference. AFAK, Android use Linux as a based but it also use emulator and native linux binary format, and many system process made to interactive directly with kernel signal and many other things like access /proc, /dev, /sys ... everything are related to Linux stuff, I think we can not handle it all.

There are simpler & easier way is use Ndiswrapper method to load WinCE's driver and call it's API, it is use in many Linux distro to reuse Windows's drivers such as closed source driver....
You all can read more about it in Wiki's page: NDISwrapper - Wikipedia, the free encyclopedia

Good luck!

Re: Alternatives to current development

I think the primary problem with this is that it would not bypass the very issues with WM6.5 that push me to Android on this phone. For example, sending and receiving texts. Would that just thunk calls down to MAPI under WM6.5, or is it possible to access lower-level radio functions and process all of that directly within Android? If it relies on MAPI then so much additional overhead will be incurred that there will be significant performance penalties. Further, the amount of RAM that WM can make available may not be enough for Android in the first place. I had this problem when I ported Quake 2 to Pocket PC. Some device models simply could not allocate enough contiguous memory for the game to run (20-30 MB). The hardware had enough physical memory, but because of OEM implementation issues it could not allocate such large blocks. These are the sorts of problems that would be encountered running one entire OS on top of another on hardware that is already resource-limited to begin with.