NERvSDK provides you a suit of SAO Utils plug-in developing package which include essential headers, libraries and some useful debugging tool kits. Developers only need to link against 2 libraries, writing 1 cpp file and few lines to implement a minimum plug-in for SAO Utils.

NERvGear, the core of SAO Utils, use the Microsoft COM(Component Object Model) technology to implement plug-in platform. But it entirely does not depend on the Windows COM Component, actually we implement a DLL COM server which is suitable for plug-ins and cooperating development ourselves. This means developing plug-ins or components for SAO Utils is platform-independent in essence, and we can enjoy the flexibility and infinite possibility of COM technology.

If you’re already managed a few of COM basic knowledge then developing a plug-in for SAO Utils would be quite an easy thing, but even if you’re a newbie of C++ developer that won’t make a big problem, just take a look at the COM design, then I believe you’ll love it and become your handy knife :) Because of the plug-in platform is based on the COM technology, you can convert the existed COM codes into SAO Utils, indeed, they(The Windows COM components and The SAO Utils Component) are almost binary compatible. But SAO Utils Components does not require you to record your DLLs into The Windows Registry, NERvGear will manage and register them dynamically.

This guideline is divided in the following sections:

You could also find the latest version of these tutorials at NERvSDK Wiki

Concepts

Plug-in

A plug-in is the basic managing unit of NERvGear, and also the minimum unit that the user can manage(Enabling, Disabling, Add or Deleting plug-ins). Generally, a plug-in could provide user a desktop widget, an extension for the launcher, providing basic components for other plug-ins or even combining all of them. A plug-in must be implemented by a single DLL, but one plug-in could register or use multiple components.

Component

The implementation of a set of specific functions that are collectively called component. The definition of component is a little bit different from the Microsoft COM’s one, they would like to combine both component and component implementation into a component concept. One (type of) component could be registered by multiple objects implementing by different developers.

Object

Object, or exactly the component object, is an implementation for a specific component. For C++ or OO languages, a component object is generally implemented by one class. Anyone can develop component objects(except for some core components) for a defined component. A component object can provide multiple interfaces, or even expose interfaces from other objects to other component users using the aggregation technology.

Interface

Interface is the atom unit of the COM modal. Component objects can communicate with each other only with interfaces rather than cut it into functions, this is the reason why we call interface as atom. Once an interface is defined, or released to public, it is NOT allowed to be modified, just like an atom.

IDs

NERvGear uses three types of IDs to identify things, and these IDs are defined as NERvGear::UID in our COM framework.

IDs	Naming
Component ID	ID_C*
Interface ID	ID_I*
Object ID	ID_O*
Plug-in ID	ID_P*

Each ID must be unique: Different types of components cannot use a same component ID, objects that implementing same (or different) components must have a different object ID, and the same as interface IDs.

Component ID (Class ID)

Generally component ID is equivalent to the CLSID of the traditional COM modal, but we reserve a part of CLSID for cataloging components by purpose.(Combining with CATIDs?)

Object ID

Object ID is unique to our COM modal, for identifying components writing by different people, and give the final component user a choice between default and specified implementation by a ID. Actually, a plug-in ID is an object ID in essence, therefore a plug-in(object) implemented by someone is an implementation for a component call “SAO Utils Plug-in” indeed, but we will insulate them for distinguishing.

Interface ID

Interface ID is completely same as IID of traditional COM, also requiring to reserve existing interfaces defined by windows, such as the IID and definition of IUnknown interface defined in SAO Utils is completely an equivalent to the windows header. Different version of a interface should be regarded as a new interface, so one interface in different version must have a different interface ID.

Requirements

Platforms:

Windows 2000/XP/Vista/8/8.1/10 32/64 bit

Compilers / IDE:

Visual Studio 2003(VC7) and above
GCC(with C++ support) 4.7 and above

Author

Joshua (GPBeta)

Websites

Studio GPBeta: http://www.gpbeta.com/ Community: http://bbs.gpbeta.com/

Date

Sep 1, 2015