design studio, James S. Hsieh

2012 01 28 加羅湖

2012-01-28T23:50:00.000+08:00

在較大的地圖上查看2012 01 28 加羅湖

從 COM 到 Windows Runtime Component

2011-11-09T10:57:00.000+08:00

Windows Runtime Component 是 COM 的一種延伸我想這是錯的, 但如果說 WinRT Component 是 COM 的一種演化, 我想這是正確的. 由於 COM 被賦予不少期待所以它很複雜, 從 binary-level interface (在 WinRT 稱 abstract binary interface), system-wide activation, automatic memory management , reflection and Type Library (在 WinRT 為 Windows Runtime metadata), threading model (在 WinRT 稱 concurrency model) 到 out-of-process object 都是 COM 想一併解決的問題. 我猜 Windows Runtime Component 的目標與 COM 相近, 並且想簡化 COM 的複雜度.

Abstract Binary Interface
由於 WinRT Component 可以使用 Pure C++ 搭配 Windows Runtime C++ Template Library (WRL) 來實作, 所以 binary-level interface 跟 COM 是相同的, 換句話說就是跟 Visual C++ 的 VTable 完全同. 不過 ABI 限制了可以傳遞的 type, 所有可以傳遞的 type 必須是 Windows Runtime types. 概念上來說如果不是一個 POD type, 那就必須是一個實作 IInspectable interface 的 COM, IInspectable 是用來做為 language projecting 用的, 簡單的說 IInspectable 可以傳回該 object 所有支援的 interfaces (IInspectable::GetIids) 還有 object 本身的 class fully-qualified name (IInspectable::GetRuntimeClassName). 有了這兩個資訊就足夠查詢 Windows Runtime metadata (*.winmd). WRL::Details:RuntimeClass 會去實作 IInspectable 這個介面.

Object Activation
COM Activation (COM DLL)有幾個步驟 :

COM DLL 可以經由呼叫 DllRegisterServer 來註冊 COM 到系統中
根據 CLSID 從 HKEY_CLASSES_ROOT\CLSID 找出 object 對應的 binary path.
載入 binary 並且呼叫 DllGetClassObject function 來取得 Class object.
呼叫 Class object 的 IClassFactory::CreateInstance 來 create object.

WinRT DLL Component 則是:

註冊 WinRT DLL Component 的方式跟 COM 很不相同, ~~我猜這跟 GAC 應該會很像~~.
[Update 2011/11/09]
目前了解是放在 Activation Store (registry)
HKEY_CURRENT_USER\Software\Classes\ActivatableClasses
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsRuntime\ActivatableClassId
根據 activatable class ID 找到對應的 binary path
載入 binary 並且呼叫 DllGetActivationFactory function 來取得 factory.
呼叫 factory 的 IActivationFactory::ActivateInstance 來 create object.

目前我看到的 WinRT Component 都必須被 package 到 Metro style app 之中也就是 local side-by-side, 不知道微軟允不允許 WinRT Component 也能做為 cross application 的 share component.

Automatic Memory Management

WinRT Component 採用的 automatic memory management 是與傳統 COM 一樣的 reference counting 而非 .NET Framework 的 mark and sweep garbage collector, 我想這是可想而知的, 因為 C++ 並沒有 runtime 的幫忙來 GC 所以必須靠每個 object 自己來管理. 由於 WinRT Component 被 JavaScript, C#, VB.NET 中被使用所以 reference cycles 這個重要的課題必須被解決, 所以微軟為 WinRT Component 引入了 weak reference 的能力, 基本上使用 WRL 實作的 component 由於繼承了 WRL::Details:RuntimeClass 所以都會實作 IWeakReferenceSource. 當然這必須是設計 component 的 developer 有意識的去使用 weak reference 才能解決 reference cycles 問題. 有興趣實作的人可以去看 WRL::Detial::WeakReference 這個 class 就能夠了解這是如何辦到的. 以下描述一個 reference cycles 如何使用 weak reference 來打斷這個 cycle, 假設有 A, B 兩個 objects:

Reflection, Projection

IDL 是用來描述 COM interface 跟 class 的描述語言, 使用 C++ (非 C++/CX )實作 WinRT Component 還是必須使用 IDL 來描述 object 的 metadata, MIDL compiler 會根據 IDL 來產生 Type Library (TLB) 與 Windows Runtime metadata (winmd). 有趣的是你可以直接用 .NET Reflector 開啟 winmd 檔案. 以下是微軟 Metro style app 的 sample DLL server authoring sample

如果是使用 C++/CX 則它會自動產生 winmd 而不用去撰寫 IDL. Language Projection 完全仰賴 IInspectable 與 Windows Runtime metadata

Threading model
根據 WRL 的 source code 上來看 reference counter 已經確保是 thread-safety, 這有別於 ATL 的設計, 由於 WinRT component 沒有 registry 或是其他 metadata 來描述 COM 的 threading model, 所以我猜測 WinRT 已經不使用 apartment 的概念來管理 WinRT component, ~~換句話說, 可能所有的 thread 都是 MTA 所有的 component 都是 Free, 但是~~ , 令我訝異的是 RoInitialize 還是必須傳入, RO_INIT_SINGLETHREADED 或是 RO_INIT_MULTITHREADED, 來描述 thread 的 concurrency model. 目前我還不知道原因.

更讓我疑惑的是 old-style COM 該怎麼辦呢? 微軟文件上是說 old-style COM 在 Metro style app 下還是能夠有限度的被使用 (PS. 可以被使用的 COM CLSID 被記錄在HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsRuntime\AllowedCOMCLSIDs), 在使用 COM 之前還是必須呼叫 CoInitializeEx 且傳遞 COINIT_APARTMENTTHREADED 或 COINIT_MULTITHREADED 描述 thread 的 threading model, 根據我測試的結果 C++/CX and XAML 的 UI thread (不是 main thread 喔) 是 STA 並且內建了 message loop. 但如果有兩個 STA 要存取對方所擁有的 COM 時, Workder thread 所 host 的 COM 可能就無法正常運作, 因為我不知道怎麼在一個 Worker thread 實作一個 message loop 來推動 STA 下 Apartment 或是 Both 的 COM object, 因為 GetMessage/PeekMessage API 在 WinRT 已經不能用了.

[Update 2011/11/09]
看了這篇 Windows Runtime internals: understanding "Hello World" article 我才恍然大悟, Threading model 是存在的, 只不過 WinRT 隱藏了這些細節, WinRT 有一個預設的 Win32 exe 也就是 WWAHost.exe ,它被用來 host Metro style application. WWAHost.exe 也就是 application 的 Server, 以我所了解, host 可以是別的 exe, 這些資訊會被記錄在HKEY_CURRENT_USER\Software\Classes\ActivatableClasses\Server\XXX\ExePath. 根據我對這篇 article 的了解, WWAHost.exe 的第一個 thread 會是 MTA, 這個 thread 被用來做為 activation 之用. 所以 WWAHost!Host::Run 會去執行twinapi!Windows::ApplicationModel::Core::CoreApplicationFactory::RunWithBackgroundFactory 並且等待新的 activation request. 當新的 request 進來時, 它會 fork 一個新的 STA thread 並且執行 request 的需求. 這個需求可能任何一種 Contract ex: Launch, Search, BackgroundTasks ....

[Update 2011/11/25]

Introduction to background tasks - Guidelines for developers 對於 threading model 有特別的解釋

For non-JavaScript apps, the background tasks are hosted in an in-proc DLL which is loaded in a multi-threaded apartment (MTA) within the app. For JavaScript apps, background tasks are launched in a new single-threaded apartment (STA) within the WWA host process. The actual background task class can be STA or MTA. Because background tasks can run when an app is in a Suspended or Terminated state, they need to be decoupled from the foreground app. Loading the background task DLL in a separate apartment enforces separation of the background task from the app while allowing the background task to be controlled independently of the app.

Out-of-Process WinRT Component
依照 WRL 的 source code 的設計來看, WinRT Component 是允許 Out-of-Process 的形式, 但是我卻找不到實際的 sample, 如同上述的問題 GetMessage/PeekMessage API 已經不存在了, 這樣如何實作一個 Out-of-Process COM 呢?

[Update 2011/11/10]
我猜想 WinRT 可能提供類似 DLL Surrogates 的方式來實作 DLL Server, 也就是說我們不用寫一個 exe 來 host COM 而是使用 WinRT 提供既有的 host exe. 另外, WinRT 提供 Broker.

還有許多問題需要釐清.... 如果我知道答案在分享出來 :D

Stack of WinRT

2011-11-08T17:08:00.000+08:00

來分享一下 WinRT 下 JavaScript 呼叫 C++ WinRT object 的 stack 你發現什麼嗎? :D

. 0 Id: f70.7f0 Suspend: 0 Teb: 7f3dd000 Unfrozen
Start: WWAHost!mainCRTStartup (001c77a2)
Priority: 0 Priority class: 32 Affinity: f
ChildEBP RetAddr
00eafb44 76e619f8 ntdll_77220000!ZwWaitForSingleObject+0xc
00eafbb0 76e61983 KERNELBASE!WaitForSingleObjectEx+0x8f
00eafbc4 6341b17b KERNELBASE!WaitForSingleObject+0x12
00eafbec 6341b21d twinapi!Windows::ApplicationModel::Core::CoreApplicationFactory::RunWithBackgroundFactoryAndThreadingModel+0x1af
00eafc04 001c92ed twinapi!Windows::ApplicationModel::Core::CoreApplicationFactory::RunWithBackgroundFactory+0x19
00eafc54 001c7750 WWAHost!Host::Run+0xec
00eafc70 001c78a9 WWAHost!RunHost+0x80
00eafc94 74d69391 WWAHost!mainCRTStartup+0x107
00eafca0 772831b0 kernel32!BaseThreadInitThunk+0xe
00eafce0 77283183 ntdll_77220000!__RtlUserThreadStart+0x6f
00eafcf8 00000000 ntdll_77220000!_RtlUserThreadStart+0x1b

. 4 Id: f70.c58 Suspend: 0 Teb: 7f2aa000 Unfrozen
Start: SHCore!CMemStream::Stat+0x3d (7437aaed)
Priority: 0 Priority class: 32 Affinity: f
ChildEBP RetAddr
038be98c 609875b6 Microsoft_Samples_DllServerAuthoring!XXX+0x8aa5
038be9d0 60987f74 jscript9!Projection::ProjectionMethodInvoker::InvokeUnknown+0x18d
038bea8c 609880a9 jscript9!Projection::InvokeMethodByThisInfo+0x44d
038beac0 608cba2f jscript9!Projection::MethodSignatureThunk+0x74
038beaf8 6098f2e7 jscript9!Js::JavascriptFunction::CallFunction+0x84
038beb20 608cba2f jscript9!Projection::ProjectionWriter::DelayedMethodAssignContinuationThunk+0x89
038beb58 6087ff39 jscript9!Js::JavascriptFunction::CallFunction+0x84
038beb74 6087fef2 jscript9!Js::InterpreterStackFrame::OP_CallI+0x43
038beba8 608dc151 jscript9!Js::InterpreterStackFrame::Process+0x687
038bec9c 04960d71 jscript9!Js::InterpreterStackFrame::InterpreterThunk+0x249
038beca8 608cba2f 0x4960d71
038bece0 608cb92f jscript9!Js::JavascriptFunction::CallFunction+0x84
038bed54 608cb81f jscript9!Js::JavascriptFunction::CallRootFunction+0x105
038bed90 608cb7a6 jscript9!ScriptSite::CallRootFunction+0x52
038bedbc 6087b6d2 jscript9!ScriptSite::Execute+0x76
038bee20 5e22dd06 jscript9!ScriptEngine::Execute+0x10f
038bee90 5e22dc32 mshtml!CListenerDispatch::InvokeVar+0xcb
038beeb0 5e059acc mshtml!CListenerDispatch::Invoke+0x3e
038bf07c 5dfdc38c mshtml!CEventMgr::Dispatch+0x648
038bf0a8 5e673887 mshtml!CEventMgr::DispatchMouseEvent+0x12f
038bf1f0 5e568ee3 mshtml!CEventMgr::DispatchClickEvent+0x236
038bf218 5e563c92 mshtml!CElement::Fire_onclick+0x51
038bf274 5e36330c mshtml!CElement::DoClick+0x10e
038bf344 5dfe786f mshtml!CDoc::PumpMessage+0x14df
038bf49c 5e1e7c35 mshtml!CDoc::OnMouseMessage+0x418
038bf644 5e2b2f16 mshtml!CDoc::OnWindowMessage+0xda3
038bf670 751d6bf8 mshtml!CServer::WndProc+0xf6
038bf69c 751d6d80 user32!InternalCallWinProc+0x23
038bf718 751d7e41 user32!UserCallWinProcCheckWow+0x100
038bf78c 751d7f32 user32!DispatchMessageWorker+0x3d4
038bf79c 60d933b6 user32!DispatchMessageW+0x10
038bf7d4 60d93466 windows_ui!Windows::UI::Core::CDispatcher::ProcessMessage+0xc7
038bf824 001cdfd6 windows_ui!Windows::UI::Core::CDispatcher::ProcessEvents+0x6c
038bf848 001cc4ac WWAHost!CoreWindowDispatcher::RunMessageLoop+0x59
038bf864 6341c6e6 WWAHost!WebInstance::Run+0x4a
038bf87c 7437abc1 twinapi!Windows::ApplicationModel::Core::CoreApplicationView::ViewProviderThreadProc+0x27
038bf8fc 74d69391 SHCore!CMemStream::Stat+0x111
038bf908 772831b0 kernel32!BaseThreadInitThunk+0xe
038bf948 77283183 ntdll_77220000!__RtlUserThreadStart+0x6f
038bf960 00000000 ntdll_77220000!_RtlUserThreadStart+0x1b

. 4 Id: 968.c0c Suspend: 0 Teb: 000007f7`8b995000 Unfrozen
Start: SHCore!IStream_WriteStr+0xa0 (000007fc`88d099f0)
Priority: 0 Priority class: 32 Affinity: f
Child-SP RetAddr Call Site
000000d1`b7b4a7b8 000007fc`8ac5110d ntdll!ZwWaitForSingleObject+0xa
000000d1`b7b4a7c0 000007fc`72da393e KERNELBASE!WaitForSingleObjectEx+0x79
000000d1`b7b4a860 000007fc`72da38f0 clr!SafeReleaseHelper+0x14b
000000d1`b7b4a8a0 000007fc`72da396d clr!CLREvent::WaitEx+0x100
000000d1`b7b4a900 000007fc`7312db92 clr!CLREvent::WaitEx+0x6a
000000d1`b7b4a9a0 000007fc`7312dab0 clr!Thread::WaitSuspendEventsHelper+0xc6
000000d1`b7b4aa60 000007fc`7339b90b clr!Thread::WaitSuspendEvents+0x11
000000d1`b7b4aa90 000007fc`72de1a78 clr! ?? ::FNODOBFM::`string'+0x43279
000000d1`b7b4aad0 000007fc`732e78c8 clr!Thread::RareDisablePreemptiveGC+0x229
000000d1`b7b4ab60 000007fc`732ee814 clr!PostSendEvent_Internal+0x35
000000d1`b7b4ab90 000007fc`73412d07 clr!DebuggerController::DispatchPatchOrSingleStep+0x1e4
000000d1`b7b4ac70 000007fc`72e571e0 clr! ?? ::FNODOBFM::`string'+0xcf569
000000d1`b7b4acd0 000007fc`72e5713d clr!Debugger::FirstChanceNativeException+0x64
000000d1`b7b4ad10 000007fc`72dbd0b8 clr!StackTraceInfo::AllocateStackTrace+0xc3
000000d1`b7b4ad50 000007fc`72dbd03c clr!CLRVectoredExceptionHandlerPhase2+0x6d
000000d1`b7b4ada0 000007fc`72dbcf71 clr!CLRVectoredExceptionHandler+0x9d
000000d1`b7b4ae00 000007fc`8da7a7e9 clr!CLRVectoredExceptionHandlerShim+0x95
000000d1`b7b4ae30 000007fc`8da80aad ntdll!RtlpCallVectoredHandlers+0x105
000000d1`b7b4aed0 000007fc`8daca7ba ntdll!RtlDispatchException+0x6d
000000d1`b7b4b5d0 000007fc`13750a1f ntdll!KiUserExceptionDispatcher+0x2e
000000d1`b7b4bb90 000007fc`1375035b 0x7fc`13750a1f
000000d1`b7b4c310 000007fc`13750226 0x7fc`1375035b
000000d1`b7b4c400 000007fc`72fce02e 0x7fc`13750226
000000d1`b7b4c4a0 000007fc`72fce241 clr!zzz_AsmCodeRange_End
000000d1`b7b4c500 000007fc`72fce173 clr!COMToCLRWorkerBody+0x219
000000d1`b7b4c580 000007fc`72fce05a clr!COMToCLRWorkerBody+0x104
000000d1`b7b4c5e0 000007fc`72fcde4a clr!COMToCLRWorkerDebuggerWrapper+0x22
000000d1`b7b4c640 000007fc`72fcdfd7 clr!COMToCLRWorker+0x1ea
000000d1`b7b4c7f0 000007fc`737942a5 clr!zzz_AsmCodeRange_Begin+0x57
000000d1`b7b4c880 000007fc`73824527 jscript9!amd64_ProjectionCall+0x65
000000d1`b7b4c8e0 000007fc`73824f54 jscript9!Projection::ProjectionMethodInvoker::InvokeUnknown+0x117
000000d1`b7b4c9a0 000007fc`738250fb jscript9!Projection::InvokeMethodByThisInfo+0x484
000000d1`b7b4cae0 000007fc`73748458 jscript9!Projection::MethodSignatureThunk+0xeb
000000d1`b7b4cb50 000007fc`7382d028 jscript9!amd64_CallFunction+0x82
000000d1`b7b4cbc0 000007fc`73748458 jscript9!Projection::ProjectionWriter::DelayedMethodAssignContinuationThunk+0xf8
000000d1`b7b4cc30 000007fc`73769584 jscript9!amd64_CallFunction+0x82
000000d1`b7b4cca0 000007fc`7376802d jscript9!Js::InterpreterStackFrame::OP_CallCommon+0x94
000000d1`b7b4cd20 000007fc`73783217 jscript9!Js::InterpreterStackFrame::Process+0x927
000000d1`b7b4ce70 000000d1`b8dd095b jscript9!Js::InterpreterStackFrame::InterpreterThunk+0x2ac
000000d1`b7b4d090 000007fc`73748458 0xd1`b8dd095b
000000d1`b7b4d0c0 000007fc`73769584 jscript9!amd64_CallFunction+0x82
000000d1`b7b4d110 000007fc`7376802d jscript9!Js::InterpreterStackFrame::OP_CallCommon+0x94
000000d1`b7b4d190 000007fc`73894fdc jscript9!Js::InterpreterStackFrame::Process+0x927
000000d1`b7b4d2e0 000007fc`737af33a jscript9!Js::InterpreterStackFrame::OP_TryCatch+0x7c
000000d1`b7b4d350 000007fc`73783217 jscript9!Js::InterpreterStackFrame::Process+0x29f4
000000d1`b7b4d4a0 000000d1`b8dd0963 jscript9!Js::InterpreterStackFrame::InterpreterThunk+0x2ac
000000d1`b7b4d690 000007fc`73748458 0xd1`b8dd0963
000000d1`b7b4d6c0 000007fc`73769584 jscript9!amd64_CallFunction+0x82
000000d1`b7b4d720 000007fc`7376802d jscript9!Js::InterpreterStackFrame::OP_CallCommon+0x94
000000d1`b7b4d7a0 000007fc`73783217 jscript9!Js::InterpreterStackFrame::Process+0x927
000000d1`b7b4d8f0 000000d1`b8dd096b jscript9!Js::InterpreterStackFrame::InterpreterThunk+0x2ac
000000d1`b7b4daa0 000007fc`73748458 0xd1`b8dd096b
000000d1`b7b4dad0 000007fc`73769584 jscript9!amd64_CallFunction+0x82
000000d1`b7b4db20 000007fc`7376802d jscript9!Js::InterpreterStackFrame::OP_CallCommon+0x94
000000d1`b7b4dba0 000007fc`73783217 jscript9!Js::InterpreterStackFrame::Process+0x927
000000d1`b7b4dcf0 000000d1`b8dd0973 jscript9!Js::InterpreterStackFrame::InterpreterThunk+0x2ac
000000d1`b7b4dec0 000007fc`73748458 0xd1`b8dd0973
000000d1`b7b4def0 000007fc`73769584 jscript9!amd64_CallFunction+0x82
000000d1`b7b4df50 000007fc`7376802d jscript9!Js::InterpreterStackFrame::OP_CallCommon+0x94
000000d1`b7b4dfd0 000007fc`73783217 jscript9!Js::InterpreterStackFrame::Process+0x927
000000d1`b7b4e120 000000d1`b8dd097b jscript9!Js::InterpreterStackFrame::InterpreterThunk+0x2ac
000000d1`b7b4e2f0 000007fc`73748458 0xd1`b8dd097b
000000d1`b7b4e320 000007fc`738bdd3e jscript9!amd64_CallFunction+0x82
000000d1`b7b4e370 000007fc`7380a2e5 jscript9!Js::JavascriptFunction::CallFunction+0x7e
000000d1`b7b4e3c0 000007fc`73794370 jscript9!Projection::Delegate::Invoke+0x485
000000d1`b7b4e670 000007fc`8c846a15 jscript9!IndirectMethodInvoker+0x60
000000d1`b7b4e6d0 000007fc`8c84417b rpcrt4!Invoke+0x65
000000d1`b7b4e720 000007fc`8c833696 rpcrt4!NdrStubCall2+0x371
000000d1`b7b4ed60 000007fc`8d728ddf rpcrt4!NdrStubCall3+0xe0
000000d1`b7b4edc0 000007fc`8d728d3c combase!CStdStubBuffer_Invoke+0x67
000000d1`b7b4edf0 000007fc`8d643927 combase!SyncStubInvoke+0x60
000000d1`b7b4ee60 000007fc`8d728bcf combase!CCtxComChnl::ContextInvoke+0x27d
000000d1`b7b4f090 000007fc`8d72f5cf combase!ComInvokeWithLockAndIPID+0x695
000000d1`b7b4f360 000007fc`8d696479 combase!ComInvoke+0x182
000000d1`b7b4f3a0 000007fc`8d6bd29b combase!ThreadDispatch+0x29
000000d1`b7b4f3d0 000007fc`8d709316 combase!CComApartment::ASTAHandleMessage+0x117
000000d1`b7b4f400 000007fc`8d6bd968 combase!`Microsoft::WRL::Module<1,Microsoft::WRL::Details::DefaultModule<1> >::Create'::`2'::`dynamic atexit destructor for 'module''+0x309a
000000d1`b7b4f6a0 000007fc`7fbbc70f combase!CoMsgWaitInProcessEvents+0xbc
000000d1`b7b4f710 000007f7`8c35232b windows_ui!Windows::UI::Core::CDispatcher::ProcessEvents+0x77
000000d1`b7b4f7c0 000007f7`8c3503af WWAHost!CoreWindowDispatcher::RunMessageLoop+0x6f
000000d1`b7b4f800 000007fc`884dbc26 WWAHost!WebInstance::Run+0x4f
000000d1`b7b4f840 000007fc`88d09ad1 twinapi!Windows::ApplicationModel::Core::CoreApplicationView::ViewProviderThreadProc+0x3a
000000d1`b7b4f880 000007fc`8d093cdc SHCore!IStream_WriteStr+0x187
000000d1`b7b4f980 000007fc`8dac3c85 kernel32!BaseThreadInitThunk+0x18
000000d1`b7b4f9b0 00000000`00000000 ntdll!RtlUserThreadStart+0x1d

ChopChop 可以讓影片發揮擴大社交圈功能！

2011-10-27T14:11:00.000+08:00

ChopChop 是免費的 Facebook 應用程式，可以讓影片發揮擴大社交圈功能！先搜尋 YouTube™ 影片，將影片全部組合到 ChopChop 腳本中，找出您最喜歡的片刻，然後將您完成的混搭影片分享給 FaceBook 上的朋友。取個有趣的片名和標題說明，然後標示您的朋友，再邀請他們加入您的 ChopChop 影片作品。 ChopChop 讓您的影片樂趣無窮！

ChopChop 是我的第一個 Web application, 他結合了影片編輯與社群互動等有趣的功能, 在這個產品中, 我負責 Video render engine, RESTful Web API 跟 Database 等規劃與設計.

DEMO: 美女接龍, 經典台詞, 2011 06 26-28 Palau + Phoenix

ChopChop is a free Facebook app that makes video social! Search YouTube™ videos, assemble them together in the ChopChop storyboard, find your favorite moments and share your mash-ups with your FaceBook friends. Add funny titles and captions, then tag your friends and invite them to add to your ChopChop video production. ChopChop is video fun for all!

ChopChop is based on Google App Engine. I am responsible for the design and development of Web API, noSQL database (BigTable), server cache line, browser extensions (IE, Chrome, Firefox, and Safari), Facebook integration, and small part of front-end UI.

2011 09 18 西藏轉山軌跡

2011-10-09T11:43:00.001+08:00

在較大的地圖上查看西藏轉山軌跡
在較大的地圖上查看西藏轉山軌跡

Word Cloud

2011-08-24T00:37:00.001+08:00

http://timc.idv.tw/wordcloud/zh/

2011 06 25-28 Palau

2011-07-06T01:21:00.002+08:00

2011 06 11-12 水漾森林

2011-06-13T08:58:00.004+08:00

在較大的地圖上查看2011 06 12 水漾森林

2011 05 21 松羅湖國家步道

2011-05-24T00:19:00.001+08:00

James and Stella - *

2011-04-14T09:54:00.000+08:00

Wedding Invitation

2011-04-07T22:28:00.000+08:00

HTML5 Video Render Engine

2011-04-01T02:15:00.000+08:00

It is a web video render engine based on HTML5 and WebGL. It provides timeline, tracks, clips, programmable animation (key-frame) and video effects for user to compose a video project. A video project of output is a small JSON file (10~50KB). Engine can compose videos, images, audios and texts according to the project file in time. The media source can be a YouTube online video, an image in Picasa web, or a MP3 audio in the cloud etc. JVRE provides APIs to edit a video project based on online resources such as YouTube videos or Picasa images. The editing result likes a “playlist”, and it can be persisted to a JSON structure. JVRE can accord to the editing result to composite visual and auditory output on-the-fly with online resources. I designed and implemented whole engine.

Give a general application, a web-site provides video editing service based on JVRE. User can create/edit/playback his video project in the browser. The project file (a JSON structure) can be store in server for next playback or editing. JVRE also supports primary features such as:

․ Support multiple layers called tracks in timeline

․ Track has multiple clips; it supports Transformation and Effects.

․ Clip is a playlist of one resource; it supports Transformation and Effect.

․ Source of clip can be a video, an audio, an image, or a title.

․ Title supports multiple texts and Transformation.

․ Effects implement with WebGL pixel-shader, it can leverage GPU.

․ User can edit timeline without pause playback.

․ Engine supports delay-loading and pre-loading videos to reduce latency.

․ Implement key-frame architecture for animations; the interpolation algorithm of key-frame is extendable.

․ Support hit-test for editing and interaction.

2011 03 02 Springfield Team 出團北海岸

2011-03-04T01:37:00.002+08:00

2011 02 26 死黨文子結婚

2011-02-27T13:39:00.000+08:00

常常搞混的 Structural pattern

2011-02-25T04:28:00.003+08:00

以下幾種 structural pattern 常常被搞混或是誤用, 甚至都以 wrapper 這個濫用的名詞來稱呼, 大多都有 aggregation 的結構關係, 其 aggregate 的目有所不同, 以下以 caller, aggregator 與 target 來說明三者的關係

Shortcut (一種退化的 Facade)
aggregator 的目的是讓 caller 對 target 使用起來更簡單方便, aggregator 大多隱藏了很多操作 target 的細節, 所以具有減化複雜度的效果, 但是其目的是以 caller 方便為出發點, 所以 aggregator 多半參雜過多 caller 的假設與邏輯而變的不容易 maintain, 另外, 如果 target 提供一個新的功能, aggregator 往往都要對映的 "開一條路" 讓 caller 使用, 如果開路的代價比方便的好處高, 這就成為一種不良的設計 middle men.

C# 有一種 syntax sugar Extension methods 可以避面這種 middle men 的問題, 又可以將操作的邏輯封裝在 caller 的部分而非獨立建立出一組 aggregator class.
Proxy
aggregator 的目的表留一種間接性來達到某種 target 沒有的功能, 這些功能跟 target 本身的功能通常比較沒有直接相關 (但不是絕對), 多半 aggregator 都是 transparent, 並且它會針對特定 target 來設計, 所以擁有相同的介面, 以下是一些比較著名的應用:

virtual proxy: 用於 lazy instantiation (visualization) 或是 lazy processing
remote proxy: 用於 IPC/RPC proxy/stub, 用以支援遠端呼叫
access proxy: 用於 access control. COM 的 Apartment proxy/stub 就是一種 access proxy 用來保證對 target 的操作是 thread-safety
Decorator
當 target 有自己的繼承體系並且該體系擁有 composite pattern 結構, aggregator 的目的是擴充一些 target 沒有的功能 (sub-classing), 並且 aggregator 必須保有 composite 的特性, 所以它必須繼承 component 而非 target. 多半 aggregator 都是 transparent.

proxy 跟 decorator 的目的嚴格說都是 sub-classing, 但是成本有時候比繼承還要高, 而 strategy 是一種比較低成本的做法, 但是這樣的機制必須被設計在 target 當中.

Boost Iostreams library 與 WIC 提供 filter 的設計思維都是種 decorator pattern
Adapter
aggregator 的目的是讓 target 加入到 caller 的繼承體系中, 用以解決不相容的問題, 這種做法非常直覺, 因為幾乎沒有人想要在 caller 的繼承體系中實做一個跟 target 功能近似的 class. 而多半會 reuse target.
Bridge
aggregator 的目的是隔離抽象性與實做, 所以 aggregator 必須定義一般性的抽像操作, 而 target 來實做細節, 一般來說 aggregator 會有自己的繼承體系, 並且 target 會有其對應關係, 不過, 繼承體系不一定是必要的 COM 的 interface 就是種例子, 繼承體系帶來的限制往往是弊多於利, 不如根據 aspect 分離 interface 是比較恰當的做法.

如果一個 aggregator 會有多個可能的 target 實做對應, 那根據 target 來定義 aggregator (interface) 是種錯誤的思維, 這違反 DIP 與 bridge 的目的, 保持抽像性與分離不相依的面像才是介面設計的原則.

Justin.tv

2011-02-22T10:14:00.000+08:00

Watch live video from nomadlibra on Justin.tv

.NET and COM interop

2011-02-09T14:36:00.000+08:00

以下是收集有用的連結
Type Library to Assembly Conversion Summary

2011 02 06 五專同學聚會

2011-02-08T10:43:00.001+08:00

Corel 尾牙 + Team building

2011-01-29T23:33:00.002+08:00

新年快樂 - 我們公司可愛的卡片

2011-01-28T11:59:00.000+08:00

Crash Dump - 要怎麼看 call stack (1)

2011-01-26T16:36:00.001+08:00

Q: Call stack 怎麼看?
A: 使用高階語言通常不需要了解 call stack 的 layout, 但是當你需要分析 dump 的時候, 這就是必備的知識. x86 CPU 使用兩個 register 來記錄 stack frame 的位置:

SP/ESP/RSP: Stack pointer for top address of the stack.
BP/EBP/RBP: Stack base pointer/Frame pointer for holding the address of the current stack frame.

一個 stack frame 包含了引數, context 與返回位址, 區域變數. 當程式呼叫某個函數時, 首先會根據 calling convention 來推入引數, 然後 call 指令會將相關的 context 跟返回位址推入堆疊, 然後修正 stack frame:

push ebp <= 將 Frame pointer 推入堆疊

mov ebp, esp <= 把 Frame pointer 修正到新的位指, 該位址就是舊的 EBP 所在處

sub esp, X <= 把 Stack pointer 移動來配置區域變數 X 表示區域變數需要的大小 (x86 堆疊是往小的位址成長)

所以, 我們可以預料, EBP 永遠指到上一個 EBP

以下是個簡單的例子來分析一下 stack, 堆疊的頭尾在 003e0000~003dfec4, 最後一個 EBP 是 003dff2c, 所以, 以下紅色的部分是 previous frame pointer, 藍色則是 return address. 這兩個部分是不需要知道每個 function 的 calling convention 就能夠推出來的部分. 我們能夠看出這個 stack 是從 ntdll!_RtlUserThreadStart 成長的, 所以這樣判對的 call stack 是正確的!

利用 r 拿到當下的 context

0:000> r

eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=003dff08 edi=00000000

eip=7722fd21 esp=003dfec4 ebp=003dff2c iopl=0 nv up ei pl nz na po nc

cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202

ntdll!NtDelayExecution+0x15:

7722fd21 83c404 add esp,4

利用 !teb 來知道 stack 的 base 跟 limit

0:000> !teb

TEB at 7efdd000

ExceptionList: 003dff1c

StackBase: 003e0000

StackLimit: 003d6000

SubSystemTib: 00000000

FiberData: 00001e00

ArbitraryUserPointer: 00000000

Self: 7efdd000

EnvironmentPointer: 00000000

ClientId: 00000a18 . 00000734

RpcHandle: 00000000

Tls Storage: 7efdd02c

PEB Address: 7efde000

LastErrorValue: 0

LastStatusValue: c0000135

Count Owned Locks: 0

HardErrorMode: 0

我們用 dds 或是 kd 指令把 raw stack 展開

0:000> dds 003dfec4 003e0000

003dfec4 7722fd21 ntdll!NtDelayExecution+0x15

003dfec8 76902c50 KERNELBASE!SleepEx+0x65

003dfecc 00000000

003dfed0 003dff08

003dfed4 d78faaa0

003dfed8 00dd337c CrashLab!__native_startup_lock

003dfedc 00000001

003dfee0 00000000

003dfee4 00000024

003dfee8 00000001

003dfeec 00000000

003dfef0 00000000

003dfef4 00000000

003dfef8 00000000

003dfefc 00000000

003dff00 00000000

003dff04 00000000

003dff08 c4653600

003dff0c ffffffff

003dff10 00000000

003dff14 003dfed4

003dff18 00000000

003dff1c 003dff78

003dff20 76925eb0 KERNELBASE!_except_handler4

003dff24 a1202d44

003dff28 00000000

003dff2c 003dff3c <= Stack frame

003dff30 76903520 KERNELBASE!Sleep+0xf

003dff34 000186a0

003dff38 00000000

003dff3c 003dff88 <= Stack frame

003dff40 00dd100b CrashLab!wmain+0xb [d:\codes\crashlab\crashlab\crashlab.cpp @ 49]

003dff44 000186a0

003dff48 00dd117d CrashLab!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 583]

003dff4c 00000001

003dff50 00571280

003dff54 005760a8

003dff58 d780fa7f

003dff5c 00000000

003dff60 00000000

003dff64 7efde000

003dff68 00000000

003dff6c 00000000

003dff70 003dff58

003dff74 cc5814dc

003dff78 003dffc4

003dff7c 00dd16f5 CrashLab!_except_handler4

003dff80 d760246f

003dff84 00000000

003dff88 003dff94 <= Stack frame

003dff8c 75453677 kernel32!BaseThreadInitThunk+0xe

003dff90 7efde000

003dff94 003dffd4 <= Stack frame

003dff98 77249d42 ntdll!__RtlUserThreadStart+0x70

003dff9c 7efde000

003dffa0 6f7de307

003dffa4 00000000

003dffa8 00000000

003dffac 7efde000

003dffb0 00000000

003dffb4 00000000

003dffb8 00000000

003dffbc 003dffa0

003dffc0 00000000

003dffc4 ffffffff

003dffc8 772803dd ntdll!_except_handler4

003dffcc 1863df43

003dffd0 00000000

003dffd4 003dffec <= Stack frame

003dffd8 77249d15 ntdll!_RtlUserThreadStart+0x1b

003dffdc 00dd12c5 CrashLab!wmainCRTStartup [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 393]

003dffe0 7efde000

003dffe4 00000000

003dffe8 00000000

003dffec 00000000 <= Stack frame

003dfff0 00000000

003dfff4 00dd12c5 CrashLab!wmainCRTStartup [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 393]

003dfff8 7efde000

003dfffc 00000000

003e0000 ????????

有時候 context 中的 EBP 可能會是錯的, 那就得猜一下了! 如果幸運的找到正確的 EBP, 你將可以使用 "k L = BasePtr [FrameCount]" 來忽略錯誤的 stack frame. 假如正確的 EBP 是 003dff44.

0:000> k L = 003dff44 10

ChildEBP RetAddr

~~003dfec4 76902c50 ntdll!NtDelayExecution+0x15~~

003dff44 00dd117d KERNELBASE!SleepEx+0x65

003dff88 75453677 CrashLab!__tmainCRTStartup+0x10f

003dff94 77249d42 kernel32!BaseThreadInitThunk+0xe

003dffd4 77249d15 ntdll!__RtlUserThreadStart+0x70

003dffec 00000000 ntdll!_RtlUserThreadStart+0x1b

有幾種最佳化的技巧會讓這個技巧無法使用:

Inline: inline 利用行內拓展來避免函數呼叫, 所以根本沒有 stack frame.
Frame pointer omission (FPO): 當 FPO enable 時, function 的呼叫可能就不在維護 EBP (有些條件還是需要), 在這種狀況, 你就沒有 EBP 可以參考. 詳細可以參考這篇文章 http://www.nynaeve.net/?p=91

Crash Dump - 為什麼 dump 的 call stack 總是會不準或很詭異

2011-01-26T01:15:00.004+08:00

Q: 為什麼 dump 的 call stack 總是會不準或怪怪的

A: 有些比較成熟的軟體會在自己 crash 的時候產生 dump, 大部分有兩種做法

程式內部使用 SetUnhandledExceptionFilter API 來設定 UnhandledExceptionFilter callback, 然後, 在 callback 利用 MiniDumpWriteDump API 來產生 dump
一樣使用 UnhandledExceptionFilter callback, 不過由外部的程式來產生 dump

在第一種做法中, 似乎是因為呼叫 MiniDumpWriteDump 的關係, 直接使用 windbg 指令 k 來傾印 call stack 會得到錯誤的結果. 例如下面這種不合理又附帶警告的 stack

0:000> k

0035eb9c 768fb75d ntdll!ZwGetContextThread+0x12

0035ebac 754513f8 KERNELBASE!CloseHandle+0x2d

0035ebbc 7483d4c3 kernel32!CloseHandleImplementation+0x3f

0035ed54 00210000 dbghelp!Win32LiveSystemProvider::OpenMapping+0x1fe

WARNING: Frame IP not in any known module. Following frames may be wrong.

0035ed6c be05061e 0x210000

0035ed70 02810048 0xbe05061e

0035ed74 0035f3d8 0x2810048

0035ed78 00000000 0x35f3d8

最簡單的方法就是將 dump 中 ExceptionStream 的 exception context record 讀出來解釋 crash stack, 最直接就是使用 .ecxr 指令, 很明顯 KERNELBASE!RaiseException 比較是合理的呼叫函數, 所以下面的 call stack 是正確的:

0:000> .ecxr

eax=0035fa0c ebx=00000001 ecx=00000003 edx=00000000 esi=ffffffff edi=00d23864

eip=768fb727 esp=0035fa0c ebp=0035fa5c iopl=0 nv up ei pl nz na pe nc

cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000206

KERNELBASE!RaiseException+0x58:

768fb727 c9 leave

0:000> k

*** Stack trace for last set context - .thread/.cxr resets it

ChildEBP RetAddr

0035fa5c 749edbf9 KERNELBASE!RaiseException+0x58

0035fa94 00ca88cd msvcr90!_CxxThrowException+0x48

0035fbc8 00ca05e6 Sample!wWinMain+0xad <= crash 所在之處

0035fc5c 75453677 Sample!__tmainCRTStartup+0x150

0035fc68 77249d42 kernel32!BaseThreadInitThunk+0xe

0035fca8 77249d15 ntdll!__RtlUserThreadStart+0x70

0035fcc0 00000000 ntdll!_RtlUserThreadStart+0x1b

如果沒有 ExceptionStream 那就比較麻煩了

0:000> .ecxr
Minidump doesn't have an exception context
Unable to get exception context, HRESULT 0x80004002

我們必須仰賴 Thread Environment Block 中的 StackBase 跟 StackLimit, 不過有時候 !teb 指令無法讀到正確的 TEB, 似乎 ThreadListStream 所記載的資料就是錯的, 後來我發現是因為建立 dump 的時候少了 MiniDumpWithProcessThreadData, 所以會有以下的狀況

0:000> !teb

TEB at fffdd000

error InitTypeRead( TEB )...

Stream 0: type ThreadListStream (3), size 00000034, RVA 0000026C

1 threads

RVA 00000270, ID 8FC, Teb:FFFFFFFFFFFDD000

Crash Dump - 如何知道 dump 包含了哪些資訊?

2011-01-26T01:00:00.007+08:00

Q: 如何知道 dump 包含了哪些資訊?

A: 指令 .dumpdebug

----- User Mini Dump Analysis

MINIDUMP_HEADER:

Version A793 (61B0)

NumberOfStreams 11

Flags 1050

0010 MiniDumpScanMemory

0040 MiniDumpWithIndirectlyReferencedMemory

1000 MiniDumpWithThreadInfo

可以由 Flags 得知 dump 包含了哪些資訊, 對應的 MINIDUMP_TYPE 請參閱 MSDN 或是 http://www.debuginfo.com/articles/effminidumps.html. 如果是自己軟體產生的 dump 甚至可以包含 ExceptionStream ! 只要在建立 dump 的 API MiniDumpWriteDump 傳入 MINIDUMP_EXCEPTION_INFORMATION, 如果是利用 UnhandledExceptionFilter 來產生 dump 就非常的方便, 因為 UnhandledExceptionFilter 就提供了 EXCEPTION_POINTERS 來傳給 MINIDUMP_EXCEPTION_INFORMATION, 程式碼如下:

MINIDUMP_EXCEPTION_INFORMATION mdei = {0};
mdei.ThreadId = GetCurrentThreadId();
mdei.ExceptionPointers = pExceptionPointers;
mdei.ClientPointers = FALSE;

MINIDUMP_CALLBACK_INFORMATION mci = {0};
mci.CallbackRoutine = (MINIDUMP_CALLBACK_ROUTINE)MiniDumpCallback;
mci.CallbackParam = 0;

MINIDUMP_TYPE mdt = (MINIDUMP_TYPE) MiniDumpWithIndirectlyReferencedMemory | MiniDumpScanMemory | MiniDumpWithThreadInfo | MiniDumpWithHandleData);

BOOL bRet = MiniDumpWriteDump(GetCurrentProcess(), GetCurrentProcessId(), hFile, mdt, mdei, 0, &mci );

Stream 3: type ExceptionStream (6), size 000000A8, RVA 000001A0

ThreadID 2720

ExceptionCode C0000005

ExceptionRecord 0

ExceptionAddress 6a6b0998

Context record RVA 1010, size 2cc

個人建議的 mini dump 至少資訊包含 MiniDumpWithIndirectlyReferencedMemory, MiniDumpScanMemory, MiniDumpWithThreadInfo, MiniDumpWithHandleData, MiniDumpWithProcessThreadData, MiniDumpWithUnloadedModules

什麼是 C++ Runtime Error!

2011-01-25T10:57:00.015+08:00

每當程式跳出了以下的視窗, 大概除了按下 "確定" 什麼也不能做, 什麼是 "C++ Runtime Error!" ?

簡單說, 大部分的 C++ Runtime Error 是眾多例外狀況 exception 的其中一種, 這裡指的 exception 是指 Windows 的 Structured Exception Handling (SEH). C++ Runtime Error 這種 exception 可以說是由 C++ Runtime 發出的 SEH exception, 當沒有人處理這個 exception 時, SEH 的 KiUserExceptionDispatcher 就會呼叫 C++ Runtime 內部預設的 unhandled exception filter __CxxUnhandledExceptionFilter 來 "處理" 這個例外, 處理的方法則十分的簡單, 就是顯是以上的畫面然後結束程式! 所以我們可以看到堆疊大概會是以下的形式, 藍色部分是產生 exception 的部分, 黑色是 SEH, 而紅色則是 C++ Runtime 的部分. 這個例子是一個用 VC2008 建立的 MFC 程式, 所以會顯示 Message Box, 如果是 console 的程式, 輸出 message 到 stderror 串流.

以上略

MSVCR90!__crtMessageBoxA+0x160

MSVCR90!_NMSG_WRITE+0x16f

MSVCR90!abort+0x26

MSVCR90!terminate+0x33

CrashLab2!__CxxUnhandledExceptionFilter+0x3c

KERNEL32!UnhandledExceptionFilter+0x127

ntdll_77360000!__RtlUserThreadStart+0x62

ntdll_77360000!_EH4_CallFilterFunc+0x12

ntdll_77360000!_except_handler4+0x8e

ntdll_77360000!ExecuteHandler2+0x26

ntdll_77360000!ExecuteHandler+0x24

ntdll_77360000!KiUserExceptionDispatcher+0xf

KERNELBASE!RaiseException+0x58

MSVCR90!_CxxThrowException+0x48

CrashLab2!CCrashLab2App::CCrashLab2App+0x9c

以下略

你可以用 WinDbg 把 exception record 印出來, 關鍵在於 __CxxUnhandledExceptionFilter 這個函數, 因為每個 unhandled exception filter 都有 EXCEPTION_POINTERS 引數, 該結構包含了 EXCEPTION_RECORD 跟 CONTEXT. 你可以看到相當多的資訊, 包含了 exception 物件的指標跟型別, 所以這個例子只是很簡單的丟出一個 int 並且 "int" 的值是 "1", 有趣的是只要是 MSVC 丟出來的 exception, 他的 ExceptionCode 都會是 0xe06d7363, 直翻成 Ascii code 就剛好是 ".msc" 順帶一提, 如果是 .NET Runtime 的 exception 則 ExceptionCode 剛好是 0xe0434f4d ".COM".

0:000> .exr 001af4f0

ExceptionAddress: 0000000076a1b727 (KERNELBASE!RaiseException+0x0000000000000058)
   ExceptionCode: e06d7363 (C++ EH exception)
  ExceptionFlags: 00000001
NumberParameters: 3
   Parameter[0]: 0000000019930520
   Parameter[1]: 00000000001af8c8
   Parameter[2]: 0000000001093dc0
  pExceptionObject: 00000000001af8c8
  _s_ThrowInfo : 0000000001093dc0
  Type : int

0:000>  dt int 00000000001af8c8
1

~~因為這個 exception 已經被 "處理" 所以如果你用 SetUnhandledExceptionFilter API 將無法攔到這個 exception.~~  我判斷是錯誤的, 正確的說  SetUnhandledExceptionFilter API 可以攔到部分的 C++ Runtime Error, 只要這個 error 是建立在 SEH Exception 之上. 但某些錯誤 (Pure virtual function call) 則必須註冊 signal 來攔截, 因為他不會產生 exception 卻會直接 terminate process. 當然你也可以用 signal 來攔截 C++ Runtime 產生的 SEH exception. 大多數的 Windows programmer 對 signal 都不是非常的熟悉, 也許是因為 signal 是 UNIX 的產物, signal 是 ANSI C 定義的一種 callback 方式, 專門接收特殊的信號以便傳遞給 program, 舉個例子 CTRL+C 可以關閉命令列程式就是用這種方式來傳遞 SIGINT.

以下就是個簡單的例子, 程式將會在 __CxxUnhandledExceptionFilter 執行 terminate.

以下是呼叫 "terminate" callback function 的堆疊

CrashLab2!terminate

msvcr90d.dll!raise

msvcr90d.dll!abort

msvcr90d.dll!terminate

CrashLab2.exe!__CxxUnhandledExceptionFilter

KERNEL32!UnhandledExceptionFilter+0x127

ntdll_77360000!__RtlUserThreadStart+0x62

ntdll_77360000!_EH4_CallFilterFunc+0x12

ntdll_77360000!_except_handler4+0x8e

ntdll_77360000!ExecuteHandler2+0x26

ntdll_77360000!ExecuteHandler+0x24

ntdll_77360000!KiUserExceptionDispatcher+0xf

KERNELBASE!RaiseException+0x58

MSVCR90!_CxxThrowException+0x48

CrashLab2!CCrashLab2App::CCrashLab2App+0x9c

以下略

有哪些狀況會產生 C++ Runtime Error 呢? 我所知道的有以下條件

未處理的 C++ exception
a. 產生 exception 而外部又沒有 try-catch
b. 在 catch statement 中又產生 exception 而外部又沒有 try-catch
無法處理的 exception
a. printf, scanf 引數匹配錯誤
b. Pure virtual function call

以下是個 Pure virtual function call 的例子, 當你建構 class B 就會發生.

其他例子的詳細描述可以參考 C Run-Time Errors R6002 through R6025

2011 01 22 加羅湖

2011-01-23T23:00:00.002+08:00

軌跡記錄到紮營點而已

在較大的地圖上查看2011 01 22 加羅湖

在較大的地圖上查看2011 01 22 加羅湖

Neutral Apartments

2011-01-17T01:33:00.001+08:00

終於找到關於 Neutral Apartments 的描述了, 記得之前都查不到呢, 根據 MSDN 上寫的日期, 這是 9/2/2010 的文件, 真是 "新" 啊!

Neutral Apartments http://msdn.microsoft.com/en-us/library/ms681813(v=VS.85).aspx
Threading Model Attribute http://msdn.microsoft.com/en-us/library/ms681753(v=VS.85).aspx
有張挺有價值的表格 :)
COM+ Contexts and Threading Models http://msdn.microsoft.com/en-us/library/ms681289(v=VS.85).aspx

而外還找到一個不錯解釋, 解釋的比 MSDN 還好, 真不知道他怎麼知道的 ..... 呵呵
摘錄於 http://gsraj.tripod.com/com/com_threading.html

Components that use the Thread Neutral Apartment model (TNA), mark themselves as Free Threaded or Both. Here the component instances run on the same thread type as the caller's thread. Each instance of a COM class can run on a different thread each time a method is called. When a thread is executing a method in a COM object, and that method creates a new object, MTS will suspend the current thread and create a new thread to handle the new object. Like the MTA, TNAs allow more than one thread to enter an apartment. However, once a thread has entered an apartment, it obtains an apartment-wide lock and no other thread can enter that apartment until it exits. This model was introduced into MTS and COM+ to ensure that context switches are faster.

MySQL licensing

2011-01-16T22:09:00.003+08:00

大家都知道 MySQL 是以 GPL 的方式授權使用, 而他也提供付費授權的版本, 那麼, 如果一個網站使用 MySQL 做為營利用途, 那是否得公開源始碼呢? 否則就違反 GPL 授權了. 根據 GPL 的規範, GPL 軟體與軟體的衍生物都必須以 GPL 的方式公開源碼, 而衍生物比較廣泛的定義應該包含了 dynamic linking 跟 database access 這類的行為吧. 所以從這個角度來看, 營利網站似乎不能使用 GPL 的 MySQL ....

不過我又查到有此一說: 以下摘錄於 http://stackoverflow.com/questions/620696/mysql-licensing-and-gpl

Provided that you keep it server-only(and therefore "private"), you don't have to release it as GPL. But as soon as it reaches public desktops, it can no longer be considered an internal build, and therefore source code is needed.

So you can:

Release your code as GPL
Buy the commercial version of MySQL
Keep it server-only.

從這樣的說法來看 Server 使用 MySQL 又好像不用付費 ... 我更好奇 Amazon 推出的

Relational Database Service 服務又該怎麼算呢? 它可是建立在 MySQL 之上呢.

神秘的 COINIT Enum 到底做啥用的啊?

2011-01-07T00:03:00.003+08:00

http://msdn.microsoft.com/en-us/library/ms678505(v=vs.85).aspx

COINIT_DISABLE_OLE1DDE
Disables DDE for OLE1 support.
COINIT_SPEED_OVER_MEMORY
Trade memory for speed.

到底是啥鬼?

SQLIte Query Planning

2010-12-24T11:21:00.005+08:00

SQL 語言隱藏了大部分演算法跟資料結構的細節, 這讓 SQL 變得有彈性與容易使用, 但付出的代價就是效率, 當你要做出高效的 query 時, 你就必須了解你的 query statement 是怎麼被分析與執行的, 如果你能夠了解這些, 你就可以利用以前演算法的複雜度分析來思考 query statement, 如此也能找到更好的 statement 跟對應的 indexing. 這幾篇文章讓我獲益不少, 在此分享一下吧:)

The SQLite Query Planner http://www.sqlite.org/optoverview.html
EXPLAIN QUERY PLAN http://www.sqlite.org/eqp.html
Query Planning http://www.sqlite.org/queryplanner.html
Performance Tuning http://www.sqlite.org/cvstrac/wiki?p=PerformanceTuning
How do I improve the performance of SQLite? http://stackoverflow.com/questions/1711631/how-do-i-improve-the-performance-of-sqlite

Some SQLite 3.7 Benchmarks http://blog.quibb.org/2010/10/some-sqlite-3-7-benchmarks/
Fast Bulk Inserts into SQLite http://blog.quibb.org/2010/08/fast-bulk-inserts-into-sqlite/

Wedding slideshow

2010-12-19T20:12:00.000+08:00

Create your own video slideshow at animoto.com.

Stella 與 James 的婚紗

2010-12-16T10:39:00.002+08:00

2010 12 11 北插二行

2010-12-14T01:00:00.002+08:00

Corel 的聖誕卡

2010-11-30T01:21:00.001+08:00

我挺喜歡公司這張賀卡的風格分享給大家看看嘍

Stella 的一格漫畫

2010-10-31T23:34:00.000+08:00

2010 10 29 萬聖節變裝

2010-10-30T01:03:00.001+08:00

2010 10 24 磺溪溫泉

2010-10-26T18:48:00.000+08:00

2010 10 12 帛琉 Part 4 and HDR

2010-10-12T10:44:00.000+08:00

2010 10 11 帛琉 Part 3

2010-10-11T10:42:00.000+08:00

2010 10 10 帛琉 Part 2

2010-10-10T10:37:00.002+08:00

2010 10 09 帛琉 Part 1

2010-10-09T10:36:00.003+08:00

2010 10 05 五專死黨歡唱

2010-10-06T09:47:00.000+08:00

2010 08 29 新店天湖

2010-09-21T13:27:00.001+08:00

2010 08 15 老梅

2010-08-20T01:53:00.000+08:00

2010 08 01 菊島之旅

2010-08-04T12:14:00.001+08:00

2010 07 04 桶後溪 22km 健行

2010-07-04T20:35:00.001+08:00

今天走了 22 公里的林道, 雖然並不陡峭但是在那艷陽下真的叫人吃不消, 爬一半的過程中我們家楊大還拿出溫度計來看山上的氣溫, 結果, 太陽下竟然有 37度.... 畢竟高度只有 400~500 公尺高

黃色是今天走的, 紫色是 2008 年的紀錄喔下次希望能到礁溪

在較大的地圖上查看桶後溪旅行紀錄

VM-based 的程式語言總是讓人又愛又恨

2010-07-04T01:21:00.001+08:00

我想大家寫過 .NET Framework, Java 甚至是 Python 之後再回去開發 C/C++ 的程式碼應該多少都有一點 "卡卡" 的吧, 原因是因為, 對於 programmer 來說上述的三種語言都有著豐富且 "統一" 的 library 可以供大家使用, 所以寫起來也比較順手. 這些 VM-based 的程式語言還個重要的好處, 就是它與硬體平台並不相依, 所以基本上如果兩個平台有著相同的 "軟體抽象層" (包含 Programming model 跟 library), 用這些語言寫的程式是可以直接在上面跑的, 另一個共通的特點就是這些語言都提供 Garbage collection 的機制, 所以寫程式 "比較" 不用在意記憶體釋放的細節. 這些好處都可以快速的增加 programmer 的生產力, 但是, 付出的代價也是非常的多...

首先 VM-based 的程式語言都需要 VM (廢話), 在沒有支援 JIT 的情況下, 程式碼必須以 Byte-code 的形式在 VM 中執行 (Java 在 ARM CPU上有 Jazelle 可以直接執行) 速度與 Native-code 相比還是差了一點點, 如果是 JIT 的話那應該就差不了太多了, 不過, 就我的經驗 JIT 還是挺花時間與記憶體, 在 Mobile 或是 Embedded system 的世界中對於記憶體的要求可能就更嚴格了.

Garbage collection 是個很方便的技術真的大幅提升了開發的速度, 但是付出的代價就是 programmer 對於記憶體使用量的控制性降低了, 畢竟 GC 不可能隨時隨地都在做, 通常只有在記憶體比較不足或是系統比較有空的時候才會發生, 這對於程式來說有兩種影響 1. 記憶體的使用量比 Native-code 大而如果 programmer 需要精細的配置記憶體的使用量可能不大容易 2. GC 可能會影響系統執行的流暢度.

觀察現行的 Mobile platform 各式各樣的硬體 CPU 規格, 要使用非 VM-based 的語言來開發軟體在佈署與相容性上將會非常麻煩, 以下是各個平台的概況:

Windows CE 提供了 C/C++ SDK 與 .NET Framework Compact 供 programmer 發展, 但是似乎是比較傾向 Native code, 以 Windows CE 7 來說, 微軟提供了 Microsoft Silverlight for Windows Embedded 給 C++ (沒錯不是 C# 喔) 做為 UI Framework,
Windows Phone 7 上則是主推 Silverlight, XNA 與 .NET Framework Compact (我猜是想把 Windows Phone 7 變成遊戲平台吧 :P) 這兩個平台的發展方向目前有點不同! 這有篇相關的文章可以看看 "Microsoft's new pitch: 'Every .Net developer just became a Windows Phone developer"
Android 則是 Java 配上 Application Framework 與 NDK, NDK 相關的資訊還真的少得可憐, Google 則強烈建議大家用 Java 開發應用程式.
iOS 提供的原生程式語言是 Objective-C, 基本上是 C-based 的程式語言, 所以速度上應該不是問題, 在加上 Apple 的硬體 model 單純所以沒有太多相容與移植的問題, 所以狀況比較單純, 但是還是有人對於 Objective-C 的速度有些意見:P "Android Dalvik VM performance is a threat to the iPhone" 另外 .NET CLI 也可以在 iPhone 跑ㄟ MonoTouch
MeeGo API 部分是使用 Qt Framework 做為 UI Framework, 主要是使用 C/C++, 感覺 MeeGo 比較像一般的 OS, 現行的 Mobile OS 都在 Application framework 還有跨硬體平台的部分有著特殊的設計, 但是 MeeGo 在這方面著墨比較少.

可以見得每個平台的選擇都還不少, 除了 Apple iOS 獨樹一格之外, 其它開放性的系統都會有硬體相容性與移植的問題, 要用 VM-based 的程式語言還是 Native 的程式語言好呢? 我想混用最好, 但是佈署可就要花點心思了.

OS 與 programmer 的距離越來越遠...

2010-06-25T11:49:00.002+08:00

為什麼我會說 "OS 離 programmer 越來越遠..." 呢? 還記得我以前一開始寫程式的時候常常會想, 物件導向不是很棒嗎? 為什麼 Windows 下的 API 都這麼難用, 雖然它還是有物件的觀念但使用起來跟真正的物件還是有些差異雖然 MFC 包裝了不少 Win32 API, 但總免不了跟 OS 打交道的機會. 後來有了 Java 跟 .NET Framework, 在他們的世界裡物件模型是一致並且可以擴充的, 這時終於讓我天真感受到 "我終於活在完整的物件導向世界中 :P" 儘管實際沒有那麼盡善盡美, 但可以確定的是在那樣的開發環境下 OS 離我越來越遠... 我想這一切都是從 Java 開始的吧...

最近開始學習與了解 Android 的軟體架構 (我好像動作都比別人慢...) 也稍微 study 了一下 iOS 的設計, 反觀現有的 Windows. 有個共通的特點就是這些開發廠商都想慢慢的隱藏 "OS 的細節與耦合程度", 以微軟來說 COM 與 .NET Framework 提供了遠多於 Windows 本身豐富的元件, 也將一些生澀的 Win32 API 包裝成好用的物件, 所以 programmer 在 .NET 的環境下使用 P/Invoke 打交道的機會就越來越少. Android 也是個有趣的例子, 大家都知道 Android 底層是 Linux kernel, Google 在 Linux kernel 建構了變形的 Java VM 稱 Android Runtime 與 Application Framework 來增加 programmer 的生產力, Application Framework 是一群 Java 的元件並且描繪出 Android 上為了 mobile 特性自有的 programming model, 有了這層 Runtime, programmer 就不需要顧慮他的軟體到底跑在哪一個硬體平台 ARM or x86..., Apple 的 iOS 與 MacOS 則是在 Linux/FreeBSD 上以 Objective-C 的方式提供了 Cocoa, Carbon 與 Java 等 Application Framework, 目的也是一樣加速軟體的開發.

我想這就是近幾年 OS 的發展趨勢 "提供統一且豐富的元件加速軟體的開發", 以往的 OS 著重如何高效率的使用硬體, 而現經則是重視怎樣提升 OS 上軟體的開發速度. 畢竟一個 OS 的成功與否是取決於上面有多少 Application.

2010 06 19 加羅湖登山口之旅

2010-06-22T20:46:00.001+08:00

Media Library Engine 2.0

2010-06-01T02:24:00.000+08:00

It is a file-based media content management service that provides query/access, management, and tracing APIs. Windows applications can search, manage, and sync content with MLE2. It includes a daemon which syncs metadata and thumbnails between database and file system in background. MLE2 database back-end is SQLite engine. Comparing to Google Picasa cataloging engine, MLE2 can handle more files (10K~100K files) than Picasa, and they have similar performance for cataloging and search. In addition, it provides a schema-free metadata system to store complex metadata. It supports multiple applications or instances to concurrently access library. MLE 2.0 also supports primary features such as:

․ Support multiple libraries in concurrent.

․ Support high performance query, full-text-search, grouping and paging; MLE can handle a query to search 100000 ~ 250000 files less than 1 sec (depends on HDD and CPU).

․ Support bulk operation to modify library.

․ Support file time and size stacking

․ High throughput thumbnail system which supports three levels pixel, 96x96, 160x160, and 480x480.

․ Support applications to trace change of files.

․ Extensible metadata and tags model, applications can define customized metadata and tags for special purpose.

․ Extensible fault-tolerable media parsing framework, applications can implement multiple media parsers to support customized file formats. MLE includes a default media parser which supports JPEG, PNG, and BMP format based on Microsoft Windows Imaging Component.

․ An async message channel between MLE and all clients. MLE uses that to notify change notification, and applications can use it to communicate each other.

I designed and implemented whole engine.

2010 05 02 巴拉卡亂拍

2010-05-02T01:21:00.001+08:00

2010 04 25 華山 Art Area

2010-04-25T01:21:00.001+08:00

2010 04 16 大甲媽遶境第四年

2010-04-18T17:46:00.001+08:00

2010 04 10 哈盆露營

2010-04-11T21:04:00.002+08:00

領悟

2010-04-05T22:51:00.001+08:00

領悟就是辛曉琪的歌

2010 03 28 淡水福佑宮

2010-03-28T23:01:00.003+08:00

2010 03 27 雲森瀑布

2010-03-27T22:58:00.002+08:00

COM Managing Memory Allocation

2010-03-23T14:46:00.001+08:00

回憶一下吧~
Managing Memory Allocation
Memory Management Rules

2010 03 06 迪化街

2010-03-06T21:18:00.000+08:00

2010 02 28 平溪天燈

2010-03-01T00:14:00.001+08:00

GANTZ 又回到了這房間...

2010-02-19T23:54:00.002+08:00

軟體的藝術 trade off

2010-02-19T22:42:00.002+08:00

今天看了篇文張程式設計的兩個觀點：架構狂還是效率狂？覺得十分有趣也心有所感, 以下是我的想法: 我也算是個架構狂, 比較執著於彈性與複用, 所以 dependency 與 role and responsibility 的設計就非常龜毛. 但最近面對的工作對效率比架構還有著較嚴苛的要求, 如此的要求下變的必須以效率為導向來決定整體的架構. 有著最佳的效率意味著整體都要互相配合, dependency 就變的比較強也比較無法複用, 但贏得的是效率的提升, 這也是我這一兩年來對於架構跟效率有著比較不同的體認, trade off 就是軟體的藝術, 對效率與架構也不例外 :)

2010 02 14-18 Carcassonne

2010-02-18T01:28:00.001+08:00

命運之輪是由小豬來轉動的....

C++ Object Persistent for SQLite

2010-02-12T14:13:00.010+08:00

上一篇文章我提到了 LiteSQL 的設計是利用 DB Schema (XML file) 來產生對應的 C++ Class, 而我的設計是從另一個角度出發 "設計 C++ 產生對應的 DB Schema" , 我設計了一系列的 Class, macro 跟 template function 來達到 Object Persistent 這個目的, 而 SQLite 接合的部份我選擇了 SQLite3++ 這個 SQLite3 backend library, 撰寫 Persistent Class 的時候只要利用這些東西就可以輕易的產生出可以 Persist 到 DB 的 class, 其中的功能包含簡易的 Reflection 跟 DB 對應的操作 function 諸如: CreateTable, InsertInto, UpdateAll, UpdateModified, SelectFromRow 等等... 以下是個使用的例子

Persistent class declaration

當我們利用 macro 寫出這個 Class 的時候, 這些 macro 讓我們描述了 class MLDBPersistSample 所對應的 DB Schema 跟 metadata , 因為繼承自 MLDBPersistBase class, 所以擁有了上述 DB 操作的能力, 使用的時候就不需要再去組合 SQL 字串了 :D 要建立 Table 只要呼叫 CreateTable 這個 static function

它就會根據我們所描述的 metadata 產生出以下的 SQL statement

CREATE TABLE MLDBPersistSample(Column1 TINYINT , Column2 SMALLINT , Column3 INTEGER PRIMARY KEY AUTOINCREMENT, Column4 BIGINT DEFAULT 0, Column5 TEXT , Column6 REAL NOT NULL, Column7 DATETIME , CHECK(Column1 >= 0 AND Column1 <= 5))

如果我們想要 insert 或是 update 一個 object 到 DB, 只要 (Column? 只是個例子, 實務上 Symbol 可以取得更有意義一點)

就能產生出以下的 SQL statement

INSERT INTO MLDBPersistSample (Column3) VALUES (?)

UPDATE MLDBPersistSample SET Column5 = ? WHERE Column3 = ?

問號 ? 的部分, 會利用 data binding 的方式傳給 SQLite 的 API

Query 的部分, 我則是從 LiteSQL 例子中得到了一些啟發, 我實做了相對應的 query class 來產生對應的 SQL statement, 以下是個 C++ statement 與產生出 SQL statement 的結果

SELECT MLDBPersistSample.Column3,MLDBPersistSample.Column5 FROM MLDBPersistSample WHERE (MLDBPersistSample.Column3 >?) AND (MLDBPersistSample.Column5==?) ORDER BY MLDBPersistSample.Column1,MLDBPersistSample.Column2

我想這個部份是最有趣的, 也是 LiteSQL 最有創意的地方, 所以我也提供了這樣的使用方式, 利用這樣直覺得 C++ 操作可以產生出比較複雜一點點的 SQL query 真的是非常方便, 而且 C++ 的部分還會做 syntax checking, 而 10 跟 "hi" 的兩個 condition 會做 type checking, 並且兩個值會以 data binding 的方式傳給 SQLite API, 非常方便吧 :D

LiteSQL - SQLite Object Persistent for C++

2010-02-02T11:25:00.003+08:00

最近因為工作的原因需要用到 SQLite, Review 現有的 C++ Project, 我發覺我們現有 Project 在使用 SQLite 非常的不方便, 它使用最基本 (原始?!) 的方法自己組合 SQL statement 來操作 DB, 並建立一組 Class hierarchical 來 Modeling DB 的 Schema. 這樣設計的好處在於操作 DB 可以比較自主效能上也許會好些, Class hierarchical 也可以比較複雜. 壞處則是, 許多 DB 的操作 SQL statement 都有固定的 pattern 這個部份可以抽離出來, 但是 Class, statement 與 DB Schema 的對應關係需要人工來維護. 能夠盡量減少人力來維護是我的目標, 所以, 我們需要一個有彈性的 SQLite Object Persistent Library.

我 Survey 了一下現有的 C/C++ SQLite wrapper project, 有支援 Object Persistent 的似乎只有 LiteSQL 這個 open source project, 是用 LiteSQL 必須使用 XML 來定義 DB Schema, 並使用他們提供的 Code generator 來產生 C++ Modeling 的程式碼, 以下是官網上面的 example.

PersonDatabase db("sqlite3", "database=person.db");
Person person(db);
person.name = "Bob"; // assign values to fields
person.age = 20;
person.update(); // writes a new record to database

我們可以輕易的操作 Person 物件來建立/改變 DB 中的 record, 該例子隱藏了 SQL statement 並且轉換成較我們較直覺得物件化操作, 對於 Relation 的部分, LiteSQL 可以建立 Relation-class 來 Modeling 兩個 Persistent Object 之間的關係, 這樣的設計在 C# 那種具有完整 Reflection 能力的語言中是非常容易實做, 但在 C/C++ 中則是非常困難.

除了Object Persistent 之外, LiteSQL 還提供了一下的 select 語句來方便查詢

PersonDatabase db("sqlite3", "database=person.db");
vector = select(db).all();
Person bob = select(db, Person::Name == "Bob").one();

這個 library 給我不少的啟發, 但我實際上試用它卻有不小的挫折, 原因在於我們使用的 DB Schema 似乎無法產生正確的 class, 畢竟這個計畫目前的狀態仍然是在 proof-of-concept implementation 的階段.

我遇到的另一個問題是, LiteSQL 是使用 Gen-Code 的方式來產生 Modeling Class, 所以, 如果 DB Schema 改變了, 程式碼應該有不小幅度的改變 (我想無法避免), 但是開發過程中 Schema 改變是免不了的, 所以我嘗試設計了一個以 class modeling 為主的方式來產生 DB Schema, 只要遵照一定的 class 設計方式, 就能夠利用類似 Reflection 的方式還產生 Schema 與 record 操作, 主要是配合 macro 跟 template 的方法來實現, 目前我還在設計中, 有機會再跟大家分享 :)

ETW Scenario library and Real-time ETW Viewer

2010-01-19T20:43:00.009+08:00

微軟在 Windows 2000 之後引入了 Performance Monitoring 機制 - Event Tracing for Windows ETW, 而在 Windows Vista 對於 ETW 有更多的改進, Vista 導入了 Unified event provider model 與新的 APIs 讓我們可以用一致的方式來處理 ETW event. 你不難發現微軟已經大量的整合 ETW event 到 CPU scheduler, File system, GPU Driver, Image Loader, .NET Framework JIT, GC, WPF render engine 等... 重要的模組中, 因為 ETW 是 Kernel build-in 等多種特性所以在使用上有較小的效能影響, 並且可以收集到 System-wide 的資訊. 微軟也為此提供豐富的 Tools 來支援軟體開發與 Performance tuning, 諸如 Microsoft Windows Performance Toolkit, Visual Profile, Logman, Reliability and Performance Monitor (RPM)...

但是, 如果我們要開發自己的 ETW event provider, 並且有圖形化的介面可以幫助我們了解效能上的問題有現成的 tool 嗎? 有的, Microsoft Windows Performance Toolkit 中的 Event Trace 或是 xperfview 都可以幫助我們圖型化我們自製的 ETW event, 但是, 它只能提供一般性的呈現方式, 原因很簡單, 因為這些 tool 並沒有足夠的 domain knowledge 來解釋這些 event, 所以他只能以 Generic event 的方式呈現, 如此我們只能以時間分佈的單一維度來觀察我們的 event, 其實這並不方便

xperfview - Generic event 只能看到事件發生的時間點

之前曾在微軟的 Blog 看到人家發問 "xperfview 是否能夠支援擴充" 不過到目前為止的答案是否定的, 其次 xperf 因為效率的考量所以只有提供 offline 的方式來分析 ETW event, 但對於有些特定的 use case 下將會非常麻煩, 我們總想知道使用者互動下效能與操作行為的相關性, real-time 的方式分析有時候比較快速與直覺, 有鑑於此我們就自己開發了簡單的 ETW Viewer 來幫助我們做到這些事情.

首先, 我們要定義比 Generic event 在豐富那麼一點點的語意來表達更多的資訊, 並且在 Client 的整合上可以更方便快速, 所以我們選擇一個 MSDN Code Gallery 上 ETW 相關的 Project - Scenario 來做為整合的目標, Scenario 是個 ETW event provider 的實做體, 它提供了 Native 與 Managed code 的兩種實做版本, 在 event 的格式部分, 因為 Scenario ETW Format 有定義了兩個值 Category (Unicode string) 與 Size (int64) 來讓我們描述 Client 想要描述的 "量" (你可以用來描述 FPS, cache miss rate 等等自訂的語意), 使用 Scenario 可以說非常的簡單, 我們只要埋入幾個特定的 check points: Begin, Step, End 在我們想觀察的 case 中, 並且將我們自訂的數值傳遞給 Scenario 就夠了. 就像:

// C#: Generate an ETW event (when enabled by an ETW controller)
using Scenario;
...
Scenario timer = new Scenario();
timer.Begin(); // checkpoint 1
// ...
// Code that you want to time
// ..
timer.Step(size) // checkpoint 2
// ...
// Code that you want to time
// ..
timer.End(); // checkpoint 3

以上的程式為例, Scenario 就會幫我們把 3 個 checkpoint 的時間間隔量出來, 並且把我們自訂的 Size 值也跟著傳給 ETW consumer.

接下來我們的問題就是如何顯示這個收集到的 event , 我們使用了 C# 開發了一個簡單的 WinForm 程式, 這個程式包含了一個 ETW controller 跟 ETW consumer, ETW controller 有能力動態的 Enable 或 Disable 指定的 ETW event, 在配合 Scenario 的設計下當一個 ETW event 被 Disable 時我們所 monitor 的程式除了一些簡單的判斷式, 它將不會執行 ETW provider 相關的程式碼, 這樣能確保在 Disable 的狀況下只有很少的效能損失. 利用 ETW consumer 我們能即時且非同步的方式處理收到的 event, 並將其 Size 與 checkpoint 的時間顯示在 UI 的笛卡兒座標上, 這就是我們希望視覺化的部分. 此外, 這個程式也有能力將這些資訊寫進 SQLite 的 database 中, 這樣的好處是, 我們可以在將來更輕易的整合到 Auto testing 與 Build process 中. 以下就是 Real-time ETW Viewer 的 Snapshot!

ETW Realtime Scenario Viewer - timeline view

ETW Realtime Scenario Viewer - list view

Improve Debugging And Performance Tuning With ETW 是篇還蠻具體而微的文章, 對於這方面有興趣的人可以參考.

2010 01 17 陽明山七星池

2010-01-17T16:09:00.004+08:00

檢視較大的地圖

什麼是好的軟體?

2010-01-13T22:21:00.004+08:00

實務派的人說:

軟體是種高度特化的藝術品, 所以裡面怎麼做不重要, 只要整體的功能與效率符合需求並且執行的很好, 最好能夠用最低的成本來達到目標就是王道.

架構派的人說:

軟體是種有系統性的積木, 為了增加複用性與生產力, 降低擴充與維護的成本, 架構是軟體的靈魂.

產品派的人說:

軟體只要功能多成本低, 能快速生產能夠高度客製化, 在效能上有好的表現, 很少 BUG 就是好軟體.

使用者說:

軟體只要便宜 (最好不用錢), 好用, 快速就是好軟體.

軟體的特性還蠻複雜的, 它有著生產, 運作, 維護時間長, 複製成本極低, 規格變動, 汰換率與人事變動成本高, 不易維護, 除錯與驗證等多種複雜特性. 要減少這些特性的缺點增加其優點是很明確的目標, 所以上面沒有一種人說錯, 軟體是在上述的多種衝突需求中找到一個最佳的平衡點就是好軟體. 但怎樣的平衡是正確的選擇就有很大的學問,

舉個例子: timing 就是市場的一切, 快速的做出產品可以爭取更多的機會來把握 timing, 然而好的架構會因為降低耦合增加彈性等多種考量而延長產品的開發時間, 有時候這些設計可能在當下會被視為 over design 而被捨棄或忽略, 某個層面這是對的. 如果這個產品賣得好而延長了程式與架構的生命週期, 接下來要面對的就是該產品的架構會因為未來的需求而受到考驗, 好的架構也可以降低維護的成本. 所以這個平衡的因子似乎因為生命週期而有不同的選擇, 儘管軟體的生命週期會因為市場的反應而難以評估, 有些軟體可能會沿用個 10 年, 有些則只會出一個版本.

再舉個例子: 架構的取捨有時候還得考量 programmer 的技術能力, 也許你會遇到一個窘境是你使用了一堆很棒的 design pattern 但你的同事卻一個也看不懂還是能存活下來. 你該用易懂直觀的架構還是稍微難懂但頗富彈性的架構呢?

再再舉個例子: 如果有個公司就是做 OEM 或是硬體驅動程式 BIOS 這類強烈需求導向的工作, 也許這個軟體一但 GM 就等於進了墳墓, reuse 對這類型的工作也許毫不重要, 也可能這些具有 reuse 特性的部分人家都已經做好了等著你用, 這樣的公司文化與工作特質下, 怎樣的選擇好呢?

什麼是好的軟體? 因為人, 因為時間, 因為佈署的方式, 因為舊有的包袱, 因為公司的文化與營運方式有著截然不同的答案. 連怎樣評估軟體是好是壞都是如此的複雜...

幾個關於 .NET Framework 4 的幾個疑惑與希望...

2010-01-09T02:27:00.018+08:00

.NET Framework 3.5 以來, 普及率一直不是很理想, 微軟也針對關鍵性的幾個因素做改善, 一下的幾點筆記是該去研究一下 :P

大家都知道 .NET 的 Application 的啟動時間可能會很慢, JIT 是個原因之一, 利用 NGEN 來改善 Startup Performance 是微軟提供的一種解決方法, 我們是該驗證一下這個方式, 有幾篇文章可以追一下: The Performance Benefits of NGen, CLR Optimizations In .NET Framework 3.5 SP1, Improvements to NGen in .NET Framework 4, To NGen or Not to NGen?, Improving WPF applications startup time, Splash Screen To Improve WPF Application Perceived Cold Startup Performance

我驗證的結果, WPF 的 Cold/Cool Startup time 還是很久, 即使用了 NGen 速度還是沒辦法像 native code 一樣.
WPF 與 Direct3D 的 footprint 差異有多大, WPF 的記憶體使用量一直為人所詬病 (相較於MFC), 不知道 4.0 是否有改善
.NET Framework 的 installer size 一向不小, 所以微軟設計了.NET Framework 4 Client Profile 還有Web Bootstrapper, 文章上描述 .NET Framework 4 Client Profile 的安裝不一定需要 Reboot 並且可以 Parallel Download and Install, 這個也是需要追一下: What's up with the "Reboot" step? , The .NET Framework 4.0 Beta 2 Installer Improvements, What’s new in .NET Framework 4 Client Profile Beta 2, .NET Framework Client Profile Deployment Guide

Installer size 已經比以前小很多了, 但是 install size 還是一樣肥的嚇人, 以 x86 為例, installer 的大小大約是 30.9 MB, 但是解壓縮加上 JIT 之後的大小需要 850 MB 左右, 這真的讓人卻步, 不過我承認 installer 縮小有助於程式在網路上散佈. 不過如果我想寫個 WPF 小軟體卻要求使用者要有 850 MB 的空間來安裝我的軟體, 應該沒有幾個使用者能夠接受.

今天在別人的電腦嘗試安裝 Client profile 結果 installer 還是要求重新開機, 仔細觀察 MsiInstaller 的 log 發現這台電腦必須重新開機有幾個原因:
C:\WINDOWS\system32\dfshim.dll 正在被下列處理名稱所使用中: explorer 識別碼 1920
C:\WINDOWS\system32\mscoree.dll 正在被下列處理名稱所使用中: explorer 識別碼 1920
C:\WINDOWS\system32\mscoree.dll 正在被下列處理名稱所使用中: iexplore 識別碼 220
C:\WINDOWS\system32\mscoree.dll 正在被下列處理名稱所使用中: iexplore 識別碼 1764

這台電腦的使用者算是個很基本的 End user 所以電腦安裝的軟體並沒有什麼特別之處但是還是被要求重新開機, 原因是 IE 跟 Shell 都佔住了 .NET Framework 的 runtime, 看來狀況並不明朗啊.. 然後查了一下 MSDN 發現, Client profile 的 installer 提供 command parameter

/norestart: Setup doesn’t reboot automatically. The chaining application needs to capture the return code and process and handle reboot if this switch is used.
但也只是暫時讓他不需要 reboot 罷了.

根據张羿的文章 ".NET中的幕后英雄MSCOREE.dll " 所描述, mscoree.dll 提供了 _CorExeMain 這個進入點做為 CLR 程式啟動之用, 重點是不管哪個版本的 .NET Framework 都是用這支 DLL 來啟動, 所以 mscoree.dll 在系統中只會有兩支 (32/64bit), 而 .NET Framework 4.0 似乎需要置換掉這個檔案, 所以重新開機也許在所難免. 除非類似 SxS 的方式使用私有的 mscoree.dll, 而张羿似乎有找到解決的方法不過還沒分享出來, 詳細可以參考 ".NET 4.0新功能：Mscoree.dll + Mscoreei.dll=更少的Reboot"

免費的 "IStream, IPropertyStorage" system-provided, stand-alone implementation COM

2010-01-08T01:53:00.010+08:00

相信寫過 .NET C# 的人對於 System.IO.MemoryStream 這樣的物件都感到十分方便, 因為MemoryStream 會在需要的時候自己 ReAlloc 來改變大小, 並且由於 MemoryStream 繼承自 Stream 這個 class 所以用途十分廣泛. 其實 COM 也有相似的設計 (不如說 .NET Framework 學 COM 的) COM 有定義一個基本的 interface IStream, 概念上 IStream 就如同 .NET 中的 Stream 一樣, 不過它是 interface 而不是 abstract class, 在 COM 的世界裡 interface 是種 protocol, 所以任何人都可以實做 IStream 的 COM, 並且跟認得 IStream 的其它 COM 合作. 我之前就有寫過一個實做 IStream 的 COM, 它支援 non-buffering 的方式來 OpenFile. MSDN 就有一篇文章來教大家怎麼時做一個 FileStream - Default IStream Implementation.

COM 的定位並不是個 Framework 所以沒有那麼多現成的 class 可以使用, 而且系統提供的 COM implement 也少的可憐. 但是 OLE32.DLL 還是提供了類似 MemoryStream 這類好用的東西, 我們可以使用 CreateStreamOnHGlobal 來建立一個實做 IStream 的 COM instance, 而這個 instance 的功能就如同 MemoryStream 一樣會自動 ReAlloc. 當然 OLE32 也允許你從 IStream 拿到 HGlobal 的 HANDLE, 我們只要呼叫 GetHGlobalFromStream

HGLOBAL handle = NULL;
CComPtr spStream;
HRESULT hr = ::CreateStreamOnHGlobal(handle , FALSE, &spStream);
hr = ::GetHGlobalFromStream(spStream, handle);

一但有了這個類似 MemoryStream 的 IStream 實做體, 我們還可以利用更多 OLE32 提供的功能, 例如 IPropertyStorage, IPropertyStorage 這個 interface 的功能是個用來存放 property 的 container, property 可以是 PROPVARIANT 所支援的任何 type, WIC 就是用 PROPVARIANT 來記錄存放在 JPEG EXIF 中的 metadata 詳細可以參考 IWICEnumMetadataItem (說遠了), 為什麼要介紹 IPropertyStorage 呢, 因為 OLE32 又提供了一個 system-provided, stand-alone implementation 的實做體, 我們只要提供 IStream 或是 IStorage 給傳給 StgCreatePropStg 這個 API, 它就會送一個 IPropertyStorage 的 instance 給我們, 我想 property bag 這種東西的方變程度就不用說了. 有注意到嗎? 我們只要結合 CreateStreamOnHGlobal 和 StgCreatePropStg, 它就可以幫我們建立一個在記憶體中的 property bag, 這是何等的方便與容易呢?

延伸思考一下 IStream 能不能在 .NET 中使用呢? 當然可以啊因為 IStream 是 COM 呢, 連 .NET Framework 都有對應的 Interop interface System.Runtime.InteropServices.ComTypes.IStream 而 IPropertyStorage 則對應於 MS.Internal.IO.Packaging.CompoundFile.UnsafeNativeIPropertyStorage, 不過似乎沒有公開 ...
(後來查了一下 MSDN 發現 Microsoft.VisualStudio.OLE.Interop 有公開對應大部分 OLE32 的介面, 不過放在一個很怪的 DLL 中 microsoft.visualstudio.ole.interop.dll ) 而 IStream 與 Stream 的轉換則有 DataStreamFromComStream 與 ComStreamFromDataStream 兩個 wrapper class 可以使用, 不過都包在 System.Windows.Forms.UnsafeNativeMethods 這個 internal class 中, 微軟真的很小氣 = =. 不過 UnsafeNativeMethods 真的是大個誇張啊, 大家可以用 .NET Reflector 看一下就可以知道了.

順帶一提 System.IO.UnmanagedMemoryStream 似乎是個不錯用的 class, 它可以 wrapper 一個 unmanaged 的 pointer 程為一個 Stream class, 雖然它是 unsafe 的 class 但是對於 performance 也許有不少幫助呢.

2010 01 02-03 北插天山露營

2010-01-03T19:09:00.011+08:00

這太白癡了不得不貼出來 .....

2010 01 01 跨年

2010-01-01T18:06:00.002+08:00

JPG, PNG, BMP 速度大車拼

2009-12-30T02:11:00.014+08:00

由於工作的關係我得嘗試去分析在相似的軟硬體環境, 小型的影像檔案到底哪個格式的 access 速度比較快呢? 嚴格說這個問題在現代的多工作業系統下是不容易有個穩定的答案, 但是我們還是值得去找到個趨勢來改進我們程式的效能.

首先我們先定義小檔案有多小, 我取了一個以 80x80 的 24bit BMP 檔案做為基準, 該檔案的大小是 19,254 Bytes (磁碟大小 20,480 Bytes), 相對應的 PNG 為 17,533 Bytes (磁碟大小 20,480 Bytes), JPG 為12,532 Bytes (磁碟大小 16,384 Bytes). 我所選擇的 codec 為 Windows Vista 內建的 WIC decoder.

實驗的設計必須考慮作業系統對檔案快取造成的影響以及硬碟檔案的分佈與離散成度, 所以我做了以下的設計:

在實驗前先對目的磁碟做 defragment 來減少斷裂與離散的問題
利用程式對三種格式產生 0000~9999 為編號的 10K 個檔案
每次從 10K 檔案中隨機抽 1K 個檔案做為實驗之用降低快取的影響
每次實驗後都重新開機, 開機後等待系統進入穩態以確保快取的影響降到最低

以下是兩個實驗內容:

實驗一:

對 10K 檔案中隨機抽 1K 個檔案, 使用 WIC 載入記憶體並且 decode 其四次實驗結果如下:

PNG: 81, 86, 109, 110 平均 96.5 files/sec 120%
JPG: 77, 102, 89, 93 平均 90.25 files/sec 112%
BMP: 71, 75, 85, 89 平均 80 files/sec 100%

該實驗的目的在於知道混合 CPU bound 與 I/O bound 的情況下, 不同格式在 WIC codec 的速度

實驗二:
一個檔案已經事先載入到記憶體中, 然後使用 WIC 對相同記憶體 decode 10K 次其結果如下:

JPG: 1788 files/sec 159%
BMP: 1118 files/sec 100%
PNG: 963 files/sec 86%

該實驗的目的在於知道如果排除 I/O bound 的問題, 不同格式在 WIC codec 下速度

其實有只要有 I/O 因素的狀況下變異數都很大, 結果令人訝異的是 PNG 在第一個實驗有較好的表現, 但第二個實驗不考慮 I/O bound 的狀況下卻是最差的, 我能想到的解釋就是 JPG 在 decode 需要花費比較多的 seek time, 但是以磁碟機這種 block based device 來說這些檔案最多才佔 4 個 sectors 而且 JPG 檔案還比較小所以只佔 3 個, 所以 seek 動作應該是不太會發生在一次的 decode 中畢竟硬體不會一次只讀一個 sector.

所以這兩個實驗的結果還是沒有一個合裡的解釋, 誰能告訴我為什麼呢?

從實驗來看可以知道實驗一是個 I/O bound 遠高於 CPU bound 的問題, 所以加速的關鍵會再如何更好的降低 I/O 的影響, 所以我設計下個實驗:

實驗三:

以三種格式做隨機存取來分析哪種方式的 I/O 效率最好,

使用原來的方法做為基準, 一個目錄有 10K 個檔案
將 10K 個檔案合併成一個很大的檔案, 純粹將多個檔案 "黏" 在一起
將 10K 個檔案合併成一個很大的檔案, 使用 COM Structured Storage 來儲存

實驗的結果如下以 PNG 檔案為例

Big chunk file: 309 240 351 平均 300 files/sec 238%
10K files: 104 139 135 平均 126 files/sec 100%
Structured Storage file: 100 72 72 平均 81.3 files/sec 64%

結果變異數還是不小, 不過可以看出一個趨勢就是 Big chunk file 比分散的檔案快而且快很多, 而 COM Structured Storage 是最慢的.

實驗四:

對 Structured Storage 檔案中隨機抽 1K 個檔案, 使用 WIC 載入記憶體並且 decode 其三次實驗結果如下:

JPG: 90, 92, 91, 平均 91 files/sec 133%
BMP: 68, 68, 69, 平均 68.3 files/sec 100%
PNG: 65, 66, 66, 平均 65.6 files/sec 97%

結果的變異數並不大, 且實驗中CPU 使用率很高, 以雙核心且程式使用一個 thread 的情況下, CPU 使用率約 50~54%. 但是實驗一的情況下 CPU使用率相對低很多. 其實 Structured Storage 在大檔案的狀況下效能真的不好但是功能確還蠻迷人, 如果單純用在諸如 Word 這類軟體的 serialize 上的確非常方便, 相關的經驗還可參考 Performance of structured storage files.