tag:blogger.com,1999:blog-62359342024-08-30T04:05:41.427+08:00Sean's BlogThoughts on Software DevelopmentAnonymoushttp://www.blogger.com/profile/06408158878791718465noreply@blogger.comBlogger57125tag:blogger.com,1999:blog-6235934.post-6941801729081479672011-07-10T03:01:00.002+08:002011-07-10T03:12:30.379+08:00Windbg: oleaut32!DllMain+0x76 除錯筆記最近看到了一個令人匪夷所思的 Crash Dump，Call Stack 是長這樣：
0c 078efe7c 770d15a8 oleaut32!DllMain+0x76 (Unloaded)
0d 078efe9c 7c94118a oleaut32!_DllMainCRTStartup+0x52 (Unloaded)
0e 078efebc 7c953a23 ntdll!LdrpCallInitRoutine+0x14
0f 078eff34 7c80c126 ntdll!LdrShutdownThread+0xd7
10 078eff6c 7813299f kernel32!ExitThread+0x3e
11 078eff74 781329c0 msvcr80!_endthreadex+0x1f
12 078effac 78132a47 msvcr80!Anonymoushttp://www.blogger.com/profile/06408158878791718465noreply@blogger.com0tag:blogger.com,1999:blog-6235934.post-88549806818369136272011-05-29T00:27:00.000+08:002011-05-29T00:27:45.162+08:00Automate Characterization Test by Googletest也許你我都有面對過自己不熟析的程式碼的經驗，通常我會用兩種方式來了解程式碼：一種方式就是直接面對做 Code Tracing，讀文件，檢視所有的流程；另一種方式就是從外面去測試，Live Debugging，看看這個程式碼的行為為何。
Characterization Test 指的就是類似後者的策略。Characterization Test 主要是要藉由測試的過程，去檢查(Check)現有的程式碼的行為，而不是去驗證(Verify)現有程式碼是否有符合Specification。最終的目的就是要取出可以代表目前程式碼的特徵(Characterizing)。
事實上，很多程式碼本身就沒有 Specification 來定義行為，純粹就是做到剛好可堪用(Just work)。當後來在修改的時候，如果又沒有 Unit Test，要避免任何不必要的 Side-Effect，大概只能夠依靠Anonymoushttp://www.blogger.com/profile/06408158878791718465noreply@blogger.com0tag:blogger.com,1999:blog-6235934.post-34489487576961786502011-04-30T04:07:00.006+08:002011-07-26T16:01:50.764+08:00WinDbg: CreateProcessAsUser 回傳 ACCESS_DENIED 之案例分析最近手邊處理了一個案例。因為一些特殊需求，想要試試看在 Administrator 帳號下，呼叫 CreateProcessAsUser 建立在別的 Logon Session 的進程。這並不是一個典型的應用。你可以照著 MSDN 上的說明處理，幫 Administrator 加上需要的權限，看起來可以在 Console Session 上正常運作。
事情沒那麼簡單，在 Windows Server 2003 下面，CreateProcessAsUser 沒辦法在 Terminal Service 的 Logon Session 下面建立進程，永遠會得到一個 ACCESS_DENIED (5) 的錯誤碼。不過，MSDN 並沒有描述這個錯誤碼的原因。
看來，要有把手弄髒的心理準備。
首先，嘗試用 WinDbg 逐步執行看看是哪裡丟出了這個錯誤碼。結果發現，Anonymoushttp://www.blogger.com/profile/06408158878791718465noreply@blogger.com0tag:blogger.com,1999:blog-6235934.post-39566145758968996442011-04-23T01:19:00.002+08:002011-04-30T19:49:36.319+08:00WinDbg：手把手教你看C++ Exception不管是用WinDbg打開一個Dump File或是Live Debug，如果遇到的是C++ Exception的話，WinDbg就會丟出C++ EH exception的訊息。
(abc.2dc): C++ EH exception - code e06d7363 (first/second chance not available)
eax=073bee80 ebx=03bb12f0 ecx=00000000 edx=00000000 esi=073bef08 edi=0000005c
eip=7c812afb esp=073bee7c ebp=073beed0 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=Anonymoushttp://www.blogger.com/profile/06408158878791718465noreply@blogger.com0tag:blogger.com,1999:blog-6235934.post-49833223420291950852011-04-14T01:21:00.000+08:002011-04-14T01:21:21.954+08:00Googlemock: Mock Object 應用於 C++ RAII 實例在 Unit Test 中，Mocking 的技巧是用假的元件去取代受測元件所依賴的外部元件，稱為 Mock Object。測試者藉由控制 Mock Object 去可以改變受測元件的內部流程、或是驗證受測元件與外部元件的互動行為。
在 C++ 當中，常常慣用 RAII 的技巧，讓 Object 在進入 Function/Block 的範圍內獲取資源，離開範圍內釋放資源。舉例來說：
void example()
{
File file("output.log");
file.write("test");
}
在這種情況下，通常都會在測試程式中另外實作一組假的 File。不過，因為 Object 生成的時機是在進入受測的函式中，沒有機會用 ON_CALL 去控制 Mock Object 的行為。
所幸，你可以用下面的方式將 File 的實作，交給另外一個擁有相同介面的類別。Anonymoushttp://www.blogger.com/profile/06408158878791718465noreply@blogger.com0tag:blogger.com,1999:blog-6235934.post-17970811985051816642011-04-11T02:00:00.000+08:002011-04-11T02:00:31.328+08:00NacoOS期末作業[本來想要把另一個已經廢棄已久的 Blog 關掉，發現有兩篇文章被大量閱讀。看起來應該是對某些人還是有些幫助，我決定將他們轉錄到這邊來。感謝讀者的支持。]
期末專題(NachOS)有兩個作業-Implement system call "Sleep"
Implement SJF scheduling
紀錄一些過程，免得做報告時忘記了...Implement system call "Sleep"
Implement Alarm.waitUtil(...) by InterruptHandler, getTime(). Then implement syscall sleep(...).
Sleep(...)一定會不準，因為waitUtil(...)是以Real-Time為準，可是卻是以InterruptHandler實做(InterruptHandler天生就不準)。
ImplementAnonymoushttp://www.blogger.com/profile/06408158878791718465noreply@blogger.com0tag:blogger.com,1999:blog-6235934.post-46587786211672332522011-04-11T01:52:00.000+08:002011-04-11T01:52:45.826+08:00NachOS安裝心得[本來想要把另一個已經廢棄已久的 Blog 關掉，發現有兩篇文章被大量閱讀。看起來應該是對某些人還是有些幫助，我決定將他們轉錄到這邊來。感謝讀者的支持。]
Date: 2005/06/15
作業系統期末作業是以NachOS這個教學用的平台，體驗作業系統的運作。不過，安裝的過程卻一點也不順遂，所以我把一些安裝心得整理在這邊；方邊我自己參考，也幫助其他同樣遭遇到安裝問題的人。
目前我有找到四個NachOS版本，一個是最原始的，用C++實做的版本；另一個也是用C++實做的版本；最後兩個是跟隨其後，以Java來實做的版本。四種版本的架構都很類似，而我就是在安裝C++版本遇到挫折之後，轉而決定要來累積一些心得的。
NachOS 4.0 (C++ version) @UC Berkeley
NachOS 4.1 @Universität Karlsruhe
NachOS 5.0j @UC Anonymoushttp://www.blogger.com/profile/06408158878791718465noreply@blogger.com0tag:blogger.com,1999:blog-6235934.post-72149200589782394432011-04-10T20:05:00.000+08:002011-04-10T20:05:18.088+08:00軟體測試：Unit Test 隨便談，從動機到工作流程改善在軟體測試的領域裡，最能夠吸引開發者的測試系統大概就是 Unit Test。這難以假手於他人的 Best Practice，莫不提起開發者對於 Unit Test 既予高度的期待。大部分的討論主題都是在教你如何寫出容易維護的 Unit Test，或是提高 Testability 的程式設計技巧。但我認為更重要的是要討論 Unit Test 的動機，進而了解它對於專案開發效益，到底可以帶給開發團隊什麼樣的好處。
上圖說明了我們對於軟體開發過程的假設。在任何階段產生的臭蟲，如果不能及時被抓出來，維修的成本提昇的速度會隨著它潛伏的時間快速成長。舉個例子，Toyota 的煞車延遲事件，如果提前在研發或工廠中發現問題，純粹就只是一個工程的問題，而不會是對簿公堂，變成競爭者攻擊的話題，它所損失的絕對超過產品本身召回的金額。
那麼，如果可以越早的找到臭蟲，我們就可以降低已知問題Anonymoushttp://www.blogger.com/profile/06408158878791718465noreply@blogger.com0tag:blogger.com,1999:blog-6235934.post-41507955145059506972011-04-01T22:49:00.001+08:002011-04-01T22:54:47.587+08:00Win32程式設計: _beginthreadex or CreateThread?先說結論，永遠先用_beginthreadex()來建立新的執行續，把它當作是你的 Code Convention。
為什麼？先從動機說起。
在 C Run-Time (CRT) 函式庫裡有許多函式在多執行續的環境下，會利用 Thread Local Storage (TLS) 去存取每個獨立執行續的資源，藉此達到 Thread-Safe。
舉例來說，errno 是檢查錯誤碼的變數，在多執行續的環境下，如果A()和B()兩個函式從不同的執行續改寫了 errno，那麼接下來的程式碼就無法確認 errno 來決定上面一個函式究竟是成功還是失敗。
為了解決這種問題，在多執行續的 CRT 下，errno 會被替換成 #define errno (*_errno())。_errno() 裡面做的事情就是去取出 TLS 裡面存放的 per-thread errno。這樣每一個執行續Anonymoushttp://www.blogger.com/profile/06408158878791718465noreply@blogger.com0tag:blogger.com,1999:blog-6235934.post-51457891241858792692011-03-28T01:54:00.000+08:002011-03-28T01:54:35.721+08:00軟體設計：給Developer的四個好工作習慣提案在我的工作環境中，Developer和QA是兩個不同的腳色。在開發的過程中兩者就不斷的在Coding-Testing-Debugging的反覆循環中讓事情繼續前進。就因為這個生產線般的過程，Developer所做的事情都會直接影響QA的工作效率。
所以，如果你是Developer，在你提交你的程式碼以前，請保持以下的好習慣：
至少測過一次：
不管修了多小的Defect，請在自己的機器上測過一次，然後再交給QA。如果你聲稱解決了某個Defect，QA卻驗證失敗，除了浪費了QA的驗證時間（人家也是要在很多Test Case之間Context-Switch的...），也會讓QA對於Developer的程式碼失去信心。
確認已同步最新的程式碼：
如果你的團隊有用SCM（沒有嗎！God bless you...），在提交程式碼前，請再一次同步程式碼。如果有變動，就請再重新編譯一次。如果你的專案Anonymoushttp://www.blogger.com/profile/06408158878791718465noreply@blogger.com0tag:blogger.com,1999:blog-6235934.post-85398234507919142522011-03-24T23:47:00.001+08:002011-03-24T23:49:00.521+08:00User-Buffered I/O for C Library昨天討論到了 Win32 Kernel Mode 下的 Buffered I/O 和 Unbuffered I/O 的差異。其實在 User Mode 的環境下，C標準函式庫的File I/O（fread, fwrite...）也存在自己的 Buffered 方式，稱之為 User-Buffered I/O 或稱為 Stream Buffering。重點在於決定何時把 Buffer 內的東西透過 System Call 倒入 Kernel Mode。
Fully Buffered:
系統或 Caller 決定一個固定大小的緩衝區。
當透過 File I/O 寫滿緩衝區，I/O 才會發生。
Line Buffered:
當 File I/O 寫到換行符號，I/O才會發生。
在 Win32，沒有這個選項...
No Buffered:
就是沒有Buffer...
Anonymoushttp://www.blogger.com/profile/06408158878791718465noreply@blogger.com2tag:blogger.com,1999:blog-6235934.post-36519796288109242992011-03-23T23:52:00.000+08:002011-03-23T23:52:03.952+08:00Buffered I/O & Unbuffered I/O簡單來說，
Buffered I/O 讀寫的資料都會經過 Cache Manager，會暫存一份在 Memory 當中，然後會根據作業系統決定寫回硬碟的時機（如果用 Write Through，還是可以自行控制）。此模式適合常讀寫檔案，因為可以快速的從 Memory 讀寫。
(想想 L1, L2 cache 之於 RAM 的關係。)
Unbuffered I/O 讀寫的資料不會經過 Cache Manager，而是直接對硬碟讀寫。因此也不會因為大量讀寫資料造成 Cache Trashing。
以下是我的推測，不代表真實測試結果。XDInstaller 的檔案複製可能就適合 Unbuffered I/O，因為 Buffered I/O 可能會造成大量的 Cache Trashing。
當有大量的 Cache Trashing 發生時，可能也會影響到 Unbuffered I/O 的效能。Anonymoushttp://www.blogger.com/profile/06408158878791718465noreply@blogger.com0tag:blogger.com,1999:blog-6235934.post-18151185905981507462011-03-22T23:09:00.000+08:002011-03-22T23:09:01.219+08:00C++：auto_ptr, scoped_ptr, shared_ptr and weak_ptr簡單整理各種Smart Pointer的特色：
auto_ptr
Supported in C++ Standard Library
Support Ownership Transfer
scoped_ptr
Supported in C++ TR1
Not Support Ownership Transfer
shared_ptr
Supported in C++ TR1
Using Reference Count
Object copy or assignment will increase the reference count.
weak_ptr
Supported in C++ TR1
Created from shared_ptr. Cannot be created alone.
Support Ownership Transfer
Easy and safe to Anonymoushttp://www.blogger.com/profile/06408158878791718465noreply@blogger.com1tag:blogger.com,1999:blog-6235934.post-26858542605810239802011-03-12T16:48:00.001+08:002011-03-12T16:57:45.944+08:00軟體設計：設計是什麼？從自身經驗說起在1992年，Jack W. Reeves發表了一篇"What is Software Design"。主要的論述就是表達"Source code is the design."的看法。
這點也和我自己的經驗不謀而合。在專案的規劃中，我們都把需求(Requirement), 設計(Design)和建構(Construction)分開成為一個循序的過程。設計過程是確保你可以建構出符合需求的working software/component。但是在真實的情況下，我所經歷的設計過程其實是一些不同的Activities不停的來回，而且沒有一定的順序。譬如說：
首先要了解需求，開始設計。
如果設計發現有定義模糊的需求，要進一步和stakeholder釐清。
為了要確保設計是可行的，也須需要做POC(Proof of Concept)。
魔鬼都在細節中。所以POC也不能馬虎，幾乎就是要做到Anonymoushttp://www.blogger.com/profile/06408158878791718465noreply@blogger.com0tag:blogger.com,1999:blog-6235934.post-940413654166301452011-03-11T03:09:00.000+08:002011-03-11T03:09:34.511+08:00Security Enhancement in CRT: Good or Bad Side-Effect?從Visual Studio 2005開始，編譯器都會建議使用者把某些CRT function換成更安全的版本。舉例來說，編譯器會建議你把strcpy改成strcpy_s。
這樣改的好處是什麼呢？在程式執行的過程中，有一種類型的bug叫做buffer overflow。以strcpy來說，就是你的來源字串長度可能比準備的buffer來的長，又因為strcpy沒有buffer size的資訊，所以在資料複製的過程中，就有可能覆蓋到buffer後面的資料。
如果buffer在stack上，那就有可能覆蓋到其他變數，甚至是call stack的return address。總之，小則程式執行不正常或崩潰，大則會被attacker利用來取得控制權。
換成安全的版本，編譯器就會嘗試把buffer size偷偷帶進strcpy_s當中，幫你在執行的過程中檢查有沒有buffer overflow。Anonymoushttp://www.blogger.com/profile/06408158878791718465noreply@blogger.com0tag:blogger.com,1999:blog-6235934.post-59045219972884606572010-10-28T13:12:00.003+08:002010-11-14T00:47:23.734+08:00[網摘] High Scalable Architecture底下只是一些資料收集，都是關於"High Scalable Architecture"的一些研究和實作。Jeffery Dean: MapReduce論文的作者, Protocol Buffer的創始人。
http://research.google.com/people/jeff/
Dan Kegel: 經典"The C10K problem"的作者。
http://www.kegel.com/c10k.html
Felix von Leitner: 在2003年以一篇"Scalable Network Programming"對於Web Server做深入分析。
http://www.fefe.de/
http://bulk.fefe.de/scalable-networking.pdf
Node.js: 以V8 JavaScript engine為基礎的JavaScript Anonymoushttp://www.blogger.com/profile/06408158878791718465noreply@blogger.com0tag:blogger.com,1999:blog-6235934.post-86426388774208161352010-10-23T03:15:00.001+08:002010-10-24T03:16:11.969+08:00悖論與Halting Problem悖論是指某些奇特的推論。這些推論的假設和邏輯看似合理，但卻帶出明顯地不可接受的結論。(思方網) 用邏輯的語言來說，悖論就是若假設命題A為真，經過一系列合理的推導，最終卻得到命題A為假的結論。
Halting Problem就是悖論的一個例子。Halting Problem是說是否可以寫一支程式，用來檢查任何一個程式是否會在有限的時間內結束。最後的結論是不可能存在這樣的一支程式，證明的方式正是利用悖論中的矛盾。
推導過程很簡單，首先假設這支程式已經存在，我們命名為H(M, w)，M為任一支被檢查的程式，w為M的輸入參數。為了方便說明，我把H(M, w)表示成為虛擬碼。
Function H(M, w)
{
if M(w) halts
return true
else
 Anonymoushttp://www.blogger.com/profile/06408158878791718465noreply@blogger.com2tag:blogger.com,1999:blog-6235934.post-4202025802391633342010-08-27T02:33:00.003+08:002010-08-27T03:01:40.704+08:00今日隨筆今天在幫朋友看一個電腦的問題，過程中發現很多使用者介面設計的想法：介面的文字要明確之外，還要白話。像是UAC視窗，剛從XP時代升級上來的使用者，會因為UAC被嚇到。另一種想法就是要有足夠的教育訊息(第一次發生UAC的時候可能要有一段簡易的Tutorial。)使用者完成他的目的後，介面一定要有明確的訊息去告訴使用者目前已經完成。有些程式是Console模式，執行完就消失，使用者完全不知道是做完了沒。初階的使用者更需要準確的指示讓他們Steps by Steps完成一件事情，如果提供一些模糊的指示只會讓他們更害怕去操作。(像是Screen Shot比文字描述更容易讓初階使用者接受)Anonymoushttp://www.blogger.com/profile/06408158878791718465noreply@blogger.com0tag:blogger.com,1999:blog-6235934.post-4273242822039037672010-03-14T19:41:00.001+08:002010-03-14T19:41:00.266+08:00《書籍》理性市場的神話 最近閱讀的經濟書籍當中，最想推薦的大概就是這本了。內容涵蓋範圍很廣，作者明快的敘述了20世紀的華爾街與學術界在經濟學和財務學上的互動。 從前都是單獨閱讀大師的著作，多少會被作者的思維帶著走。不過從歷史的角度來閱讀，多了比較，也多了一些批判。如果有看過裡面提到的一些書籍，我想更會有把事情串起來的感覺。 題外話，好像電腦科學從二戰之後也已經快要步入百年歷史，不知道有沒有類似的書籍也可以來讓讀者過癮一下呢。 Anonymoushttp://www.blogger.com/profile/06408158878791718465noreply@blogger.com0tag:blogger.com,1999:blog-6235934.post-53336178342972065212009-11-25T01:10:00.000+08:002009-11-25T02:11:32.369+08:00軟工隨想：User Login is not a Use Case.以前在學校的時候上過一門軟體工程的課，課堂最後有個期末專題。專題內容就是要我們親自跑一次Project。我記得那時候做了一個線上聊天室系統，在台上Demo系統Login的時候，被助教問了個問題：為什麼User Login不在你們的Use Case中？ 對呀，為什麼我忘記把Login/Logout放進Use Case中呢？當時我一直覺得一定是自己的粗心大意，忽略了這個功能。不過，最近閱讀到Karl的書，作者指出User Login並不適合放進Use Case中，也解答了為何從需求的角度來看待系統，很容易就會忽略User Login的Use Case。 Karl首先定義Use Case的涵義： Describes how an actor uses a system to achieve a goal and what the system does for the actor Anonymoushttp://www.blogger.com/profile/06408158878791718465noreply@blogger.com0tag:blogger.com,1999:blog-6235934.post-77080229872086122702009-09-27T00:41:00.001+08:002009-09-27T00:42:57.033+08:00書摘：與熊共舞—軟體專案的風險管理在漸進交付計畫這一節當中，有一段是這麼說的。
The second constraint is that the design blueprint must show the entirety of the design partitioning, down to the lowest level. It's common practice to do some hand-waving at what seems to be an upper-level design, declare the design complete, and leave the rest of the design partitioning to be done as a by-product of coding. When this happens, all the advantages of the Anonymoushttp://www.blogger.com/profile/06408158878791718465noreply@blogger.com0tag:blogger.com,1999:blog-6235934.post-44454167821001429932009-09-04T01:11:00.000+08:002009-09-04T03:13:26.372+08:00軟體除錯《Cross-DLL Hazard: Multi Copies of Template Class》在編譯 DLL 的時候，Template Class 的 Code 都會被編譯 DLL 當中。因此若整個專案裡面有數個 DLL 分享同一份定義在 .hpp 的 Template Class，那麼你就有可能會有好幾份同樣 Type 的 Template Class 的 Code 落在數個 DLL 中。如果把物件轉成指標 Cross DLL 互傳，可能會遇到底下幾個問題。 不同的DLL可能使用不同版本的 .hpp。如果在這種情況下，Template Class 沒有做到 Binary Compatibility，那麼 A DLL 傳給 B DLL 的物件，操作一定會有問題。 就算不同的DLL使用同樣版本的 .hpp，還是會有問題。舉例，A DLL 傳給 B DLL 的物件之後，最後 A DLL 先 Unload，而 B DLL 手上握的物件洽好有參考到 Virtual Method Anonymoushttp://www.blogger.com/profile/06408158878791718465noreply@blogger.com0tag:blogger.com,1999:blog-6235934.post-56261891002338556152009-08-21T00:46:00.000+08:002009-08-21T02:47:18.717+08:00Code Inspection 經驗談軟體測試的方法中，有一種是叫作 Code Inspection，測試的流程就是請工程師根據 Checklist 和人工 Walkthrough 程式邏輯去找出程式碼中的錯誤。按照 Wikipedia 的定義，流程可以分為： Planning: Moderator 負責計畫 Inspection 的內容和時程。目的是 Initiate 和 Follow 一次完整的 Inspection。 Overview meeting: Author 簡介自己的程式碼。目的是先幫助 Inspector 可以更快進入狀況。 Preparation: 每個 Inspector 在舉行 Inspection Meeting 之前先要閱讀程式碼並且標記所有找到的錯誤。目的是先將所有的錯誤找出來。目的是要 Identify 出所有的 Defect。 Inspection meeting:Anonymoushttp://www.blogger.com/profile/06408158878791718465noreply@blogger.com0tag:blogger.com,1999:blog-6235934.post-67322173824707878912009-08-17T00:41:00.001+08:002011-05-01T23:50:09.984+08:00[Windbg] How to Brake at Child Process Creation有時候，想要從進程(Process)一建立起來就開始除錯，一種方式是直接用 Windbg 直接用 .create 去把進程跑起來。可是在 Google Chrome 這種多進程的程式，想要從某個子進程開始除錯，一定要等主進程把子進程帶起來時才可以除錯。此時，就會需要用一些技巧讓 Windbg 去中斷子進程。
首先，先執行 Google Chrome，它是一個多進程架構的瀏覽器，適合作為這次的範例。
然後，在用命令列或GUI的方式 Attach 到主進程 Chrome.exe (1508)。
1) 用 .childdbg 1 命令 Windbg 中斷在子進程的建立。
0:013> .childdbg 1
Processes created by the current process will be debugged
2) 用 g 命令 Windbg 繼續執行程式，並且去Anonymoushttp://www.blogger.com/profile/06408158878791718465noreply@blogger.com0tag:blogger.com,1999:blog-6235934.post-45894533279457178742009-08-15T01:39:00.002+08:002011-04-13T00:00:38.988+08:00免費 Win32 Kernel/User 效能分析工具 - Kernrate“Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest.” - Rob Pike
在Windows平台上，Microsoft有推出一個可以測量Kernel/User Mode的System Profiler。我們可以用它測量某一段時間的各種Performance Statistics。最棒的是，它可以用取樣(Sampling)的方式來統計出哪些API是屬於HotSpot，可以成為Performance Tuning的根據。
首先，可以在Microsoft Download上面找到它。
http://www.microsoft.com/downloads/details.aspx?familyid=Anonymoushttp://www.blogger.com/profile/06408158878791718465noreply@blogger.com0