Showing posts with label Cpp. Show all posts
Showing posts with label Cpp. Show all posts

Sunday, December 15, 2013

Microsoft Windows - Client Operating Systems - API unity


Why Microsoft needs three or more operating systems

   A common operating system core, with common APIs and capabilities, is inevitable, and it is logical. Microsoft might even start to use common branding, most likely with Windows Phone becoming just "Windows." But that doesn't mean that it won't actually have three operating systems. Windows on a phone will be different from Windows on a tablet—in much the same was as iOS on the iPhone is different from iOS on the iPad. The user interface will be tailored to the form factor, making the two close siblings but not identical.

This will result in Windows for ARM phones, Windows for ARM tablets, and Windows for x86/x64 PCs. One might even make a case for a fourth to be added into the mix: Windows for x86 phones.

More exotic is the Xbox One operating system. This has no branding of its own, as it's never decoupled from the Xbox One hardware


A completely different API? That’s a different OS !


The operating system that is meaningfully different is Windows Phone. Windows Phone 7 used Windows CE (Microsoft's lightweight, customizable, embedded operating system) as its kernel. At the time, Windows CE was Microsoft's only ARM-compatible operating system, and the company had considerable experience using it on smartphones (as it was also used in Windows Mobile). This seemed like a sensible decision. Third-party applications were built using a modified version of Silverlight with a .NET environment .


For Windows Phone 8, Microsoft wanted to use the NT kernel. The NT kernel is more capable and is where most of Microsoft's development effort is spent, so this made sense for the company (if not for end users). Since the development of Windows RT meant that the Windows software stack ran on ARM, there was no longer any reason to stick with Windows CE. Accordingly, Windows Phone 8 shares major parts with Windows 8, with low-level components such as the network stack and security infrastructure in common between the operating systems.

To support existing Windows Phone 7 apps, Windows Phone 8 included essentially the same Silverlight environment. New applications for Windows Phone 8, however, didn't use the Silverlight environment. They have a couple of options: a new .NET environment similar to the old Silverlight one (though this time built on the full .NET runtime and notably missing the XNA 3D graphics API that the Silverlight system supported) and native code C++ with Direct3D.

Significantly, Windows Phone apps can't use Windows' Win32 API. Nor can they use most of the new WinRT API.

Developers wanting to share code between their phone and tablet software aren't completely out of luck: it's possible to write .NET code that conforms to a common subset of functionality that's available on both Phone and regular Windows (producing what are called "Portable Class Libraries"). Windows Phone 8 also gives C++ developers access to a limited subset of the WinRT API (sometimes called WinPRT), and large parts of Direct3D. Sources speaking to Paul Thurrott claim that overall, there's about a 33 percent commonality between the phone and non-phone operating systems.

This makes Windows Phone 8 a strange orphan operating system. Windows Phone 8 has few APIs in common with either Windows or Windows RT, so while iOS and Android phone apps can also be used on iOS and Android tablets, Windows Phone apps are strictly for the phone alone !

Universal binaries : Microsoft is currently pushing the notion of universal binaries that would let developers create a single app that can run both on Windows RT and Windows Phone. Where Windows Phone 8 has 33 percent "API unity" with Windows RT, Windows Phone 8.1 will hit 77 percent.

Friday, April 13, 2012

SQLite plugin for Eclipse



How to browse an Android SQLite Database from Eclipse Kepler

http://www.youtube.com/watch?feature=player_embedded&v=sAvlV0uw5zc

CellObject SQLite Browser : 
http://www.questoid.com/Download.aspx

Questoid website is down and the jar can be downloaded from : 
http://www.java2s.com/Code/Jar/c/com.questoid.htm
http://www.java2s.com/Code/JarDownload/com.questoid/com.questoid.sqlitebrowser_1.2.0.jar.zip

Requirements and how to use CellObject SQLite & XML Browser at
 http://cellobject.net/Tools/CellObjectSQLiteXMLBrowser.aspx

Java Sources at Google Code :
http://code.google.com/p/cellobject/source/browse/

-----------------------------------
How To Install:

Inside the downloaded .zip/.tar file there's a .jar file named net.cellobject.sqlitexmlbrowser_1.2.0.jar. 
Just copy this jar file into the "plugins" folder of your eclipse installation directory, then restart your eclipse.
That's it.








I needed to create an SQLite database for an Android application I was working on. I wanted to browse the database of my application from within Eclipse, instead of pulling it out and browsing with another application.
If you just want to do a little bit of debugging, see if your tables get created the way you want and similar things, there is a very nice plugin for Eclipse that might fit you:
  • Download  the CellObject SQLite & XML Browser plugin.
  • Unzip it
  • Put the .jar file you just extracted inside your eclipse plugin folder (/plugins)
  • restart Eclipse.
  • Start your emulator or plugin in the device on which you installed the application you want to test
  • Open the DDMS perspective in Eclipse (Window —> open perspective —> other —>DDMS)
  • Select your application database (you find it under data/data/[yourapplicationpackage]/databases)
  • Now click on the icon of CellObject browser on the upper right, it will open the CellObject SQLite Browser View.
Instead of Opening DDMS, we can open the CellObject SQLite & XML browser in our Java perspective itself by opening it from Windows--> Show View --> Other --> Other --> CellObject SQLite Browser...

adb shell
sqlite3 /data/data/com.app.name/databases/DatabaseName.db
adb pull /data/data/com.app.name/databases/DatabaseName.db .
sqlite3 DatabaseName.db



Other solution : 
http://www.mysamplecode.com/2011/06/android-emulator-sqlite-database.html
http://sourceforge.net/projects/sqlitebrowser/
http://sqlitebrowser.sourceforge.net/images/slackware9.jpg
http://sourceforge.net/p/sqlitebrowser/svn/73/tree/trunk/src/