「系統架構、邏輯運算」的不同！

計算器有「五大單元」 的型態！



經常會聽到「系統變數」這種說詞？

其實？

「邏輯運算」也就是「語言編譯器」運行的環境，去「設定存取模式」！

這使得「大多數的「編程人員」 不需要去思考「系統架構」，而能夠方便的「撰寫程式」。

這也使得「編程人員」成為「尾巴大」的一群！

而這樣的「尾巴大」 之下，「編程人員」多半在運用「現有、以存」的函式庫，去運行整個程式的運用，若萬一？缺乏一個「函式、驅動」的組態時，「尾巴大」將無法作任何工作！


因此？

許多「尾巴大」，都留存在「特定的平台」，去編輯他門的「編譯器」，而這種情節？也限制他們在「資訊工作」專業的偏門？而無法回到「基礎架構」上，去編輯「原生系統」，而永遠留在「語言架構」上！

這個情況；除了「純粹的「 C 語言、BaseScript」外？都無法由「低、中、高階語言」去解決！」


必須經由「變數」去架構「存取直譯器」的編輯平台？這只能運作在「邏輯運算」的層次，而無法突破。

而「中、高階語言」 又偏向「組態變數」的呼叫，這對「系統在函式變數」的需求就更大！

在編譯器呼叫「系統變數、系統函式」 的結構時？就造成「往複運作」的問題？

在「直譯語言」時，「邏輯運算」發生難以證明的「困難」，這種現象在「Win95 ~ Win 9X」時期，就非常明顯的看到「尾巴大」，經常寫出「運行有異常」的編譯。

要改變這樣的困擾？

必須要由「系統工程」 上去釋出完善的「變數、函式」才能解決嗎？

 或說？你一開始決定對什麼「系統構成」下？去編譯「語言」，而能增加「效能」？


在「語法宣告、流程簡潔 、直譯迅速、減少累贅」的流程結構，才能符合，最有效的「編譯效能」。


「為此？其實 ？難道？」

能簡單運作的「Basic」 難道很困難嗎？

 以「Vbasic Script ( vbscript )」來說？

有人說「Vbasic Script」是「DOS batch」的進階型態？


他有效的介入

一、Windows作業系統
二、網頁瀏覽器（客戶端的VBS）
三、網頁伺服器（伺服器方面的VBS）

（ VBS 也作為「變數」供其他「編譯需求」，去呼叫VBS；藉此取得 VBS 在整各系統邏輯的需要。）

「 VBS 」對於「DOS batch」這樣一個角色？其實具備很大的進階功能！

近來？微軟開始推行「Power Shell」這樣一個「純文字主控台」，來替代「VBS、DOS batch」............

但在「 Power Shell 」的「相關語言庫」，未能完整開放前？「Power Shell」 就成為一個「閒置」的需求，畢竟「Power Shell」的語言型態？與先前完全不同！

他的架構可說是「更接近「系統」描述」的方式，去達成「各種運行」？

 在「Power Shell」的效益？卻又是回到「微軟 .NET Framework 」的觀念上？

「.NET Framework」 是微軟用以向「Java」競爭的高級語言！又在延伸出一個「Power Shell 」；其實？有人說「Power Shell」的價值是「連結工具」，但若要進行連結？為何不直接採取「Exchange」？


在主控台用 Power Shell 銜接「COM+」與「.NET」架構嗎？



竟而造成人們嫌棄  Power Shell 為一個無用機構！成為一個累贅。


因為這顯得？微軟將「相關資源」釋出給「Power Shell」去做出合理編譯！

這使得「微軟作業系統」建構出一個「中間者 = Power Shell」的「再處理」現象，使得不少「需求」必須經由「Power Shell」處理後，轉給其他「介面」去再生 Per View 這並不是一個良好的系統現象。

 .