NOR: Faster to read, slower to write, XIP(execute in place)
NAND: Slower to read, faster to write.
原文參考:
http://blogs.msdn.com/b/windowsmobile/archive/2005/08/19/453784.aspx
星期二, 7月 27, 2010
WM6 != CE6
Windows Mobile 6的CE kernel版本是5.02
WM5則是CE5.01
CE5以前的OS版本,
最多支援32個processes,
同時最大的runtime memory為32mb.
CE6則最多有32k個processes,
2gb的vm空間.
原文參考:
http://blogs.msdn.com/b/ce_base/archive/2007/02/14/windows-mobile-6-and-the-ce-os.aspx
http://blogs.msdn.com/b/mikehall/archive/2007/01/17/windows-mobile-and-windows-embedded-ce-what-s-the-difference.aspx
WM5則是CE5.01
CE5以前的OS版本,
最多支援32個processes,
同時最大的runtime memory為32mb.
CE6則最多有32k個processes,
2gb的vm空間.
原文參考:
http://blogs.msdn.com/b/ce_base/archive/2007/02/14/windows-mobile-6-and-the-ce-os.aspx
http://blogs.msdn.com/b/mikehall/archive/2007/01/17/windows-mobile-and-windows-embedded-ce-what-s-the-difference.aspx
VS2005 debugging在 Windows Mobile release版程式行數對不準的原因.
之前用VS2005 run debug mode要deug某支release版AP時,
會發生單步執行時,單行code的內容跟所執行的不太一致,
比如code執行到return或是function結尾,
程式卻繼續往下跑.
隨興看到這篇,
問題發生的原因可能是Optimization,
摘要重點如下,
Optimization can affect:
*Local variables, which can be removed by the optimizer or moved to locations the debugger does not understand.
*Positions inside a function, which are changed when the optimizer merges blocks of code.
*Function names for frames on the call stack, which may be wrong if the optimizer merges two functions.
參考資料:
http://msdn.microsoft.com/en-us/library/606cbtzs%28v=VS.80%29.aspx
會發生單步執行時,單行code的內容跟所執行的不太一致,
比如code執行到return或是function結尾,
程式卻繼續往下跑.
隨興看到這篇,
問題發生的原因可能是Optimization,
摘要重點如下,
Optimization can affect:
*Local variables, which can be removed by the optimizer or moved to locations the debugger does not understand.
*Positions inside a function, which are changed when the optimizer merges blocks of code.
*Function names for frames on the call stack, which may be wrong if the optimizer merges two functions.
參考資料:
http://msdn.microsoft.com/en-us/library/606cbtzs%28v=VS.80%29.aspx
訂閱:
文章 (Atom)
