多檢查一下程序吧，這個類用了很久了，酒精考驗了，類似Read、Write之類的就不用問了，肯定沒問題的。
抱歉，那段代碼是支持WINCE，他的代碼是只支持WINDOWS的@bird
例子是有BUG的，必須用1.51的版本，或者按照本文的進行修正。
當中間包含有0x00 的數據時不可以使用ReadString
應使用Read
C++寫的類，當然性能是正常的。俺這么多年從來就沒有聽說性能問題。
什么叫慢？你的代碼片段不足以讓人了解你要做什么，如何測試，DLL和主模塊如何搭配，業務的東西你要自己做的，我不對業務做咨詢。
你如果能夠準確明了的描述問題和想法，我有時間還是會做解答，但不承諾。
只對CnComm本身問題做咨詢。
注意超時控制，如果你想要接收到數據再返回，
要用精確控制。
比如14個字節的應答包
void OnReceive()
{
for (1..14)
Read(&c, 1);//一個字節一個字節讀
或者Read(&c, 14);//直接控制恰當的字節數，而不是一味的用1024
或則Read函數會一直等到1024個字節，但實際上它等不到，因為根本不可能應答1024字節，它就會等個幾百毫秒超時了在返回，可能這就是你說的慢，不知道我的理解真不正確？
另外你的模式有問題，
while(1)
{
Sleep(1); //暫停1毫秒
if(intReceived==1 && (BYTE)buffReceived[0]== 0x01)
{
return true;
}
}
不應該這樣用你可以用通知方式會更理想，循環很浪費CPU，直接WaitEvent更好一些
}
re: CnComm勘誤及Faq（將會持續更新） llbird 2009-05-15 22:57
Comm_.Write(buffer);
不返回發送數量是因為重疊IO的作用。
系統將在后臺幫你把數據發送出去，由于串口是低速設備，如果你要等待返回發送數量將浪費系統資源，所以函數直接返回，以便你繼續操作，這樣并行操作，提高系統利用率
re: CnComm勘誤及Faq（將會持續更新） llbird 2009-05-15 22:52
memcpy(NewBlock(dwSize)->P_, ((LPBYTE)lpBuf) + dwCopy, dwTemp);//
這里忘記把const屬性去掉
這個不知道，那還是要屏蔽的，這個大家可以自行改一下，不屏蔽會造成后面的語句失效。
if(!CN_ASSERT(::SetupComm(hComm_, 4096, 4096)))//! 配置端口發送接收隊列大小, 讀4096字節, 寫4096字節, 阻塞I/O模式發送隊列無意義
return false;
改成
#ifdef CN_COMM_FOR_CE
::SetupComm(hComm_, 4096, 4096);
#else
if(!CN_ASSERT(::SetupComm(hComm_, 4096, 4096)))//! 配置端口發送接收隊列大小, 讀4096字節, 寫4096字節, 阻塞I/O模式發送隊列無意義
return false;
#endif
re: 【轉】尋找軟件高手一起開發產品 llbird 2009-04-18 22:12
為什么要有年齡限制，高手和年齡有何關系？不解$%#%
不過我在年齡范圍內，但不在北京，就不知道什么才算是高手，傳說中的HighHand.
re: 自己實現的memcpy llbird 2009-04-18 20:07
你這好像要靠編譯器優化，并沒有顯示優化，不能說沒有更快，
最簡單拿你那個復制5個字節的例子，就沒必要函數調用，可以內聯展開，并且把循環忽略掉
跟貼的小鳥挺多的，呵呵。
C++的string就不是一個類型，是個納入的C++標準擴展類而已，并沒有進入核心類型。
另外string是一個模板的實現(basic_string<char>)，理論上你可以靜態重載模板參數來使用任何字符集
；
UNICODE: wstring basic_string<wchar_t>;
字符編碼當然是個標準，并不存在平臺的不同，否則就不是標準。
至于高低字節順序的問題，那應該有程序轉載文件是做轉換，不是說文件內編碼順序不一樣