• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            posts - 62,  comments - 19,  trackbacks - 0
            [問題]
            通常我們按下CTRL+ATL+DEL組合鍵后,可以看到正在運行的程序或者進程,有沒有辦法讓程序從CTRL+ATL+DEL消失掉呢?也就是說讓正在運行的程序對CTRL+ATL+DEL不可見。
            [解答]
            答案是肯定的,辦法如下:
            使用Win32 API 函數RegisterServiceProcess,但是這個API函數的文檔你是很難找到的。這里我們要用一下匯編。

            #include <windows.h>

            HINSTANCE hLibrary;
            void *regproc;

            void CADInit(void);
            void HideApp(void);
            void ShowApp(void);
            void CADClean(void);

            int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
            {
              CADInit(); //加載 DLL 并創建一指向它指針
              HideApp(); //隱藏程序
              //ShowApp(); //顯示程序

              //其他處理或調用
              
              CADClean(); //卸載 DLL
              return 0; //retrun 0 因為沒有進入消息循環
            }

            void CADInit(void)
            {
              //加載 kernel32.dll
              hLibrary = LoadLibrary("kernel32.dll");
              //獲取函數RegisterServiceProcess的地址
              regproc = GetProcAddress(hLibrary, "RegisterServiceProcess");
            }

            void HideApp(void)
            {
              //實現程序的隱藏
              __asm
              {
               push 1
               push 0
               call regproc
              }
              return;
            }

            void ShowApp(void)
            {
              //恢復狀態
              __asm
              {
                  push 0
                  push 0
                  call regproc
              }
              return;
            }

            void CADClean(void)
            {
              //卸載 DLL
              FreeLibrary(hLibrary);
              return;
            }
            本程序在W2K和Win9x測試通過。
            posted @ 2007-04-09 14:51 喬棟 閱讀(747) | 評論 (0)編輯 收藏
            一、數字音頻基礎知識
            • Fourier級數:

            任何周期的波形可以分解成多個正弦波,這些正弦波的頻率都是整數倍。級數中其他正線波的頻率是基礎頻率的整數倍。基礎頻率稱為一級諧波。

            • PCM:

            pulse code modulation,脈沖編碼調制,即對波形按照固定周期頻率采樣。為了保證采樣后數據質量,采樣頻率必須是樣本聲音最高頻率的兩倍,這就是Nyquist頻率。
            樣本大小:采樣后用于存儲振幅級的位數,實際就是脈沖編碼的階梯數,位數越大表明精度越高,這一點學過數字邏輯電路的應該清楚。

            • 聲音強度:

            波形振幅的平方。兩個聲音強度上的差常以分貝(db)為單位來度量,

            • 計算公式如下:

            20*log(A1/A2)分貝。A1,A2為兩個聲音的振幅。如果采樣大小為8位,則采樣的動態范圍為20*log(256)分貝=48db。如果樣本大小為16位,則采樣動態范圍為20*log(65536)大約是96分貝,接近了人聽覺極限和痛苦極限,是再線音樂的理想范圍。windows同時支持8位和16位的采樣大小。



            posted @ 2007-04-09 14:50 喬棟 閱讀(664) | 評論 (0)編輯 收藏

            問題:
            對button,我直接用WM_COMMAND是可以的。 現在我想嘗試使用VC的ON_NOTIFY,怎么試也不起作用。

            解答:
            ON_NOTIFY是針對WM_NOTIFY的消息宏,而WM_NOTIFY是針對 
            ListCtrl,TreeCtrl,TabCtrl等通用控件使用的消息 
            button,listbox等基本控件是不會用到這個消息的 .

             

            posted @ 2007-04-09 10:12 喬棟 閱讀(4423) | 評論 (0)編輯 收藏




            http://blog.csdn.net/ruibird/archive/2007/03/31/1547882.aspx




            posted @ 2007-04-05 11:18 喬棟 閱讀(247) | 評論 (0)編輯 收藏


            http://www.vckbase.com/document/viewdoc/?id=957




            posted @ 2007-04-05 11:16 喬棟 閱讀(170) | 評論 (0)編輯 收藏

            DICOM 標準包括以下內容:
            PS 3.1: Introduction and Overview (引言和概述);
            PS 3.2: Conformance(一致性);
            PS 3.3: Information Object Defini-tions(信息對象定義);
            PS 3.4: Service Class Specifications (服務類規范);
            PS 3.5: Data Structure and Encod-ing: (數據結構和編碼規定);
            PS 3.6: Data Dictionary(數據字典);
            PS 3.7: Message Exchange(信息交換);
            PS 3.8: Network Communication Support for Message Exchange(信息交換的網絡通訊支持);
            PS 3.9: Point-to-Point Communi-cation Support for Message Exchange (信息交換的點對點通訊支持);
            PS 3.10: Media Storage and File Format for Data Interchange(便于數據交換的介質存儲方式和文件格式);
            PS 3.11: Media Storage Application Profiles(介質存儲應用框架);
            PS 3.12: Storage Functions and Media Formats for Data Interchange(便于數據交換的存儲方案和介質格式);
            PS 3.13: Print Management Point-to-Point Communication Support(打印管理的點對點通訊支持)。



            DICOM 涵蓋了數字圖像信息構成和通信兩個領域,內容極其煩瑣、龐大,目前沒有任何醫學系統可以
            支持所有的DICOM 服務,每一種設備都是只針對自己最需要的部分提供支持。我們也根據核醫學的需
            要,制定了自己的符合DICOM 標準的圖像文件格式。其中核醫學圖像文件結構部分主要參閱了DICOM
            標準的PS 3.3~PS 3.6 和PS 3.10。

            其中規定了Patient、Study、Series、Image 四個層次的醫學圖像
            信息結構,以及由它們組成的信息對象(Informa-tion Object); 采用服務類客戶/服務類提供者(Service
            Class User/Service Class Provider)概念組成的服務—對象對(Service-Object Pair); 支持點對點(PPP)和
            TCP/IP 網絡通信協議。

            DICOM 文件一般由一個DICOM 文件頭和一個DICOM 數據集合組成。DICOM 數據集合是按照DICOM 標準的PS 3.5 部分來編碼組成的.

            在DICOM 文件中最基本的單元是數據元素(Data Element)。DICOM 數據集合就是由DICOM 數據元素
            按照一定的順序排列組成的。
            DICOM 數據元素的組成主要由四個部分組成: 標簽、VR (Value Representation,數據描述)、數據長度和數據域。
            (1) 標簽是一個4 字節的無符號整數。DICOM 所有的數據元素都可以用標簽來唯一表示,各個標簽對
            應什么數據元素可以查閱DICOM 標準PS 3.6 部分—數據字典。
            在DICOM 中人為地將標簽分為兩個部分: 組號(高位2 字節)和元素號(低位2 字節),在數據字典中所有
            的元素都是用“(組號,元素號)”這種方式來表示的。
            (2) VR 指明了該數據元素中的數據是哪種類型的。在DICOM 文件中,它是一個長度為2 的字符串,例
            如,如果一個數據元素的VR 為“DA”,則表示該數據元素中存儲的數據為日期型數據,如果一個數據
            元素的VR 為“FL”則表示該數據元素中存儲的數據為浮點型數據。關于VR 的詳細取值和說明可以參閱
            DICOM 標準PS 3.5 部分第15~21 頁的表6.2-1。
            在數據元素中,VR 是可選的,它取決于協商的傳輸數據格式。DICOM 中規定了顯式(Explicit VR)和隱
            式(Inexplicit VR)兩種傳輸格式,其中在顯式傳輸時,VR 必須存在; 在隱式傳輸時,VR 必須省略。表1
            和表2 是顯式傳輸時數據元素的格式,表3 為隱式傳輸時數據元素的格式。
            (3) 數據長度指明該數據元素的數據域中數據的長度(字節數)。
            (4) 數據域中包含了該數據元素的數值。

            DICOM 文件頭
            DICOM 文件頭(DICOM File Meta Information)包含了標識數據集合的相關信息。每個DICOM 文件都必
            須包括該文件頭。文件頭的最開始是文件前言,它由128 個00H 字節組成,接下來是DICOM 前綴,它
            是一個長度為4 字節的字符串“DICM”,可以根據該值來判斷一個文件是不是DICOM 文件。
            文件頭中
            還包括其它一些非常有用的信息,如文件的傳輸格式、生成該文件的應用程序等等,關于文件頭詳細的
            說明請參閱DICOM 標準PS 3.10 的13~14 頁表7.1-1。
            說明:
            (1) 除了128 字節的文件前言和4 字節的DICOM 前綴外,所有其它的文件頭元素都必須采用上面介紹
            的顯示格式編碼,各個數據元素排列的順序按照標簽數值從小到大的傳輸格式(Little Endian)編碼。
            (2) 每個文件頭元素的長度必須為偶數,否則應該按照規定補充一個字節。
            (3) 所有(0002,****)類的標簽都為DICOM 所保留。為了兼容后續版本,如果發現文件中有目前尚未
            規定的(0002,****)類標簽,則應該忽略它。

            DICOM 數據集合
            DICOM 文件主要組成部分就是數據集合。這不僅包括醫學圖像,還包括許多和醫學圖像有關的信息,
            如病人姓名、圖像大小等。

            表中“使用”列為“M”時表示該模塊必須存在,“U”表示可選,“C”表示在特定的情況下必須存在。
            例如在制定Patient 模塊時,查閱DICOM 標準PS 3.3 部分的C.7.1.1 小節,可以查到的病人模塊屬性表.


            &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&



            posted @ 2007-04-03 10:02 喬棟 閱讀(1392) | 評論 (2)編輯 收藏
               技術類:                                                                    非技術類:
               深入淺出MFC                                                         余秋雨
               規定每天看夠30~50頁.至少看夠30頁               <<千年一嘆>>

                .NET框架                                                                  茅于軾
                等待上本看完后再定進度.                                    <<生活中的經濟學>>


                重構(優化現有代碼設計)                                       <<張居正>>
                 等待上奔看完后再定進度
            posted @ 2007-04-02 11:05 喬棟 閱讀(99) | 評論 (0)編輯 收藏

              @echo off

              echo 正在清除系統垃圾文件,請稍等......

              del /f /s /q %systemdrive%\*.tmp

              del /f /s /q %systemdrive%\*._mp

              del /f /s /q %systemdrive%\*.log

              del /f /s /q %systemdrive%\*.gid

              del /f /s /q %systemdrive%\*.chk

              del /f /s /q %systemdrive%\*.old

              del /f /s /q %systemdrive%\recycled\*.*

              del /f /s /q %windir%\*.bak

              del /f /s /q %windir%\prefetch\*.*

              rd /s /q %windir%\temp & md %windir%\temp

              del /f /q %userprofile%\COOKIES s\*.*

              del /f /q %userprofile%\recent\*.*

              del /f /s /q "%userprofile%\Local Settings\Temporary Internet Files\*.*"

              del /f /s /q "%userprofile%\Local Settings\Temp\*.*"

              del /f /s /q "%userprofile%\recent\*.*"

              sfc /purgecache '清理系統盤無用文件

              defrag %systemdrive% -b '優化預讀信息

              echo 清除系統LJ完成!

              echo. & pause






            posted @ 2007-03-30 17:18 喬棟 閱讀(412) | 評論 (0)編輯 收藏
            作為程序員,平時最擔心見到的事情就是程序發生了崩潰,無論是指針越界還是非法操作,都將給我們的應用系統造成巨大的損失。但在一個大型系統的測試過程中,初期出現程序崩潰似乎成了不可避免的事。其實測試中出現程序崩潰并不可怕,反而是測試的成功。我們更為關心的是程序中的哪一行導致了系統崩潰,這樣我們才能有針對性的進行改正。
              在VC中,我們可以利用出現程序崩潰時VC的自動跳轉,定位到出錯代碼行。但在大量的壓力測試時,尤其是多線程測試時,同時出現幾十個錯,這時VC本身的出錯跳轉往往會失靈。
              在這里我們介紹一種輔助查找程序崩潰代碼行的好方法,它的核心就是利用編譯時生成MAP文件中的信息來定位代碼行。
            下面就開始我們的介紹。
              首先我們必須生成程序的MAP文件。那么什么是 MAP 文件呢?簡單地講, MAP 文件是程序的全局符號、源文件和代碼行號信息的唯一的文本表示方法,是整個程序工程信息的靜態文本。它可以在任何地方、任何時候使用,不需要有額外的程序進行支持,僅僅通過一個文本閱讀工具如Ultra Edit就可以打開了。而且,這是唯一能找出程序崩潰代碼行的救星。
              那么我們應該如何生成MAP文件呢?在 VC 中,我們可以按下 Alt+F7,打開“Project Settings”選項頁,選擇 C/C++ 選項卡,并在最下面的 Project Options 里面輸入:/Zd ,然后要選擇 Link 選項卡,選中“Generate mapfile”復選框,并在最下面的 Project Options 里面輸入:/mapinfo:lines,表示生成 MAP 文件時,加入行信息。最后按下 F7 來編譯生成 EXE 可執行文件和 MAP 文件,此時可以在工程的Debug目錄下找到剛剛生成的MAP文件,文件名為“工程名.map”。
              通過上面的步驟,已經得到了 MAP 文件,那么我們該如何利用它呢?讓我們從一個簡單的實例入手,一步一步演示使用MAP文件定位程序崩潰行的過程。
            首先假設我們的VC工程中有下面這個文件:
            //*****************************************************
            // 程序名稱:演示如何通過崩潰地址找出源代碼的出錯行
            // 作者:劉可
            // 日期:2003-6-19
            // 本程序會產生“除0錯誤”,所以會導致
            // 程序崩潰,彈出“非法操作”對話框。
            //******************************************************
            #include

            int crashtest(int a,int b)
            {
            int c;
            c = a/b;
            return c;
            }

            void main(void)
            {
            int a = 30;
            int b = 0;
            int ret;
            printf("let's begin crash test...\n");
            ret = crashtest(a,b);
            }

            很顯然本程序有“除0錯誤”,在 Debug 方式下編譯,運行時會產生“非法操作”。我們記錄下產生崩潰的地址——在我的機器上是 0x0040102f 。這個在不同的機器上可能地址不同,但記下這個地址我們下面將要使用。
            我們打開它的 MAP 文件:(這里列出我們比較關心的內容,其他的就略過了)

            abort(工程名)

            Timestamp is 3ef16533 (Thu Jun 19 15:24:35 2003)

            Preferred load address is 00400000

            Start    Length    Name        Class
            0001:00000000 0001081dH .text        CODE
            0002:00000000 000013baH .rdata        DATA
            0002:000013ba 00000000H .edata        DATA
            0003:00000000 00000104H .CRT$XCA       DATA
            0003:00000104 00000104H .CRT$XCZ       DATA
            0003:00000208 00000104H .CRT$XIA       DATA
            0003:0000030c 00000109H .CRT$XIC       DATA
            0003:00000418 00000104H .CRT$XIZ       DATA
            0003:0000051c 00000104H .CRT$XPA       DATA
            0003:00000620 00000104H .CRT$XPX       DATA
            0003:00000724 00000104H .CRT$XPZ       DATA
            0003:00000828  00000104H .CRT$XTA       DATA
            0003:0000092c  00000104H .CRT$XTZ       DATA
            0003:00000a30  00003236H .data        DATA
            0003:00003c68  000019c8H .bss        DATA
            0004:00000000  00000014H .idata$2       DATA
            0004:00000014  00000014H .idata$3       DATA
            0004:00000028  00000120H .idata$       DATA
            0004:00000148  00000120H .idata$5        DATA
            0004:00000268  000004f4H .idata$6       DATA

            Address Publics by Value Rva+Base Lib:Object

            0001:00000020 ?crashtest@@YAHHH@Z 00401020 f main.obj
            0001:0000003c _main 0040103c f main.obj
            0001:000000b0 _printf 004010b0 f LIBCD:printf.obj
            0001:00000130 __chkesp 00401130 f LIBCD:chkesp.obj
            0001:00000170 _mainCRTStartup 00401170 f LIBCD:crt0.obj
            0001:000002a0 __amsg_exit 004012a0 f LIBCD:crt0.obj
            0001:00000300 __stbuf 00401300 f LIBCD:_sftbuf.obj
            0001:00000460 __ftbuf 00401460 f LIBCD:_sftbuf.obj
            0001:00000520 __output 00401520 f LIBCD:output.obj
            0001:000013c0 ___initstdio 004023c0 f LIBCD:_file.obj
            0001:000014f0 ___endstdio 004024f0 f LIBCD:_file.obj
            0001:00001510 __CrtDbgBreak 00402510 f LIBCD:dbgrpt.obj
            0001:00001520 __CrtSetReportMode 00402520 f LIBCD:dbgrpt.obj
            0001:00001580 __CrtSetReportFile 00402580 f LIBCD:dbgrpt.obj
            0001:00001600 __CrtSetReportHook 00402600 f LIBCD:dbgrpt.obj
            0001:00001620 __CrtDbgReport 00402620 f LIBCD:dbgrpt.obj

              如果仔細瀏覽 Rva+Base 這欄,我們可以發現第一個比崩潰地址 0x0040102f 大的函數地址是 0x0040103c ,所以在 0x0040103c 這個地址之前的那個入口就是產生崩潰的函數,也就是這行:

            0001:00000020 ?crashtest@@YAHHH@Z 00401020 f main.obj

              因此,發生崩潰的函數就是 ?crashtest@@YAHHH@Z,所有以問號開頭的函數名稱都是 C++ 修飾的名稱。所以在我們的源程序中,這個發生崩潰的函數就是 crashtest ()!

              現在我們便輕而易舉地知道了發生崩潰的函數名稱。把它記下來,然后我們將要直接定位發生崩潰的代碼行了。我們注意 MAP 文件的最后部分——代碼行信息(Line numbers information),它是以這樣的形式顯示的:

            Line numbers for .\Debug\main.obj(D:\我的工作\技術\出異常例子abort\main.cpp) segment .text

            12 0001:00000020 14 0001:0000002b 15 0001:00000035 16 0001:00000038
            19 0001:0000003c 20 0001:00000057 21 0001:0000005e 23 0001:00000065
            24 0001:00000072 25 0001:00000085

              第一個數字代表在源代碼中的代碼行號,第二個數是該代碼行在所屬的代碼段中的偏移量。如果要查找代碼行號,需要使用下面的公式做一些十六進制的減法運算:

            崩潰行偏移 = 崩潰地址(Crash Address)- 基地址(ImageBase Address)- 0x1000

              為什么要這樣做呢?因為我們得到的崩潰地址都是由 偏移地址(Rva)+ 基地址(Base)得來的,所以在計算行號的時候要把基地址減去。一般情況下,基地址的值是 0x00400000 。另外,由于一般的 PE 文件的代碼段都是從 0x1000 偏移開始的,所以也必須減去 0x1000 。
              所以我們的:崩潰行偏移 = 0x0040102f - 0x00400000 - 0x1000 = 0x2f
            我們在MAP 文件的中的代碼行信息里查找不超過計算結果0x2f,但卻最接近的數。發現是 main.cpp 文件中的:

            14 0001:0000002b

              也就意味著在源代碼中的第 14 行!讓我們來看看源代碼,注意注釋行和空行也要計算在內,程序的第14行為:

            c = a/b;

            果然就是第 14 行啊,它發生了“除0異常”!

              方法已經介紹完了,從今以后,我們就可以精確地定位到源代碼中的崩潰行,而且只要編譯器可以生成 MAP 文件,無論在WIN平臺還是UNIX平臺,本方法都是適用的。
              本文我們只是列舉了一個非常簡單的“除0異常”例子,使用MAP文件的效力或許還不十分明顯。但相信在我們的大型應用系統調試中,使用MAP文件的輔助方法來快速定位發生程序崩潰的函數以及代碼行,將會為我們的程序調試工作節省大量時間和精力,提高我們的調試質量。我們甚至可以要求遠地用戶直接提供程序崩潰的地址,然后就可以在自己機器上利用MAP文件靜態地找到出錯的那行,并在程序中進行相應修正了。

            &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

            VC7下運行OK.


            posted @ 2007-03-26 10:37 喬棟 閱讀(801) | 評論 (0)編輯 收藏
            從前,現在,將來

            從前的我,熱衷于收集網絡上所有我可能會用到的技巧,并為能在自己的作品中出現這樣的技巧而興奮不已.

            現在的我,熱衷于看別人寫下的文章,并嘗試理解它的意義,迅速的記錄下來,并且更加迅速的忘掉.

            將來的我......

            我想,將來應該嘗試去寫一些這樣的文章,去以一個書寫者的角度來觀感別人的作品,或許更有收獲.


            從前的我,不知道自己是不是能當一個好程序員.

            現在的我,知道自己可以作一個好程序員,但是不知道下來怎么辦.

            將來的我.......

            不知道.

            從前的我,熱衷社交,喜歡琢磨穿著飲食.

            現在的我,更加喜歡耐臟而樸素的衣服,更加順口健康的食品,當然,越廉價越好

            將來的我.......

            也許,會追求時裝會品位美食,也可能會更喜歡樸素的衣服,和健康而廉價的食品.

            從前,我沒有這樣的文字.

            現在,我嘗試將這樣劈為橫枝豎條的爛木頭一樣文字組合起來,卻為其轟然倒塌而沮喪不已.

            將來,我會寫出更好的更滿意的文字去記錄這些歷程,像大廈一樣堅固.
            posted @ 2007-03-25 22:57 喬棟 閱讀(914) | 評論 (2)編輯 收藏
            僅列出標題
            共7頁: 1 2 3 4 5 6 7 
            <2009年4月>
            2930311234
            567891011
            12131415161718
            19202122232425
            262728293012
            3456789

            常用鏈接

            留言簿(6)

            隨筆分類

            隨筆檔案

            文章分類

            文章檔案

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜


            My blog is worth $0.00.
            How much is your blog worth?

            韩国三级中文字幕hd久久精品 | 精品乱码久久久久久夜夜嗨| 久久国产热精品波多野结衣AV| 欧美日韩精品久久久久| 伊人热热久久原色播放www| 久久久久国产精品嫩草影院| 国产叼嘿久久精品久久| 久久亚洲精品无码播放| 亚洲精品高清一二区久久| 亚洲欧美精品一区久久中文字幕| 久久一区二区三区免费| 精品久久久久成人码免费动漫 | 国产aⅴ激情无码久久| 欧美日韩精品久久久久| 日韩人妻无码精品久久久不卡 | 精品久久久久久久无码| 久久91精品国产91久久麻豆| 色综合久久久久| 久久综合久久性久99毛片| 亚洲国产成人久久精品99| 精品国产青草久久久久福利| 97久久精品国产精品青草| 91视频国产91久久久| 久久精品国产91久久综合麻豆自制| 蜜桃麻豆www久久| 久久亚洲AV无码西西人体| 亚洲七七久久精品中文国产 | 久久人人爽人人爽人人片av高请| 7777久久亚洲中文字幕| 蜜桃麻豆www久久国产精品| 久久人人爽人人爽人人片av高请| 精品久久久久久99人妻| 久久久久亚洲精品无码网址 | 久久精品嫩草影院| 中文字幕无码久久久| 久久精品人人做人人爽电影| 亚洲欧美另类日本久久国产真实乱对白| 久久男人Av资源网站无码软件| 久久国产热这里只有精品| 97久久久久人妻精品专区| 久久人妻AV中文字幕|