將中斷改為其他程式觸發：
將中斷改由外部程式控制，其中Timer改為外部程式觸發可以改為可以”停格”的作業系統模擬，可以觀察各中斷程式是否有執行異常，或是驗證程式。結果如下：
改進資料傳輸：
資料傳輸功能主要是可以使uCOS-II可以模擬在大量資料輸入狀況下，測試程式是否正常，可以應用在有通信的狀況下，或有輸出入資料的狀況下，看程式對於資料處理的情況。也可以增加除錯的報告，將程式運作的各種狀況報告，增加對程式的除錯。實行則以選擇跨行程通信的方式來做，選擇使用Pipe。因為Pipe具有以下特性：
1. 在Windows及Linux皆可以使用，具有平台轉移性。
2. 以檔案呼叫方式做為資料傳輸的方式，容易理解函式的用法。
因為檔案呼叫也會停止Thread，故Pipe實現在uC/OS-II中亦要一個獨立Task才不會干擾到其他的Task。結果如下：
可以發現兩支應用程式的資料為完全一樣，證明有寫到uC/OS Win32 Port。而且可以設定在Server程式關閉時，Client端亦可同時關閉。
加入此功能可以實現以軟體模擬外部環境對uC/OS-II做輸出入測試。
其他問題及改善提議：
在Windows上模擬uC/OS仍和DOS上執行的uC/OS有些行為不同。
1. random()行為不一樣：每一個Thread都有自己的random()的變數，和DOS不同是共用，所以不用保護也可以正常使用。但各Task的random()產出的數列完全相同，在DOS則完全不同。使得Win32 port模擬結果和DOS不同。
2. Mutex功能使用後當機，經查原始碼，發現也是因為hTaskThread[]沒有同步更新造成。
若是將Win 32A PI Thread Handle放在TCB中管理也許可以解決，但要重新做核心除錯。其主要構想為：
1. 利用沒有用到的Stack做為Thread Handle存放地方，就可以經由TCB管理。而Stack在實體CPU會用到，但也不會亂改，所以是安全的。
2. 影響到函式有OSSchedulThread()及OSTCBInitHook()。
3. 需要修改的變數有二個hTaskThread[]及taskSuspended[]。
4. taskSuspended[]是管理task是可以執行或是不可執行flag。
hTaskThread[]是Win32API的Thread Handle。此二個變數要改用Stack做為存放的地方，故資料結構要做變動。
5. OSTCBInitHook()是向Win32API申請Thread Handle的函式，要改成Handle改存到pTcb->OSTCBStkPtr，taskSuspended[]標記亦一併存入。
6. OSSchedulThread()則要改成取用Handle時改由OSTCBCur->OSTCBStkPtr中取出Win32API Thread Handle，taskSuspended[]標記亦一併取出。
實作驗證是成功的。
後記：在要發表這篇時，將舊程式拿出來Run時，結果是當機的。原因在於Bee換了一台雙核電腦。也就是原先在單核心上是可以正常執行。
也因這個原因，改善的部分延至今日發表。
因為已經找到當機原因，且有在研究解決方法了。
所以就再次發表。後面會加上新的版本。
