这是什么意思？每个进程都有一个特殊的寄存器，这个寄存器指向下一条要执行的指令的内存地址，即32位Intel和AMD处理器上所谓的EIP寄存器。因为EIP是个特殊的寄存器，所以你不能像访问通用寄存器（EAX，EBX等）那样来访问它。换句话说，你找不到一个可以用来寻址EIP并且对它进行读写的操作码（OpCode）。然而，EIP同样可以被JMP，CALL，RET等指令隐含地改变（事实上它一直都在改变）。让我们举例说明32位的Intel和AMD处理器上CALL/RET是如何工作的吧：

     当我们用CALL调用一个子程序时，这个子程序的地址被加载进EIP。同时，在EIP被改变之前，它以前的值会被自动压栈（在后来被用作返回指令指针[return instruction-pointer]）。在子程序的最后RET指令自动把这个值从栈中弹出到EIP。

     现在我们知道了如何通过CALL和RET来修改EIP的值了，但是如何得到他的当前值？
还记得CALL把EIP的值压栈了吗？所以为了得到EIP的值我们调用了一个“假（dummy）函数”然后弹出栈顶值。看一下编译过的NewProc：

Address    OpCode/Params    Decoded instruction
————————————————–
:00401000   55          push ebp             ; entry point of
                                                ; NewProc
:00401001   8BEC             mov ebp, esp
:00401003   51               push ecx
:00401004   E800000000       call 00401009        ; *a*     call dummy
:00401009   59          pop ecx             ; *b*
:0040100A   83E909           sub ecx, 00000009    ; *c*
:0040100D   894DFC           mov [ebp-04], ecx    ; mov pData, ECX
:00401010   8B45FC           mov eax, [ebp-04]
:00401013   83E814           sub eax, 00000014    ; pData–;
…..
…..
:0040102D   8BE5             mov esp, ebp
:0040102F   5D               pop ebp
:00401030   C21000           ret 0010

     a． 一个假的函数调用；仅仅跳到下一条指令并且（译者注：更重要的是）把EIP压栈。
     b． 弹出栈顶值到ECX。ECX就保存的EIP的值；这也就是那条“pop ECX”指令的地址。
     c． 注意从NewProc的入口点到“pop ECX”指令的“距离”为9字节；因此把ECX减去9就得到的NewProc的地址了。

     这样一来，不管被复制到什么地方，NewProc总能正确计算自身的地址了！然而，要注意从NewProc的入口点到“pop ECX”的距离可能会因为你的编译器/链接选项的不同而不同，而且在Release和Degub版本中也是不一样的。但是，不管怎样，你仍然可以在编译期知道这个距离的具体值。
     1． 首先，编译你的函数。
     2． 在反汇编器（disassembler）中查出正确的距离值。
     3． 最后，使用正确的距离值重新编译你的程序。

     这也是InjectEx中使用的解决方案。InjectEx和HookInjEx类似，交换开始按钮上的鼠标左右键点击事件。

解决方案2

     在远程进程中把INJDATA放在NewProc的前面并不是唯一的解决方案。看一下下面的NewProc：
static LRESULT CALLBACK NewProc(
   HWND hwnd,       // handle to window
   UINT uMsg,       // message identifier
   WPARAM wParam,   // first message parameter
   LPARAM lParam ) // second message parameter
{
     INJDATA* pData = 0xA0B0C0D0;     // 一个假值

     //—————————–
     // 子类代码
     // ……..
     //—————————–

     // 调用以前的窗口过程
     return pData->fnCallWindowProc( pData->fnOldProc,
                                     hwnd,uMsg,wParam,lParam );
}

     这里，0XA0B0C0D0仅仅是INJDATA在远程进程中的地址的占位符（placeholder）。你无法在编译期得到这个值，然而你在调用VirtualAllocEx（为INJDATA分配内存时）后确实知道INJDATA的地址！（译者注：就是VirtualAllocEx的返回值）

     我们的NewProc编译后大概是这个样子：
Address    OpCode/Params      Decoded instruction
————————————————–
:00401000   55                 push ebp
:00401001   8BEC               mov ebp, esp
:00401003   C745FCD0C0B0A0     mov [ebp-04], A0B0C0D0
:0040100A   …
….
….
:0040102D   8BE5               mov esp, ebp
:0040102F   5D                 pop ebp
:00401030   C21000             ret 0010

     编译后的机器码应该为：558BECC745FCD0C0B0A0……8BE55DC21000。

     现在，你这么做：
     1． 把INJDATA，ThreadFunc和NewFunc复制到目的进程。
     2． 改变NewPoc的机器码，让pData指向INJDATA的真实地址。
     比如，假设INJDATA的的真实地址（VirtualAllocEx的返回值）为0x008a0000，你把NewProc的机器码改为：

558BECC745FCD0C0B0A0……8BE55DC21000   <- 修改前的 NewProc 1    
558BECC745FC00008A00……8BE55DC21000   <- 修改后的 NewProc  

     也就是说，你把假值 A0B0C0D0改为INJDATA的真实地址2
     3． 开始指向远程的ThreadFunc，它子类了远程进程中的控件。

     &sup1; 你可能会问，为什么A0B0C0D0和008a0000在编译后的机器码中为逆序的。这时因为Intel和AMD处理器使用littl-endian标记法（little-endian notation）来表示它们的（多字节）数据。换句话说：一个数的低字节（low-order byte）在内存中被存放在最低位，高字节（high-order byte）存放在最高位。
想像一下，存放在四个字节中的单词“UNIX”，在big-endia系统中被存储为“UNIX”，在little-endian系统中被存储为“XINU”。

     &sup2; 一些蹩脚的破解者用类似的方法来修改可执行文件的机器码，但是一个程序一旦载入内存，就不能再更改自身的机器码（一个可执行文件的.text段是写保护的）。我们能修改远程进程中的NewProc是因为它所处的那块内存在分配时给予了PAGE_EXECUTE_READWRITE属性。

     何时使用CreateRemoteThread和WriteProcessMemory技术

    通过CreateRemoteThread和WriteProcessMemory来注入代码的技术，和其他两种方法相比，不需要一个额外的DLL文件，因此更灵活，但也更复杂更危险。一旦你的ThreadFunc中有错误，远程线程会立即崩溃（看附录F）。调试一个远程的ThreadFunc也是场恶梦，所以你应该在仅仅注入若干条指令时才使用这个方法。要注入大量的代码还是使用另外两种方法吧。

     再说一次，你可以在文章的开头部分下载到WinSpy，InjectEx和它们的源代码。

     写在最后的话

     最后，我们总结一些目前还没有提到的东西：

     方法 适用的操作系统 可操作的进程进程    
     I. Windows钩子 Win9x 和WinNT 仅限链接了USER32.DLL的进程1    
     II. CreateRemoteThread & LoadLibrary 仅WinNT2 所有进程3，包括系统服务4    
     III. CreateRemoteThread & WriteProcessMemory 近WinNT 所有进程，包括系统服务  

     1． 很明显，你不能给一个没有消息队列的线程挂钩。同样SetWindowsHookEx也对系统服务不起作用（就算它们连接了USER32）。
     2． 在Win9x下没有CreateRemoteThread和VirtualAllocEx（事实上可以在9x上模拟它们，但是到目前为止还只是个神话）
    3． 所有进程 ＝ 所有的Win32进程 ＋ csrss.exe
     本地程序（native application）比如smss.exe, os2ss.exe, autochk.exe，不使用Win32 APIs，也没有连接到kernel32.dll。唯一的例外是csrss.exe，win32子系统自身。它是一个本地程序，但是它的一些库（比如winsrv.dll）需要Win32 DLL包括kernel32.dll.
     4.如果你向注入代码到系统服务或csrss.exe，在打开远程进程的句柄（OpenProcess）之前把你的进程的优先级调整为“SeDebugprovilege”(AdjustTokenPrivileges)。

     大概就这些了吧。还有一点你需要牢记在心：你注入的代码（特别是存在错误时）很容易就会把目的进程拖垮。记住：责任随权利而来（Power comes with responsibility）！

     这篇文章中的很多例子都和密码有关，看过这篇文章后你可能也会对Zhefu Zhang（译者注：大概是一位中国人，张哲夫??）写的Supper Password Spy++感兴趣。他讲解了如何从IE的密码框中得到密码，也说了如何保护你的密码不被这种攻击。

     最后一点：读者的反馈是文章作者的唯一报酬，所以如果你认为这篇文章有作用，请留下你的评论或给它投票。更重要的是，如果你发现有错误或bug；或你认为什么地方做得还不够好，有需要改进的地方；或有不清楚的地方也都请告诉我。

感谢
     首先，我要感谢我在CodeGuru（这篇文章最早是在那儿发表的）的读者，正是由于你们的鼓励和支持这篇文章才得以从最初的1200单词发展到今天这样6000单词的“庞然大物”。如果说有一个人我要特别感谢的话，他就是Rado Picha。这篇文章的一部分很大程度上得益于他对我的建议和帮助。最后，但也不能算是最后，感谢Susan Moore，他帮助我跨越了那个叫做“英语”的雷区，让这篇文章更加通顺达意。
――――――――――――――――――――――――――――――――――――
附录
A) 为什么kernel32.dll和user32.dll中是被映射到相同的内存地址？
我的假定：以为微软的程序员认为这么做可以优化速度。让我们来解释一下这是为什么。
一般来说，一个可执行文件包含几个段，其中一个为“.reloc”段。

当链接器生成EXE或DLL时，它假定这个文件会被加载到一个特定的地址，也就是所谓的假定/首选加载/基地址（assumed/preferred load/base address）。内存映像（image）中的所有绝对地址都时基于该“链接器假定加载地址”的。如果由于某些原因，映像没有加载到这个地址，那么PE加载器（PE loader）就不得不修正该映像中的所有绝对地址。这就是“.reloc”段存在的原因：它包含了一个该映像中所有的“链接器假定地址”与真正加载到的地址之间的差异的列表（注意：编译器产生的大部分指令都使用一种相对寻址模式，所以，真正需要重定位[relocation]的地方并没有你想像的那么多）。如果，从另一方面说，加载器可以把映像加载到链接器首选地址，那么“.reloc”段就会被彻底忽略。

但是，因为每一个Win32程序都需要kernel32.dll，大部分需要user32.dll，所以如果总是把它们两个映射到其首选地址，那么加载器就不用修正kernel32.dll和user32.dll中的任何（绝对）地址，加载时间就可以缩短。

让我们用下面的例子来结束这个讨论：
把一个APP.exe的加载地址改为kernel32的（/base:”0x77e80000″）或user32的（/base:”0x77e10000″）首选地址。如果App.exe没有引入UESE32，就强制LoadLibrary。然后编译App.exe，并运行它。你会得到一个错误框（“非法的系统DLL重定位”），App.exe无法被加载。

为什么？当一个进程被创建时，Win2000和WinXP的加载器会检查kernel32.dll和user32.dll是否被映射到它们的首选地址（它们的名称是被硬编码进加载器的），如果没有，就会报错。在WinNT4 中ole32.dll也会被检查。在WinNT3.51或更低版本中，则不会有任何检查，kernel32.dll和user32.dll可以被加载到任何地方。唯一一个总是被加载到首选地址的模块是ntdll.dll，加载器并不检查它，但是如果它不在它的首选地址，进程根本无法创建。

总结一下：在WinNT4或更高版本的操作系统中：
●总被加载到它们的首选地址的DLL有：kernel32.dll，user32.dll和ntdll.dll。
●Win32程序（连同csrss.exe）中一定存在的DLL：kernel32.dll和ntdll.dll。
●所有进程中都存在的dll：ntdll.dll。

B) /GZ编译开关
在Debug时，/GZ开关默认是打开的。它可以帮你捕捉一些错误（详细内容参考文档）。但是它对我们的可执行文件有什么影响呢？

当/GZ被使用时，编译器会在每个函数，包含函数调用中添加额外的代码（添加到每个函数的最后面）来检查ESP栈指针是否被我们的函数更改过。但是，等等，ThreadFunc中被添加了一个函数调用？这就是通往灾难的道路。因为，被复制到远程进程中的ThreadFunc将调用一个在远程进程中不存在的函数。

C) static函数和增量连接（Incremental linking）
增量连接可以缩短连接的时间，在增量编译时，每个函数调用都是通过一个额外的JMP指令来实现的（一个例外就是被声明为static的函数！）这些JMP允许连接器移动函数在内存中的位置而不用更新调用该函数的CALL。但是就是这个JMP给我们带来了麻烦：现在ThreadFunc和AfterThreadFunc将指向JMP指令而不是它们的真实代码。所以，当计算ThreadFunc的大小时：
const int cbCodeSize = ((LPBYTE) AfterThreadFunc – (LPBYTE) ThreadFunc);
你实际得到的将是指向ThreadFunc和AfterThreadFunc的JMP指令之间的“距离”。现在假设我们的ThreadFunc在004014C0，和其对应的JMP指令在00401020
:00401020    jmp   004014C0
…
:004014C0    push EBP           ; ThreadFunc的真实地址
:004014C1    mov   EBP, ESP
…
然后，
WriteProcessMemory( .., &ThreadFunc, cbCodeSize, ..);
将把“JMP 004014C0”和其后的cbCodeSize范围内的代码而不是ThreadFunc复制到远程进程。远程线程首先会执行“JMP 004010C0”，然后一直执行到这个进程代码的最后一条指令（译者注：这当然不是我们想要的结果）。

然而，如果一个函数被声明为static，就算使用增量连接，也不会被替换为JMP指令。这就是为什么我在规则#4中说把ThreadFunc和AfterThreadFunc声明为static或禁止增量连接的原因了。（关于增量连接的其他方面请参看Matt Pietrek写的“Remove Fatty Deposits from Your Applications Using Our 32-bit Liposuction Tools”）

D) 为什么ThreadFunc只能有4K的局部变量？
局部变量总是保存在栈上的。假设一个函数有256字节的局部变量，当进入该函数时（更确切地说是在functions prologue中），栈指针会被减去256。像下面的函数：
void Dummy(void) {
     BYTE var[256];
     var[0] = 0;
     var[1] = 1;
     var[255] = 255;
}
会被编译为类似下面的指令：
:00401000    push ebp
:00401001    mov   ebp, esp
:00401003    sub   esp, 00000100            ; change ESP as storage for
                                          ; local variables is needed
:00401006    mov   byte ptr [esp], 00       ; var[0] = 0;
:0040100A    mov   byte ptr [esp+01], 01    ; var[1] = 1;
:0040100F    mov   byte ptr [esp+FF], FF    ; var[255] = 255;
:00401017    mov   esp, ebp                 ; restore stack pointer
:00401019    pop   ebp
:0040101A    ret

请注意在上面的例子中ESP（栈指针）是如何被改变的。但是如果一个函数有多于4K的局部变量该怎么办？这种情况下，栈指针不会被直接改变，而是通过一个函数调用来正确实现ESP的改变。但是就是这个“函数调用”导致了ThreadFunc的崩溃，因为它在远程进程中的拷贝将会调用一个不存在的函数。

让我们来看看文档关于栈探针（stack probes）和/Gs编译选项的说明：
“/Gssize选项是一个允许你控制栈探针的高级特性。栈探针是编译器插入到每个函数调用中的一系列代码。当被激活时，栈探针将温和地按照存储函数局部变量所需要的空间大小来移动

如果一个函数需要大于size指定的局部变量空间，它的栈探针将被激活。默认的size为一个页的大小（在80×86上为4k）。这个值可以使一个Win32程序和Windows NT的虚拟内存管理程序和谐地交互，在运行期间向程序栈增加已提交的内存总数。

我能确定你们对上面的叙述（“栈探针将温和地按照存储函数局部变量所需要的空间大小来移动”）感到奇怪。这些编译选项（他们的描述！）有时候真的让人很恼火，特别是当你想真的了解它们是怎么工作的时候。打个比方，如果一个函数需要12kb的空间来存放局部变量，栈上的内存是这样“分配”的
sub     esp, 0x1000     ; 先“分配”4 Kb
test   [esp], eax       ; touches memory in order to commit a
                       ; new page (if not already committed)
sub     esp, 0x1000     ; “分配”第二个 4 Kb
test   [esp], eax       ; …
sub     esp, 0x1000
test   [esp], eax

注意栈指针是如何以4Kb为单位移动的，更重要的是每移动一步后使用test对栈底的处理（more importantly, how the bottom of the stack is “touched” after each step）。这可以确保了在“分配”下一个页之前，包含栈底的页已经被提交。

继续阅读文档的说明：
“每一个新的线程会拥有（receives）自己的栈空间，这包括已经提交的内存和保留的内存。默认情况下每个线程使用1MB的保留内存和一个页大小的以提交内存。如果有必要，系统将从保留内存中提交一个页。”（看MSDN中GreateThread > dwStackSize   > “Thread Stack Size”）

..现在为什么文档中说“这个值可以使一个Win32程序和Windows NT的虚拟内存管理程序和谐地交互”也很清楚了。

E) 为什么我要把多于3个case分支的swith分割开来呢？
同样，用例子来说明会简单些：
int Dummy( int arg1 )
{
     int ret =0;

     switch( arg1 ) {
     case 1: ret = 1; break;
     case 2: ret = 2; break;
     case 3: ret = 3; break;
     case 4: ret = 0xA0B0; break;
     }
     return ret;
}
将会被编译为类似下面的代码：
Address    OpCode/Params     Decoded instruction
————————————————–
                                              ; arg1 -> ECX
:00401000   8B4C2404          mov ecx, dword ptr [esp+04]
:00401004   33C0              xor eax, eax      ; EAX = 0
:00401006   49                dec ecx           ; ECX —
:00401007   83F903            cmp ecx, 00000003
:0040100A   771E              ja 0040102A

; JMP to one of the addresses in table ***
; note that ECX contains the offset
:0040100C   FF248D2C104000    jmp dword ptr [4*ecx+0040102C]

:00401013   B801000000        mov eax, 00000001    ; case 1: eax = 1;
:00401018   C3                 ret
:00401019   B802000000        mov eax, 00000002    ; case 2: eax = 2;
:0040101E   C3                 ret
:0040101F   B803000000        mov eax, 00000003    ; case 3: eax = 3;
:00401024   C3                 ret
:00401025   B8B0A00000        mov eax, 0000A0B0    ; case 4: eax = 0xA0B0;
:0040102A   C3                 ret
:0040102B   90                 nop

; 地址表 ***
:0040102C   13104000          DWORD 00401013    ; jump to case 1
:00401030   19104000          DWORD 00401019    ; jump to case 2
:00401034   1F104000          DWORD 0040101F    ; jump to case 3
:00401038   25104000          DWORD 00401025    ; jump to case 4

看到switch-case是如何实现的了吗？
它没有去测试每个case分支，而是创建了一个地址表（address table）。我们简单地计算出在地址表中偏移就可以跳到正确的case分支。想想吧，这真是一个进步，假设你有一个50个分支的switch语句，假如没有这个技巧，你不的不执行50次CMP和JMP才能到达最后一个case，而使用地址表，你可以通过一次查表即跳到正确的case。使用算法的时间复杂度来衡量：我们把O（2n）的算法替换成了O(5)的算法，其中：
1． O代表最坏情况下的时间复杂度。
2． 我们假设计算偏移（即查表）并跳到正确的地址需要5个指令。

现在，你可能认为上面的情况仅仅是因为case常量选择得比较好，（1，2，3，4，5）。幸运的是，现实生活中的大多数例子都可以应用这个方案，只是偏移的计算复杂了一点而已。但是，有两个例外：
●如果少于3个case分支，或
●如果case常量是完全相互无关的。（比如 1， 13， 50， 1000）。
最终的结果和你使用普通的if-else if是一样的。

有趣的地方：如果你曾经为case后面只能跟常量而迷惑的话，现在你应该知道为什么了吧。这个值必须在编译期间就确定下来，这样才能创建地址表。

回到我们的问题！
注意到0040100C处的JMP指令了吗？我们来看看Intel的文档对十六进制操作码FF的说明：
Opcode    Instruction   Description
FF /4     JMP r/m32    Jump near, absolute indirect, address given in r/m32

JMP使用了绝对地址！也就是说，它的其中一个操作数（在这里是0040102C）代表一个绝对地址。还用多说吗？现在远程的ThreadFunc会盲目第在地址表中004101C然后跳到这个错误的地方，马上使远程进程挂掉了。

F) 到底是什么原因使远程进程崩溃了？
如果你的远程进程崩溃了，原因可能为下列之一：
1． 你引用了ThreadFunc中一个不存在的字符串。
2． ThreadFunc中一个或多个指令使用了绝对寻址（看附录E中的例子）
3． ThreadFunc调用了一个不存在的函数（这个函数调用可能是编译器或连接器添加的）。这时候你需要在反汇编器中寻找类似下面的代码：
:004014C0     push EBP          ; entry point of ThreadFunc
:004014C1     mov EBP, ESP
…
:004014C5     call 0041550      ; 在这里崩溃了
                               ; remote process
…
:00401502     ret
如果这个有争议的CALL是编译器添加的（因为一些不该打开的编译开关比如/GZ打开了），它要么在ThreadFunc的开头要么在ThreadFunc接近结尾的地方

不管在什么情况下，你使用CreateRemoteThread & WriteProcessMemory技术时必须万分的小心，特别是编译器/连接器的设置，它们很可能会给你的ThreadFunc添加一些带来麻烦的东西。

参考（省略）
文章历史（省略）

<结束>

Windows下C语言网络编程快速入门

  
C语言的学习，一般的方式是，先学C，然后是C++，最好还要有汇编语言和微机原理基础，然后才是Visual C++。这样的方式，对学习者来说，要花费很多时间和耐力。而在学校教学中，也没有时间深入学习Windows编程的实用技术了。

其实，具有了C语言基础后，再有一些基本的C++类的概念，就可以直接学习Windows C编程了。

一、走近Windows C语言

很多语言都把显示一个“Hello,World!”做为第一个入门程序， C语言的第一个程序是这样的：

#include<stdio.h>
main()
{
printf(“Hello,World!”);
}

如果把main函数写成带参数的main函数，应该是：

#include<stdio.h>
main(int arge,char *argv[])
{
printf(“Hello,World!”);
}

Windows C的第一个程序和这个程序在形式和原理上都是一致的，只是有两点不同：

1. 主函数接收的形参不只是命令行中的字符串的个数和字符串的首地址。

2. C语言的很多函数在Windows C中都可以继续使用，但象printf（）屏幕显示等函数就不能继续使用了。因为Windows是多任务操作系统，屏幕已不再为某一个应用程序所独有，Windows C应用程序要显示字符串，需要使用Windows提供的API函数，开自己的窗口

下面是一个最简单的，显示“Hello,World!”的Windows C程序：

#include<windows.h>
APIENTRY WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,
LPSTR lpCmdLine,int nCmdShow)
{
MessageBox(NULL,"Hello,World!","第一个Windows C程序",MB_OK|MB_ICONASTERISK);
}

主函数的形参有四个：

1) Hinstance：接收程序运行时当前实例的句柄；
2) HprivInstance：前一个实例的句柄；
3) LpCmdLine：程序命令行指针；
4) NcmdShow：一个用来指定窗口显示方式的整数。

这几个参数的使用我们会在深入的学习中介绍的。

显示Hello,Word!字符串，我们使用了一个MessageBox函数，这个函数会在屏幕上显示一个对话框，它的原型是：

int MessageBox(HWND hWnd,LPCTSTR lpText,LPCTSTR lpCaption,UNIT uType)

四个参数分别是：

1) HWnd：父窗口的句柄；
2) LpText：要显示字符串的指针；
3) LpCaption：对话框标题字符串的指针；
4) UType：显示在对话框上的小图标的类型。

使用这个函数要包含windows.h头文件。

调试一下，怎么样？窗口上弹出了一个“第一个Windows C程序”对话框，上面有一行字：“Hello,World!”。

世界真的很美好啊！！

深入编程：

在C语言中，函数的声明，如果没有指明返回值类型，缺省值为void，这个程序的主函数就没有返回值。不过，在Windows编程时，我们最好养成个好习惯，指明函数的返回值类型，因为在C++中，函数返回值类型是不可以缺省的。而我们在Windows C编程时，还是会用到C++的一些概念，这样做，有利于以后深入地学习。

规范一点的程序应该是这样的：

#include<windows.h>
int APIENTRY WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,
LPSTR lpCmdLine,int nCmdShow)
{
MessageBox(NULL,"Hello,World!","第一个Windows C程序",MB_OK|MB_ICONASTERISK);
return 0;
}

这里，我们声明的类型为int型，并且返回一个值0，这样的函数就可以使用在复杂一点的函数调用中了。

在这一节中，我们有几处都提到了句柄的概念，句柄和指针的概念不同，它是作为操作系统内部索引表中的一个值来使用的，这样可以防止应用程序直接访问名对象的内部结构，体现了Windows资源管理的优越性。譬如说，一个窗口找开之后，好对应内存中的一个内存块，这个窗口所在的内存快地址往往会由操作系统做动态的调整，但其却不会随之变化。不过，通过它可以访问这个窗口，所以在使用的时候，可以把它当做指针一样看待。
二、 获取本地计算机的主机名和IP地址

和C语言一样，函数是Windows C编程的最基本的单位。不过，Windows C主要使用API函数，而网络编程则主要使用Winsock提供的API函数。

Winsock是90年代初，为了方便网络编程，由Microsoft联合了其他几家公司共同制定的一套WINDOWS下的网络编程接口，它是通过C语言的动态链接库方式提供给用户及软件开发者的，主要由winsock.h头文件和动态链接库winsock.dll组成，目前有两个版本：Winsock1.1和Winsock2.0。

在Win32平台上，访问众多的基层网络协议，Winsock是首选接口。

用Visual C++6.0编译Windows C程序，使用Winsock API函数时，首先要把wsock32.lib添加到它的库模块中，否刚在链接的时候，会出现“error LNK2001”错误。添加wsock32.lib的具体步骤是：打开工程菜单，选择设置，在弹出的Project settings对话框中，点击link选项卡，然后在对象/库模块文本框中添加wsock32.lib。

最简单的网络编程是获取本机的主机名和IP地址，这个程序使用了WSAStart（）、WSAClenaup()、gethostname（）、gethostbyname（）四个winsock API函数,这四个函数的功能和使用方法介绍如下：

1． WSAStartup():

【函数原型】

int PASCAL FAR WSAStartup(WORD wVersionRequired, LPWSADATA lpWSAData);

【使用说明】

每一个使用winsock的应用程序，都必须进行WSAStart函数调用，并且只有在调用成功之后才能使用其它的winsock网络操作函数。

WVersionRequired：<输入>表示欲使用的Ｗinsock版本，这是一个WORD类型的整数，它的高位字节定义的是次版本号，低位字节定义的是主版本号。

LpWSAData：<输出>是一个指向WSADATA资料的指针。这个资料我们一般不使用。

返回值：调用成功返回0；否则，返回出错信息。

2． WSAClenaup():

【函数原型】

int PASCAL FAR WSACleanup(void);

【使用说明】

winsock使用后，要调用ＷSACleanup函数关闭网络设备，以便释放其占用的资源。

3．gethostname()

【函数原型】

int PASCAL FAR gethostname (char FAR * name, int namelen);

【使用说明】

该函数可以获取本地主机的主机名，其中：

name：<输出>用于指向所获取的主机名的缓冲区的指针。

Namelen：<输入>缓冲区的大小，以字节为单位。

返回值：若无错误，返回0；否则，返回错误代吗。

4．gethostbyname()

【函数原型】

struct hostent FAR * PASCAL FAR gethostbyname(const char FAR * name);

【使用说明】

该函数可以从主机名数据库中得到对应的“主机”。

该函数唯一的参数name就是前面调用函数gethostname()得到的主机名。若无错误，刚返回一个指向hostent结构的批针，它可以标识一个“主机”列表。

Hostent结构定义如下：

Struct hostent
{
char FAR * h_name;
char FAR FAR ** h_aliases;
short h_addrtype;
char FAR FAR ** h_addr_list;
}

其中：

h_name：<输入>主机名地址（PC）。
h_aliases：一个由主机备用名组成的空中止数组。
H_addrtype：返回地址的类型，对于Winsock,这个域总是PF_INET。
H_lenth：每个地址的长度（字节数），对应于PF_INET域应该为4。
H_addr_list：应该以空指针结尾的主机地址的列表，返回的地址是以网络顺序排列的。

其中，h_addr_list[0]存放的就是本地主机的4个字节的IP地址，即：

h_addr_list[0][0].h_addr_list[0][1].h_addr_list[0][2].h_addr_list[0][3]

一个简单的用消息框显示主机名和IP地址的源程序如下：

#include<winsock.h>

int WSA_return;
WSADATA WSAData;

HOSTENT *host_entry;
char host_name[256];
char host_address[256];

int APIENTRY WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,
LPSTR lpCmdLine,int nCmdShow)
{
WSA_return=WSAStartup(0x0101,&WSAData);

if(WSA_return==0)
{
gethostname(host_name,256);
host_entry=gethostbyname(host_name);
if(host_entry!=0)
{
wsprintf(host_address,"%d.%d.%d.%d",
(host_entry->h_addr_list[0][0]&0x00ff),
(host_entry->h_addr_list[0][1]&0x00ff),
(host_entry->h_addr_list[0][2]&0x00ff),
(host_entry->h_addr_list[0][3]&0x00ff));

MessageBox(NULL,host_address,host_name,MB_OK);
}
}
WSACleanup();
return 0;
}

深入编程：

前面显示IP地址的时候，我们使用的是消息框，规范一点的编程应该使用对话框，如何编辑一个对话框，很多书中都有介绍，编辑的对话框可参考图5的运行界面。

头文件Get_IP.h如下：

BOOL APIENTRY Hostname_ipDlgPro(HWND hDlg,UINT message,WPARAM wParam,LPARAM lParam);

这个程序只使用了一个对话框过程，一般把这个过程的声明放在头文件中。

源程序Get_IP.c：

#include<winsock2.h>
#include"Get_IP.h"
#include"resource.h" //这个头文件在创建资源的时候会自动生成,
//并会在插入资源时自动生成控件标识号.
int WSA_return;
WSADATA WSAData;

HOSTENT *host_entry;
char host_name[256];
char host_address[256];

int APIENTRY WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,
LPSTR lpCmdLine,int nCmdShow)
{
WSA_return=WSAStartup(0x0101,&WSAData);
if(WSA_return==0)
{
gethostname(host_name,256);
host_entry=gethostbyname(host_name);
if(host_entry!=0)
{
wsprintf(host_address,"%d.%d.%d.%d",
(host_entry->h_addr_list[0][0]&0x00ff),
(host_entry->h_addr_list[0][1]&0x00ff),
(host_entry->h_addr_list[0][2]&0x00ff),
(host_entry->h_addr_list[0][3]&0x00ff));
}
}
WSACleanup();
DialogBox(hInstance,"DIALOG1",NULL,(DLGPROC)Hostname_ipDlgPro);
return 0;
}

BOOL APIENTRY Hostname_ipDlgPro(HWND hDlg,UINT message,
WPARAM wParam,LPARAM lParam)
{
switch(message)
{
case WM_INITDIALOG:
return(TRUE);
case WM_COMMAND:
if(LOWORD(wParam)==IDOK)
{
SetDlgItemText(hDlg,IDC_EDIT1,host_name);
SetDlgItemText(hDlg,IDC_EDIT2,host_address);
SetDlgItemText(hDlg,IDCANCEL,"确定");
}
if(LOWORD(wParam)==IDCANCEL)
EndDialog(hDlg,TRUE);
return(TRUE);
break;
}
return(FALSE);
}