class MY_API Aplication
{
   struct App_imp   *imp_;
public:
   int someValue_get();
};

Monolithic kernels vs. microkernels

Monolithic kernels are often preferred over microkernels due to the lower level of complexity of dealing with all system control code in one address space. For example, XNU, the Mac OS X kernel, is based on Mach 3.0 + BSD in the same address space in order to cut down on the latency incurred by the traditional microkernel design.

In the early 1990s, monolithic kernels were considered obsolete. The design of Linux as a monolithic kernel rather than a microkernel was the topic of a famous flame war (or what then passed for flaming) between Linus Torvalds and Andrew Tanenbaum; a summary is available online.

There is merit in both sides of the arguments presented in the Tanenbaum/Torvalds debate.

Monolithic kernels tend to be easier to design correctly, and therefore may grow more quickly than a microkernel-based system. There are success stories in both camps. Microkernels are often used in embedded robotic or medical computers because most of the OS components reside in their own private, protected memory space. This is not possible with monolithic kernels, even with modern module-loading ones.

Although Mach is the best known general-purpose microkernel, several other microkernels have been developed with more specific aims. L3 was created to demonstrate that microkernels are not necessarily slow. L4 is a successor to L3 and a popular implementation called Fiasco is able to run Linux next to other L4 processes in separate address spaces. There are screenshots available on freshmeat.net showing this feat. A newer version called Pistachio also has this capability.

QNX is an operating system that has been around since the early 1980s and has a very minimalistic microkernel design. This system has been far more successful than Mach in achieving the goals of the microkernel paradigm. It is used in situations where software is not allowed to fail. This includes the robotic arms on the space shuttle to machines that grind glass where a tiny mistake may cost hundreds of thousands of dollars.

Many believe that since Mach basically failed to address the sum of the issues that microkernels were meant to solve, that all microkernel technology is useless. Mach enthusiasts state that this is a closed-minded attitude which has become popular enough that people just accept it as truth.

void node_doWork( DataNode &node )
{
   DataNode child( node, "relative/path/to/child/node" );
   int x = child.someVal_get();
}

// а когда все через интерфейсы:
void node_doWork( IDataNode &node )
{
    IDataNode *child = node.child_open("relative/path/to/child/node");
    int x = child->someVal_get();
    child->close();
}

// казалось бы все тоже самое, а когда есть сборка мусора, тогда еще и не надо заботится о child->close()

// Однако вот еще другой пример:
void node_doWork( DataNode &node )
{
   MyCoolDataNode child( node, "relative/path/to/child/node" );
   int x = child.someVal_get();
   child.myWork();
}

class MY_API MyClass
{
   struct MyClass_imp  *imp_; // это реализация, можно менять как угодно
public:
   void foo(); // а это интерфейс
   void bar(); // руками не трогать!
};

// где MY_API - это __declspec(dllexport/dllimport)

A>>Не совсем понимаю — и причём тут двоичная совместимость ???

// отдельный MuClass.h
class IMyClass {
public:
   virtual void f1() = 0;
   virtual void f2() = 0;
};

// проект DLL
class MyClass : public IMyClass {
public:
   virtual void f1() {
     // your implementation
   }

   virtual void f2() {
     // your implementation
   }
};

void* loadClass() {
  return new MyClass();
}

Ядро собирается в одну большую махину без намеков на компоненты. Например, драйвер можно выдрать из ядра только если поставить дефан в исходниках и перекомпилировать ядро.

//---------------------------------------------------------------------------
// GDI+ classes for forward reference
//---------------------------------------------------------------------------

class Graphics;
class Pen;

...

//---------------------------------------------------------------------------
// Private GDI+ classes for internal type checking
//---------------------------------------------------------------------------
class GpGraphics {};
class GpBrush {};
class GpTexture : public GpBrush {};

...


//--------------------------------------------------------------------------
// Pen class
//--------------------------------------------------------------------------

class Pen : public GdiplusBase
{
public:
    friend class GraphicsPath;
    friend class Graphics;

    Pen(IN const Color& color, 
        IN REAL width = 1.0f)
    {
        Unit unit = UnitWorld;
        nativePen = NULL;
        lastResult = DllExports::GdipCreatePen1(color.GetValue(),
                                    width, unit, &nativePen);
    }

...

protected:
   GpPen* nativePen;         // здравствуй пимпл :)
    mutable Status lastResult;
};

public class Control : Component, UnsafeNativeMethods.IOleControl, UnsafeNativeMethods.IOleObject, 
UnsafeNativeMethods.IOleInPlaceObject, UnsafeNativeMethods.IOleInPlaceActiveObject, 
UnsafeNativeMethods.IOleWindow, UnsafeNativeMethods.IViewObject, UnsafeNativeMethods.IViewObject2, 
UnsafeNativeMethods.IPersist, UnsafeNativeMethods.IPersistStreamInit, UnsafeNativeMethods.IPersistPropertyBag, 
UnsafeNativeMethods.IPersistStorage, UnsafeNativeMethods.IQuickActivate, ISupportOleDropSource, IDropTarget, 
ISynchronizeInvoke, IEnablable, IWin32Window, IArrangedElement, IBindableComponent, IComponent, IDisposable

/**************************************************************************\
*
* Copyright (c) 1998-2001, Microsoft Corp. All Rights Reserved.
*
* Module Name:
*
* Gdiplus.h
*
* Abstract:
*
* GDI+ public header file
*
\**************************************************************************/

V>public class Control : Component, UnsafeNativeMethods.IOleControl, UnsafeNativeMethods.IOleObject, 
V>UnsafeNativeMethods.IOleInPlaceObject, UnsafeNativeMethods.IOleInPlaceActiveObject, 
V>UnsafeNativeMethods.IOleWindow, UnsafeNativeMethods.IViewObject, UnsafeNativeMethods.IViewObject2, 
V>UnsafeNativeMethods.IPersist, UnsafeNativeMethods.IPersistStreamInit, UnsafeNativeMethods.IPersistPropertyBag, 
V>UnsafeNativeMethods.IPersistStorage, UnsafeNativeMethods.IQuickActivate, ISupportOleDropSource, IDropTarget, 
V>ISynchronizeInvoke, IEnablable, IWin32Window, IArrangedElement, IBindableComponent, IComponent, IDisposable
V>