<?xml version="1.0" encoding="utf-8"?>

<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

<!-- This component and the accompanying materials are made available under the terms of the License 

"Eclipse Public License v1.0" which accompanies this distribution, 

and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

<!-- Initial Contributors:

    Nokia Corporation - initial contribution.

Contributors: 

-->

<!DOCTYPE concept

  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

<concept id="GUID-4ADD8234-4AFD-4E80-94A4-AC018FE83276" xml:lang="en"><title>Differences

between OSS and Symbian GLib</title><shortdesc/><prolog><metadata><keywords/></metadata></prolog><conbody>

<p>The three areas of difference between the way GLib is implemented in Symbian

platform and in OSS are as follows: </p>

<ul>

<li><p>Memory allocation</p></li>

<li><p>Spawn APIs</p></li>

<li><p>Libgmodule APIs </p></li>

</ul>

<section id="GUID-DFAD39D6-BA92-4293-B5EC-97077CE1FC1A-GENID-1-10-1-12-1-1-7-1-6-1-4-1-3-3">       <title>Memory

allocation</title>       <p>The Symbian GLib implementation does not follow

the default OSS behavior. The default OSS behavior is such that in the event

of a memory allocation failure the application, using <codeph>g_malloc()</codeph> and

not <codeph>g_try_malloc()</codeph>, will call <codeph>abort()</codeph> and

thus terminate the application.  </p><p>The Symbian implementation, on the

other hand will return NULL and not terminate the application in the event

of a memory allocation failure. Thus, it is the application’s responsibility

to check if the memory allocation failed due to the needed tasks.</p><p>Generally,

all the application code written using GLib does not perform memory allocation

failure checks. Hence, for Symbian GLib it is the application programmer's

responsibility to check for memory allocation failures.  </p>     </section>

<section id="GUID-DFAD39D6-BA92-4293-B5EC-97077CE1FC1A-GENID-1-10-1-12-1-1-7-1-6-1-4-1-3-4">       <title>Spawn

APIs</title>       <p>GLib has a set of APIs for process spawning. Since Symbian

platform does not support the <codeph>fork()</codeph> and <codeph>exec()</codeph> APIs,

the <codeph>g_spawn*</codeph> APIs have limitations in their functionality.

The limitations are explained per API in detail below.</p><p><b><codeph>g_spawn_async_with_pipes</codeph></b></p><p>The

signature of this API is:</p><codeblock xml:space="preserve">gboolean g_spawn_async_with_pipes (

    const gchar *working_directoy,

    gchar **argv,

    gchar **envp,

    GSpawnFlags flags, 			

    GSpawnChildSetupFunc child_setup, 			

    gpointer user_data, 			

    GPid *child_pid, 			

    gint  *standard_input, 			

    gint *standard_output, 			

    gint *standard_error, 			

    GError **error); </codeblock><p>This API executes the program asynchronously:

that is, the caller does not block for the spawned process to complete. The

setting of the following parameters does not have any effect in Symbian GLib:</p><ul>

<li><p><codeph>working_directory</codeph></p></li>

<li><p><codeph>envp</codeph></p></li>

</ul><p>If a value other than NULL is passed for <codeph>standard_input</codeph>, <codeph>standard_ouput</codeph>,

or <codeph>standard_error</codeph>, the value at the location is set to -1.</p><p><b><codeph>g_spawn_async</codeph></b></p><p>The

signature of the API is:</p><codeblock xml:space="preserve">gboolean g_spawn_async (

    const gchar *working_directory, 	 	  

    gchar **argv, 		  

    gchar **envp, 		  

    GSpawnFlags flags, 		  

    GSpawnChildSetupFunc child_setup, 		  

    gpointer user_data, 		  

    GPid *child_pid, 		  

    GError **error); </codeblock><p>This API calls <codeph>g_spawn_async_with_pipes</codeph> without

any pipes. The setting of the following parameters does not have any effect

in Symbian GLib:</p><ul>

<li><p><codeph>working_directory</codeph></p></li>

<li><p><codeph>envp</codeph></p></li>

</ul><p><b><codeph>g_spawn_sync</codeph></b></p><p>The signature of the API

is:</p><codeblock xml:space="preserve">gboolean g_spawn_sync(

    const gchar *working_directory, 	 	

    gchar **argv, 		

    gchar **envp, 		

    GSpawnFlags flags, 		

    GSpawnChildSetupFunc child_setup, 		

    gpointer user_data, 		

    gchar **standard_output, 		

    gchar **standard_error, 		

    gint *exit_status, 		

    GError **error); </codeblock><p>This API executes the program synchronously:

that is, the calling process waits for the spawned process to complete before

returning. The setting of the following parameters does not have any effect

on Symbian GLib:  </p><ul>

<li><p><codeph>working_directory</codeph></p></li>

<li><p><codeph>envp</codeph></p></li>

</ul><p>If a value other than NULL is passed for<codeph> standard_output</codeph> or <codeph>standard_error</codeph>,

the value at the location is set to -1. </p><p><b><codeph>g_spawn_command_line_sync</codeph></b></p><p>The

signature of the API is:</p><codeblock xml:space="preserve">gboolean g_spawn_command_line_sync(

    const gchar *command_line, 

    gchar **standard_output, 

    gchar **standard_error, 

    gint *exit_status, 

    GError **error);  </codeblock><p>This API is a simple version of <codeph>g_spawn_sync</codeph> in

which there are fewer number of parameters involved, and it takes a command

line instead.</p><p>If a value other than NULL is passed for <codeph>standard_output</codeph> or <codeph>standard_error</codeph>,

the value at the location is set to -1.</p><p>In many spawn APIs a variable

of type <codeph>GSpawnFlags</codeph> is passed. The following flags have no

effect:</p><ul>

<li><p><codeph>G_SPAWN_LEAVE_DESCRIPTORS_OPEN</codeph></p></li>

<li><p><codeph>G_SPAWN_STDOUT_TO_DEV_NULL</codeph></p></li>

<li><p><codeph>G_SPAWN_STDERR_TO_DEV_NULL</codeph></p></li>

<li><p><codeph>G_SPAWN_CHILD_INHERITS_STDIN</codeph></p></li>

</ul>     </section>

<section id="GUID-4B68F695-1BDB-4AA0-B77A-7F808A157E7A"><title>Libgmodule

APIs</title><p>Libgmodule has APIs that provide a portable method for dynamically

loading 'plug-ins' or, in other words, DLLs. There are some deviations in

the <codeph>libgmodule</codeph> APIs on Symbian platform as compared to the

OSS behavior. The APIs with their limitations are explained in detail below.</p><ul>

<li><p><b><codeph>g_module_open</codeph></b>: The signature of the API is:</p><codeblock xml:space="preserve">GModule *g_module_open (const gchar *file_name, GModuleFlags flags);</codeblock><p>This API is used to open a module. The default OSS behavior when file_name

is passed as NULL such that it obtains a <codeph>GModule</codeph> representing

the main program. In Symbian GLib, NULL is returned instead. Of all the <codeph>GModuleFlags</codeph> only <codeph>G_MODULE_BIND_LOCAL</codeph> is

honored. If the user passes any other flags, the module is still opened using

the flag <codeph>G_MODULE_BIND_LOCAL</codeph>. </p></li>

<li><p><b><codeph>g_module_symbol</codeph></b>: The signature of the API is:</p><codeblock xml:space="preserve">gboolean g_module_symbol (GModule *module, const gchar *symbol_name, gpointer *symbol);</codeblock><p>This API gets the symbol from the <codeph>GModule</codeph> opened using <codeph>g_module_open</codeph>.

In OSS, <codeph>symbol_name</codeph> is the name of the symbol that needs

to be queried from the <codeph>GModule</codeph>. In Symbian platform, the

ordinal number (passed as a string) of the symbol name must be passed and

not the symbol name.</p></li>

</ul><p>See also <xref href="GUID-01E7AE98-024C-4119-87D0-5BB9D53DA119.dita">Introduction

to libgmodule</xref> for more details about <codeph>libgmodule</codeph>. </p></section>

</conbody></concept>