Developing Applications with Nokia WRT - VTU EduSat ppt

Check out this SlideShare Presentation on Developing Applications with Nokia Web Runtime.
This was broadcasted live to all VTU colleges in Karnataka on 14th Sept 2009 as part of VTU's EDUSAT programme.

My self and Raghava had an opportunity to represent Nokia's Web Runtime.
We tried to present the latest developments in Nokia's WebRuntime.

Dependency Walker for Windows binaries

I find Dependency Walker a very useful utility. This helps us to scan any of windows binaries (exe, dll ...).

It can dissect almost any type of windows binary file, to show up all possible details hidden within.

Listing few of the details this utility can provide,

• Basic binary properties Ex: physical path, version info, etc.
• Exported functions with their signatures and ordinal numbers.
• Recursive list of dependent libraries and their details.

It didn’t took much time for me to discover the power of this tiny tool which is distributed as apart of MS Visual Studio Tools. This can also be downloaded for free at http://www.dependencywalker.com/.

Below is one of such situation, where this tool helped me to rapidly identify and debug the problem.

I was building Qt for Win with ‘-openssl-linked’ option and this required me to download the openSSL libraries separately. I had downloaded and copied ‘libeay32.dll’ under Qt’s bin folder.

Even though Qt compiled without any problems, I had issues with launching few of the processes which had dependency over libeay32.dll. For some reasons, loader started complaining about missing ordinal in libeay32.dll.

Dependency walker came into rescue. I simply loaded the failing process into DependencyWalker and it listed all dependent DLLs with respective details. I could just walk to the libeay32.dll and examine its version.

There you go! It was loading an older version of DLL which had been installed as part of Wireless monitor app. Since PATH variable had the wireless app’s path occurring before Qt’s bin path, it was always picking the older DLL from wrong location which caused the issue.

It hardly took me few minutes to identify and fix the issue.

Hope this is useful :)

HTML5 video

Just wanted to embed a video using HTML5 video feature.  The source looks very simple!

<video controls="controls" src="http://tinyvid.tv/file/3ifyc1xrvwkjr.ogg" tabindex="0">
   <p>
   Sorry, your browser doesn't support the <video> element. You'll need a browser that can playback Ogg media using HTML5 video and audio tags.
   </p>
</video>

This tries to embed one of my favorite music video – In the Shadows by The Rasmus :)

Please use the latest versions of Chrome or Firefox to experience the embedded video. The latest versions of Chrome and Firefox are already supporting the HTML5 video and audio features.

Have fun!

Reference : HTML5 spec

Resolving the exported symbols from a Symbian DLL

Symbian OS optimizes DLL program code to save ROM and RAM space, by offering only "lookup by ordinal" and not "lookup by name".

Symbian OS does not offer “lookup by name” because this adds an overhead to the size of the DLL (storing the names of all the functions exported from the library is wasteful of space). Instead, Symbian OS only uses link by ordinal, which has significant implications for binary compatibility.

If we are loading a DLL dynamically and need to resolve a exported function address, we need to use the following RLibrary API, which takes an integer parameter representing the ordinal number of the exported function.

TLibraryFunction RLibrary::Lookup(TInt anOrdinal)

Luckily, as part of POSIX for Symbian (P.I.P.S), widely known as Open-C library, we can achieve “lookup by name” with a Symbian DLL.

This is possible only if the library is built as STDDLL.

This allows us to have the POSIX like behavior for resolving the exported DLL symbols even on Symbian. Following POSIX like APIs can be used on Symbian provided the DLL is built as STDDLL.

void *dlopen(const char *filename, int flag);
void *dlsym(void *handle, const char *symbol);
void dlclose(void *handle);

An example with source using the PIPS libraries is here.

Digest authentication with Apache

This article is in continuation with previous and talks about setting up digest authentication with Apache.

There are few changes compared to the steps for Basic authentication.

1. Generating the password file for digest auth.

htdigest -c digest.txt secret prash

digest.txt is the password file, secret - the realm and prash is the username.

2. Create htaccess.acl under c:\wamp\www\digest-auth\ with following data

AuthUserFile C:\wamp\bin\apache\Apache2.2.11\bin\digest.txt
AuthName "Protected by Digest auth"
AuthType Digest
AuthDigestProvider file

<Limit GET POST>
require valid-user
</Limit>

‘AuthDigestProvider file’ is an additional property that needs to be mentioned for proper working of digest authentication.

3. And, last but not the least. Enable auth_digest_module by un-commenting the following line if its already commented in httpd.conf.

LoadModule auth_digest_module modules/mod_auth_digest.so

Reference : http://httpd.apache.org/docs/2.2/mod/mod_auth_digest.html

Setting up HTTP Basic authentication with Apache

Last week, I had a chance to setup our test Apache server for Basic and Digest authentication. The setup was required to verify few of the HTTP authentication related test cases.

I’m blogging it here so that I’ll not forget, if I need it again :)

I had WAMP Server v2.0  which included Apache v2.2.11 web server.

Setting up Basic authentication was straight forward.

1. Update http.conf by adding :

AccessFileName htaccess.acl .htaccess

An htaccess file can be used to modify the Apache configuration on a per-directory basis.

On some operating systems ‘htaccess.acl’ is not required. Ex, on Linux, you can just mention it as .htaccess. This is because, on Linux you can create a file with name .htaccess.

2. Add “Directory” tag into http.conf as shown below :

<Directory "c:/wamp/www/basic-auth/">
    Options None
    AllowOverride all
    Order Deny,Allow
</Directory>

c:/wamp/www/basic-auth/ is the folder which needs to be secured by the authentication scheme which we are trying to impose.

3. Next step is to create password file.

cd C:\wamp\bin\apache\Apache2.2.11\bin
htpasswd -c pwd.txt prash

This prompts for the password for the username – ‘prash’. After supplying the password we will be ready with the password file – ‘pwd.txt’ under ‘C:\wamp\bin\apache\Apache2.2.11\bin’.

4. Create the htaccess file - ‘htaccess.acl’ file with the following data.

AuthUserFile C:\wamp\bin\apache\Apache2.2.11\bin\pwd.txt
AuthName "Protected"
AuthType Basic

<Limit GET POST>
require valid-user
</Limit>

This specifies which password file need to be considered for the authentication – ‘C:/wamp/bin/apache/Apache2.2.11/bin/pwd.txt’ also the type of authentication scheme – Basic.

Place this file under the folder ‘c:/wamp/www/basic-auth/’ along with other live data and restart the server.

Now, try accessing the folder http://localhost/basic-auth. This should prompt for username and password.

Reference : http://httpd.apache.org/docs/2.2/mod/mod_auth_basic.html

Making my blog 'Mobile Friendly'

Being part of mobile software industry and that too working for S60 Browser research team, I desperately wanted to make my blog mobile friendly.

Unfortunately Blogger, where this blog is hosted lacks this service. This would be a very nice and really useful feature.

Wordpress seems to offer this already - http://wordpressmobile.mobi/.

After I did some googling I came across MoFuse. Mofuse provides feeds based solution to convert your blogs to mobile readable version.

Setting up a mobilized version with MoFuse was pretty straight forward, I just registered for a new mobilized blog URL - http://prashtech.mofuse.mobi which internally points to my blogs' RSS feeds.

That's it. If any of you visiting my blog from your mobile, try the mobilized version of my Blog!

http://prashtech.mofuse.mobi.

Backward Compatibility with DLLs – Part 2 (Private Implementation)

A very Happy New Year to all of the readers!

This article is in continuation with the previous one, about preserving DLL exported APIs’ backward compatibility.

The last article described a technique of achieving this by privatizing the API’s constructor. This has many disadvantages of its own, as the c’tor is private, ex: Object can not be instantiated on stack.

An alternative technique is to have a “Private Implementation”.

If you have a class, which you intend to export, separate out all the internal implementation including the data members and the functions which you think can be hidden. The exported class will only have the functions exported along with a private member pointer to the new internal class.

As an example, consider the following class,

#define DLL_EXPORT __declspec(dllexport)
class DLL_EXPORT ExampleExport
{
public: // c'tors and d'tors
    ExampleExport();
    ~ExampleExport();

public: // functions
    void function1();
    int function2();

private: // private data members
    int m_member1;
    int m_member2;
};

We have 2 integer member variables. Adding or removing the member variables later, will always cause a binary compatibility break as described in the previous article.

Let’s try to separate out the internal implementation. We will move all the private data members to a different class – ExampleExportPrivate.

class ExampleExportPrivate
{
public: // c'tors and d'tors
    ExampleExportPrivate();
    ~ExampleExportPrivate();

public: // data members
    int m_member1;
    int m_member2;
};

We will redefine ExampleExport to use ExampleExportPrivate.

#define DLL_EXPORT __declspec(dllexport)

class ExampleExportPrivate; // <<-- forward declaration of the private implementation which is defined in cpp file

class DLL_EXPORT ExampleExport
{
public: // c'tors and d'tors
    ExampleExport();
    ~ExampleExport();

public: // functions
    void function1();
    int function2();

private:
    ExampleExportPrivate *m_private; // <—Pointer to private implementation. };

As a first step, forward declare the private implementation class – ExampleExportPrivate. The actual definition of this private implementation class can be placed as part of the cpp file. So, we are not exposing this class outside, even in the header files exported. Next step is to have a private pointer member variable which points to ExampleExportPrivate. Any references to the data will be redirected to the internal private implementation.

This technique will help us to not change the size of the exported class. If we need to add or delete a new member variable, ExampleExportPrivate will be the class which will have those changes, but not ExampleExport.

This technique is usually called as “PImpl” (Private Implementation). Here is an interesting article http://www.gotw.ca/publications/mill04.htm