幫了個MM寫程式,寫了程式還要寫文檔於是我先用Word2003寫了個文檔,為了表達清楚,所以插了幾幅圖(這是引發問題的原因)歡天喜地傳給她,結果說是開啟了是亂碼~~~問了一下她裝的是Office2000,於是想亂碼是情有可緣的,我的Office2003沒打相容性補丁不想打補丁了,看了一下AdobeAcrobat在Word2003裡的外掛程式按鈕,哈哈馬上轉成.pdf的,再傳然後再教她上E383裝AdobeAcrobatReader,結果說開啟的時候有錯誤,打不開了鬱悶!!看了看Word2003的
void __fastcall TMainForm::GetToolBarContent(){ //TODO: Add your source code here int nItemCount; int i; char chBuffer[256]; DWORD dwProcessID; HANDLE hProcess; void * Pointer; SIZE_T nNumberOfBytesRead; nItemCount
學編程是從DOS下開始的,用了一定時間的TC2.0,使得養成了用printf輸出變數值進行調試的壞習慣。到了寫視窗程序時,就遇到了些麻煩。 視窗程序沒有方便的進行控制台輸出的方法(其實是我不知道),於是,用了幾年的用MessageBox進行輸出的調試手段,太麻煩了,因為MessageBox會打斷程式流程,還要人為手動讓它繼續運行,這是最讓人惱火的。 後來用上了VC.NET2003,發現有OutputDebugString這個調試API,在IDE下調試,
隨著今天下午搬走了最後一批東西,包括一張床墊一個皮箱一包衣服和一箱書,我可以說已經正式告別了這個住了一年的地方,這個自我走出學校進入社會後第一處自己花錢住的地方,留下了很多回憶的地方。 那天和小思宇一起回去拿餐具的時候,小思宇說覺得自己以後應該再也不會回去那個地方了,我想我還不是一樣不會再去那個地方了,留下的只有回憶。以一種不光彩的方式,結束了在那的生活。 小區門口,新陽麗舍的碑牌 新雅閣
Fterm所附帶的IP資料都存放在一個叫QQWry.dat的檔案裡面,因為學校裡的校園網比較發達,幾乎每個想上校園網的人都得擁有一個獨立的IP,所以就有為學校的IP做記錄的想法。為了修改Fterm裡的IP資料庫,先找到一個叫“QQIP資料編輯器”的程式,好像QQ2004精靈坊顯IP版15.0永久珍藏版裡就附帶了這個程式,檔案名稱是QQIP.exe,用這個程式,可以開啟QQWry.dat檔案,並將其轉換為Wry.dll,這是另一種檔案記錄格式,Wry.dll可以用QQIP.exe進行編輯,對IP資
最後的最後,我終於發現了關於完成連接埠第一次WSARecv投遞失敗的原因!MSDN中關於WSARecv的原型如下:int WSARecv( SOCKET s, LPWSABUF lpBuffers, DWORD dwBufferCount, LPDWORD lpNumberOfBytesRecvd, LPDWORD lpFlags, LPWSAOVERLAPPED lpOverlapped,
得到了反組譯碼代碼,就可以看到程式是如何運作的。用IDA Pro 4.5裝入已經脫了殼的w3l.exe,經過IDA的一番咀嚼,會得到排版比較好看的代碼:loc_401000: ; CODE XREF: foo.:0040109Aj ; foo.:004010ABj ...這個地方開始,是表明出錯了。 push 1
TFT在連PvPGN架的戰網時,要用特定的Loader來載入啟動,那Loader也就2個檔案,一個是w3l.exe,另一個是w3lh.dll,每次都是通過運行w3l.exe來啟動正常的魔獸。由於覺得好奇,所以這次把w3l.exe肢解了看看。基本需求:知道80x86彙編,會一點C,瞭解Windows程式設計基本原理,最好還有MSDN隨時備查。先用PEiD看了看w3l.exe(這是用於1.14-1.16的loader),提示UPX 0.89.6 - 1.02 / 1.05 - 1.24 ->
上個月寫了一篇關於外掛程式系統的文章,也是我現在一直在做的一個項目。在實現這個基於外掛程式機制的系統過程中有不少自認為有意思的地方。這裡寫出來與大家共用。在外掛程式系統中,每一個外掛程式都有自己的一些配置資訊,比如說表徵圖資訊、介面顯示資訊等。如果以前做了一個外掛程式,發現另外一個外掛程式和它的功能差不多的時候該怎麼辦呢?可以用設定檔將不同的地方描述出來,也可以在以前的基礎上做一個衍生類別。到底是用配置還是用派生,這個問題就有趣了。都是變化惹得禍中國特色的軟體產品就是地區版本多,同樣一件事情每個
外掛程式的獨立性與外掛程式之間的依賴關係是外掛程式架構必須解決的問題。其中獨立性與外掛程式的劃分粒度相關,將每一個外掛程式實現為一個dll,從物理層面強制保證了外掛程式的獨立性。外掛程式之間的依賴關係是要解決的更加複雜的一個問題。一、觀察者模式我們將系統分割成一系列相互協作的類,常見的會有一個副作用:需要維護相關對象間的一致性。但我們並不希望為了維持一致性而使各類緊密耦合,因為這樣降低了它們的可重用性。(引用自GoF的《設計模式》)在Subject的某一個固定時刻,將會調用Observer的Up
以前寫什麼程式,都是隨著自己的興趣來的。那個LLYFSpy,完全是看著MySpy和Spy4Win,覺得可以把它們兩個的功能整合一下,再加一點其它 的功能,於是就成了現在這個樣子,而且前段時間有一次為了研究一個別人的程式,發現有些時間只有用Spy++才行,於是責問自己,為什麼LLYFSpy不 行,不是早就得意洋洋地認為全面超越了Spy++的功能了嗎?再早一點的ProcessHelper,也是因為看到最佳化大師裡的那個進程管理器,覺得可以
一切都是為了更加簡單。從函數到函數庫,然後到類,然後到外掛程式,都是因為我們的軟體系統日益複雜,人腦畢竟有限,不能同時處理那麼多的資訊量,所以採用分而治之的方法來管理。 今年已經研究了一年的外掛程式系統,從最開始的懵懵懂懂到現在能有些經驗和大家分享,這個過程本身就是很有意思的。
等級制度是把所有人或團體分成等級的制度,在這種制度下各個等級擁有不平等的權利,上層等級權利大,下層等級權利小。有一種說法是,等級制度萌芽在原始社會的末期,私人制產生之前,首先表現為社會分層,同時開始產生階段。 既然等級制度有其產生的原因,那Team Dev中是否需要等級制度呢?等級制度的優劣
自從我學習程式設計開始,就不斷地聽到大家談論物件導向。在最開始接觸C++時,確實被它的OO特性迷住了,相比之前用過的C語言更加豐富多彩。想當初,經常因為寫出了一個類而暗自自豪半天。現在做程式員也有些年頭了,回過頭來看以前似乎領悟到的OO思想又有了一些新的感悟。一、代碼之外的對象提起OO,大家都會想到class關鍵字。以前老師這麼教的,平時自己也是這麼用的。雖然有些語言中的表現不一樣,但本質上都是差不多的。剛開始時,說OO是一種技術;後來說OO是一種潮流;再後來說OO是一種信仰;後來的後來說OO是
今天在公司,感覺沒什麼事可以做的,其實零零散散還是有些事,但就是沒提起勁來。突然覺得在這裡混不下去了,有點需要重新正視自己,我是不是有些什麼問 題,怎麼沒人會喜歡我呢,連工作的時候跟領導關係都搞不好,領導都不喜歡我,當然混不出啥名堂了。一旁的同事在那邊收拾東西,她終於可以如願去北京了。另 外一個最近經常一起吃午飯的同事,說已經跟領導說了,要辭職了。我問他去哪裡,他說還沒找,就在這裡找一下,想找個自己感興趣的崗位。還說,上次問過我想
在我們的生活中到處都充斥著隱喻。中國人是最會拐彎抹角的,很多話都不直說,不明說。雖然這樣可能會產生一些問題,但是也沒有辦法,畢竟延續了幾千年的習慣,不是一朝一夕能改掉的。在軟體工程中有人提到過要將隱喻的概念納入進來,本身是一個非常好的想法,但由於各方面的原因最終還是沒能運用起來。一、XP中被遺棄的隱喻在軟體工程學中,由一些大師組成敏捷聯盟,提出一套敏捷式軟體開發 (Agile Software Development)的理論與方法。其中極限編程(XP)是最著名的一個。在早先的XP中,有“隱喻”
大概是因為經常參加體育鍛煉,又注意保養的結果吧! 每次看《Contribute to
之前寫過不少關於外掛程式系統的文章,有介紹架構的,也有介紹外掛程式結構的。今天主要是分析一下外掛程式系統的組裝過程。組裝包括兩個部分,介面的裝配、外掛程式互動關係的裝配。下面會介紹三種組裝策略,並簡單分析一下不同組裝策略的差異。一、外掛程式系統的生命期外掛程式是獨立的模組,每個模組向使用者提供一部分功能,只有將幾個模組組合起來才能真正給使用者帶來價值。外掛程式系統分為裝載期和運行期兩個階段。 裝載期時,裝載程式將不同的外掛程式按照設定檔群組裝起來,主要包括介面布局和外掛程式介面之間的調用關係。
隱喻是由團隊提出一個程式工作原理的公用景象。它可以協助我們從整體上把握系統的全域,使得描述問題非常直觀。團隊在做外掛程式系統的時候,我們拿到的只有Rose圖,和一些基本設計的思路文檔,但對於外掛程式系統究竟是什麼,每個人的理解深度、方式都不一樣。究其 原因,就是因為我們沒有一個直觀,形象的描述系統的一個東西。概要設計文檔是不能算的,太粗且不形象。這個時候我們需要的就是一個隱喻系統,協助團隊統一
在Gof的設計模式中,有一個模式引起的爭議比較大,有很多人甚至認為這個模式應該排除在OO模式之外,原因在於它不具有OO的特性。不管怎麼說,這個引起爭議的模式還是非常特別的,只要我們靜下心來分析一下,不難發現它的迷人之處。這個模式就是Command模式。一、基本的Command模式最簡單的Command模式中,包含一個ICommand介面,介面只有一個方法Execute。不同的Command對象實現這個介面,用戶端程式通過介面訪問Execute方法的不同實現。好像也沒什麼,這個模式太簡單了,幾分鐘