FORM 2
THE PATENTS ACT 1970
[39 OF 1970]
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
[See Section 10; rule 13]
"A PROCESS FOR DEVELOPING COMPUTER PROJECTS"
NEXWAVE SOLUTIONS, a French body corporate of Immeuble le Seranne, BAT A, 130-140 Quai Flora Tristan, F-34070 Montpellier, France,
The following specification particularly describes the invention and the manner in which it is to be performed:

MODULAR COMPUTER SYSTEM AND ASSOCIATED PROCESS
INTRODUCTION
5 The present invention relates in a general manner to software systems which allow users to interact with computer hardware.
More precisely, the invention relates to a software system comprising an operating system offering qualities of flexibility and of speed of execution which are not conceivable even with the most powerful present-day operating systems.
15 The invention also relates to a process associated with such a system.
Also, as will be seen, the invention applies
advantageously (but not limitingly) to the development
20 of applications associated with on-board computer
systems.
It is recalled that the operating system is an essential element of any software system, of which it constitutes the part which interacts directly with the hardware constituent of a computer system.
Numerous operating systems are already known which allow development teams to create applications and allow end users to implement these applications.
The existing operating systems may be schematically split up into two main families.

- 2 - Monolithic architectures
The first family consists of monolithic architecture operating systems. Such systems constitute a single software set, which comprises three main layers:
• a so-called bottom layer which corresponds to the
kernel of the system. The kernel can be defined as a
passive and privileged code set permanently loaded
into the memory of the system and capable of being
10 used by all the application packages.
Its essential mission is to regulate the use of the shared resources of the system (memory, processor, peripheral). To fulfil this mission, the kernel caters for certain important functionalities
15 including:
Ö the management of the memory (distribution of memory resources between the applications as a function of their requests, etc.), Ö the management of the procedures (scheduling,
20 management of access to the processor, multitask management, etc.), Ö the management of the drivers of peripherals, Ö the management of files (name, address, etc.), Ö the management of users (access, profiles, etc.) .
25 • a so-called top layer dedicated to the applications, and with which the users can interact in order to input instructions into the system and to input requests destined for the kernel,
• an intermediate level of so-called "libraries", which
30 is sometimes regarded as a layer and in which the
recurrent functionalities are gathered together so as to allow fast implementation thereof.
Such a monolithic architecture is represented schematically in Figure 1 appended to the present text, which shows the centralized and hierarchical arrangement of the layers K (kernel), L (libraries) and A (applications).

- 3 -
The definition of "layers" makes it possible to hierarchize the communications between the elements of the operating system, the bottom-most layers being defined as "privileged" layers which can be called by higher-level layers.
The layers are thus classes of software elements which share the same privileges. Also, a privilege can be defined as the ability to use certain resources of the computer system (hardware resource or software resource).
As has been stated, a system built according to such a
monolithic architecture constitutes a single software
set, which is "blockwise" compilable.
15
An advantage of this configuration is that the systems are generally stable and fast.
However, such operating systems exhibit significant limitations in terms of flexibility and upgradability of the system.
Indeed, a modification in the kernel systematically involves a complete recompilation of the kernel. For each modification, it is thus necessary to undertake total acceptance of the system again.
Also, this inflexibility of the system is detrimental since upgrades of the system are rendered cumbersome and complex, and its maintenance expensive. Moreover, the system may become unstable owing to successive "add-ons".
Furthermore, in the case of on-board computer systems (that is to say where at least a part is intended to be integrated into mobile hardware such as a vehicle, a portable telephone, etc.), this inflexibility may show itself to be extremely detrimental, since it also makes

- 4 - it necessary to fix a certain number of characteristics of the computer system a priori (such as the fact that the speed of execution, or the size of the memory, etc. is privileged) .

In fact, the diversity of on-board applications often confronts the programmers with varied requirements of the associated computer systems, and it would be advantageous to be able to freely define and upgrade the main characteristics of the system.
Thus, by reason of the drawbacks alluded to hereinabove and stemming mainly from the inflexibility of the monolithic operating systems, this monolithic architecture is essentially intended for applications requiring no significant upgrading of software or of hardware, and it is poorly suited to on-board systems.
Ø Micro-kernel architectures
20
To attempt to alleviate this limitation, a second architecture family has been devised for operating systems. These are systems of the micro-kernel type, such as those represented in Figure 2.
25
This figure shows that the micro-kernel systems are, in the manner of monolithic systems, made up of concentric layers surrounding a central kernel which constitutes the "core" of the operating system.
30
The kernel element MK is here reduced to a "microkernel" which fulfils only the essential functionalities required for the operation of the system, namely:
35 • the management of the memory,
• the management of the procedures, at least as regards the so-called low-level procedures - concerned with the switching of tasks. It is pointed out that certain micro-kernel systems manage the high-level

- 5 - procedures with the aid of a server, whilst others manage them by means of the micro-kernel itself, • the management of ports (mailboxes) and the passing of messages, • the arbitration of the allocating of hardware resources between the various drivers (a driver being defined as a program which controls the operation of a card or of any peripheral).
10 The other functionalities traditionally fulfilled by the kernels of monolithic systems are fulfilled by servers S. These servers form an intermediate layer between the upper layer of applications A and the layer L of libraries which directly surround the micro-kernel
15 MK. They take priority over the applications A.
Such a micro-kernel architecture makes it possible to upgrade the operating system without having to recompile the entire system; this second family of operating systems thus permits a certain flexibility as compared with monolithic systems.
However, the architectures of this family are still constructed in successive layers about a central" kernel, and all the communication exchanges internal to the operating system must necessarily pass through the micro-kernel.
In fact, the passing of the communications through the successive layers of the system, which are more numerous than in the case of monolithic systems, gives rise to additional processing and slows down the overall operation of the system.
35 Also, it is consequently necessary to optimize these communication exchanges for any new development of the system, thereby complicating the work of the programmers.

- 6 - It is therefore apparent that the micro-kernel systems, although they afford additional flexibility as compared with monolithic systems, are associated with lengthier processing operations and represent only an imperfect solution.
Ø Additional comment regarding existing architectures
Moreover, the present-day systems (monolithic and micro-kernel) are all centred on a kernel element around which successive layers are hierarchized as a function of predetermined access privileges.
Indeed in all these systems, each program is systematically associated with a given layer according to an immutable typology inherent to the system itself, so that this program will systematically be accompanied by a level of privileges beyond the control of the programmers, thereby constituting a first drawback 20 common to existing systems.
Thus, the programs may for example be:
• a "kernel" or "supervisor" or "system" code (the
privileged code which manages the interaction with
25 the hardware),
• a "library" element of passive functionalities (mathematical, video decompression, etc.),
• an application package code.
30 These various types of code often correspond to different file formats, and are managed differently by different elements of the operating systems.
Also, it is not then possible to display with a single tool all the programs installed in the system; likewise it is generally not possible during the operation of the system to replace the "kernel" parts, which form an opaque and indivisible block.

- 7 - It follows that different tools must be used to create and debug these various types of code, thereby complicating the development operations in all cases; this constitutes a second drawback common to existing systems.
Also, it is understood that the kernel of existing systems constitutes the absolute centre of the system. This kernel has a special status by dint of its level of privileges; it constitutes the least portable part of the system and cannot be modified simply.
Moreover, another -characteristic common to existing software systems is that their design has been performed with:
• a phase of functional analysis which has made it
possible to describe the system in terms of
functionalities to be fulfilled, thereby constituting
a very intuitive and immediately intelligible
20 descriptive level,
• followed by a writing and a compilation of programs
during which this level of intelligibility and of
readability is adversely altered, the programs
constituting opaque sets whose manner of operation is
25 predetermined.
The programs of these systems operate on request as "automata", and the kernel merely works in reaction as a function of the needs expressed by the applications.
30 .
It is thus apparent that the kernel, although it tailors the resources and can use optimization functions to improve the overall operation of the system, always works in reaction downstream with
35 respect to the needs expressed by the applications. This constitutes another essential limitation of existing systems.

- 8 -
As will be seen, in the case of the invention on the
other hand, the manner of operation of all the
components of the system is integrated and the
functional links established during the functional
5 analysis phase are preserved in the architecture of the
system.
Thus, relative to a known system such as that represented by the Java language (registered trade
10 mark) , a description of which will be found in the document "Introduction to programming using Java", Version 3.0, summer 2000" by D.J. ECK - Department of mathematics and computer science, Hobart and William Smith College, Geneva, New York, US 24/05/2000,
15 accessible on 7 March 2001 at the Internet address http://math.hws.edu/eck/csl2 4/downloads/Javanotes3.pdf>, it would be advantageous to offer a degree of additional flexibility in the establishing of relations between the entities.
20
The term "entity" should be understood in the case of known languages (Java for example) to mean the objects and classes which can be deployed.
25 In the case of the Java language, in fact, if a given entity can actually call other entities which are required for its operation, the programmer must necessarily explicitly specify which entities should be loaded into the random access memory of the system to
30 allow the said given calling entity to operate properly.
It is thus apparent that this type of known language, although it actually offers some flexibility related to an object architecture, nevertheless compels specific entities to be chosen right from the design, thereby greatly limiting the flexibility of the system.
Furthermore, such a known system does not return any error message during loading operations, so that it is

- 9 -
possible that a defective entity or one which is incapable of fulfilling its role might be loaded into the system. Also, the deficiency of the said entity will be noted only during the overall operation of the 5 system, or during test operations which will then have to be scheduled specially.
Ø Aims of the invention
10 The main aim of the invention is to propose an operating system offering qualities of flexibility and of speed of execution which are not conceivable even with the most powerful present-day operating systems.
15 Another aim of the invention is to propose a software system which furthermore makes it possible to overcome the drawbacks alluded to hereinabove with regard to all existing systems.
20 Yet another aim of the invention is to provide a software solution tailored to the constraints inherent in the design of on-board systems.
In order to achieve these aims, the invention proposes a
25 process for developing computer projects intended to be
implemented by a computer system, process comprising a
phase of functional analysis with a view to cataloguing
the functionalities which are to be catered for, a
phase of creating components of the project with the
30 aid of computer means so as to fulfil the said
functionalities, a phase of declaration on the same
system of the components created during the creation
phase, and a phase of loading the said components into
a memory area of the system for their implementation by
35 the system,
characterized in that:
• during the components creation phase, each functionality is completely fulfilled by the component associated therewith,

- 10 -
• during the components declaration phase, each
component created is declared to a system loading
component, and
• during the components loading phase, there are
5 provided means for, in association with each
functionality requested by a loaded component, automatically searching for a component offering the said functionality.
10 Preferred but nonlimiting aspects of the process according to the invention are the following:
• the said automatic search is performed while taking a
condition into account,
• the said condition is expressed as a function of
15 criteria expressed as a function of properties
associated individually with each component,
• during the creation of a component, the following
steps are carried out:
Ø creation of an interface source file of the
20 component, with a view to constituting an
"interface" part of the component,
Ø creation of at least one code source file making
it possible to realize the functionality of the
component, with a view to constituting an
25 "implementation" part of the component,
• each code source file created with a view to
constituting an "implementation" part of the
component can be formulated in any programming
language,
30 • each component can fulfil the functionality associated therewith by deploying software and/or hardware means,
• the interface file of each component comprises a
description of the functionality fulfilled by the
35 said component, independent of the manner in which this functionality is fulfilled by the component,
• the interface file also comprises a description of
the functionalities that the component needs to

- 11 -
import from other components in order to fulfil its own functionality,
• each component can be dynamically replaced by another
component which exports the same functionality,
5 • the said replacement deploys the following steps:
> saving of the current state of the component to be replaced,
> loading and initialization of the new component,
Ø transmission of the current state of the component
10 to be replaced to the new component,
Ø establishment of a communication channel between the component calling the functionality and the new component,
Ø unloading of the component to be replaced,
15 • if the loading or the initialization of the new component is not performed correctly, means are provided for returning an error message,
• during the creation of a component, the following
step" are also carried out:''"
20 Ø creation of a makefile in which are specified:
Ö the language(s) used for the source file(s)
created during the code source file(s) creation
step,
Ö the code source file(s) corresponding to the
25 "implementation" part of the component,
Ø creation of a prototype of the component,
Ø editing of links between the "interface" part and the "implementation" part of the component, so as to generate an executable component prototype,
30 Ø deployment of the makefile so as to compile the component individually, and constitute a respective object file for the interface source file of the "interface" part of the component as well as for the or each code source file of the
35 "implementation" part of the component,
Ø encapsulation of the object files created during
the preceding step into a single executable
module,

- 12 - l during the creation of the prototype of a component, a prototype comprising:
Øan object interface resulting from the compilation of the interface source file of the component,
Ø a prototype object file in respect of each code
source file of the "implementation" part of the
component,
is created,
l during the compilation of the interface source file of the component, there is carried out:
> the analysis and the verification of the consistency of the source file of the interface,
> the translation of the source file of the interface into binary data,
> the automatic generation of at least one file so as to call the functionalities which are to be imported by the component,
l after the step of editing links between the "interface" part and the" '"implementation" part of the component so as to generate an executable component prototype, an automatic integrity testing step is carried out during which one verifies whether the project is consistent and closed,
l during the automatic integrity , test, for each functionality required in the project, there is an automatic search, from among a list of accessible components, for a component which fulfils the said functionality,
in the case where several components fulfilling the requested functionality are identified, a particular component can be chosen from among these components, in the case where the integrity test reveals that the project is not correctly closed, an error message is issued indicating the inconsistencies so as to be able to modify certain components and/or add some, for each component loaded into the system, the description of the functionalities that the component needs to import from other components so as to fulfil

- 13 - its own functionality is permanently accessible to the said means of automatic component search, l during the encapsulation of the object files created during the preceding step into a single executable module, one verifies that all the functionalities supplied by the various interface parts of the project have actually been described fully in an associated source file and have been compiled, l the process comprises the storage in a random access memory area of the system of a map of the components loaded into the system,
l the said map is intended to be consulted when a calling component calls a functionality, so as to determine whether a component of the said map is able to supply the functionality called up, l it is the said means of automatic component search which are able to consult the said map, l the said map is updated in real time during the operation of the system, as a function of the components loaded into the system,
l each component can be associated with a level of privileges which conditions the possibilities of access of the component to other components, as a function of the respective levels of privileges of the said other components,
l means are provided for automatically unloading each component where the functionality which it offers is no longer necessary for the operation of the computer projects,
l the said means comprise a usage counter for each component,
l the said counter counts the number of components which import a functionality of the component with which the counter is associated, and the said component is unloaded as soon as its usage counter has decreased to zero,
l there are provided means for automatically freeing the resources used by the said unloaded component.

- 14 - ØIntroduction of the figures
Other aspects, aims and advantages of the system according to the invention will become better apparent on reading the following description of an embodiment of the invention, given with reference to the appended drawings in which, apart from Figures 1 and 2 which have already been commented on:
• Figures 3a to 3c are three schematic representations
10 of an operating system according to the invention,
• Figure 4 is a schematic representation of a component of the system according to the invention,
• Figure 5 is a schematic representation of the steps for formulating such a component,
15 • Figure 6 is a logic chart illustrating the creation and deployment of a component of an operating system according to the invention,
• Figure 7 represents the mode of apportioning and of
loading the software components of the system
20 according to the invention,
• Figure 8 illustrates the reduction in memory
consumption during the dynamic loading and unloading
of components of a system according to the invention,
• Figure 9 is a logic chart illustrating the dynamic
25 replacement of a component in a system according to
the invention,
• Figures 10a, 10b and 10c are three maps of the
components loaded into a system according to the
invention. Figure 10a corresponding to a minimal
30 configuration in which only the components strictly necessary for the initial operation of a system according to the invention are loaded. Figure 10b corresponds to a basic configuration which furthermore allows multi-thread management. Figure
35 10c corresponds to an enhanced version of a system according to the invention.

- 15 - ØGeneral introduction to the system
It has been stated that existing systems, whether they be monolithic or micro-kernel, systematically differentiate the programs as a function of the system layer with which they are associated.
The system according to the invention does not differentiate the programs in this way. On the
10 contrary, in the case of the invention, the operating system consists entirely of non-hierarchical components. Thus, according to an original characteristic, the system according to the invention does not exhibit a layered structure.
15
Also, although the programmer of a software system retains in the case of the invention the possibility of associating a particular level of privileges with each component of the system so as to communicate with the
20 other components (this level of privileges possibly corresponding to those conventionally used in the state of the art systems - "kernel", "library", "application package", or having been created on request), the programmer is free to effect or otherwise such an
25 association for each component, and to choose any desired level of privileges for the component.
It is pointed out that the term "programmer" is defined as relating to a single person or to a team of
30 developers. A major benefit of the system according to the invention is, as will be understood, to allow teams of developers to work in the most effective manner possible, each developer being able to take responsibility for a functionality of an application,
35 by developing a component. Also, the detailed management of privileges which is offered by the system according to the invention opens up numerous possibilities, such as for example:

- 16 -
• the creation, the development and the complete
testing of a component in "non-privileged" mode
(application package) , and its utilization on the
target in "privileged" mode (system) once development
has terminated and been fully validated. This approach allows the same flexibility of fine-tuning as a micro-kernel system, by making it possible to design a "driver" in application form, so as subsequently to utilize it at a performance level 10 equal to a monolithic kernel, in "system" mode,
• the possibility of assigning different privileges
within a group of components of the same type (for
example "codecs", data coders/decoders) : utilization
of a simple component (example: GIF "codec") in
system component form, for speed; and of a complex component (example: HTML "codec" or Macromedia Flash (registered trade marks)) in user component form, not as . fast but secure and offering complete fault tolerance.
This choice on a case by case basis allows the programmer to construct his system entirely as a function of his objectives.
25 Figures 3a to 3c schematically illustrate the architecture of a system according to the invention, which is embodied solely on the basis of components, and which comprises no "central" element such as a kernel or a micro-kernel.
30
As will be seen, each of these components has its own existence in the system; they can be created, compiled, loaded into memory in the system and unloaded independently of one another, thereby making it
35 possible to:
• dynamically update the system (new version, correction of bugs, etc.) without ever rebooting,
• circumvent during the design of the software system the "stances" which are rather unportable in the

- 17 - abstraction of the hardware by the software system, by offering the possibility of changing the hardware management policies as a function of the end product's own requirements.

Each component of the system according to the invention is dedicated to a single functionality, in contrast to conventional operation systems in which the kernel, as well as most of the programs, fulfil multiple functionalities.
Also, to fulfil the functionality associated therewith, each component can request the execution of one or more other functionality (functionalities) by one or more other component(s).
15
Thus, to operate, the system according to the invention places each given component loaded into its memory in communication with other components which fulfil a functionality required for the given component's own
20 operation.
Figures 3a to 3c thus comprise arrows which illustrate the communication channels which are established by the system between certain components so as to allow them to transmit functionalities to one another.
These figures also illustrate the dynamic nature of the architecture of the system, it being possible for a component 31 to be replaced with a component ' 32 so as 30 to fulfil the same functionality, without requiring the changing of any other component, as is represented in Figure 3c. These aspects will be detailed hereinbelow.
Ø The components - general considerations
35
* General definition:

- 18 - It is understood that the component is a fundamental element of the system according to the invention, hence it is important to define it accurately.
5 A component in the sense of the invention is an isolated, independent and autonomous code element. As will be described in greater detail, each component of the system according to the invention possesses the following properties: • it fulfils a unique functionality, to which it is dedicated,
• it fulfils this functionality completely. A given
functionality is executed in a single component. This
makes it possible not to have to modify or replace
15 more than one component if one wishes to alter a given functionality, in the running of an application or of any other program,
• just as for the object philosophy, the way in which a
" given functionality is fulfilled by a component is
20 not known to the other components which use this functionality,
• each component is compiled independently, so as to
form a separate executable file which can be likened
to a capsule of the component (referred to as a
25 "module" of the component). During compilation, there is no editing of links between the components. This allows hitherto unknown flexibility, especially in respect of the components which fulfil the essential functionalities of the system and are allocated to
30 the "kernel" in traditional systems,
• each component is associated with an executable code
encapsulated in its module with the aid of an
interface which is likewise associated individually
with the component. During the design of a component,
35 the designer describes, in a text file which constitutes the source version of the interface of the component, the functionality which the component supplies, with the aid of a description language designed specially for this purpose by the Applicant.

- 19 - This description is the only information made available to the system with regard to the component. Such encapsulation guarantees the absence of "edge effects" and of uncontrollable interdependencies 5 between components of the system.
A component of the system according to the invention is therefore a completely encapsulated (in the module) software object isolated from the remainder of the 10 system with the aid of an interface, which as will be seen possesses properties:
• of reusability and modularity (one and the same
component can be deployed in various applications -
or more generally in various programs),
15 • of independence of the environment (each component being generated individually and being capable of being loaded and unloaded independently in the system),
• of dynamic linkage (the components intervening on 20 request, and not systematically) ,
• and of specialization within a given functionality.
A component C consists of two main parts, as illustrated in Figure 4:
25 • a part IMP which allows the realization of the functionality associated with the component, which part will by convention be dubbed the "implementation part" of the component. This part corresponds to the code which is executed to fulfil the functionality of
30 the component, and/or to a hardware implementation on hardware elements. The term "code" is understood to mean one or more programs, which may be written in any language known per se, the said program(s) being intended to fulfil the functionality associated with
35 the component and executing one or more functions for this purpose,
• and an "interface" part INT of the component, which
is the descriptive part permitting dialogue with the
other components of the system.

- 20 -
■ Encapsulation of the components
Each component is encapsulated in a "module", an 5 executable file which links the object files corresponding to the interface and to the code of the component. As will be seen, this file is generated in an autonomous manner for each component, independently of the other components which constitute the system 10 according to the invention.
To generate a component, it is necessary to define the functionalities external to the component and the results of which will need to be used during the 15 execution thereof; this comes within a conventional functional analysis scheme.
On the other hand, as will be understood, the system according to the invention preserves the semantic 20 information arising from this functional analysis phase until the realm of the execution of the component.
This greatly facilitates upgrades of the system and increases its readability.
25
The functionalities external to the component are described in the interface source file of the component, with the aid of the dependencies language created by the Applicant and alluded to earlier.
30
More precisely, each interface source file INT associated with a component C makes it possible to describe this component completely. It describes the interface elements, which it has to import from other
35 components, and those which it exports to other components.
This file will be compiled (with the aid of a compilation file MF, also called a makefile) and linked

- 21 - with the object file(s) corresponding to the code of the implementation part IMP (that is to say to each of the source file(s) of the implementation part of the component), to form the module M of the component which 5 constitutes the executable version of the component, as schematically represented in Figure 5 hereinbelow. The dependency language used to create the interface source files will be explained later in this text.
10 A module M can then be loaded onto a target 50 (the target being defined as the computer hardware on which the software system according to the invention operates) , and be immediately recognized by the other components present on this target, as will be detailed.
15
■ The implementation part of the component
The implementation part IMP is the operational core of the component. This is the part which allows the 20 effective realization of the functionality of the component. This functionality can be realized in various ways by the implementation part, according to the functions deployed by the code.
25 Thus, various components can each realize one and the same functionality, whilst however taking different criteria into account, which criteria may be predetermined during the design of the application or of the program which the component is involved in, or
30 determined dynamically during the actual execution of the application.
These criteria are described in the form of properties (for example void, char, I etc.) which are associated 35 with the interface of the component and which will be described later in .this text.
The criteria are expressed as a function of one of these properties, which is defined in the interface of

- 22 - the component which exports the functionality, the interface of the component which imports the functionality associating a comparison operator with this property (<, >, =, etc. as described hereinbelow), as well as a comparison value.
Also, it is possible to tailor the system or the application statically or dynamically, as a function of criteria external to the component (hardware for example) , or of the current state of the system and of the application during execution.
The interface file of each component thus supplies a set of meta-information which, as will be seen, will
15 allow a specific component of the system (the dependencies manager) to manage in a relevant manner the relations between the components, as a function of the criteria alluded to earlier (which may relate to a version of the component, a location of this component,
20 a data item of the state of the system, etc.).
It is also pointed out that if each functionality can be realized uniquely by a code ("software" implementation of the functionality), it is also 25 possible to involve at least one hardware element to fulfil the functionality ("hardware" implementation of the functionality).
■ The interface part of the component
30
The interface part makes it possible to describe precisely which functionality is supplied by the component and which functionalities will have to be supplied to it, during its execution.
35
It defines, in the dependencies language developed by the Applicant, the format of the data required to be supplied as input to the component and the format of the data output by the component. This format is

- 23 - dependent solely on the functionality realized, and not on the way in which the functionality is realized by the implementation part.
5 This interface part makes it possible to construct a description of the functionality realized by the component, independently of the manner in which this functionality is realized by the implementation part. Indeed, whatever the mode of deployment of the
10 functionality by a code (or by a programmed hardware element), this functionality remains identical. It performs the same processing operations, requests the same information at input and supplies the same data at output.
15
The interface part therefore amply enables upgrades of the system. A software implementation of a functionality (corresponding to a component whose implementation part consist's of code) will thus be
20 realized later by a hardware implementation.
In this case, the corresponding component comprises an interface file, but its implementation part consists of a very simple program describing the linkage with the 25 hardware element.
Conversely, a hardware- implementation may be replaced without any impact on the other components by a software implementation of a functionality. 30
An interface is defined with the keyword "interface" in the description of the module of the component.
The following table describes various properties of a 35 functionality; these properties may relate to functionalities requested by the component (direction = import) or the functionality which the component supplies (direction = export):

- 24 -

■ ■■■,;■■■*•!■•■■■■■■; PROPEPROPERTY"•%■' DIRECTION DESCRIPTION
unique Export A single implementation of this interface can exist on a local system. The system will therefore load only the first implementation and will reject the subsequent ones.
foreign Import The interface is imported from another component.
loadtime Import The interface is loaded automatically, at the same time as the component which uses it.
runtime Import The interface will be loaded on the request of the component which uses it (dynamic management - see the paragraphs regarding the dependencies manager).
required Import The interface is indispensable foroperation.The component will not be loaded ifthe functionality associated with thisinterface is not actually imported.
multiple Import Imports all the components which export the functionality requested by this interface.
An interface can be defined in its text file with the aid of various properties. An example is given 5 hereinbelow:
inprocess supervisor module { interface component {
/* Definition of the exported interface */
}
10 foreign loadtime required interface codec {
/* Definition of the imported interface */ }
};
5 => Properties of an interface:
The properties of an interface make it possible to define the criteria alluded to earlier in this text. They are typed, as in the C language (registered trade 0 mark). The following table describes the various types of properties:

- 25 -
Property DESCRIPTION
void Void (equivalent to type C)
char 8-bit integer
short 16-bit integer
int,long 32-bit integer
long long 64-bit integer
float Floating
double Double (equivalent to type C)
struct name Structure
union name Structure
string UTF-8 string terminated by a zero
Boolean Boolean
memarea Memory area
enum name Enumeration (enum)
The following extensions can be associated with these properties:

Extension Descriptxon
signed Signed value (by default)
unsigned Unsigned value
const Constant value
During the description of the dependencies in the interface file, operators make it possible to specify the properties of the interfaces. They thus make it possible to authorize the importation of another 0 interface only if the value of a property of this other interface corresponds to a well-defined criterion.
The following operators can be associated with the properties of the interfaces:

- 26 -

in This parameter is an input (by default)
out This parameter is an output and will be provided by the functionality called
inout This parameter is an input/output
= Assignment operator
== Ditto C language
< Ditto C language
<= Ditto C language
> Ditto C language
>= Ditto C language
! = Ditto C language
&& Boolean ANDThe result of the logical AND isdifferent from zero
! & Inverse of (&&)The result of the logical AND is zero
The keyword "undef" can be used as comparison value for the properties or the functions. In the example 5 hereinbelow, the component considered requires an interface named codec, containing a 32-bit integer property named mainType, whose value must be 2 exactly. This interface must ensure a functionality Func{} taking a character string as parameter and returning a 10 32-bit signed integer.
foreign loadtime reguired interface codec {
/* Definition of the imported interface */
int mainType == 2;
15 int Func (string name) ! = undef;
}
The supplying and the requesting of the functionality
20 are therefore done via the description of programming
interfaces, supplied or requested. A component can for
example supply the "scheduler" programming interface

- 27 -
(the scheduler allows the
creation/destruction/manipulation of procedures and of threads and their synchronization), whilst requesting the "memory" interface (memory management), the "timer" 5 interface (management of a time counter, needed by the scheduler to interrupt a procedure after a given time and go to the next), etc.
These programming interfaces may contain both: 10 • properties (version, type of memory management, properties of the sequencing, etc.), • and methods (functions) called up for the execution of the component.
15 The properties can be used both during the supplying and during the requesting of a given interface. It is therefore possible to express the fact that the memory interface associated with a component is in its version 1.5.2 thereof (property expressed during the supplying
20 of the interface) ; or else the fact that there is a request for a memory interface whose version is at least 1.0.0 but not the version 1.0.4 since it is known to have an unavoidable "bug" (property expressed during the interface request).
25 '
Also, the content of the interface (properties and methods) constitutes a description written by the programmer with the aid of the language created by the Applicant for this purpose.
30
This language is compiled by the compiler of dependencies, in a binary form which is included within the executable component constituted by the module, in the same capacity as the code of the component and the
35 associated data.
This binary form is easily utilizable on execution, by the system, so as to interlink the components, according to the functionalities requested.

- 28 -
This language is also used to specify which type of code the component contains ("system" or otherwise, "passive" (library) or "active" (application), etc.)/ 5 and which type of code can access a given function (making it possible to restrict the "dangerous" functions of the system to the "system" callers for example)/ this makes it possible to choose the most optimized means of communication. 10
Ø The components - creation and loading into the system
With reference now to Figure 6, the steps of the creation of a component of the system according to the 15 invention will now be described together with its implementation in the system according to the invention.
This Figure 6 is a logic chart in which the columns 20 represent various elements used for the creation and the deployment Of the components of the system according to the invention. From left to right, this table is therefore made up of:
• two columns "COMP" corresponding to the
25 component itself, the leftmost column "INT"
corresponding to the interface part whereas the next column "IMP" corresponds to the implementation part,
• a column "MF" for the makefile which is the
30 component compilation file,
• a column "COMPIL DEP" corresponding to a
components design element which is the
dependencies compiler, an element specially
developed by the Applicant for the compilation
35 of a component,
• a column "COMPIL CODE" corresponding to the
compiler (s) of known type of the file(s) which
constitutes (constitute) the code of the
component,

- 29 -
• a column "LINK" corresponding to the link editor,
• a column "KBIM" corresponding to a particular development tool of the system according to the
5 invention which comes in during the design of a
project (a concept which is defined hereinafter),
• a column "GD" dedicated to a particular
component of the system according to the
10 invention, dubbed the dependency manager (or
GD), which as will be seen constitutes the core of the system according to the invention, but is completely different from the kernels and microkernels of the state of the art,
15 • a column "LOAD" corresponding to particular components of the system according to the invention, the loaders, which make it possible to load the components of the system into a random access memory area of the target,
2 0 • the right-hand column giving an indication of the various phases described.
■ Creation of the component
25 Here we define the general concept of a "project", which designates a set of components having a common goal in the system according to the invention. A project can thus correspond to an application, but also more generally to any type of program which can be
30 executed by a computer system, and which differs from an application (peripherals manager for example).
Prior to the creation of a project intended to be implemented in the ;system according to the invention, a 35 phase of "functional analysis (AF) is carried out at 601, in a conventional manner.
This phase makes it possible to define the various components required, their respective functionalities

- 30 - and the needs associated with each of these functionalities (functionalities which have to be catered for by other components) . It is possible, as will be seen, to use components which are already 5 loaded into the system to afford the project certain functionalities.
Once this prior analysis has been performed, and the needs in terms of components are known, the programmer 10 carries out for each component the succession of steps 602 to 606:
• at 602, creation of an interface source file of
the component in which are described, in the
dependencies language developed by the
15 Applicant, the characteristics of the component.
The characteristics of this language and its main possibilities will be returned to later in this text,
• at 603, the programmer then creates the code,
20 that is to say the source file(s) making it
possible to cater for the functionality of the component, in one or more language (s) which can be of known type(s). During this step, the function(s) to be exported by the component are
25 defined only in terms of prototype, the
corresponding code not being written. It is specified that a functionality corresponds to a processing or to an operation to be undertaken (the description of a functionality
30 will be expressed in French) , for example the management of the memory, when starting up the procedures in progress so as to manage their access to the processor of the target, graphical display, etc. What we call a function is a
35 software code part which also undertakes a
processing operation. The function is the software translation into a programming language
of the functionality (hence its name)

- 31 - In all programming languages, a function is undertaken in very much the same way as our system. It comprises:
Ö a prototype which defines the input and output parameters (their name and their type) . This prototype can be likened to the interface part of our components (its role is identical), Ö a code part. This part performs a processing on data and thus makes it possible to determine the result to be supplied at output. It is also specified that the prototype of a function defines the name of the function, its input parameters (their names and their types) as well as the type of information of the result returned by the function, at 604, the programmer creates a makefile in which he specifies in particular: Ö the language(s) used for the source file(s)
created during the previous step 603, Ö the source file(s) corresponding to the
implementation part of the component, Ö the compilation options,
at 605, the programmer creates with the compiler
of dependencies and the compiler(s)
corresponding to the language(s) used a
prototype of the component, comprising:
Ö an object interface resulting from the
compilation of the interface source file of
the component created at 602, by the compiler
of dependencies. For this compilation of the
interface, the compiler of dependencies
analyses the text of the source file of the
interface, verifies its consistency, then
translates it into binary data which will be
understandable to the GD. The compiler of
dependencies automatically generates files
for calling the functionalities cited in the

- 32 - interface and which are to be supplied to the component.
These files are files of "include" type,
generated by the compiler of dependencies. An
5 "include" file is generated for each code
implementation language. The role of these
files is to define in the computer system a
naming space (that is to say a context with
which correspondences are associated),
10 external to that of the component and
distinct from it, which makes it possible to
access the functionalities which are
requested by the component in its interface.
Each of these "include" files thus defines
15 structures which will be able to be called up
by the interface of the component, in such a
way as to translate the requests made in the
interface into structures and names which can
be used by the implementation language with
20 which the "include" file is associated,
Ö an object file for each source file created at 603; at this juncture each object file corresponds to a prototype source file whose functions are not written fully, 25 • at 606, the programmer then edits the links between the object interface and the object file(s) of the implementation part of the component, in such a way as to generate an executable component prototype. 30
KBIM then carries out at 607 an integrity test on the entire set of prototype components thus developed for the project envisaged, verifying that the project created is consistent and closed (that is to say that 35 all the functionalities required for the project are present within this project).
During the integrity test, KBIM is furnished with the list and with the description of the interfaces of all

- 33 -
the components. Thus, KBIM can search, among these
components, for the component which fulfils a
functionality required for the project. If several
components fulfil1 the requested functionality, KBIM
5 prompts the programmer to choose between these
components. The component found automatically by KBIM
or designated by the programmer is then added to the
components which constitute the project. This new
component can also require other functionalities which
10 KBIM will attempt to resolve. KBIM thus makes it
possible to automatically resolve most of the
functionalities required for a project.
If the project is not correctly closed, KBIM issues an 15 error message indicating the inconsistencies to the programmer and the latter will rerun the succession of steps 602 to 606 so as to modify certain components of the application and/or add some; if the project is consistent and closed, the programmer completes at 608 20 the prototypes of the functions of the code of the implementation part of the component, by writing the complete version of the functions, in the source file(s) of this implementation part.
25 At 609, the programmer deploys the makefile to compile each component separately, in such a way as to create for the code the object files which will make it possible to execute the functionality of the component. During this step, the makefile brings in the
30 involvement of the dependencies compiler as well as the compiler (s) of the language (s) used to formulate the code. Steps 608 and 609 are repeated for each component of the project currently undergoing development.
35 At 610, the programmer then deploys the link editor to create an executable module for each component, the said module being ' associated with the set of object files created during the compilation steps 605 and 609 (the object interface having been created during step

- 34 - 605, whereas the object file(s) associated with the code was or were created during step 609).
During this link editing which corresponds to the 5 encapsulation of the component in the module, the editor verifies that all the functionalities supplied by the various interfaces of the project have actually been described fully in an associated source file and have been compiled. 10
■ Declaration of the component
Once an executable module has thus been created for each component of the project, the programmer must
15 declare the existence of these components so that they are taken into account by the system. This declaration is performed at 611, during which step the programmer declares each component to a "loader", the loaders being themselves specific components of the system
20 according to the invention.
During this step 611, the loader to which a component is declared stores the component in an individual list of the loader which gathers together the set of 25 components which have been declared thereto.
This step 611 is also a step which relates in an overall manner to the project currently undergoing development, the set of components developed in respect 30 of a project being declared to at least one loader -each loader corresponding to a medium of the computer .system (disk, network, etc.) on which the components associated with this loader are stored.

- 35 -■ Loading of the component into the system
Described hereinabove were the steps for creating and
declaring a "project" which can comprise several
5 components. Hereinbelow will now be described the
deployment of these components, which is illustrated in
the lower part of Figure 6.
At 620, a component CI calls a functionality Fl which 10 it requires.
Two possibilities arise for this call:
• either the functionality Fl is defined with the
"loadtime" property in the interface of the component
15 CI (the "loadtime" property is described above). In this case, the GD will search for and load into the system the component which fulfils this functionality Fl, prior to the loading of the component CI. S If this component itself requires a "loadtime" 20 functionality, GD will then also load the component required to fulfil this functionality, again prior to the loading of the component CI. GD will thus recursively load all the components required to fulfil the various "loadtime" 25 functionalities which it will encounter (how a component is loaded into the system will be explained further below),
• or the functionality Fl is defined with the "runtime"
property (the "runtime" property is described above).
30 The component CI must then make an explicit call to another functionality, "depmgr", supplied by the GD, to call the "runtime" functionality Fl. To do this, the "depmgr" functionality absolutely must be declared with the "loadtime" property in the
35 interface of CI so as to be able to use this interface as soon as CI is loaded and initialized (see above the processing of the "loadtime" functionality).

- 36
- -CI will then be able to import the '"runtime" functionality Fl called at 620 at the precise moment at which it is to use it. The component which fulfils this functionality Fl will then be loaded by GD. 5 If this component requires a functionality at the moment it is loaded (functionality declared "loadtime" in its interface), the component fulfilling this "loadtime" functionality will also be loaded.
10 GD will thus recursively load all the components required to fulfil the various "loadtime" functionalities which it will encounter (how to load a component into, the system will be explained further below). The functionality Fl requested initially at
15 620 will therefore be available for CI only if all the "loadtime" functionalities encountered during its resolution are also resolved. If a single functionality requested on loading by CI (functionality declared "loadtime") is not resolved,
20 CI will not be loaded. CI will not in fact be able to fulfil its functional mission since it will not be able to use another functionality which it requires.
If the functionality that CI needs to import is not 25 fulfilled by one of the components of the project to which CI belongs and with which it is declared to one of the loaders of the system, the system, as will be seen, identifies in another project a component making it possible to supply this functionality to CI. 30
For these purposes GD, which is permanently loaded into the random access memory of the system, searches through its "link graph" for whether the interface object file of one of the components of the link graph 35 •indicates , that this component supplies the functionality requested by CI.
To do this, the GD interprets the "binary" version of the interface file, which version is stored in the

- 37
- -executable component, and is loaded/transmitted by the "loaders" components to the GD on execution.
The GD firstly searches for the interfaces possessing the same name as the one requested (imported) . When it 5 finds same, it then verifies within them that all the ■ properties of the requested functionality are present and that any constraints and conditions (version higher than 0.6.2, etc.) are satisfied.
10 The GD link graph is a list of the components which are loaded into the system, that is to say which are not only declared as was described hereinabove with regard to step 611, but whose object interface file has been imported into a random access memory area of the
15 target, and which is connected with other components of the link graph to exchange functionalities supplied and/or requested.
The link graph, which is stored in a random access 20 memory area of the target, is thus an instantaneous image of the loaded components, this link graph being able to adapt dynamically. The link graph is unique and associated with the GD, the GD having access to the information of this link graph. 25
If during step 621 the GD determines that the functionality called up by CI is supplied by one of the components of the link graph (which will be dubbed C2 "called component", whilst CI is the "calling 30 component") , it establishes a communication channel between this component C2 and the component CI by importing at 627 characteristics of the component C2 into the component Cl.
35 More precisely, the GD constructs for Cl a data structure called "view" which offers a view with regard to the imports to be undertaken. This "view" contains the value of the properties as well as the pointers for

- 38
- -the functions imported (or for the code which indirectly makes it possible to reach them, such as for example a system call, a migration of threads, etc.). This "view" emanates directly from the elements 5 generated by the compiler of dependencies in the "include" files.
If now the GD determines at 621 that the functionality called by CI is not supplied by any of the components
10 of the link graph, it will interrogate the lists of the loaders of the system one after the other, so as to determine whether one of the components declared to these loaders offers the functionality requested by CI. This interrogation of the loaders is represented by
15 step 622.
During this interrogation, the GD uses a "loader" functionality which possesses the functions required to Tist the components viewed by each "loader". The
20 "loader" functionality allows the GD to compare a functionality exported by a component of the loader, with the functionality required to be imported. It also allows the GD to load and unload an individual component, from the medium with which the loader is
25 associated to the random access memory of the target.
It is specified that each of the loaders of the system according to the invention is associated with a particular medium making it possible to store
30 components; it will thus be possible for each loader to
• be associated with a memory disk, or with any other
recording support, of CD-ROM type for example. The
plurality of loaders will be illustrated in particular
with reference to Figure 7.
35
If such a component is located in the list of one of
the loaders of the system (step 623), the first loader
-whose list comprises such a component transmits at 625
to the dependency manager the object interface of the

- 39
- -component C2 identified, and the GD itself transmits at 62 6 the "view" of this component C2 to the component CI. (step 627).
The "view" of C2 has been stored by the GD in a system 5 memory area which is created dynamically by the GD, upon the loading of the component C2, and which will be destroyed at the same time as this component is unloaded. This area is situated in the same address space as the component which can access it.
10
If now the search of the GD to identify in the list of one of the loaders a component supplying the requested functionality turns out to be fruitless during step 623, the system stops at 624.
15
In any event, the loading of a component CI into the random access memory of the system brings about as explained hereinabove the automatic searching by the GD for a component C2 offering the functionality Fl which
20 is required for the-operation of the component CI.
Also, if the component CI calls not just one but several functionalities, the GD will likewise carry out the automatic search for components offering these 25 requested functionalities.
It will be noted that the system according to the invention offers a degree of additional flexibility as compared with the known systems.
30
Indeed, in the case of known systems built with entities the programmer must for each given calling entity specify the list of the other entities of the system which are required for the operation of the said
35 calling entity, and which have to be loaded into the system for the proper operation of this calling entity.

- 40 –
- Thus, in the case of these known systems, the needs of the entities are not generally expressed in terms of functionalities, but in terms of specific entities (such is the case for example for the Java language). 5
Also, in the case of the invention each of several different components is apt to be associated with a calling component CI, in so far as the said different components offer the same functionality.
10
Also, an additional advantage of the invention derives from the criteria which can be associated with the components, these criteria-, being taken into account by the GD during its automatic search for components
15 offering a functionality requested by a first component.
Indeed, during this search for components the GD searches not only for a component offering a requested 20 functionality, but more precisely for a component offering the said functionality in association with a specific condition expressed according to the criteria which were mentioned earlier in this text.
25 In the case of existing languages (for example of the type of the Java language - registered trade mark), in fact, the programmer absolutely must create an explicit link between a calling entity and a called entity. It is thus apparent that the deployment of this type of
30 known system does not in any way offer the same degree of flexibility as the invention, which lends itself much better to maintenance and upgrading (for example to produce enhanced versions, in which components offering a requested functionality can be replaced by
35 other components fulfilling the same functionality in a different manner, or else new components fulfilling the said functionality' can be added so as to offer new possibilities of choice to the GD.

- 41 –
- Thus, the invention makes it possible to build extremely upgradable systems, in which just one or more desired component(s) can be replaced at will.
5 Each replaced component offers a functionality which was already offered by the old component which is replaced.
However, the specific means for fulfilling this 10 functionality, be they software and/or hardware, can adapt at will.
Within the framework of applications such as the maintenance of a network of systems installed on
15 various sites, or else the maintenance of a mobile set of devices (such as portable telephones or personal organizers for example) which one does not wish to physically return to a central site in order to upgrade them, this possibility is especially beneficial.
20
Thus, the applications installed on the devices of the abovementioned type can be upgraded by simply downloading one or more new component (s) onto these devices, from a central site, doing so without it being
25 necessary to physically move the devices which can be disseminated over any territory.
Furthermore, the replacements of these components do not require the recompilation of the computer system 30 which deploys them.
In the case where a component C2 offering the functionality requested by CI has been identified (possibly with the criteria satisfying a condition 35 requested by the interface of (1)) and the characteristics of C2 have been imported into Cl at 627, the dependency manager will operate differently according to whether the component C2 does or does not already form part of the link graph (step 628).

- 42
- -If C2 already belongs to the link graph, the GD goes directly to step 633 for creating a communication channel between CI and C2. To do this, the system will either use one of the four communication modes 5 described hereinbelow, or use a specific mode created specially, as a function of the characteristics specified in the interface of CI and/or C2:
=> Direct calls:
10
This is the fastest method. The functionality or method
requested is called directly, and its result returned
directly. There is no intermediate code. The
.dependencies manager chooses this means when the two
15 components are on the same machine, in the same address space, and at the same level of privileges.
An address space is defined as a logical memory area in
which code addresses or data addresses have a meaning
20 for all the components accessing this area. A pointer to the code or to the data can be transmitted as is from one component to another and, without its value being modified, will make it possible to access the same data.
25
In the invention, the term "address space" also implies common privileges, an address space defining a "space" or a class of objects having the same level of privileges: the pointed-at objects of one and the same
30 address space can thus be accessed in the same way by the various components.
Also, it is thus possible for example to define a "user" space with a lower level of privileges, and a 35 "supervisor" space with a higher level.
The consistency of the pointers between the "user" space of each procedure and the "supervisor" (system) space is complied with (the processor of the computer

- 43
- -system having access to both spaces at the same time), but the "user" code cannot reference data lying in the "supervisor" space.
The privileges are possibilities of access between components; in the source interface it is possible to use the following levels of privileges:

Level I Description
Inprocess The module is executed in the same addres" space as its calling party.
spawn The component is executed in its own procedure, created during its loading. It is pointed out that when a component marked "spawn" is loaded, the GD automatically asks a "scheduler" component dedicated to scheduling to create a procedure which will be started by CI and a corresponding address space. The component is then contained in the address space of this procedure, and operates in the guise of active element (it is possible to perform processing operations without any action other than the starting of the component), and not passive element as in the case of a component not marked "spawn" (which simply waits to be called up in order to perform a processing operation). The GD differentiates this level of privileges of the component before step 621.
Io The module performs input/output operations (driver).
Supervisor The component must be executed in supervisor mode (the highest level of privileges).
To assign one of these levels of privileges to a component, the programmer fixes the corresponding parameter in the definition of the module of the component, which definition is contained within a text of the type:
inprocess supervisor module { /* Definition of the module */

- 44
- -Thus, in general, it is possible to associate a given level of privileges with each individual component, the said privilege level conditioning the possibilities of access of this component to other components, as a 5 function of respective levels of privileges of the said other components.
Stated otherwise, the association of a level of privilege [lacuna] to a component gives this component 10 the possibility of "viewing" the functionalities offered by the interfaces of certain components, as a function of the levels of privileges which are actually associated with these other components.
15 Also, as will be seen hereinbelow, this hierarchy of access between the components which is established by • the levels of privileges which can be associated individually with the various components can be "short-circuited" by operators associated individually with
20 certain specific components.
Examples of such calls are the following:
• supervisor component to supervisor component,
• user component (that is to say from the lower level 25 of privileges) to user component in the same address
space (such an application using a component managing a library of shared and passive functions).
This method is the only one employed if the memory 30 component does not provide protection, this possibly being the choice of the engineer who constructs the system for his product, thereby providing an extremely fast system in the absence of protection.
35 The memory component does not "provide" protection when this component offers just a single address space, of the "system" type. This type of memory management offers no protection (everything operating within the same space and potentially being able to destroy or

- 45
- -modify the code or the data belonging to other components) , but is the only one possible on certain targets not possessing any "MMU" (memory management unit). 5
=> System calls:
The appeal is diverted to a system call. The latter transfers the parameters from the user stack to the 10 supervisor stack, changes level of privileges, makes the call, returns to the lower level of privileges and returns the result directly.
This method is selected when a user component (non-15 privileged) calls upon a functionality of a supervisor component, on condition that this functionality authorizes the no privileged components to use it.
This authorization is made at the level of the 20 dependencies description language, via the keyword "promote". Also, more generally, the following keywords may be associated with a component (in the syntax of the language developed by the Applicant, the keywords are simply prefixed to the property or method whose 25 manner of operation they are to alter):

Keyword Description
promote Makes it possible to call a functi___ implemented in a "supervisor" component from a user component.
untrusted Like promote, but without automatically switching to supervisor mode.
A sync Hands back immediately to the calling party and continues the processing of the functionality in parallel: in this case, the indirect call through the "view" ends up at code of the GD which creates a thread (which itself calls the function in question) and hands over immediately (execution continuing in the thread created).
serial Calls which are concurrent with the functionality are prohibited (the other calling parties will be placed on hold).

- 46
- -Thus, the authorization alluded to hereinabove, deployed via the keyword "promote" makes it possible to "short-circuit" levels of privileges which have been established elsewhere, in order to individually 5 authorize access of one component to another, to which its level of privileges would not give it access.
=> Migration of threads:
10 The system according to the invention separates the logical management of an execution thread (identifier, priority, system stack, etc.) from its physical management (processor context, user stack, address space in which the thread is contained, etc.).
15
When a component calls upon a function situated in another address space and does so synchronously (the calling party is blocked pending the result), the calling party "migrates" into the called party and
20 performs the processing.
For this purpose, the logical' part of the thread "stacks up" its current physical part, and attaches itself to a new physical part created in the address 25 space of the called party.
The code of the desired functionality is then executed in the context of the called party (that is to say in the same address space and the same containing 30 procedure), but in the logical thread of the calling party. Once the function has terminated, the calling thread "unstacks" its original physical part and "migrates" into the calling party again.
35 The threads migration code is also responsible for sending the parameters in both directions, copying or remapping the memory areas, the strings, etc. supplied as parameter.

*

5
- 47
- This mechanism avoids the much more expensive traditional method consisting in composing a message, sending the message to a thread in the called component, suspending the thread of the calling party, decomposing the message in the called party, executing the desired function, recomposing a message in respect of the result, waking up the calling party, suspending the called party again.
10 This also avoids numerous problems related to the synchronous passing of messages, such as the reversal of priorities (here, the called functionality is executed with the priority of the calling party), the accounting of resources (the machine time is counted
15 down at the calling party) , as well as the need to
maintain a "pool" of threads in the called component,
which are asleep, taking unnecessary memory resources,
■ until calls are received, subsequently being of
insufficient number should there be floods of calls
20 (here, the calling parties migrate into the called parties, there is always the exact number of threads required).
This method greatly optimizes the commonest case of 25 calls outside of address space: synchronous calls on the same machine.
=> Passing of messages:
30 In contradistinction to the case of micro-kernel based systems, for example, in which this method is systematically employed, it is used solely for calls which do not come within the above categories, such as:
• asynchronous local call (the calling party does not 35 remain blocked pending the result),
• remote call to another machine.
The passing of messages consists in encoding the parameters supplied in a message, in routing the

- 48
- message to the destination component, decoding it, executing the function, storing the result in a message, returned to the calling party. This method is, as mentioned hereinabove, particularly tailored to 5 asynchronous calls (the result message is sent later), and to remote calls, requiring the construction of network packets in any manner.
Returning to the description given with reference to 10 Figure 6, the creation of a communication channel is associated with the call of the function for recording the calling component CI in the implementation part of the called component C2.
15 This function, dubbed Register(), forms part of the "component" functionality which is supplied by all the components of the system, in addition to their own specific functionality. The "component" functionality comprises four functions:
20 • initialization,
• deinitialization,
• recording,
• derecording.
25 If now the GD determines at 628 that the component C2 does not form part of the link graph, at 629 it calls the loader of this component C2 so as to bring C2 into the random access memory of the target, to call at 630 the functions for initializing C2 and to update the
30 link graph at 631.
Figure 7 thus illustrates the link graph G, into which the GD can import a component or a set P2 of components from the memory location 72 of a first loader, so as to 35 allow a component CI already present in the link graph (having previously been imported from the memory area 71 of another loader with the project PI of which it forms part) to be connected with a called component C2 which has been identified by the GD during step 623 for

- 49
- searching among the loaders as affording a functionality required by Cl.
Indeed it is recalled that during the integrity test 5 performed by KBIM at 607 (see Figure 6) , KBIM verifies that each functionality called by a component is offered not strictly by a component of one and the same project, but more generally by a component loaded into the software system. 10
Coming back again to Figure 6, step 631 leads on to step 633 already described.
Also, whereas the loading of a component C2 called by a 15 component Cl has been described, it is understood that the component Cl has itself been called by another component, and that it has been necessary to initiate the call of the functionalities when booting the system. 20
~ For this purpose, when starting an application, the GD requests an "interaction" functionality and searches for a component supplying this functionality. The GD can also import a component which requests this 25 functionality. In, all cases, the "interaction" functionality will call another component, which in turn will call at least one other component.
Ø The dependencies manager
30
It has been stated that the dependencies manager is a component permanently loaded into the system according to the invention. It makes it possible to construct the links between the various components which constitute
35 an application; these links are established from the interfaces of the components.
According to an advantageous aspect of the invention, only those components which are useful in respect of

- 50
- -the operation of the application and of the system will be loaded, thus optimizing the resources required. This optimization can be achieved according to one of the following modes: 5
■ Automatic loading of components during execution
When a component is loaded so as to be executed, the dependencies manager analyses its dependencies as
10 expressed in its interface and automatically seeks to resolve all the dependencies expressed therein, that is to say to supply the component with all the functionalities which it needs, and also to "close" the system of dependencies by likewise seeking to supply
15 every component thus deployed with the functionalities which it needs.
The GD then automatically loads into the link graph the components resolving the interfaces imported whose 20 property is "loadtime", also resolves their dependencies and creates the communication channels between these various components, as a function of their respective locations.
25 A communication channel can thus be created according to any mode of communication as defined above; it consists of any data transmission pathway (specific to each mode of communication) capable of calling a functionality with the associated parameters, and of
30 recovering the return value(s) resulting from the processing performed by the functionality.
As soon as the communication channels are created, the components can communicate directly with one another. 35
■ Dynamic loading and unloading of components:
When an imported interface has the "runtime" property, the component which uses this interface will request

- 51 -
the loading of the component which implements this
interface, only when this component needs the
functionality associated with the interface.This
"runtime" property is thus an alternative to the
5 . "loadtime" property already described.
This management makes it possible to accurately determine the properties of the implementation of the interface which has to be loaded, as a function of 10 dynamic parameters, which are not known when loading the component requesting the functionality.
For example, a "text" component can import a codec interface so as to decompress the files which it 15 receives, this "text" component being able to receive several types of files.
During reception of a file, the "text" component can search for the codec interface tailored to the 20 decompression of this file, as a function of its extension for example. To do this, it uses the Query() functionality of the dependencies manager, passing the search parameters to it.
25 It can then order the dependencies manager, with the aid of the Open() functionality, to load the component. It can then use the codec interface of this component to decompress the file.
30 When the decompression has terminated, the "text" component can request the unloading of the codec component used.
It is thus possible to load a component dynamically. 35 This possibility allows components to be loaded only when they are required to perform a processing. The component can then be unloaded when its processing has terminated.

- 52
- -According to another example, an application can display an image during its loading and subsequently no longer have to process images of this format, or process them only exceptionally. 5
This application can therefore dynamically load the component for processing the image format, requesting it to process the file so as to display the image and subsequently unload this component. The component is
10 loaded into memory only when it is strictly required, this making it possible to share the memory resources among the various components, as a function of processing operations to be undertaken at a given instant.
15
This method therefore allows a considerable reduction in the memory resources required.
The dependencies manager can also automatically manage 20 the loading and unloading of components as a function of their usage statistics and memory resources. This management then becomes completely transparent to the programmer of the application.
25 The diagram of Figure 8 shows the benefit of dynamic management of the components on a system possessing few memory resources. In this example, the application displays two images, a GIF and a JPEG. Each image is processed sequentially, thereby making it possible to
30 load and unload the components dynamically.
In this example, the dynamic loading and unloading of the components makes it possible to reduce the maximum memory resource required. 35
Furthermore, in most cases, this loading and unloading will not be perceptible in terms of performance.

- 53
- -Indeed, .the modules of components have a reduced size (of the order of a few hundred bytes to a few kilobytes). The operation of loading them into memory is therefore one which is carried out very fast. 5 Furthermore, most of the applications perform sequential processing operations and the input information is often supplied by a human user and the output information are supplied to the user.
10 Hence, on the human scale, the few micro-seconds which will be required to load and unload a component will not even be perceptible; in the case of the example illustrated by Figure 8, the operations are carried out according to the following sequence:
15 • loading of an image (loading of the JPEG code),
• displaying of this image on the screen,
• the user,
• loading of another image (unloading of the JPEG code and unloading of the GIF code),
20 • displaying of this other image.
The loading and unloading time is insignificant compared with the other processing operations.
25 ■ Optimization of resources by the dependencies manager:
The dependencies manager manages a usage counter for each component. ■ This counter counts the number of
30 "importers" of the component, that is to say of components which import a functionality from the component with which the counter is associated. A component is unloaded as soon as its usage counter has decreased to 0.
35
When a component is no longer used, the dependencies manager automatically frees the resources used for this component.

- 54
- -It will be noted that the invention thus allows particularly effective optimization of the resources deployed by the system, without burdening the general manner of operation of the system. 5
Indeed, the known systems generally deploy periodic means for verifying the state of the components, the said means being deployed by a specific task which "takes over" periodically so as to identify the 10 components which have to be unloaded.
Such a periodic verification task is not well suited to real time, since it does not enable the modifications of state of the components to be tracked with good
15 reactivity.
Moreover, a manner of operation of this type demands a multitask environment owing to the presence of the verification task.
20
An illustration of a manner of operation of this type deploying periodic verification will be found in the Java language, the verification task deploying an element of the "garbage collector" type.
25
■ Details regarding the functionalities undertaken by a hardware element:
It has been stated that the implementation part of a 30 component could correspond to a code (which comprises one or more programs so as to fulfil the functionality of the component) , but also to a hardware implementation based on hardware elements comprising electronic circuits. 35
Thus, a functionality can be undertaken by a component
Cl which implements it by using an electronic circuit
(video decompression circuit for example). However,
this functionality can also be undertaken by a

- 55 –
- component CI which implements it on the basis of software alone. If for an application the electronic circuit is indeed present and operating correctly, the system will use the component CI. If, on the other 5 hand, the electronic circuit is not present or if it is not operating correctly, the system will use the component CI', in a manner which is transparent to the other components. In all cases, the functionality is undertaken.
10
Likewise, if a functionality is undertaken today by software code, it may be undertaken later by a component which implements it using an electronic circuit, in a manner which is completely transparent to
15 the other components.
The diagram of Figure 9 illustrates the replacing of a component CI by another component, CI, which exports the same functionality.
20
CI currently executing as indicated at 900, a component C2 which possesses a channel for communication with CI and is thus linked to it in the link graph requests the GD at 901 for the replacement of CI by CI.
25
GD then requests CI to save its current state (step 902), this being undertaken by CI at 903. GD then loads and initializes CI (904 and 905).
30 If the loading or the initialization of CI are not performed correctly (step 906), the GD returns an error to the requester C2.
If the loading and the initialization of CI took place • 35 correctly, the GD transmits at 908 the current state of CI to CI, so that CI places itself in the same state.
For these purposes, CI interprets the current state transmitted (909) and accepts it or rejects it (910).

- 56 -
If it rejects it, the GD unloads C'l (911) and deinitializes it (912) . The GD then returns an error message to the requester C2 (913 and 914). 5
If now C'l accepts the current state of CI, the GD updates its graph (916) by replacing CI with C'l therein. It then reconstructs the communication channels for C'l (917); these channels are those which 10 were used for CI. Then the GD deinitializes and unloads CI (918 and 919).
The replacement having been performed correctly, GD informs C2 thereof (920, 921); the latter can continue 15 its processing.
Described hereinabove was the principle of the system according to the invention, and the application thereof (among other things with reference to Figure 6).
20
Let us specify that it is also possible to parameterize the interface of the component CI so that, when the GD searches for a component which exports a functionality imported by Cl, it continues its search among the set
25 of components loaded into the system and transmits to Cl a "view" of each of the components of the link graph which exports this functionality, in a step equivalent to step 627 of Figure 6.
30 As a function of the parameterized selection criteria, Cl will then be able to select the appropriate component for it from among those identified by the GD.
Let us also specify that, in its current version, the 35 system according to the invention requires a minimum of four components to operate, as represented in Figure 10a (in which the arrows indicate the functionalities transmitted between components - this type of figure is thus a representation of the link graph).

*

- 57 -
These are the following components:
• "interaction" which as has been stated is required in
order to initiate the operation of the system,
5 • "shuttle" which is called by "interaction" and which itself calls the following two components:
• the GD,
• and finally "VMM", the so-called memory component or memory management component which also calls the GD
10 as well.
Figure 10b shows a likewise minimal configuration of the system, in which three components "CPU", "TIMER3" and "SCHED" have been added so as to permit multi-15 thread management.
Finally, Figure 10c represents an enhanced configuration of a system according to the invention, which constitutes a small application.
20
In this figure, the "interaction" component uses a "COM" component for communication so as to exchange data over a network and uses the "GUI" (graphics interface) component to display graphical
25 presentations.
The "MOUSE" component makes it possible to manage the MOUSE peripheral. It transmits information regarding the changes of state of this peripheral (move, click on 30 the buttons). The "GUI" component uses the "WINDOW" and "BUTTON" components to carry out the displays requested by the "INTERACTION" component.
The "WINDOW" and "BUTTON" components use the GIF and 35 JPEG codec components to display images in their respective display areas.
The GUI, COM, WINDOW, BUTTON, GIF and JPEG components also use functionalities of the basic components of the

- 58
- -system. However, the links corresponding to these functionalities are not represented in the diagram of Figure 10c so as not to overburden this figure.
The components are classed into domains, which are categories not corresponding to a level of privileges, but to a type of use. Various domains are as follows, with certain associated components:

Domain Description
SHEDULE Scheduler components MULTILEVEL
GESTION MEMOIRE Memory management components VMM LMM
BUS Bus management components ISA PCI
COMM Communication components ETHERNET FTPIPSTACK SERIAL
INPUT Input systems management componentsELOTOUCH (touch-sensitive panel)KEYMAPPCKBDPS2MOUSE (PS2 mouse)REBOOT (watchdog)
GFX Graphics interface management componentsGFX - . BUTTONWINDOWSCROLLBARTEXTIMAGE
SON AUDIO management components AUDIO codec
IMAGES Image and video management components JPEG codec GIF codec PNG codec BMP codec MPEG codec
FILE SYSTEM (FS) Disk management components FAT HDD CD

- 59
- -It will be noted that because all the components of the system according to the invention are realized according to the same format, the system manages all the components in the same way and the abovementioned 5 advantageous properties of the components apply in the same way to the components, regardless of their level of privileges.
Lastly, it is apparent that the system according to the 10 invention makes it possible:
• for programmers to have an overview of all the
elements of the operating system, regardless of their
level of privileges,
• to use the same tools to create these various
15 elements,
• to effect interconnections between the various parts,
without restriction. The power of the system is not
expressed by its number of components, but the number
of possible interconnections, in the traditional
20 systems (both monolithic and micro-kernel), the means of communication between the various parts are limited and fixed. It is systematically necessary to go via an arbitrary bottleneck (the system calls being limited in number, for the kernel, whether this
25 be a monolithic kernel or a micro-kernel, etc.). Management of dependencies and dynamic creation of communication means makes it possible to overcome this limitation,
• to offer equal properties to all the code types. In
30 the case of the invention, it is in fact no longer
necessary to design a system for managing kernel modules, libraries, or even "plug-ins" of applications. All this is replaced by the components management system, 35 • to create as many components, in the future, as functionalities which will need to be fulfilled. This allows the system according to the invention to be completely upgradable.

- 60 –
- Furthermore, as has been seen in the description hereinabove, the invention shows a great readability and a reactivity to the developer, by returning error messages in many instances. 5
Indeed, during the loading of the component, a function (Init) is automatically executed for this component. This function (Init) verifies that the set of components required for the operation of the loaded
10 component is actually loaded into the system. In the case where this verification is not satisfactory (at least one requested functionality is not fulfilled, or else a component offering a requested functionality is associated with a defective hardware element, etc., an
15 error message is returned to the calling party.
Furthermore, in the case where a called component is associated with a defective element (hardware and/or software), it is automatically unloaded into the random 20 access memory of the system.
Additionally, it was seen with reference to Figure 9 that error messages were also returned when components were called. 25
Thus, if a hardware or software element is absent or defective with regard to operating a calling component, an error message keeps one advised thereof without requiring a complete operation of tests of the system.

WE CLAIM:
1. A process for developing computer projects (PI, P2) intended to be
implemented by a computer system, the process comprising a phase of
functional analysis (601) with a view to cataloguing the functionalities
which are to be created for, a phase of creating components (C1,C2) of the
project so as to fulfill the said functionalities, a phase of declaration on the
same system of the components created during the creation phase, and a
phase of loading the said components into a memory area of the system for
their implementation by the system, characterized in that:
• during the components creation phase, each functionality is completely fulfilled by the component associated therewith,
• during the components declaration phase, each component created is declared to a system loading component, and
• during the components loading phase, there is provided a dependency manager component (GD) for, in association with each functionality requested by a loaded component, automatically searching for a component offering the said functionality.

2. A process as claimed in the preceding claim, wherein the said automatic search is performed while taking a condition into account.
3. A process as claimed in the preceding claim, wherein the said condition is expressed as a function of criteria expressed as a function of properties associated individually with each component.
4. A process as claimed in one of the preceding claims, wherein during the creation of a component, the following steps are carried out:
• creation (602) of an interface source file of the component, with a view
to constituting an interface" part (INT) of the component,
-62-

• creation (603) of at least one code source file making it possible to
realize the functionality of the component, with a view to constituting an
"implementation" part (IMP) of the component.
5. A process as claimed in the preceding claim, wherein each code
source file created with a view to constituting an "implementation" part of
the component can be formulated in any programming language.
6. A process as claimed in one of the preceding two claims, wherein each component can fulfill the functionality associated therewith by deploying software and/or hardware means.
7. A process as claimed in one of the preceding four claims, wherein the interface file of each component comprises a description of the functionality fulfilled by the said component, independent of the manner in which this functionality is fulfilled by the component.
8. A process as claimed in the preceding claim, wherein the interface file also comprises a description of the functionalities that the component needs to import from other components in order to fulfill its own functionality.
9. A process as claimed in one of the preceding claims, where each component (CI) can be dynamically replaced by another component (C'l) which exports the same functionality.
10. A process as claimed in the preceding claim, wherein the said replacement deploys the following steps:

• saving of the current state of the component to be replaced,
• loading and initialization of the new component,
• transmission of the current state of the component to be replaced to the new component,
-63-

• establishment of a communication channel between the component calling the functionality and the new component,
• unloading of the component to be replaced.

11. A process as claimed in the preceding claim, wherein if the loading or the initialization of the new component is not performed correctly, means are provided for returning an error message.
12. A process as claimed in one of the preceding four claims, wherein during the creation of a component, the following steps are also carried out:
• creation (604) of a makefile in which are specified:
•S the language (s) used for the source file(s) created during the code source file(s) creation step,
S the code source file(s) corresponding to the "implementation" part of the component,
• creation (605) of a prototype of the component,
• editing of links (606) between the "interface" part and the "implementation" part of the component, so as to generate an executable component prototype,
• deployment of the makefile (609) so as to compile the component individually, and constitute a respective object file for the interface source file of the "interface" part of the component as well as for the or each code source file of the "implementation" part of the component,
• encapsulation (610) of the object files created during the preceding step into a single executable module.
13. A process as claimed in the preceding claim, wherein during the
creation of the prototype of a component, a prototype comprising:
• an object interface resulting from the compilation of the interface
source file of the component,
-64-

• a prototype object file in respect of each code source file of the
"implementation" part of the component,
is created.
14. A process as claimed in the preceding claim, wherein during the
compilation of the interface source file of the component, there is carried
out:
• the analysis and the verification of the consistency of the source file of the interface,
• the translation of the source file of the interface into binary data,
• the automatic generation of at least one file so as to call the functionalities which are to be imported by the component.

15. A process as claimed in one of the preceding three claims, wherein after the step of editing links between the "interface" part and the "implementation" part of the component so as to generate an executable component prototype, an automatic integrity testing step (607) is carried out during which one verifies whether the project is consistent and closed.
16. A process as claimed in preceding claim, wherein during the automatic integrity test, for each functionality required in the project, there is an automatic search, from among a list of accessible components, for a component which fulfils the said functionality.
17. A process as claimed in the preceding claim, wherein in the case where several components fulfilling the requested functionality are identified, a particular component can be chosen from among these components.
18. A process as claimed in one of the preceding two claims, wherein the case where the integrity test reveals that the project is not correctly closed, an error message is issued indicating the inconsistencies so as to be able to modify certain components and/or add some.
-65-

19. A process as claimed in one of the preceding seven claims, wherein for each component loaded into the system, the description of the functionalities that the component needs to import from other components so as to fulfill its own functionality is permanently accessible to the said means (GD) of automatic component search.
20. A process as claimed in one of the preceding eight claims, wherein during the encapsulation (610) of the object files created during the preceding step into a single executable module, one verifies that all the functionalities supplied by the various interface parts of the project have actually been described fully in an associated source file and have been compiled.
21. A process as claimed in one of the preceding nine claims, wherein the process comprises the storage in a random access memory area of the system of a map (G) of the components loaded into the system.
22. A process as claimed in the preceding claim, wherein the said map is intended to be consulted when a calling component calls a functionality, so as to determine whether a component of the said map is able to supply the functionality called up.
23. A process as claimed in the preceding claim, wherein it is the said dependency manager components (GD) of automatic component search which are able to consult the said map.
24. A process as claimed in one of the preceding three claims, wherein the said map is updated in real time during the operation of the system, as a function of the components loaded into the system.
25. A process as claimed in one of the preceding claims, wherein each component can be associated with a level of privileges which conditions the possibilities of access of the component to other components, as a function of the respective levels of privileges of the said other components.
26. A process as claimed in one of the preceding claims, wherein means are provided for automatically unloading each component where the
-66-

27. functionality which it offers is no longer necessary for the operation of the computer projects.
27. A process as claimed in the preceding claim, wherein the said means comprise a usage counter for each component.
28. A process as claimed in the preceding claim, wherein the said counter counts the number of components which import a functionality of the component with which the counter is associated, and the said component is unloaded as soon as its usage counter has decreased to zero.
29. A process as claimed in the preceding claim, wherein there is provided dependency manager components (GD) for automatically freeing the resources used by the said unloaded component.
Dated this 13th day of December, 2002.
[RITUSHKA\NEGI)
OF REMFRY 8B SLAGAR
ATTORNEY FOR THE APPLICANT(S)
-67-