共用方式為

簡介

  • 發行項

 

簡介

Brent Rector
明智的 Owl 諮詢

2003 年 10 月

目錄

本書的用途
    「Longhorn」 應用程式模型
    可信任的運算和安全性
    豐富的儲存體和資料存取
    通訊和共同作業
    豐富的簡報和媒體
您可以在此書籍中找到的內容

身為許多年的軟體發展人員，我針對許多平臺和作業系統撰寫了程式，全都有其優點和缺點。 一般而言，大部分的平臺和作業系統都類似于其前置專案，並具有累加式改善。

到目前為止，Microsoft® Windows® 本身已以這種方式演進。 一開始，撰寫 Windows 應用程式的目的是要對 Microsoft Win32® API 進行程式設計。 (實際上，它是 Win16 API 一次，但它們在概念上相同。) Microsoft 將 WIN32 API 設計為 C 程式可呼叫的一般程式 API。 一次，為任何 Windows 應用程式開發人員閱讀了此 API 的Charles Petzold 程式 設計 Windows書籍。

WIN32 API 的一件好事是，它可讓您執行許多您想要的動作。 (您幾乎 必須 執行您想要的所有工作。) 您必須先在所有 Windows 訊息上破解，並回應它們以任何適當 (或不當) 方式發出訊號的事件。 您可以修改記憶體—您自己的進程記憶體，甚至是另一個進程的記憶體，不過您想要的安全性允許。 您可以用任何方式繪製視窗。 您的作業 只是 在正確的時間，將正確的位放在正確位置的畫面上。

Windows 本身的設計實際上相當物件導向。 您可以操作視窗 物件、使用圖形 化手寫筆等等。 不過，您可以藉由呼叫正確的 API，以適當的順序從數千個可用的) 中呼叫正確的 (API，並傳遞適當的資料類型，大部分沒有編譯器在發生錯誤時提供協助來執行這些作業。

當 Microsoft 第一次發行 Windows 之後，軟體發展人員通常會撰寫整合式隔離的應用程式。 開發人員沒有撰寫應用程式的元件，也沒有支援組合的機制;此外，應用程式並未嘗試與相同系統上的其他應用程式通訊，更不要與不同電腦上的應用程式通訊。

在 1993 年，Microsoft 引進了元件物件模型 (COM) 。 Microsoft 將 COM 設計為嘗試解決下列兩個問題。 COM 引進二進位標準，讓不同來來源語言編譯器所產生的元件可以使用不可變的介面定義來互通。 分散式 COM (DCOM) 網路通訊協定可讓這些元件跨進程和機器界限進行互動。

Microsoft 在 1993 之後引進的許多 Windows API 都是以 COM 為基礎的 API。 兩個範例包括 Microsoft DirectX® 和 Shell 擴充功能 API。 目前，Windows 有 10，000 個 API，由許多不同的開發人員在許多不同的小組上設計，其目標不同。 因此，Windows 會將某些 API 公開為動態連結程式庫中的一般 C 語言進入點， (DLL) 。 它會將其他 API 公開為一組複雜的互動 COM 介面。 還有其他 API 可讓您使用其他技術來存取。

實際上，您是開發人員，希望作業系統在大部分時間都受到這種複雜度防護。 因此，Microsoft 和 Out 內有許多不同的小組開發了各種架構程式庫，以簡化應用程式開發。 某些熱門的架構程式庫是 Microsoft Foundation Classes (MFC) 、Microsoft ActiveX Template Library (ATL) 、Microsoft Visual Basic® 中的程式庫、Borland 的 Object Windows Library (OWL) ，而且不確定許多其他程式庫。

例如，MFC 會嘗試使用一組一致且物件導向的 C++ 類別來包裝 WIN32 API 的各種慣用語。 當您選擇的程式設計語言是 C++，而 MFC 程式庫直接支援您想要執行的動作時，您的作業很簡單。 不過，當您想要一些稍微超出主流的內容時，您大多是自己，事實上，其形狀比之前還差，因為您現在必須瞭解如何使用 WIN32 API，再加上讓您的工作與現有的 MFC 類別交互操作。

ATL 可讓您撰寫非常有效率的 COM 物件，以及使用模糊和 (給許多開發人員的 Windows 應用程式，) 無法理解的 C++ 樣板型類別。 這並不遠的延展性，表示您可以輕鬆地得到沒有人瞭解的高效能物件。

Microsoft 的 Visual Basic 小組採用不同的方法。 他們會以容易學習和使用語言和程式庫的方式包裝 WIN32 API 的存取權，但會犧牲移除功能和選項。 Visual Basic 讓產生應用程式及使用這些元件之應用程式的元件非常簡單。 不過，Visual Basic 不允許您完整存取 WIN32 API 供應專案的所有專案。 有時候 Visual Basic 開發人員因為所選開發環境所加加的限制而無法完成工作。

在 1990 年代初期到 1990 年代，World Wide Web 已關閉。 電腦開始變得更為連線。 一開始，網頁瀏覽器只會轉譯靜態 HTML，流覽網頁很像查看雜誌頁面。

當 Microsoft 在 1997 年發行 Internet Explorer 4 時，其他可能性就會出現。 開發人員可以建立包含腳本加上標記的 HTML 檔案。 HTML 物件模型中的物件取得行為，您可以撰寫回應事件並提供自訂行為的腳本。 HTML 頁面現在可以回應用戶端上的使用者事件，並比需要每次螢幕更新往返伺服器的先前 Web 應用程式更快速回應。

Web 應用程式的其中一大優點是，只要將一組檔案複製到伺服器，即可輕鬆地部署應用程式。 下次用戶端流覽至應用程式時，她與最新版本互動。

Web 應用程式的另一大優點是豐富媒體整合的內建支援。 流程型頁面配置和支援多個字型、圖形和多媒體內容，比目前透過 Win32 應用程式所提供的 Web 應用程式更為容易，不論您使用的架構為何。

不過，整體來說，目前仍難以撰寫 Web 應用程式，因為這類應用程式的程式設計語言和程式庫支援有限。 偵錯 Web 應用程式通常是一個夜間。 在許多方面，用戶端使用者體驗仍然不如以 WIN32 API 為基礎的用戶端應用程式所提供的豐富，因為 Web 應用程式可用的控制項集有限。

在 1990 年代之前，Windows 開發人員通常必須特製化。 您是 WIN32 API 程式設計人員，可以緩慢寫入任何類型的用戶端應用程式。 或者，您是 Visual Basic 開發人員，而且可以撰寫相對豐富的表單型使用者介面， (UI) 應用程式，但完全無法撰寫特定其他類型的應用程式。 MFC 開發人員稍微雜亂這兩個極端，雖然實際上，您必須是熟悉 WIN32 API 的不雅 C++ 開發人員，才能成為良好的 MFC 開發人員。 ATL 和 COM 物件開發人員通常是系統的管線，並提供這些其他開發人員重複使用的元件。

在 2000 年，Microsoft 引進了 .NET。 確切 .NET 的定義 會 根據您詢問的內容而有所不同。 在我的意見中，.NET 是一種新式軟體發展平臺，其產生速度比先前更快速、更正及保護使用 XML 和 Web 服務等最新技術的 Windows 應用程式，同時仍允許存取您的傳統程式碼。

一般 .NET，特別是 Managed 程式碼，為軟體發展人員提供許多優點：

  • 物件導向、語言無關、型別安全的物件模型。
  • 減少不同元件版本之間的衝突。
  • 由於常見的程式設計錯誤，導致 Bug 和安全性漏洞數目降低。 例如，沒有更多緩衝區溢位，而且不會再發生記憶體管理錯誤。
  • 所有開發人員都可以使用的單一架構和程式庫集。 .NET Framework類別庫會封裝最常使用的 WIN32 API，以及整合套件中許多 SDK 所提供的其他 API。
  • 比先前可用的抽象概念更高。

在某些方面，.NET 只是一個新的物件導向、語言無關的架構，可封裝 WIN32 API 的許多層面。 個人來說，我偏好將 .NET 視為 WIN32 API 的最新替代專案，但隨著時間而變得更完整。

例如，.NET 1.0 版提供物件導向、以表單為基礎的用戶端應用程式開發類別。 您可以將這些視為基本 Win32 視窗化 API 的包裝函式。 不過，.NET 也提供 ASP.NET 類別來封裝 Web 應用程式開發和 HTML 加上行為產生。 這些類別實際上會擴充 Windows API，而且不是 WIN32 API 中任何專案的包裝函式。 .NET 對 Web 服務和 XML 的豐富支援一般是 .NET 提供的新功能兩個更多範例，而不是現有 Win32 功能的簡單包裝函式。

本書的用途

本書籍著重于開發人員的 Microsoft 「Longhorn」 功能。 從開發人員的觀點來看，「Longhorn」 提供我們廣泛分類五個領域的新功能：

「Longhorn」 應用程式模型

「Longhorn」 會以更強大的新方式定義應用程式。

  • 「Longhorn」 API 是管理類別，可處理許多程式設計維護，並減少開發人員的工作負載。 支援 .NET Common Language Runtime 的所有協力廠商開發人員編譯器和工具， (CLR) 會自動支援新的 「Longhorn」 API。
  • 「Longhorn」 應用程式模型同時支援傳統表單型和新頁面型導覽應用程式。 作業系統提供應用程式頁面型導覽支援。
  • 新的 「Longhorn」 安全性和隱私權模型，這是受控 API 和數位身分識別組合的結果，從開發程式開始提供應用程式安全性。 由於使用 Managed 程式碼，所以信任 「Longhorn」 應用程式和元件。
  • 「Longhorn」 API 代表各種現代技術的最佳開發概念。 在許多方面，開發人員不再受限於設計決策超過十年前。
  • 自動應用程式狀態管理和保留，以方便應用程式開發。
  • ClickOnce 部署技術支援複雜的部署功能，例如程式檔、版本設定、並存安裝，以及 Drizzle 下載。
  • 導引 UI 會引導使用者完成工作。
  • 協助工具和自動化功能內建于平臺中。 您的應用程式會自動獲得這類支援。

可信任的運算和安全性

「Longhorn」 是以 Common Language Runtime 程式碼存取安全性 (CAS) 模型為基礎，但具有重大擴充功能的應用程式安全性。

  • 「Longhorn」 可辨識某些應用程式完全信任，而其他應用程式則只有部分信任。 完全參與 「Longhorn」 安全性模型的應用程式將具有 「Longhorn」 功能的完整存取權。 只有部分參與模型的應用程式會有一些優點，但有一些限制。
  • 「Longhorn」 提供超安全、Managed 程式碼、執行時間環境，稱為「安全執行環境」 (SEE) ，可保護使用者免于「不良」應用程式行為。
  • 信任管理員會為 「Longhorn」 應用程式提供評分系統，以決定使用者可以授與應用程式的建議信任層級。
  • 「Longhorn」 提供安全性信任中心，可讓使用者管理經常性修正及存取 Windows 更新。 此外，資訊安全建議程式會通知使用者安全性風險和違規。
  • Digital Rights Management 是 Managed 程式碼的一部分，為智慧財產權提供強式保護。 這可在 「Longhorn」 環境中安全地儲存和傳輸先前易受攻擊的智慧財產權。
  • 「Longhorn」 可唯一識別使用數位簽章的使用者和電腦。 與簽署授權單位結合進行驗證時，「Longhorn」 可以在運算案例中安全地可靠地識別個別使用者。

豐富的儲存體和資料存取

「Longhorn」 透過新的檔案系統提供大幅改善的應用程式資料儲存和存取。

  • 新的 ADO.NET 提供改善的資料存取。
  • 日常資訊的常見架構，例如連絡人、組織、位址等等，允許應用程式、作業系統和殼層的共用資訊存取。 事實上，新的殼層使用者介面是新儲存系統最繁重的使用者之一。
  • 應用程式可以將額外的中繼資料附加至檔案系統中的物件，這可比傳統檔案系統更快速地搜尋和擷取檔案物件。
  • 「Longhorn」 環境中的物件變更會自動傳播至這些物件的其他實例，並使用動態資料系結。

通訊和共同作業

「Longhorn」 應用程式現在具有豐富的通訊和共同作業功能。

  • 會話和頻道等功能可為參與者提供豐富的共同作業服務。
  • 通訊和共同作業功能可以透過防火牆和網路位址轉譯 (NAT) 安全地運作，允許周遊公司界限。
  • 以 Web 服務為基礎的標準化通訊可讓舊版和新應用程式參與共同作業。
  • 伺服器型/對等式通訊功能可以透過集中式基礎結構或直接對使用者用戶端運作。
  • 虛擬顯示支援可讓使用者透過立即訊息等功能與其他人共同作業， (常見通知、邀請等等) 。
  • 整合式安全性是這些功能不可或缺的一部分。
  • 殼層擴充性支援，例如共同作業 ** 動詞 (使用預設聊天用戶端等) ，可識別為使用 「Longhorn」 即時通訊中的熟悉工具。
  • 新的人員選擇器控制項之類的一般控制項提供通訊應用程式的高階應用程式支援。

豐富的簡報和媒體

開發人員可以使用 「Longhorn」 中提供的簡報和媒體服務，更輕鬆地產生提供豐富使用者介面的應用程式。

  • 「Longhorn」 為開發人員提供豐富的圖形類別，以提供動畫、效果，以及利用硬體加速的視覺令人興奮的影像。
  • 功能強大的宣告式和動態向量圖形允許彈性呈現和調整高解析度輸出裝置，同時節省資源，因為圖形是從描述性語言產生。
  • 輕鬆套用的動畫可改善 UI 的可用性和持續性。
  • 圖形支援使用硬體加速 DirectX/3D 視訊卡來建立更沉浸式且流暢的環境。
  • 您的應用程式可以順暢地整合所有形式的使用者介面—影像、視訊、音訊、向量圖形、控制項、文字等等。
  • 新的版面配置模型允許 RTF 和媒體顯示，因為會自動調整分頁、位置等等的架構，以顯示幕幕大小。
  • 新的文字服務，例如包含子圖元轉譯 (ClearType) 允許在任何電腦上以視覺方式吸引人 GUI，且 3D 快速鍵與可能的螢幕解析度無關。
  • 您可以將不同的資料片段合併到容器中，以在 UI 周圍移動。
  • 以類型、值或其他規則為基礎的資料條件式轉換，可讓開發人員工具建立更具外觀的 UI。
  • 廣泛的多媒體平臺允許無問題播放音訊和視訊;電腦與消費者電子裝置之間的分散式 A/V 體驗;高品質的音訊和視訊編解碼器;即時、高定義內容擷取和編輯的高效能;豐富的 CD、DVD 和電視中繼資料服務。

您會在此書籍中找到的內容

這些主題中的每一個都可以自行填滿書籍。 因此，我不會描述 「Longhorn」 中的所有各種 API。我也不會深入探討每個技術的詳細描述。 這不是 API或參考書籍。 我確定要等到您可以在書籍存放區中找到許多稍微編輯和重新整理的檔複本，才會太久。

我即將執行的動作是示範如何開始開發 「Longhorn」。您至少應該閱讀 Chapters 1 和 2，因為它們涵蓋開發 「Longhorn」 平臺應用程式所需的絕對基本概念。

在第 1 章中，我討論新的應用程式模型。 不要傳遞 Go。 請勿收集 $200 美元。 您真的需要閱讀第 1 章，否則您會在郵件中取得 [移至越獄] 卡片。 我也會在第 1 章仲介紹新的標記/程式設計語言。 無論您是 VB.NET 開發人員、C# 開發人員或其中一位 COBOL.NET 開發人員，都必須瞭解這個新的標記/程式設計語言。 閱讀第 1 章：「Longhorn」 應用程式模型。 我不是兒童。 事實上，請立即執行，然後返回。 我將會等候。

好的，現在您已閱讀第 1 章，而且很興奮地建置自己的應用程式，您可能應該閱讀第 2 章。 在此範例中，我示範如何編譯、部署和執行 「Longhorn」 應用程式。 因此第 2 章也很重要，但不需要急著跳。 這是非常病患的章節，會等候您完成此簡介。

其餘章節將介紹本簡介中所學到的各種技術。 第 3 章是使用新標記語言建立使用者介面的絕佳簡介，並為您提供其功能。 第 4 章介紹新的檔案系統 API，而且可能會導致您放棄 Win32 檔案系統 API。

在第 5 章中，我示範如何使用資料系結，將資料從幾乎任何 .NET 物件移至您的使用者介面，然後再次返回，而不需撰寫任何程式碼。 我示範如何在第 6 章中建立功能強大的可靠通訊應用程式。 最後，最後一章會討論建立新式連線行動應用程式的一些指導方針。

感謝您在這段完整簡介結束時停止。 現在是時候閱讀第 2 章了。 (您先前已閱讀第 1 章，但您不是) 使用 「Longhorn」我當然有！

繼續進行第 1 章：「Longhorn」 應用程式模型

Brent Rector

Brent Rector 是 Wise Owl Consulting (www.wiseowl.com) 的副總裁和建立者，在軟體發展方面有超過三十年的經驗。 Brent 已設計和實作作業系統，以及新的電腦程式設計語言及其編譯器。 Brent 已開始在 1985 年使用 Windows 1x Beta 開發 Windows 應用程式，且自以來已參與 Windows 開發。 他是許多 Windows 程式設計書籍的作者和共同撰寫者，包括 ATL 內部 和 Win32 程式設計。 Brent 也是 .NET 的 Demeanor 作者，這是適用于 .NET 應用程式的頂級程式碼模糊化程式。

© 2003 Microsoft Corporation. 著作權所有，並保留一切權利。

IntelliSense、Microsoft、MSDN、MS-DOS、Visual Basic .NET 和 Visual Studio .NET 是 microsoft Corporation 在美國和/或其他國家/地區的注冊商標或商標。 在此處所提到的其他產品及公司名稱可能是它們各自擁有人的商標。