Alternatives to current development

[highlandsun]

Congratulations, you've duplicated one API, only a couple thousand more to go. If you implement one/day successfully, you might be done in 3-5 years. Hint: you won't average one/day.

Sent from my TP2 using Tapatalk

[arrrghhh]

lol, I was just going to ask does BT work? GPS? Prox sensor? Ambient light sensor? How about stylus detection?

AmeiseMike, you seem like a sharp guy... Why not help out with the community development? The devs have made great progress, and help is always appreciated. The more people writing code, in theory the more code that makes it into the kernel .

[AmeiseMike]

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.

[arrrghhh]

Originally Posted by AmeiseMike

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 .

[vinceweis]

Originally Posted by arrrghhh

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.

[highlandsun]

Originally Posted by AmeiseMike

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.

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 )

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.

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.

[tiger2wander]

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!