vcc27.htm

SHELL排序算法与应用

          <br>
          　　);<br>
          <br>
          　　<br>
          　　因而，在Win32下不能通过判断hPrevInstance是否为NULL来判断一个程序的另一个实例是否存在，要用其他的方法来判断。<br>
          <br>
          　　<br>
          　　方法一<br>
          <br>
          　　用FindWindow 函数查找指定窗口，如果成功，则返回要找的窗口的句柄，否则返回NULL，由此可判断是否有程序的另一个实例存在。<br>
          <br>
          　　<br>
          　　下图的代码片段演示如何使用FindWindow函数：<br>
          <br>
          　　<br>
          　　TCHAR szClassName[] = _TEXT(&quot;My Wnd Class&quot;)；<br>
          <br>
          　　TCHAR szWndName[] = _TEXT(&quot;My Wnd&quot;)；<br>
          <br>
          　　HWND hWnd = FindWindow(szClassName，szWndName)；<br>
          <br>
          　　<br>
          　　if(hWnd){<br>
          <br>
          　　MessageBox(NULL, _TEXT(&quot;Another Instance is already running.&quot;), 
          _TEXT(&quot;Information&quot;),<br>
          <br>
          　　 MB_OK | MB_ICONINFORMATION);<br>
          <br>
          　　}<br>
          <br>
          　　<br>
          　　需要注意的是，很可能程序的各个实例有不同的窗口名，如果象下面这样调用FindWindow<br>
          <br>
          　　 HWND hWnd = FindWindow(szClassName，NULL)；<br>
          <br>
          　　则查找所有的窗口并匹配窗口类名，如果你能保证你的窗口类名是唯一的，那么你可以信赖FindWindow，否则，你需要用更好的方法。<br>
          <br>
          　　<br>
          　　方法二<br>
          <br>
          　　<br>
          　　通过在EXE之间共享数据段从而共享数据来判断是否有程序的另一个实例存在。<br>
          <br>
          　　每个EXE或DLL都是由段的集合组成，在Win32程序中，每个段以点（.）开头。例如，当编译程序是编译器时，则将所有代码放入一个叫.text的段、将所有未初始化的数据放入.bss段、将所有初始化的数据放入.data段。<br>
          <br>
          　　<br>
          　　可以给每个段赋予一个或多个属性（以下为常用的一些段属性）：<br>
          <br>
          　　<br>
          　　READ 段中的数据可读<br>
          <br>
          　　WRITE 段中的数据可写<br>
          <br>
          　　SHARED 段中的数据可被多个实例共享<br>
          <br>
          　　EXECUTE 段中的数据可被执行<br>
          <br>
          　　<br>
          　　可以用以下指令生成段:<br>
          <br>
          　　#pragma data_seg(&quot;Shared&quot;)<br>
          <br>
          　　static LONG g_lInstanceCount = -1;<br>
          <br>
          　　#pragma data_seg()<br>
          <br>
          　　<br>
          　　编译器生成这段代码时，产生一个新段，并把它所在#pragma data_seg(&quot;Shared&quot;)指令后的初始化数据放入新段Shared，未初始化的数据放入.bss段。#pragma 
          data_seg()以后的数据放回缺省数据段。<br>
          <br>
          　　<br>
          　　仅告诉编译器把特定数据放入自己的段内还不足以共享它们，还要告诉链接器在某一特定段内变量要共享。可以在链接时指定这个段的属性。<br>
          <br>
          　　/section:Shared,rws<br>
          <br>
          　　 段名 属性<br>
          <br>
          　　<br>
          　　程序初始化时，例如调用WinMain函数时，调用InterlockedIncrement函数使共享段内变量加1，就可以通过判断共享段内变量的值来判断一个程序有几个实例在运行。以下代码演示了如何判断一个正在运行的程序实例是这个程序的第一个实例。<br>
          <br>
          　　<br>
          　　BOOL bIsFirstInstance = (InterlockedIncrement(&amp;g_lInstanceCount) 
          == 0);<br>
          <br>
          　　 if(!bIsFirstInstance){<br>
          <br>
          　　 MessageBox(NULL, _TEXT(&quot;Screen Saver Launcher is already running.&quot;), 
          g_szAppName,<br>
          <br>
          　　 MB_OK | MB_ICONINFORMATION);<br>
          <br>
          　　 }<br>
          <br>
          　　<br>
          　　使共享段内变量加1，没使用 g_lInstanceCount ++，而是使用InterlockedIncrement(&amp;g_lInstanceCount)，因为InterlockedIncrement函数对变量的访问进行同步（Synchronize），阻止多个线程同时访问同一个变量。有关线程同步的内容请参阅有关Win32 
          SDK的文档。<br>
          <br>
          　　禁止多个Win32实例的方法很多，如Win32核心对象（Mutex, Semaphore）、全局原子等都可以用来禁止多个Win32实例，在这里我们只简单地介绍以上两种方法。<br>
          <br>
          　　<br>
          　　3．Screen Saver Launch:<br>
          <br>
          　　屏幕保护程序是以scr为扩展名的标准Windows可执行程序。当编辑可用屏幕保护程序的列表时，Control Panel Desktop 
          Applet在Windows启动目录（Windows目录和系统目录）下查找扩展名是scr的基于Windows的可执行程序，如果Windows目录和系统目录下同时存在相同文件名的屏幕保护程序，则忽略Windows目录下的那一个。任何蓄意的捣乱（如将文本文件或是基于DOS的可执行文件扩展名改为scr）Window95都不予理睬，但是将标准Windows可执行程序的扩展名改为scr时，Windows95及NT将不会察觉。这只是很极端的情况，相信用户不会采用这种做法来&quot;测试&quot;你的Windows.<br>
          <br>
          　　标准的基于Win32的屏幕保护程序必须按照严格的标准编写，有关详细介绍请参阅有关Win32 SDK文档。这里需要提到的一点是所有的基于Win32的屏幕保护程序都要求有一个不超过25个字符的说明字符串。在屏幕保护程序的资源字符串表中，这个说明字符串的标识必须是1。<br>
          <br>
          　　但我们发现在Windows 95下的屏幕保护程序不完全是严格按照标准编写的，当编辑可用屏幕保护程序的列表时，Control Panel 
          Desktop Applet只是简单地把屏幕保护程序的文件名加入列表，而不是加入上面提及的说明字符串。而在Windows NT下，系统严格区分标准的和非标准的屏幕保护程序。对于标准的屏幕保护程序，系统取得它的说明字符串并将其显示在屏幕保护程序的列表中；对于非标准的屏幕保护程序，系统只把它的文件名加入列表。<br>
          <br>
          　　由于Windows 95和Windows NT下屏幕保护程序的列表显示略有不同,所以这里分别加以说明。为区别起见，Windows 95下的SSLaunch用SSLaunch95表示，Windows 
          NT下的SSLaunch用SSLaunchNT表示。<br>
          <br>
          　　SSLaunch95 采用Window 95调用屏幕保护程序的方法，在Windows95的启动目录下搜索屏幕保护程序，把文件名加到任务栏通知区图标上下文菜单中，单击鼠标即可启动相应的屏幕保护程序。Windows 
          95把用户选中的屏幕保护程序名保存在 System.ini文件中\boot\SCRNSAVE.EXE 下。SSLaunch95比较系统保存的用户选中的屏幕保护程序名和搜索到的屏幕保护程序名，如果相同，则在任务栏通知区图标上下文菜单的相应菜单项设置检查标志，以表示这个屏幕保护程序是否是当前用户选中的。SSLaunch95没有判断Windows启动目录下的屏幕保护程序是否是真正的屏幕保护程序，因为Windows 
          95下的Win32不能轻易地判断一个scr文件是否是基于GDI的Windows可执行文件（NE 或PE格式）。作者找到了两个可用于判断文件类型的函数：SHGetFileInfo，GetBinaryType。SHGetFileInfo可以判断出.exe、.com、.bat几种文件类型，但认为.scr文件不是可执行文件；GetBinaryType可以轻易地判断出文件类型，但Windows 
          95不支持，只是简单地返回ERROR_NOT_IMPLEMENT，而Win32却支持它。<br>
          <br>
          　　点击示意图<br>
          <br>
          　　SSLaunch95也可以在Windows NT 下运行，不过弹出的上下文菜单不能用屏幕保护程序说明字符串填充，并且不能判断scr是否是基于GDI的Windows可执行程序。<br>
          <br>
          　　下面介绍SSLaunchNT在Windows NT下对scr文件的判别，以及从scr文件资源中取得屏幕保护程序描述字符串的方法。<br>
          <br>
          　　a.对scr文件的判别<br>
          <br>
          　　Windows NT提供了对GetBinaryType函数的支持，因此，可用此函数判断一个scr文件是否是Windows可执行程序，并判断出它是基于Win16还是 
          Win32的可执行程序。这一点很重要，因为，对基于Win32的scr文件，我们在后面要取得它的字符串资源中的一个重要信息，及对屏幕保护程序的描述字符串。还应注意的是，lpApplicationName应给出全路径，否则，它只在进程所在的路径下寻找文件，这样会导致错误，从而不能返回在Windows启动目录下的.scr文件的信息。<br>
          <br>
          <br>
          　　BOOL GetBinaryType(<br>
          <br>
          　　LPCTSTR lpApplicationName,<br>
          <br>
          　　LPDWORD lpBinaryType<br>
          <br>
          　　);<br>
          <br>
          　　GetBinaryType调用成功后，lpBinaryType指向的DWORD返回以下值：<br>
          <br>
          　　SCS_32BIT_BINARY 基于Win32的应用程序<br>
          <br>
          　　SCS_DOS_BINARY 基于MS-DOS的应用程序<br>
          <br>
          　　SCS_OS216_BINARY 基于16位OS/2的应用程序<br>
          <br>
          　　SCS_PIF_BINARY MS-DOS应用程序的PIF 文件<br>
          <br>
          　　SCS_POSIX_BINARY 基于POSIX的应用程序<br>
          <br>
          　　SCS_WOW_BINARY 基于16位Windows的应用程序<br>
          <br>
          　　b.从scr文件字符串资源中取得屏幕保护文件描述字符串<br>
          <br>
          　　当我们判断出了一个基于Win32的scr文件后，就可以着手取得它的字符串。在Win32中，有一种简单有效的方法：把一个EXE或DLL文件以数据文件方式加载，调用LoadLibraryEx函数。<br>
          <br>
          　　HINSTANCE LoadLibraryEx(<br>
          <br>
          　　LPCTSTR lpLibFileName, // EXE或DLL文件名<br>
          <br>
          　　HANDLE hFile, // 保留参数，必须为NULL<br>
          <br>
          　　DWORD dwFlags // 函数入口标志<br>
          <br>
          　　);<br>
          <br>
          　　dwFlags可以是0或以下标志的组合：<br>
          <br>
          　　DON'T_RESOLVE_DLL_REFERENCES 系统将DLL映射到进程的地址空间而不调用DllMain函数。<br>
          <br>
          　　LOAD_LIBRARY_AS_DATAFILE 系统将DLL象一个数据文件那样映射到进程的地址空间，而不调用DllMain函数。如果要取得EXE中的资源，也可调用LoadLibraryEx函数把EXE映射到进程地址空间。<br>
          <br>
          　　LOAD_WITH_ALTERED_SEARCH_PATH 将改变LoadLibraryEx在定位DLL文件时所采用的方法。<br>
          <br>
          　　<br>
          　　当以LOAD_LIBRARY_AS_DATAFILE的方式调用LoadLibraryEx时，系统只是简单地创建一个文件映象对象，把DLL（EXE）映射到本进程的地址空间，并不调用DllMain（WinMain）。如果调用成功，则函数返回一个HINSTANCE，即被映射到本进程地址空间的DLL（EXE）的装入地址，这样，就可以调用LoadString函数，从DLL（EXE）文件的字符串资源表中取得指定的字符串。<br>
          <br>
          　　点击示意图<br>
          <br>
          　　这里仍需指出的是，必须判断LoadString函数调用是否成功，因为有些scr文件（即使是基于Win32的）也有可能是非标准的（如Windows 
          95下的大多数scr文件），如果LoadString调用失败，则SSLaunchNT用文件名取代scr的描述字符串填入SSLaunchNT上下文菜单的菜单项。</span></font></p>
        <p>  转载自中国程序员网站 </span></font>
         
      </td>
    </tr>
    </tbody> 
  </table>
</div>
<p align="center"><script src="../../2.js"></script></a>
</body>
</html>