2011年5月6日

IPC$(Internet Process Connection)是共享"命名管道"的資源，它是為了讓進程間通信而開放的命名管道，通過提供可信任的用戶名和口令，連接雙方可以建立安全的通道并以此通道進行加密數據的交換，從而實現對遠程計算機的訪問。IPC$是NT/2000的一項新功能，它有一個特點，即在同一時間內，兩個IP之間只允許建立一個連接。NT/2000在提供了ipc$功能的同時，在初次安裝系統時還打開了默認共享，即所有的邏輯共享(c$,d$,e$……)和系統目錄winnt或windows(admin$)共享。所有的這些，微軟的初衷都是為了方便管理員的管理，但在有意無意中，導致了系統安全性的降低。

  2009年5月21日

-道德的起源-
    把五只猴子關在一個籠子里，上頭有一串香蕉實驗人員裝了一個自動裝置。一旦偵測到有猴子要去拿香蕉，馬上就會有水噴向籠子，而這五只猴子都會一身濕。首先有只猴子想去拿香蕉，當然，結果就是每只猴子都淋濕了。之後每只猴子在幾次的嘗試后，發現莫不如此。于是猴子們達到一個共識：不要去拿香蕉，以避免被水噴到。后來實驗人員把其中的一只猴子釋放，換進去一只新猴子A。這只猴子A看到香蕉，馬上想要去拿。結果，被其他四只猴子海K了一頓。因為其他四只猴子認為猴子A會害他們被水淋到，所以制止他去拿香蕉，A嘗試了幾次，雖被打的滿頭包，依然沒有拿到香蕉。當然，這五只猴子就沒有被水噴到。后來實驗人員再把一只舊猴子釋放，換上另外一只新猴子B。這猴子B看到香蕉，也是迫不及待要去拿。當然，一如剛才所發生的情形，其他四只猴子海K了B一頓。特別的是，那只A猴子打的特別用力（這叫老兵欺負新兵，或是媳婦熬成婆^O^）。 B猴子試了幾次總是被打的很慘，只好作罷。后來慢慢的一只一只的，所有的舊猴子都換成新猴子了，大家都不敢去動那香蕉。但是他們都不知道為什么，只知道去動香蕉會被猴扁。這就是道德的起源。
    -階級的起源-
    實驗人員繼續他們的實驗，不過這一次他們改變了噴水裝置。一旦偵測到有猴子要去拿香蕉，馬上就會有水噴向拿香蕉的猴子，而不是全體。然后實驗人員又把其中的一只猴子釋放，換進去一只新猴子C。不同以往的是猴子C特別的威武武有力。當然猴子C看到香蕉，也馬上想要去拿。一如以前所發生的情形，其他四只猴子也想海K猴子C一頓。不過他們錯誤估計了C的實力，所以結果是反被C海K了一頓。于是猴子C拿到了香蕉，當然也被淋了個透濕。C一邊打著噴嚏一邊吃著香蕉，美味但是也美中不足。A、B、D、E沒有香蕉吃卻也比較快樂，畢竟沒有被淋到嘛。  后來C發現只有拿香蕉的那個才會被淋到，他就要最弱小的A替他去拿。A不想被K，只好每天拿香蕉然后被水淋。B、D、E越發的快樂了起來，這就叫比上不足，比下有余嘛:)于是五只猴子有了三個階級。這下子階級也隨著道德起源了。
    -道德的淪喪-
    天變熱了，籠子里的猴子們想沖涼卻找不到地方。終于出現了一位反潮流英雄，猴子HERO。HERO在無意中碰到了香蕉，理所當然的引來了一頓飽打。但在挨打的過程中，猴子們享受到了沖涼的樂趣。等身上的水干了之后，猴子A在無意中碰撞了HERO，使HERO又一次接觸到了香蕉，于是，猴子們享受了第二次沖涼，HERO遭到了第二次痛毆。在此之后，只要大家有沖涼的需要，就會有一只猴子X挺身而出，對HERO進行合理沖撞。大家對HERO的態度也有了明顯的不同，在平時大家會對HERO異常溫和，以彌補在沖涼時為維護規則而不得不對它進行的暴力舉動。一天，在大家沖涼時，飽受折磨的HERO聞到了香蕉的清香,生物本能使它在別的猴子心有旁鶩時將香蕉吃了。而且此后沒有了新的香蕉來填補空缺。猴子們陷入了另一個尷尬境地：沒有沖涼的水，也沒有香蕉，只有HERO。于是，另一個規則形成了。猴子在煩躁的時候會痛打HERO出氣，HERO不得反抗。 當籠子里的舊猴子被新猴子換掉時，新猴子會在最快的時間內學會毆打HERO。
終于有一天，老天有眼，歷盡滄桑的HERO被另一只猴子代替了。猴子們失去了發泄的對象，只能任意選取一個目標進行攻擊。從此以后，籠子里的猴子們不吃不喝不沖涼，唯一的舉動就是打架。這就是道德的淪喪。
    -道德的重建-
    實驗人員對猴子們的爭斗不休感到不安。為了重建道德秩序，他們決定繼續供應香蕉。一天，正在混戰的猴子們發現頭頂多了一串香蕉，它們其中的一個A不顧身上的劇痛，把香蕉摘了下來。于是久違的甘露出現了，未曾嘗過甜頭的猴子們先是茫然失措，繼而爭先恐后的加入沖涼的行列。香蕉反而被遺忘了。當猴子B、C、D、E發現A在享受淋浴的同時還吃著美味的香蕉，嫉妒心使它們暫時團結起來，共同K了A一頓，將A吃剩的香蕉奪過來，但是，此刻的香蕉成了匹夫懷里的寶玉，得到它的猴子雖然可以享受美味，但付出的代價也是巨大的。實驗人員不斷放入香蕉，卻發現戰斗比以前更激烈了。分析清楚原因后，他們用木頭做了一個假香蕉扔進了籠子。此時猴子們已經學聰明了，它們知道觸摸香蕉可以享淋浴，而試圖獨占香蕉則會遭到痛扁。于是，一個新的現象出現了，當猴子們有沖涼的需要時，會有一只猴子將香蕉拿起來，而當它發現有遭到攻擊的可能時，它會馬上放下香蕉逃到一邊去。這樣，猴子們都能沖涼，但是又不至于再象以前那樣N敗俱傷。沒有猴子發現那個香蕉是假的。
    -信仰的起源-
    五只猴子A、B、C、D、E三個階級快樂地生活了很久。他們精確的給出了三個階級的定義，即吃香階級、拿香階級和干看著階級。可惜猴子A由于長期的水中作業無可避免地引發了它肺部功能的衰竭。一天他在例行的拿香蕉作業中跌倒了就再也沒有爬起來。于是實驗人員又送進了一只同樣孔武有力的猴F。當然他還是對屋頂的香蕉很有興趣。不幸的是他最終以微弱的劣勢被以C為首的群猴再次海K。第二天，又到了拿香蕉的時候。猴子C很無所謂，反正他還要吃香蕉，反正他不會被水淋到。真正恐慌的是B、D、E三猴。F是那么的健壯，他們這些媳婦是熬不成婆了:(他們將面臨一個艱難的抉擇，誰該去步A的后塵?猴子B、D、E展開了激烈的爭論，討論誰最應該做下一個拿香階級。 猴子F很奇怪也很好奇，什么叫“拿香階級”呢？猴子B、D、E解釋道：所謂“拿香階級”就是猴子界勇敢者的階級。需具備一不怕苦二不怕死的大無畏精神方能得此殊榮。猴子F聞聽不禁有些神往，有些躍躍欲試。當然他最終達到了目的，作了唯一的拿香階級。再后來，B、D、E三猴陸續被換出局，換來的猴子個個健壯如C。他們繼續大大出手，不過目標不是香蕉，而是那個唯一的拿香階級。于是信仰也出現了
    -迷信的起源-
    后來A終于被好心的實驗人員拉出了苦海。 新來了猴子F。C覺得有必要維護自己的階級地位，B、D、E則生怕自己頂了A的坑……在各種復雜心情的作用下，B、D、E在C的帶領下爆扁了F一頓，然后強令F做拿香蕉階級。F開始不樂意，后來慢慢在B等的勸說下等“待多年的媳婦熬成婆”這一宿命。慢慢的老資格的B、D、E猴子漸漸被淘汰，C發現自己在體力上不再占有優勢，很難再通過武力讓這一游戲規則繼續下去，覺得十分苦惱。這時，一只最有希望升級為吃香蕉階級（暨C的理所當然接班人）也是C謀臣的H向C進言。于是君臣定計。H開始依靠自己多懂幾種猴語而在其他若干猴面前樹立的權威形象向其他猴鼓吹：“每一只新來籠子的猴子都是有罪的，這種罪責來自血統。……只有摘香蕉的猴子才能被（實驗人員）送到天堂。”事實上，因為被水沖很容易得肺炎病倒而被實驗人員淘汰掉，猴子們不知道反而以為被淘汰的猴子真的進了天堂。漸漸，猴子都相信了這套理論，并且講給每一只新猴子聽。然后就這么流傳下去越傳越神奇。以至于后來摘香蕉階級的猴子都為了能摘香蕉而大打出手。……這些都是C沒有想到，H沒有看到的，那時他們都已經死了。然而迷信就這么誕生了。

      女：你有過女朋友？
　　男：東風惡，歡情薄，一懷愁緒，幾年離索。
　　女：被拆散了，現在她呢？
　　男：劉郎已恨蓬山遠，更隔蓬山一萬重！
　　女：哦，在外地。你可以去找她呀？
　　男：侯門已如深似海，從此蕭郎是路人。
　　女：已經結婚了。那這些年你是怎么過來的？
　　男：滿面塵灰煙火色，兩鬢蒼蒼十指黑。
　　女：你們有聯系嗎？
　　男：欲寄彩箋兼尺素，山長水闊知何處？
　　女：你后來遇到喜歡的人了嗎？
　　男：過盡千帆皆不是，斜暉脈脈水悠悠，腸斷白洲。
　　女：為什么沒有找到？
　　男：揀盡寒枝不肯棲，寂寞沙洲冷。
　　女：你會繼續等下去嗎？
　　男：路漫漫其修遠兮，吾將上下而求索。
　　女：(很天真)真的嗎？
　　男：千淘萬漉雖辛苦，吹盡狂沙始到金。
　　女：你……對愛情的看法呢？
　　男：只在此山中，云深不知處。
　　女：那你見我的第一感覺是什么？
　　男：忽如一夜春風來，千樹萬樹梨花開。
　　女：感覺我很美嗎？
　　男：回眸一笑百媚生，六宮粉黛無顏色。
　　女：(紅著臉)還有嗎？
　　男：風吹仙袂飄飄舉，猶似霓裳羽衣舞。
　　女：(更加開心)還有嗎？
　　男：云想衣裳花想容，春風拂檻露華濃。
　　女：(很羞澀)有那么美？
　　男：糟粕所傳非粹美，丹青難寫是精神。
　　女：你注意我多久了？
　　男：小荷才露尖尖角，早有蜻蜓立上頭。
　　女：(笑得很甜)見不到我的時候，想過我嗎？
　　男：憶君心似西江水，日夜東流無歇時。
　　女：(很羞澀)為什么想我？
　　男：蘭有秀兮菊有香，懷佳人兮自難忘。
　　女：馬屁精！你喜歡讀書嗎？
　　男：軍書十二卷，卷卷有爺名！
　　女：很不錯，你有理想嗎？
　　男：他年若遂凌云志，敢笑黃巢不丈夫。
　　女：你在吹牛吧？
　　男：大鵬一日同風起，扶搖直上九萬里。
　　女：這樣說你的報負很遠大？
　　男：會當凌絕頂，一覽眾山小。
　　女：這牛吹大了吧！你那么有才華，怎么還獨身？
　　男：小姑未嫁身如寄，蓮子心多苦自知。
　　女：(笑)假如，我是說假如，我答應嫁給你，你打算怎樣待我？
　　男：一片冰心在玉壺。
　　女：你保證不會對別的女人用心？
　　男：波瀾誓不起，妾心古井水。
　　女：你會永遠都愛我嗎？
　　男：在天愿作比翼鳥，在地愿為連理枝。
　　女：你肯定不會變心嗎？
　　男：山無陵，江水為竭，冬雷陣陣夏雨雪，天地合，乃敢與君絕。
　　女：暫且信你一回。

  2009年4月17日

我們從 UNREFERENCED_PARAMETER 開始吧。這個宏在 winnt.h 中定義如下：

#define UNREFERENCED_PARAMETER(P) (P)

　　換句話說 UNREFERENCED_PARAMETER 展開傳遞的參數或表達式。其目的是避免編譯器關于未引用參數的警告。許多程序員，包括我在內，喜歡用最高級別的警告 Level 4（/W4）進行編譯。Level 4 屬于“能被安全忽略的事件”的范疇。雖然它們可能使你難堪，但很少破壞你的代碼。例如，在你的程序中可能會有這樣一些代碼行：

int x=1;

　　但你從沒用到過 x。也許這一行是你以前使用 x 時留下來的，只刪除了使用它的代碼，而忘了刪除這個變量。Warning Level 4 能找到這些小麻煩。所以，為什么不讓編譯器幫助你完成可能是最高級別的專業化呢？用Level 4 編譯是展示你工作態度的一種方式。如果你為公眾使用者編寫庫，Level 4 則是社交禮節上需要的。你不想強迫你的開發人員使用低級選項清潔地編譯他們的代碼。
　　問題是，Level 4 實在是太過于注意細節，在 Level 4 上，編譯器連未引用參數這樣無傷大雅的事情也要抱怨（當然，除非你真的有意使用這個參數，這時便相安無事）。假設你有一個函數帶來兩個參數，但你只使用其中一個：

int SomeFunction(int arg1, int arg2){  return arg1+5;}

使用 /W4，編譯器抱怨：

“warning C4100: ''arg2'' : unreferenced formal parameter.”

為了騙過編譯器，你可以加上 UNREFERENCED_PARAMETER(arg2)。現在編譯器在編譯你的引用 arg2 的函數時便會住口。并且由于語句：

arg2;

實際上不做任何事情，編譯器不會為之產生任何代碼，所以在空間和性能上不會有任何損失。

　　細心的人可能會問：既然你不使用 arg2，那當初為何要聲明它呢？通常是因為你實現某個函數以滿足某些API固有的署名需要，例如，MFC的 OnSize 處理例程的署名必須要像下面這樣：

void OnSize(UINT nType, int cx, int cy);

　　這里 cx/cy 是窗口新的寬/高，nType 是一個類似 SIZE_MAXIMIZED 或 SIZE_RESTORED 這樣的編碼，表示窗口是否最大化或是常規大小。一般你不會在意 nType，只會關注 cx 和 xy。所以如果你想用 /W4，則必須使用 UNREFERENCED_PARAMETER(nType)。OnSize 只是上千個 MFC 和 Windows 函數之一。編寫一個基于 Windows 的程序，幾乎不可能不碰到未引用參數。
　　說了這么多關于 UNREFERENCED_PARAMETER 內容。Judy 在她的問題中還提到了另一個 C++ 程序員常用的并且其作用與 UNREFERENCED_PARAMETER 相同的訣竅，那就是注釋函數署名中的參數名：

void CMyWnd::OnSize(UINT , int cx, int cy){}

　　現在 nType 是未命名參數，其效果就像你敲入 OnSize(UINT, int cx, int cy)一樣。那么現在的關鍵問題是：你應該使用哪種方法——未命名參數，還是 UNREFERENCED_PARAMETER？
　　大多數情況下，兩者沒什么區別，使用哪一個純粹是風格問題。（你喜歡你的 java 咖啡是黑色還是奶油的顏色？）但我認為至少有一種情況必須使用 UNREFERENCED_PARAMETER。假設你決定窗口不允許最大化。那么你便禁用 Maximize 按鈕，從系統菜單中刪除，同時阻止每一個用戶能夠最大化窗口的操作。因為你是偏執狂（大多數好的程序員都是偏執狂），你添加一個 ASSERT （斷言）以確保代碼按照你的意圖運行：

void CMyWnd::OnSize(UINT nType, int cx, int cy){  ASSERT(nType != SIZE_MAXIMIZE);  ... // use cx, cy}

　　質檢團隊竭盡所能以各種方式運行你的程序，ASSERT 從沒有彈出過，于是你認為編譯生成 Release 版本是安全的。但是此時 _DEBUG 定義沒有了，ASSERT(nType != SIZE_MAXIMIZE)展開為 ((void)0)，并且 nType 一下子成了一個未引用參數！這樣進入你干凈的編譯。你無法注釋掉參數表中的 nType，因為你要在 ASSERT 中使用它。于是在這種情況下——你唯一使用參數的地方是在 ASSERT 中或其它 _DEBUG 條件代碼中——只有 UNREFERENCED_PARAMETER 會保持編譯器在 Debug 和 Release 生成模式下都沒有問題。知道了嗎？
　　結束討論之前，我想還有一個問題我沒有提及，就是你可以象下面這樣用 pragma 指令抑制單一的編譯器警告：

#pragma warning( disable : 4100 )

4100 是未引用參數的出錯代碼。pragma 抑制其余文件/模塊的該警告。用下面方法可以重新啟用這個警告：

#pragma warning( default : 4100 )

　　不管怎樣，較好的方法是在禁用特定的警告之前保存所有的警告狀態，然后，等你做完之后再回到以前的配置。那樣，你便回到的以前的狀態，這個狀態不一定是編譯器的默認狀態。
　　所以你能象下面這樣在代碼的前后用 pragma 指令抑制單個函數的未引用參數警告：

#pragma warning( push ) #pragma warning( disable : 4100 )void SomeFunction(...){}#pragma warning( pop )

　　當然，對于未引用參數而言，這種方法未免冗長，但對于其它類型的警告來說可能就不是這樣了。庫生成者都是用 #pragma warning 來阻塞警告，這樣他們的代碼可以用 /W4 進行清潔編譯。MFC 中充滿了這樣的 pragmas 指令。還有好多的 #pragma warning 選項我沒有在本文討論。有關它們的信息請參考相關文檔。

  2009年4月2日

新辦公地點可以看到鳥巢的火炬形大樓。朝窗，很爽。抬頭看到云在動

  2009年3月23日

Windows 2000 設備驅動程序設計指南（原書第二版），即

The Windows 2000 Device Driver Book (Second Edition)

不玩魔獸了！

  2009年3月4日

上班很無聊，這兩天項目到一段落，沒有代碼寫。拿本WINDOWS核心編程那么厚又不方便看。所以只能看電子書了。王爽的匯編看完了，現在要轉到win32的保護模式下來，所以就看老羅的Windows環境下32位匯編語言程序設計第二版呢。

  2009年3月3日

` 提問的智慧
看雪學院

?2000-2005 PEdiy.com All rights reserved.
By KanXue Studio