登入
|
註冊
|
會員中心
|
結帳
|
培訓課程
魔法弟子
|
自資出版
|
電子書
|
客服中心
|
智慧型立体會員
書名
出版社
作者
isbn
編號
5050魔法眾籌
|
NG書城
|
國際級品牌課程
|
優惠通知
|
霹靂英雄音樂精選
|
CentOS 6.x企業現場實戰寶典(附兩片DVD)
此作者無相關書籍
文學小說
文學
|
小說
商管創投
財經投資
|
行銷企管
人文藝坊
宗教、哲學
社會、人文、史地
藝術、美學
|
電影戲劇
勵志養生
醫療、保健
料理、生活百科
教育、心理、勵志
進修學習
電腦與網路
|
語言工具
雜誌、期刊
|
軍政、法律
參考、考試、教科用書
科學工程
科學、自然
|
工業、工程
家庭親子
家庭、親子、人際
青少年、童書
玩樂天地
旅遊、地圖
|
休閒娛樂
漫畫、插圖
|
限制級
新洞悉UNIX:軟體移植NT篇
(附CD)
作者:
Proting UNIX Applications to Windows NT;
譯者:
沈炳雄;校閱:鄧財文博士
分類:
電腦與網路
/
作業系統
出版社:
和碩科技
出版日期:1998/11/1
書籍編號:sb0059869
頁數:0
定價:
920
元
優惠價:
88
折
810
元
書價若有異動,以出版社實際定價為準
絕版書
絕版書:確定不再版的商品,僅提供書籍資訊參考。
評價數:
(請將滑鼠移至星星處進行評價)
目前平均評價:
文字連結
複製語法
新洞悉UNIX:軟體移植NT篇
圖片連結
複製語法
分
享
內容簡介
同類推薦
■ 內容簡介
目前的作業系統可謂是 UNIX 與 Windows NT二分天下的局面,正也因為如此,程式設計師在工作環境中,也就不得不去面對應用程式移植作業的頭痛問題。 本書是從一個專業者的角度,對於應用程式的移植過程中所有可能發生的問題一一提出分析探討。為了讓移植作業更為順暢,同時又能避免陷入進退兩難的窘境,作者首先對兩種作業系統的細部結構,與應用程式賴以正常運作的整體環境進行全面性的介紹,然後才再進一步對移植作業的可行性與準備工作加以評估。 本書不但具有工具書的功能,更是一本極具價值的教科書。
■ 目錄
第1章 面對問題 第2章 Unix-NT的移植作業 第3章 設計者所面臨的困境 第4章 該如何著手 第5章 Windows NT 的系統架構 第6章 輸入/輸出子系統 第7章 網路的程式規劃 第8章 使用者介面與繪圖應用程式 第9章 Windows NT 系統的原始開發工具 第10章 DLL的程式設計與低階除錯作業 第11章 類似Unix 的程式設計環境 第12章 類似Unix 的使用者環境 第13章 從Posix 的角度來探討 Win32 的 API 第14章 其他的 API 第15章 從Unix到Windows NT的專門術語 第16章 解決方案與秘訣 第17章 作業評估 索引
■ 內文選錄--
第一章面對問題 進行程式移植之前,首要之舉乃是判斷是否值得?再考慮部份程式對整個系統以及許多其他使用者的影響,並進行成本與效益評估。然後才決議「移植或另購」。同時還要決定如何完成系統測試、功能校驗以及效能評估等事項。對於相關資訊的取得也必須要瞭解。 最後關於程式移植到NT平台,勿庸置疑的,微軟公司(Microsoft)就是最新的資訊來源。對於一般中型或者是大型的計劃,建議訂閱 MSDN 與 Internet Access。下列為一些重要的相關網站: · http://www.datafocus.com/port/default.htm介紹了一些專門為Nutcracker toolset 使用者所設計的程式移植方法論。 · http://www.unix.digital.com/products/interop/UnixandNT 描述了迪吉多(Digital)公司如何投入了大量的心血去協助 VMS 及 Unix 用戶移植到 Windows NT。 · http://nentug.org/unix-to-nt,由新英格蘭地區的 NT User's Group 所主辦,其中對於相關議題的使用經驗與資料的取得都有非常詳盡的討論。筆者在此強烈的建議大家造訪上述的網站。 不幸的是,對於您所遭遇到問題,這些文獻資料往往無法提供一個滿意的方案。如果您正為了一個小錯誤而陷入膠著,特別是對於那些低階的系統程式;這時,您得進行逆向工程(reverse enginerring),以徹底瞭解系統到底在搞什麼名堂。在下一章裡,將討論如何移植現有應用程式以達到預期的功能、如何進行逆向工程的技巧;同時在第十章「DLL的程式規劃與低階除錯」裡,將討論如何利用一些有用的工具程式以徹底剖析 Windows NT。 目前在 UNIX系統中已有許多知名且有用的應用程式及程式庫成功地移植到Windows NT系統,其中包括TCP 網路協定堆疊、各種 PC-NFS(網路檔案系統)埠、各種命令解譯器(shell)、過濾器、以及包括 bash、gcc、vi 和 GNU Emacs等在內的工具程式。上述各種成功的經驗,對於正在考慮程式移植的人來說,應該是最大的鼓舞。 在移植作業上,由於 UNIX 和 Windows NT 在系統環境的基本設計理念上就不同,而導致一切困難的根源。今天,UNIX系統之所以被廣泛使用,最主要歸因於大量的免付費軟體在各式各樣的硬體環境下都能夠順利地運作。二十多年以來,Berkeley Source Distribution的主目標即在於推動系統的開放性與分散式控制。近年來,只有Unix系統在Posix.1與X/Open的努力之下,完成了大規模的標準化。不過,Unix系統的開放性作業環境雖然鼓勵了各式各樣的創新,卻也阻礙了系統的標準化。這實在是一種兩難的局面:開放式的系統環境使得各個製造商具有相當程度的自主性,大幅提高了系統的可接受度,但是卻又無法達到諸如DOS 以及Windows 等專屬系統所特有的接受程度。究其原因,則要歸咎源自其產品本質內的隱含標準。 應用程式的分類 程式移植所需花費的功夫完全取決於目標應用程式本身的目的和複雜度。首先考慮的就是使用者操作介面的問題,基本上說,在這方面有兩種不同的形式: 文字介面的應用程式 圖形使用者介面(GUI)的應用程式 在程式移植作業中,一般文字介面的應用程式只是將單純的文字資料輸出至控制台,故所遭遇的難題比較少。除非在某種指令批次檔(shell scripts)檔或者應用程式利用到高階終端機特性,或直接呼叫或是經由類似Curses的程式庫呼叫時,才需要較複雜的處理。往後我們會針對這些項目再做進一步的說明。 一般來說,GUI應用程式採用了Xlib以及Motif 專用圖形化工具組(widget),因此對於和使用者之間的互動作業,能夠提供相當複雜的控制以及強大的功能。此處的移植過程儘可能使這些結構變成為與32位元視窗應用程式介面對等的程式。不過這在技術上與在外觀上,都是一大挑戰。雖然在使用模擬軟體的某些情況下,可以節省程式移植的功夫,但是也得付出執行效率低落以及增加系統複雜度的代價。並且幾乎所有的GUI程式都得要重寫。 通常缺乏使用者介面而單純只是為其他程式提供服務的應用程式,會造成另類的問題。伺服器應用程式通常利用處理程序間通訊(Interprocess Communication)或者透過網路,以從執行過程直接傳送資料或者接收資料,這些處理程序(process)甚至可能是來自網路上的遠端電腦設備。所以程式移植的困難度會隨程式所提供的服務不同而有莫大的差異,這完全取決於Windows NT系統環境下特定的服務功能、所提供的資源以及可用的支援。Unix系統下的daemon類似於NT中的服務(service)。在第五章的「Windows NT的系統架構」裡,將進一步的討論關於服務控制管理的程式。 某些應用程式一點都不適合移植。如果你很挑剔系統回應以及處理效能的問題,則您恐怕得要慎重的考慮重寫這些程式。甚至還要去熟悉 Windows NT作業環境下的系統效能分析及低階除錯工具。 Win16,Win32,與Unix Windows 3.1 架構的主要特徵是,它在DOS作業系統上執行並將其功能擴充,故基本上它只是一個「DOS擴展程式」(DOS Extender)而已。一般程式設計師所使用的系統介面,也就是所謂的16位元視窗應用程式介面(Win16),是在16位元80286模式下執行。Win16的應用程式若在記憶體的區段式位址空間中操作,則最大的區段位址長度只有64KB。則在這種設計環境下的程式都有一種特性,那就是一旦程式需要使用大量的記憶體或者應用程式需要用到超過 64K的記憶體容量,就必須時常重載區段暫存器。 Win16的應用程式若在記憶體的單位址空間下執行,而此空間是由系統以及所有其他的執行中的程式所分享出來的。則其資源分派的方式稱為合作式排程(cooperative),表示只有當程式自願放棄系統控制權而進行內容切換,才有可能輪到別的應用程式執行。這種合作式多工作業環境對於具有即時需求的應用程式而言,是極大的缺陷。此外,共享位址空間的做法會由於其中任何一個正在執行程式的錯誤而易於造成所有應用程式的損害,進而降低整個的系統可靠度。 相對來說,Windows NT是一種以微核心(microkernel)為基礎的作業系統,並且支援記憶體位址空間保護、可岔斷式多工作業(preemptive multitasking)、以及多重程式規劃介面,其中包括MS-DOS、Win16、某些Posix與XPG3介面、以及Win32介面。 目前您所針對的作業系統應該是某個版本的Widows NT;在本書中將要探討的對象會更廣泛。對於程式移植或重新規劃流程而言,很多的概念可能與其他的作業系統如視窗95/98 互有關連。雖說在Windows NT、Win32 系統環境下的Win32 API常式以及大部分具有相同使用者介面的元件,視窗 95/98的應用程式都可加以利用。不過因為處理程序結構、登錄檔用法、安全性與其他作業系統特性的不同而可能有些許差異,但是目前微軟公司正策略性地針對具網路功能的系統以及應用程式設計層進行整合。到目前為止,這兩種作業系統的裝置驅動程式仍然有著相當程度的差異。因此在進行這個層次的程式移植作業時,仍然需要花費一番功夫。 以下內容節錄於本書第一章的最後一節 避免常見的陷阱 本節將集中焦點在一些已經是相當標準化的系統結構上,像是對於訊號處理(signal handling)以及和系統安全性相關的功能,而這些功能在 Windows NT 裡都有著非常顯著的差異。如果您正準備將一個無法和目前已經被公認為標準規格的系統如 Posix.2 或是 XPG3等完全相容的舊系統移植到 NT,則必須要採取一些額外步驟,才有可能成功的完成移植作業。最好是能夠從一個已知的狀態移植到另外一個已知的狀態,並且儘可能的使您的程式完全配合標準化的環境。 在這處理過程中最重要的部份,就是必須規劃您的執行程序,儘量配合移植來源或目標系統環境中定義不明確的系統標頭檔,但是並不建議完全拘限於所有的標準環境。舉例來說,根據 Stevens 的說法(1992),包括訊息佇列在內的System V IPC在XPG3裡有明確的定義,但是在NT中卻根本沒有訊息佇列,甚至於在不同Unix 版本間進行移植作業時還會彼此衝突。就讓我們根據一些發生在過去的衝突事件來感受一下我們將會面臨的問題。 我自己就有一個有關BSD應用程式和移植系統間因訊號解譯不同而引起衝突的經驗。主要的問題出在當系統正在處理一個系統呼叫作業的時候,應用程式的執行方式乃和系統訊號的性質有關。換句話說,系統會以應用程式的名義去執行核心程式中的有關部份。在預設狀態下,若是系統呼叫被某個訊號所中斷,則BSD會自動將它重新啟動﹔但是在一些特殊的情況下,System V以及 Posix 系統的預設狀態常常會從系統呼叫程式中回應一個錯誤訊息。譬如說,系統可能會從一個進行了一半的讀取作業中回返。您應該要修訂這個程式的處理邏輯以配合目前的作業標準(System V模式),而不是幻想要建立一組模擬 BSD型態的作業訊號。 您移植的應用程式甚至可能無法正常操作,譬如,筆者就不只一次的遇到過一些在市場上頗有名氣的應用程式,竟然從訊號處理程式呼叫了一個「不安全」的執行程式庫功能。這種做法非但不符合標準,同時還具有破壞性的。但是他們卻忽視了這一點。若是一個程式庫中的常式進行了類似 malloc 的呼叫,就應該被禁止使用。試想,若是在執行前一次的 malloc 呼叫期間收到了另一個訊號,這會產生什麼後果?答案是在某些時候會由於系統內部的記憶堆疊中的資料結構並未加以適當的保護,而導致資料的毀損。隨後整個程式會當掉(或是更糟)。 可是,這類問題的發生往往是無法預知的,同時也有可能會被掩蓋住,根據時間性來考慮的話,有時可能要等上幾年才發生。在準備或是進行這類應用程式的移植作業的時候,您有必要找出這種隱藏性或是潛伏性的缺點,作者將這類型的問題稱之為“bogons”。 試圖找出記憶體的故障所在實在是痛苦的根源。初學者應該要瞭解至少可以透過兩種不同的界面程式去使用記憶堆疊:那就是malloc程式庫實作和LocalAlloc常式。千萬要記得作業結束後應分別使用free及LocalFree呼叫,藉以釋放記憶體。事實上,您應該仔細的檢視程式中的記憶體配置邏輯。儘可能的將您的資料分開配置到隔離的堆疊區裡,同時在設計的過程中使用除錯配置程式。使用隔離的堆疊區可以監督並且避免意外的毀損系統的資料結構,以後只要有任何問題的發生,很明顯的,毛病一定是出在您的程式。在程式仍然處於測試階段的時候使用除錯程式,以協助您一段一段的清理程式的內容。 除了在本書中所提出的各種資料之外,儘可能多方面的去瞭解Unix 之間可移植性的相關問題,藉以使您更進一步的熟悉整體的作業情況,這將會是一種非常好的方法。在下一章裡,首先會提出一些簡單的問題,藉著這些問題的引導,進一步的討論在 Unix 到 Windows NT 的應用程式移植作業當中所遭遇到的問題及其解決方法。
計算機與人工智慧概論
絕對硬派:Windo
超實用!Word.E
Excel 365商
Linux系統管理達
Redmine 專案
即學即用!精選 30
AI提示工程師的16
超實用!Word.E
可觀測性入門指南:L
為了保障您的權益,新絲路網路書店所購買的商品均享有到貨七天的鑑賞期(含例假日)。退回之商品必須於鑑賞期內寄回(以郵戳或收執聯為憑),且商品必須是全新狀態與完整包裝(商品、附件、內外包裝、隨貨文件、贈品等),否則恕不接受退貨。