精品国产乱码久久久久久呢,久久天天日天天操综合伊人av,日韩十八禁一区二区久久

C++ library series -- in the MFC multiple-thread environment, how to quit worker-thread safely which begins with AfxBeginThread

flagman — Sun, 11 Dec 2011 12:35:00 GMT

In the MFC environment, normally, thread should be launched with AfxBeginThread for taking usage of MFC multiple-thread mechanism; In such mechanism, those datastructures, such as AFX_MODULE_STATE, would be used by MFC framework to maintain related thread information. It runs well when threads, launched with AfxBeginThread, quit before the main thread, which is responsible for initializing C run-time, but if such main thread quit before any other thread launched by AfxBeginThread, the current application would crash.

Such crash comes from the _afxThreadData (CThreadSlotData* _afxThreadData, which is defined in AFXTLS.cpp as global data structure) has been destructed while the main thread quits and it will invoke related function to clean up global data structures, including _afxThreadData definitely.

Consequently, serious developer should prepare for such case (other worker thread quits before main thread).

The reasonable resolve for such issue, would ensure any other threads should quit before the main thread.

.h file

/////////////////////////////////////////////////////////////////////////////

// CSafeEnterLeaveThread thread

class CSafeEnterLeaveThread : public CWinThread

{

DECLARE_DYNCREATE(CSafeEnterLeaveThread)

protected:

CSafeEnterLeaveThread(); // protected constructor used by dynamic creation

// Attributes

public:

// Operations

public:

// Overrides

// ClassWizard generated virtual function overrides

//{{AFX_VIRTUAL(CSafeEnterLeaveThread)

public:

virtual BOOL InitInstance();

virtual int ExitInstance();

//}}AFX_VIRTUAL

// Implementation

protected:

virtual ~CSafeEnterLeaveThread();

// Generated message map functions

//{{AFX_MSG(CSafeEnterLeaveThread)

// NOTE - the ClassWizard will add and remove member functions here.

//}}AFX_MSG

DECLARE_MESSAGE_MAP()

};

.cpp file

/////////////////////////////////////////////////////////////////////////////

// CSafeEnterLeaveThread

IMPLEMENT_DYNCREATE(CSafeEnterLeaveThread, CWinThread)

CSafeEnterLeaveThread::CSafeEnterLeaveThread()

{

}

CSafeEnterLeaveThread::~CSafeEnterLeaveThread()

{

}

BOOL CSafeEnterLeaveThread::InitInstance()

{

// TODO: perform and per-thread initialization here

ASSERT(this->m_hThread);

CMainApp::RegisterMFCThread(this->m_hThread);

return TRUE;

}

int CSafeEnterLeaveThread::ExitInstance()

{

// TODO: perform any per-thread cleanup here

ASSERT(this->m_hThread);

CMainApp::UnRegisterMFCThread(this->m_hThread);

return CWinThread::ExitInstance();

}

BEGIN_MESSAGE_MAP(CSafeEnterLeaveThread, CWinThread)

//{{AFX_MSG_MAP(CSafeEnterLeaveThread)

// NOTE - the ClassWizard will add and remove mapping macros here.

//}}AFX_MSG_MAP

END_MESSAGE_MAP()

And in the CMainApp,

set g_ThreadHandleSet;

HANDLE g_ThreadHandleArray[MAXIMUM_WAIT_OBJECTS];

CCriticalSection g_csGlobalData;

void CAccgbApp::CheckAllOtherMFCThreadsLeave()

{

int count = g_ThreadHandleSet.size();

if (count == 0) return;

set::iterator it;

int idx = 0;

for (it = g_ThreadHandleSet.begin(); it != g_ThreadHandleSet.end() && idx < MAXIMUM_WAIT_OBJECTS; it++, idx++)

{

g_ThreadHandleArray[idx] = *it;

}

if (count > idx) count = idx;

::WaitForMultipleObjects(count, g_ThreadHandleArray, TRUE, INFINITE);

}

void CAccgbApp::CleanupGlobalData()

{

g_csGlobalData.Lock();

g_ThreadHandleSet.empty();

g_csGlobalData.Unlock();

}

BOOL CAccgbApp::RegisterMFCThread(HANDLE hThread)

{

if (hThread == NULL) return FALSE;

g_csGlobalData.Lock();

if (g_ThreadHandleSet.find(hThread) == g_ThreadHandleSet.end())

g_ThreadHandleSet.insert(hThread);

g_csGlobalData.Unlock();

return TRUE;

}

void CAccgbApp::UnRegisterMFCThread(HANDLE hThread)

{

if (hThread == NULL) return;

g_csGlobalData.Lock();

if (g_ThreadHandleSet.find(hThread) != g_ThreadHandleSet.end())

g_ThreadHandleSet.erase(hThread);

g_csGlobalData.Unlock();

}

flagman 2011-12-11 20:35 发表评论

操作�pȝ��怎么�Ҏ(gu��)��一个HWND句柄�Q�找到相应的代码

flagman — Mon, 04 Apr 2011 06:16:00 GMT

�?�?�?的大作中提到: �?/em>

: 比如我有一个CMyButton的类�Q�我现在有他的一个handle
: �~�译器怎么�Ҏ(gu��)��q�个句柄扑ֈ�CMyButton的代码的�Q?/em>

�?�?某某的大作中提到: �?br>: �q�个和OS/Compiler没关�p�，是库��L(f��ng)��作用
: 以从某个文章里看的，说MFC用了(ji��n)一个大map�Q�没验证�q?br>: 有本讲GDI的书里，用了(ji��n)WNDCLASS里的extra bytes来实现的�q�个映射

MFC的应用里�Q�每个MFC�U�程�Q�必��要使用MFC方式启动的线�E�）(j��)都维护有一个MFC object和HWND之间�?/p>
mapping�Q�整个MFC框架��是使用�q�个机制来实现应用��C++对象和系�l��原生�H�口内核对象之间的关联；

因�ؓ(f��)�q�个mapping是以�U�程为单位来�l�护的，每个�U�程间互不关联，所以，一个应用里对于涉及(qi��ng)UI�H�口�?/p>
��d��最好是都放在同一个线�E�里面，一般就是当前进�E�的�ȝ��E�，否则可能出现MFC object和HWND之间

兌��不上的问题，而且�q�样的问题还很隐蔽�?br>

至于WNDCLASS�l�构自带的extra bytes域，是以前缺乏应用框架的时代�Q��用Win32 API直接开发时�Q�让每个

�H�口�c�（�q�里的类�Q�不是C++ class的概念，而是Windows�pȝ��H�口定义时的一�U�数据结构）(j��)都能有个�?/p>
带一些额外的自定义数据的�I�间�Q�这个空间往往被用来存放与当前�H�口�cȝ��关的用户数据�Q�通常是指�?/p>
某个内存区域的指针，当程序操作这个属于这个窗口类的窗口时��可以根据这个附带的自定义数据（�?/p>
者指针）(j��)来操作对应的兌��自定义数据；很多后来出现的框�Ӟ��也都使用�?ji��n)这个extra bytes域，来存�?/p>
框架本��n的一些和�H�口�cȝ��兌��的数据结构。从目前��势看，直接使用WNDCLASS以及(qi��ng)extra bytes的可�?/p>
性是微乎其微�?ji��n)，但是如果要做好原生应用的开发，很多底层的实现细节最要还是要知道一下，以便�?/p>
优化�l�构和性能�Q�以�?qi��ng)出错时的调试处理；因��?f��)无论是Winform/WPF�Q�还是跨�q�_��的WTL/QT/WxWindows�{?/p>
�{�新型的机制或者框架、类库，只要是在Windows�q�_��上搭建的�Q�那都是��Z��前面说过的这套最基本也是

最核心(j��)的Win32 API基础之上�?/p>

flagman 2011-04-04 14:16 发表评论

flagman — Mon, 13 Dec 2010 01:02:00 GMT

Fusion is one of the most importants features among ones in the runtime implementation of CLI.

In the fusion, or any other components or modules, how to retrieve the execution engine instance and how to generate such engine?

UtilExecutionEngine, implemented as COM object, support Queryinterface/AddRef/Release, and exposed via interface IExecutionEngine.

With SELF_NO_HOST defined,
BYTE g_ExecutionEngineInstance[sizeof(UtilExecutionEngine)];
g_ExecutionEngineInstance would be the singleton instance of current execution engine,

otherwise, without SELF_NO_HOST, the 'sscoree' dll would be loaded and try to get the exported function, which is named 'IEE' from such dll. Here, it is the well-known shim, in .net CLR, such module is named 'mscoree'. Further, if 'IEE' could not be found in such dll, system would try to locate another exported function, named 'LoadLibraryShim', and use such function to load the 'mscorwks' module, and try to locate the 'IEE' exportd functionin it.

It's very obvious that Rotor has implemented its own execution engine, but it also gives or make space for implementation of execution engine from 3rd party. Here, .net CLR is a good candidate definitely, Rotor might load the mscorwks.dll module for its usage.

PAL, PALAPI, for example, HeapAlloc, one famous WIN32 API, has been implemented as one PALAPI (defined in Heap.c), to make it possible that the CLI/Rotor be ported smoothly to other OS, such freebsd/mac os.

CRT routines are also reimplemented, such as memcpy, it has been implemented as GCSafeMemCpy

There're many macros in fuctions, such as SCAN_IGNORE_FAULT/STATIC_CONTRACT_NOTHROW/STATIC_CONTRACT_NOTRIGGER, they are for static analysis tool to scan, analyse and figour out the potential issues in code.

From view point of the execution model by CLI, the act of compiling (including JIT) high-level type descriptions would be separated from the act of turning these type descriptions into processor-specific code and memory structures.

And such executino model, in other word, the well-known 'managed execution', would defer the loading, verification and compilation of components until runtime really needs; At the same time, the type-loading is the key trigger that causes CLI's tool chain to be engaged at runtime. Deferred compilation(lead to JIT)/linking/loading would get better portability to different target platform and be ready for version change; The whole deferred process would driven by well-defined metadata and policy, and it would be very robust for building a virtual execution environment;

At the top of such CLI tool chain, fusion is reponsible for not only finding and binding related assemblies, which are via assembly reference defined in assembly, fusion also takes another important role, loader, and its part of functionality is implemented in PEAssembly, ClassLoader classes. For example, ClassLoader::LoadTypeHandleForTypeKey.

For types in virtual execution environment of CLI, rotor defines four kinds of elements for internal conducting,
ELEMENT_TYPE_CLASS for ordinary classes and generic instantiations(including value types);
ELEMENT_TYPE_ARRAY AND ELEMENT_TYPE_SZARRAY for array types
ELEMENT_TYPE_PRT and ELEMENT_TYPE_BYREF for pointer types
ELEMENT_TYPE_FNPTR for function pointer types

every type would be assigned unique ulong-typed token, and such token would be used to look up in m_TypeDefToMethodTableMap (Linear mapping from TypeDef token to MethodTable *)which is maintained by current module; If there it is, the pointer to method table of such type would be retrieved, or it would look up in the loader module, where the method table should exist in while it's JIT loaded, not launched from NGEN image;

And all the unresolved typed would be maintained in a hash table, PendingTypeLoadTable; Types and only those types that are needed, such as dependencies, including parent types, are loaded in runtime, such type is fully loaded and ready for further execution, and other unresolved types would be kept in the previous hash table.

flagman 2010-12-13 09:02 发表评论

flagman — Mon, 13 Dec 2010 00:57:00 GMT

关于�E�序设计语言本��n的设计有许多有趣的话题，比如�Q��ؓ(f��)何C++中的�c�L��员函数没有采用类似Java中的“全虚”设计�Q?br>
1) 从语�a�本��n设计上看�Q?br>效率定然是c++当初设计时考虑的重点之一�Q��D个例子，��Z��(ji��n)节省不必要的VTable开销�Q�ATL用template技术静(r��n)态�{换来模拟动态绑定以支持COM�Ҏ(gu��)��的实现�Q�和C的兼容，��VTable角度看，问题不大�Q�因为后者可以用函数指针数组来模拟；

2) 再从大多数应用中常见的类�l�承体系上看�Q?br>除了(ji��n)整个�l�承体系所�l�一开攑և�来的接口集（也就是由虚函数所�l�成�Q�，在��承体�pȝ��每个层面另外�?x��)有大量的其他辅助成员函敎ͼ�其数量通常比虚函数多的多）(j��)�Q�这些成员函数完全没必要设计成虚函数�Q?/p>
3) 从其他语�a�看，
即��较新的虚拟机语言C#(Java��是较老的虚拟��a�),反而定义了(ji��n)比C++更�ؓ(f��)严格更�ؓ(f��)昑ּ�的成员方法实现或覆盖或重载或新徏的规则；�q�是非常重要的对C++以及(qi��ng)Java设计思想的反思�?/p>
4) 从语�a�的适用场合看，
我们现在的讨论，�l�大多数情况下带有一个非帔R��要的默认前提�Q�那��是在用��h��模式下使用C++�Q�如果放宽这个约束，在内核模式下使用C++�Q�那情况又完全不同了(ji��n)�?br>引用下面�q�个文档的观点，http://www.microsoft.com/china/whdc/driver/kernel/KMcode.mspx
首先�Q�用��h��下非常廉�h(hu��n)几乎不用考虑的资源，在内�怸�是非常昂�늚��Q�比如内核堆栈一般就3个page�Q?/p>
在内�怸�能分��?paging)时必��M��证将被执行的所有代码和数据必须有效的驻留在物理内存中，如果�q�时需要多�ȝ��几张虚表以及(qi��ng)虚表指针那还是显得非常昂�늚��Q�同时编译器��函数�Q�模板等生成代码的方式，让开发�h员很隄��定要执行一个函数所需要的所有代码的所在位�|�，因此也无法直接控制用于安�|�这些代码的节（个�h认�ؓ(f��)可能通过progma segment/datasegment/codesegment对于代码和数据进行集中控�Ӟ��(j��)�Q�因此在需要这些代码时�Q�可能已�l�被page out�?ji��n)�?/p>
所有涉�?qi��ng)类层次�l�构�Q�模板，异常�{�等�q�样的一些语�a��l�构在内核态中都可能是不安全的�Q�最好是把类的��用限定�ؓ(f��)POD�c�，回到我们的主题虚函数�Q�也��是说内核态下�c�设计中没有虚函数�?/p>

flagman 2010-12-13 08:57 发表评论

flagman — Sat, 11 Dec 2010 03:19:00 GMT

�?某某提到: �?br>: 一台服务器装有windows server 2008 r2�Q�安�?6G内存�q�设�|?6G虚拟内存。最�q�在�q�行一个用C#�~�写的大规模计算�E�序时发玎ͼ�有很大一部分物理内存被莫名其妙地消耗了(ji��n)。资源监视器昄��该程序占用物理内存不�?G�Q�但是�ȝ��物理内存消耗接�q?0G�Q�可用物理内存仅�?G。随着�q?
: 除了(ji��n)�q�个�E�序之外没有其它�E�序大量占用内存。这个程序有大量��盘I(y��)O操作�Q�在�q�行中会(x��)不时地调用GC.Collect()以及(qi��ng)时清理不用的内存。这个实验中用到的一�p�d��E�序的结构基本相同，都会(x��)不时调用GC清理�Q�但其它�E�序的内存��用都正常�Q�只有这个程序会(x��)出现占用内存是实际��用的
: 请问��Z��么会(x��)出现�q�样莫名其妙多占用内存的情况呢？谢谢大家

�q�个既不是应用本�w�的bug�Q�也不是�pȝ��的memory leak�?/p>
当前资源监视器中关于�pȝ��物理内存�Q�有�q�么几个�l�计��，可用、缓存、��L��、已安装�Q�其�?�~�存"�q�项�Q�代表着已用于文件系�l�、网�l�等�{�子�pȝ��的数据缓冲存储的内存定w��Q�其中包含数量巨大的�ȝ��在物理内存中的数据页面。而这��L(f��ng)��物理内存消耗�ƈ没有归入��M��一个进�E�列表显�C�的�q�程所占用的物理内存。这��是��Z��么下面公式，

�q�程列表昄��的所有进�E�所占用的物理内存之�?+ 可用物理内存 < 物理内存��L��

�Q�成立的原因所在�?/p>
��D��q�一现象的原因，从这个大规模计算�E�序的行为描�q�看�Q�基本可以断定是�׃��以下两点�Q?br>1�Q�应用本�w�的大规模数据驻留物理内存，��D��parser.exe�q�程庞大的working set�Q?br>2�Q�大量频�J�的IO操作�Q�引起大量的物理内存为系�l�缓存所占用�Q?/p>
对于1),必须注意�Q�GC.Collect()只是讄��使能垃圾攉��的标志位�Q��ƈ没有立即启动垃圾攉��q�程�Q�这个过�E�的实际启动时刻由CLR来动态决议；

所以如果要获得��x��的托��内存的释放�Q��ƈ�q�一步释攄��理内存以减小当前�q�程的working set�Q�可以��用AppDomain�q�个.net下可以用来资源划分、获取和释放的，在概念上�q�似于轻量��q�程的编�E�语义；在AppDomain中获取的各种资源�Q�包括托��内存、加载其中的各个assembly以及(qi��ng)CCW�{�，在此AppDomain被释放时都被相应的及(qi��ng)旉��放（或者引用计数递减�Q��?/p>
对于2�Q�，重新观察先前的设计实现和模型�Q�考虑是否能把一些分散的IO操作合�ƈ��h��q�行�Q�比�?
for(long i=0; i < Count; ++i)
{
...
objIO.Operation(Data[i], 1);
...
}
修改�?br>for(long i=0; i < Count; ++i)
{
...
...
}
objIO.Operation(Data, Count);
�q�样对于提高应用的IO效率以及(qi��ng)提升�pȝ��~�存利用率应当会(x��)有帮助�?/p>

对于2�Q�，�pȝ��~�存随着�q�个大规模计��应用的�q�行而逐步增大�Q��ƈ最后导致整个系�l�无法获取的物理内存而无法��l�运行的现象�Q�估计即佉K��用了(ji��n)在上文提出的�Q�在应用�E�序代码中尽可能合�ƈIO操作�Q�减��IO�ơ数的方法，也不�?x��)改善系�l�缓存占用物理内存数量过大的问题。这个问题本质上是Windows操作�pȝ��本��n从NT时代到现在，一直存在的问题�Q�主要是围绕着Windows kernel中的Cache mananger以及(qi��ng)memory manager核心(j��)态组件的实现机制而��生的�?/p>
�Ҏ(gu��)��目前的Cc(对Cache manager的简�U�ͼ�在WindowsResourceKernel开源项目中�Q�Cache manager相关模块的函数都以Cc作�ؓ(f��)前缀�Q�比如CcCopyRead�Q�CcFlushCache�{�，Memory manager也同��L(f��ng)��U�Mm)的实现机�Ӟ��所有对文�g�pȝ��的访问，包括本地和网�l�，都会(x��)首先由Cc对相关页面作�~�存映射�Q�随着频繁的IO的操作，被Cc�~�存的页面也�q�速递增�Q�而被�~�存��面占用多少物理内存�Q�这是由Windows kernel中的Memory manager军_��。目前在64位��^��C��Q�系�l�缓存最高可�?TB�Q�所以这个应用进�E�的�q�行中出现分�?G的缓存是完全可能的，但同旉��题也随之而来�Q�那��是�pȝ��~�存占用�?ji��n)过多的物理内存�Q�导致其他进�E�以�?qi��ng)内核本�w�无法申误��够的物理内存�Q�最后致使系�l?#8220;僉|��”�Q?/p>
对于�q�个问题�Q�微软提供了(ji��n)“Microsoft Windows Dynamic Cache Service”工具来提供对�pȝ��~�存的工作集working set定w��Q�也��是�ȝ��物理内存的大��）(j��)的控�Ӟ��q�个工具主要是对SetSystemFileCacheSize的封装，可以讄��pȝ��~�存定w��的上下限�?/p>
但这只是一�U��(f��)时的解决�Ҏ(gu��)��Q�因为应用虽然可以通过上面�q�个Dynamic Cache Service来设�|�和限制�pȝ��~�存定w��的大��，但是如何��定�~�存定w��大小的非常困难，如果�q�小�Q�所有IO性能大受影响�Q�整个Cc如同虚设�Q�如果过�?�{��h(hu��n)于不受限)�Q�那么系�l�缓存占用过多物理内存导致系�l�僵�ȝ��现象��׃��(x��)重现�?/p>
所以从�Ҏ(gu��)��上看�Q�这个问题应由包括Cc和Mm在内的整个Windows kernel作出完整一致的调整�Q�但从目前的实现看要完成整个�Ҏ(gu��)��改动很大�Q�据�U�这个改�q�可能会(x��)考虑包含在Win7中发布�?/p>
Microsoft Windows Dynamic Cache Service下蝲,
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=e24ade0a-5efe-43c8-b9c3-5d0ecb2f39af&displaylang=en

Microsoft Windows Dynamic Cache Service相关的介�l�，
http://blogs.msdn.com/b/ntdebugging/archive/2009/02/06/microsoft-windows-dynamic-cache-service.aspx

flagman 2010-12-11 11:19 发表评论

flagman — Wed, 01 Dec 2010 13:28:00 GMT

最�q�正好在思考系�l�API设计中考量的一些问题，

【某�|�友讨论到�?br>: 那地址是不是同一个地址呢。我现在的理解是�q�样的，假设有巨大的真实内存。windows首先��高2G的内存自己占�?ji��n)，用作各种内核对象。这2G内存�׃�n�l�每个进�E�，但进�E�不能直接访问，只能通过windows�l�定的函数访问�?br>: 然后每个�q�程都给�?G内存�Q�进�E�如果创��q��对象��放到自己那2G内存里面�Q�如果要建立内核对象��放到共享的那高2G里面厅R�?br>: 所以不同进�E�如果可以访问高2G内存的话�Q��Q何进�E�访问到同一个高地址实际上都是访问到同一个对象。但如果讉K��?G地址的话�Q�不同进�E�是对应不同的对象的�?br>

在不同的�q�程中，询问同一个内核对象的实际地址�Q�无论是�U�性地址�q�是物理地址�Q�，是无意义的：(x��)

首先�Q�内核对象只能由在内核态下的例�E�才能直接访问，在我们日常的代码中，所调用的Windows API�Q�比如CreateFile, �Q�注意调用刚开始时是处于用��h��下的）(j��)�Q�一般都�?x��)在ntdll.dll中找到对应的内核函数或例�E�，接着�pȝ��切换到内核态，开始调用实际对应的内核函数(KiCreateFile)�Q�这个时候才�?x��)去讉K��内核对象的实际地址�Q�然后徏立一个该内核对象对应当前�q�程的Handle�Q��ƈ把它�q�回�l�caller�Q�同时切换回用户态；因此�Q�对于用��h��程序来��_(d��)��只要且只能知道该内核对象在当前进�E�中的对应的Handle��可以对其进行操作了(ji��n)�Q?/p>
其次�Q�这��L(f��ng)��设计是出于对OS核心(j��)数据�l�构�Q�当然包括我们正在讨论的内核对象�Q�的保护�Q�如果用��h��程序可以轻易的获取内核数据�l�构的实际地址�Q�那么对于整个OS的安全和�E�_��昄��构成很大的问题；一个用��h��的误操作可以轻易的引�v整个OS的崩溃，而有�?ji��n)这一层的保护�Q�崩溃的只是当前�q�程而不是整个系�l�；

接着上面�q�点�Q�也可以看出�Q�内核对象的如此设计辑ֈ��?ji��n)接�U�OS本��n的��^滑演�q�的目的。从Windows 3.0�?5/98�Q�从NT到Win2k/XP�Q�再到眼下的Vista/Win7�Q�W(xu��)indows操作�pȝ��本��n发生�?ji��n)巨大的变化和进步，采纳了(ji��n)无数的新技术新�Ҏ(gu��)��Q�但是它基本的系�l�应用编�E�接口，也就是我们所熟知的windows API�Q�却�q�没有发生太大的改变�Q�很多Win 3.0 �q�个16位OS时代的程序代码只要当初设计规范编码规范，�E�许修改��可以在最新版的OS上运行如飞；是什么做��C��(ji��n)�q�些�Q�也��是所谓的极�ؓ(f��)重要的向后兼�Ҏ(gu��)��，我个��为，把操作系�l�的重要/主要功能抽象成内核对象，�q��过一套极为solid的API暴露出来�Q�达成了(ji��n)�q�个目标�?/p>
�q�是一�U�更高层�ơ上的面向对象，把实现的�l�节�Q�把�pȝ��的复杂，��单而优雅的��装�?ji��n)�v来。你只要调用CreateFile��d��个文件或��道或邮槽，不用担心(j��)当前OS是Windows 3.0�q�是Win7�Q�获得的Handle�Q�你也不用去兛_��(j��)它以�?qi��ng)它所指向的内核对象是Windows 3.0的实现还是Win7的实现�?/p>
Windows上所有的�_�ֽ�几乎都是��Z��q�套通过内核对象概念抽象�q�暴露的API基础之上�Q�COM/OLE�Q�这个二十年前震撼性的ABI和IPC范畴的技术规范，其中很多的设计思�\也是植根于内核对象的设计理念�Q�如COM对象的引用计数和内核对象引用计数�Q�IUnknown和W(xu��)indows Handle(前者是指向某个二进制兼容的�l��g对象�Q�后者引用或间接指向某个内核对象�Q�都是对于某个复杂概�늚�一致性抽象表�q?�Q�等�{�；

十年前的.net�Q�本来是作�ؓ(f��)COM的升�U�版本推出，把COM/OLE的实现复杂性封装在�?ji��n)虚拟机�q�_��CLR里面�Q�而从�q�个虚拟机的开源实现SSCLI�Q�我们可以看到大量的COM机制�?net的具体实现里面�v�?ji��n)�D��重的作用。在�q�些VM中大量symbol有着COR的前�~�或者后�~��Q�COR指代什么？Common Object Runtime, 原来CLR/SSCLI的设计思�\也是把OS通过虚拟机VM的�Ş式，�q��过common object向应用程序暴露功能�?/p>
��结一下，
OS内核对象API�Q�三十年前系�l��别的对象抽象�Q?br>COM/OLE�Q�二十年前二�q�制�l��g�U�别的对象抽象；
.net/CLR, 十年前虚拟机�q�_��U�别的对象抽象；

写到�q�里倒是引�v�?ji��n)我其他的一些思考，软�g工业界一直以来对面向对象OO是热火朝天，特别是语�a�层面�Q�从C++/Java/C#到Python/JScript�Q�不一而��Q?/p>
但是我们有没有从�Ҏ(gu��)��性的设计理念上对面向对象�Q�察�U�雅�a��?ji��n)呢�Q?/p>
如果现在设计Windows�q�套API的�Q务放在大安��前，�?x��)采用内核对�?Handle�Ҏ(gu��)��q�是直接指向OS内部数据�l�构的方式来暴露功能�Q?/p>
从三十年前的�q�套API的设计中�Q�我们真的可以学到很多�?/p>

flagman 2010-12-01 21:28 发表评论