我在之前的一篇文章中谈到了使用网络接入点的问题：http://blog.csdn.net/pknife/archive/2008/05/21/2467602.aspx
另外的一篇文章演示了如何创建cmwap接入点：http://blog.csdn.net/pknife/archive/2008/05/22/2469126.aspx
另外，关于mobile 开发相关网页：http://hi.baidu.com/peter_zb/blog/item/030bd56129f1fc4debf8f899.html
不过，总是觉得什么地方不对劲，说得不清不楚。精心下来仔细研究了一番，有新的收获。
曾经认为ConnMgrEnumDestinations函数得到的就是网络接入点。是的，现在也可以这么说，可是不准确。就像C++中的引用一样，我认为是它个别名。看看使用这个函数得到的名称：Internet 设置、WAP、WAP网络、安全 WAP 网络、单位设置、默认 Internet 设置、默认单位设置。对于GPRS，除了自建的接入点，我们常用的是Internet 设置和WAP，可认为是cmnet和cmwap接入点，机器出厂就设置好了。
ConnMgrEnumDestinations函数使用的参数，定义如下：
typedef struct _CONNMGR_DESTINATION_INFO
{
GUID guid; // @field GUID associated with network
TCHAR szDescription[CONNMGR_MAX_DESC]; // @field Description of network
BOOL fSecure; // @field Is it OK to allow multi-homing on the network
} CONNMGR_DESTINATION_INFO;
显然，从这里得不到是否为cmwap或cmnet的标记，也得不到代理服务器信息。传说中的ConnMgrProviderMessage似乎不干活，难道就含混晦涩地通过查询注册表的方法得到更多信息？心不甘情不愿。
快进入重点了。
使用ConnMgrQueryDetailedStatus函数。用法如下：
DWORD dwSize = 0;
HRESULT hr = E_FAIL;
hr = ConnMgrQueryDetailedStatus(NULL, &dwSize);
if(STRSAFE_E_INSUFFICIENT_BUFFER != hr)
{
return hr;
}
LPBYTE pBuffer = new BYTE[dwSize];
if(NULL == pBuffer)
{
return E_OUTOFMEMORY;
}
hr = ConnMgrQueryDetailedStatus((CONNMGR_CONNECTION_DETAILED_STATUS*)pBuffer, &dwSize);
if(S_OK == hr)
{
CONNMGR_CONNECTION_DETAILED_STATUS* cmStatus = (CONNMGR_CONNECTION_DETAILED_STATUS*)pBuffer;
while(NULL != cmStatus)
{
if(CM_CONNTYPE_CELLULAR == cmStatus->dwType)//表示为GPRS连接
{
//该干哈干哈
}
cmStatus = cmStatus->pNext;
}
}
delete []pBuffer;
注意cmStatus->dwType为CM_CONNTYPE_CELLULAR才表示为GPRS连接。如上，通过cmStatus->szDescription，我们可以得到诸如GPRS连接互联网、拨号连接互联网、移动梦网(GPRS)、移动梦网拨号甚至于类似null-corp-{18AD9FBD-F716-ACB6-FD8A-1965DB95B814}等奇怪的名称。
看看CONNMGR_CONNECTION_DETAILED_STATUS的定义：
typedef struct _CONNMGR_CONNECTION_DETAILED_STATUS
{
struct _CONNMGR_CONNECTION_DETAILED_STATUS* pNext;
DWORD dwVer; // @field Structure version; current is CONNMGRDETAILEDSTATUS_VERSION.
DWORD dwParams; // @field Combination of CONNMGRDETAILEDSTATUS_PARAM_* values.
DWORD dwType; // @field One of CM_CONNTYPE_* values.
DWORD dwSubtype; // @field One of CM_CONNSUBTYPE_* values.
DWORD dwFlags; // @field Combination of CM_DSF_* flags.
DWORD dwSecure; // @field Secure level (0 == not-secure) of connection.
GUID guidDestNet; // @field GUID of destination network.
GUID guidSourceNet; // @field GUID of source network.
TCHAR* szDescription; // @field Name of connection, 0-terminated string or NULL if N/A.
TCHAR* szAdapterName; // @field Name of adapter, 0-terminated or NULL if N/A.
DWORD dwConnectionStatus; // @field One of CONNMGR_STATUS_*.
SYSTEMTIME LastConnectTime; // @field Time connection was last established.
DWORD dwSignalQuality; // @field Signal quality normalized in the range 0-255.
CONNMGR_CONNECTION_IPADDR* pIPAddr; // @field Available IP addrs, or NULL if N/A.
// End of version 1 fields.
} CONNMGR_CONNECTION_DETAILED_STATUS;
黑乎乎一堆参数，好吓人啊。还好，我们要用的大概只有szDescription和guidDestNet这两个。guidDestNet可用于ConnMgrEstablishConnectionSync，szDescription的用处接着瞧。
看到这，有没有人快晕了？快了，就快到达胜利的彼岸了。
我们最终还是要用到DMProcessConfigXML这个函数。(奇怪了，这个函数怎么是万能的？)
以下获取接入点的APN：
TCHAR* szXMLin =
L"
L"
L"
L"
L"
L"
L"
L"
L"
LPWSTR pszwXMLout = NULL;
HRESULT hr = DMProcessConfigXML(szXMLin, CFGFLAG_PROCESS, &pszwXMLout);
//在此处理pszwXMLout
if ( pszwXMLout )
{
delete [] pszwXMLout;
pszwXMLout = NULL;
}
上面的GPRS连接互联网对应之前得到的szDescription。
如果一切顺利的话，返回pszwXMLout应该如下： value="cmnet"/>
没错，APN就包含在value中，的确是cmnet。
换成移动梦网(GPRS)试试，我们可以得到APN为cmwap。
注意：此处如果使用ConnMgrEnumDestinations得到的szDescription，不能获取正确的APN信息。
如果要得到代理服务器信息，szXMLin如下：
TCHAR* szXMLin =
L"
L"
L"
L"
L"
L"
L"
此处的名称并不能与ConnMgrQueryDetailedStatus得到的名称相对应，我也不知道怎么解释。有兴趣的同学可以打开注册表看看：HKEY_LOCAL_MACHINE\Comm\ConnMgr，研究一下。好在我们知道对于cmwap，移动的代理服务器为10.0.0.172。
关于CM_Networks、CM_GPRSEntries、CM_ProxyEntries，以及要了解更多与此相关的XML格式，可参考MSDN:
(英文版)ms-help://MS.MSDNQTR.v80.en/MS.MSDN.v80/MS.MOBEMBDEV.v10.en/guide_ppc/html/ppc_wcconconfiguringconnectionmanagerforpocketpcozup.htm
(中文版)ms-help://MS.MSDNQTR.v80.chs/MS.MSDN.v80/MS.MOBEMBDEV.v10.en/guide_ppc/html/ppc_wcconconfiguringconnectionmanagerforpocketpcozup.htm
转载自：http://blog.csdn.net/ccyy2002/archive/2009/08/28/4493209.aspx