最近开始有点时间了，于是打算准备写一系列不大不小的文章介绍一下Windows下的编程教程。目前正在写总纲。考虑到没有那么多的时间详细的从头开写，所以我打算用其他书籍+我写的PPT方式。大概的效果就是已我自己走过的路进行一下总结，把我所能看到的路线用路标指出来，让新入门的人有个方向。
当然可能会有不少谬误，希望看的高手指出错误，让我不至于一错再错，通过MSN或者邮件的方式都可以谢谢。
早先听说过一个查询你的博客价值的网站，现在
http://www.egosurf.org/ 或许会有更多的Blogger关心， 因为它可以搜索你在Google、Yahoo、MSN、Del.icio.us以及Technorati中的点数，只要输入你的名字和你Blog的地址，就可以知道你各个搜索引擎上的点数是多少（应该就可以代表你的相关排名了）。它通过搜索引擎中搜索你的名字，然后查找属于你Blog的内容在搜索结果中的排名。
(00-12-79-C2-53-51)
另外还可以知道你的点数分别是从哪里赚到的，感恩节的时候记得要答谢才行，呵呵～还不快去试试！
Rebase is a command-line tool that you can use to specify the base addresses for the DLLs that your application uses.
>>A - C 0x60000000
>>D - F 0x61000000
>>G - I 0x62000000
>>J - L 0x63000000
>>M - O 0x64000000
>>P - R 0x65000000
>>S - U 0x66000000
>>V - X 0x67000000
>>Y - Z 0x68000000
agreement:
==========
the author of this document will not be responsible for any damage and/or
license violation that may occur. the information within this document is
provided "as is" without warranty of any kind...
this information was "collected" during sleepless nights, and is not
officially released by microsoft! it shall give you a peek at the windows(tm)
internals to give you a chance to recover from corrupted data.
the author has nothing to do with microsoft, except that he uses their
products...
if you don't agree with this, stop reading this document, and delete it at
once!
history:
========
what is the registry? where did it came from? two questions, which i will try to
answer here. the registry is a database (at least microsoft thinks so:)
which contains configuration information about the system.
it mainly is a memory dump which is saved to one or more files on the windows
host drive. it is loaded every system-boot and remains resident until
shutdown. since parts of it are not used during normal operation it will be
swapped out very soon. the registry appeared with windows 3.?? (sorry, i can't
remember any earlier version :-), where it was used for file associations and
the "ole" functions (the conection between ole-id's and the applications).
this is a critical information and since the registry has (almost) no
checksum information (!), it sometimes gets corrupted. this is the main
reason for this doc.
using windows 3.x, almost every configuration was done using good old ".ini"-
files, which were readable but slow and limited in size (64k). in windows 95
(and nt), the registry was used instead of these files. so, to edit a
particular setting, you would have to run the application which manages these
settings. :( but what if this app won't start? ms included a tool named
regedit in windows 3.?? and 95, and a regedt32 in windows nt. you can use
these apps to edit all contents of the registry (in windows nt the registry
supports security, as well as it provides the security for the whole system!)
an application can open a "key", write values (variables) to it and fill them
with data. each key represents also a value called "default" and can contain
any number of sub-keys. this will form a tree-structure as you can see at
the left half of regedit. (note: regedit from windows 3.?? has to be started
with /v or /y, i can't remember now)
where can i find the registry???
================================
that differs for each windows-version:
version file(s) contents
3.1x reg.dat complete windows 3.?? registry
95 system.dat system-values (hkey_local_machine)
user.dat user-values (hkey_users)
nt system32\config\sam sam-part of the registry (=nt security)
system32\config\software software-specific part
(hkey_local_machine\software)
system32\config\system system-specific part
(hkey_local_machine\system)
profiles\%username%\ntuser.dat user-specific part
(hkey_current_user\{s-1-xxx...})
profiles\%username%\ntuser.man like ntuser.dat but a
mandatory-profileif you are using a roaming-profile with windows nt, ntuser.xxx can be on
a network-share as well...
terms
=====
the registry consists of the following elements:
hive: strating point of the structure. the name of an hive starts
with the "hkey_"-prefix. can be seen as a "drive" in a file
system.
hive name beschreibung 3.1 95 nt4
hkey_classes_root points to the "class" key in
the "hkey_local_machine" hive,
the only hive in windows 3.?? x x x
hkey_current_user information and settings valid
for the currently logged in
user. (points to the correct x x
key under "hkey_users")
hkey_current_config settings for the currently
active hardware profile.
points to "hkey_local_machine\ x x
control\controlsetxxx
hkey_users contains all currently active
user settings. since nt is a
single user system, there
will be only one key (the s-id x x
of the active user), and a
".defualt" key (the settings
for the ctrl-alt-del environment)
hkey_localmachine all local settings x x
hkey_dyn_data as the name says, here you'll find x
dynamic data (cpu-usage,...)
key: a key to the registry can be seen as a directory in a file
system.
value: can be seen as the registrys "file"
data: is the actual setting, can be seen as the contents of a
file
windows 3.x
===========
this registry is the easiest one. it consists of 3 blocks, which are not
"signed" at all:
block position size
header 0 32 bytes
navigation-info 0x00000020 ???
data-block ??? ???
the "???" marked values can be read from the header.
header
======
offset size description
0x0000 8 byte ascii-text: "shcc3.10"
0x0008 d-word ?
0x000c d-word ? (always equal the d-word at 0x0008)
0x0010 d-word number of entrys in the navigation-block
0x0014 d-word offset of the data-block
0x0018 d-word size of the data-block
0x001c word ?
0x001e word ?
values marked "?" are not important for a read-access, and therefore unknown
to me...
navigation-block
================
this is where chaos rules! it consists of two different, 8 byte long blocks:
* navigation-info-record,
* text-info-record
the first record in the navigation block is a navigation info record.
navigation-info-record
offset size contents
0x00 word next key (same level)
0x02 word first sub-key (one level deeper)
0x04 word text-info-record key-namens
0x06 word text-info-record key-value (default)
the values are the locical number of the block inside the file:
offset=blocksize*blocknumber+headersize
since 2 of this values are constant:
offset=8*blocknumber+0x20
text-info-record
================
offset size contents
0x00 word ?
0x02 word number of references to this text
0x04 word text-length
0x06 word offset of the text-string inside the data-block
to get the text-offset inside the file you have to add this offset to the
data-offset inside the header.
data-block
==========
the data-block only consists of a collection of text-strings. right in front
of every text is a word which may or may not have a meaning. the offset in
the text-info record points directly to the text, the text-size has to be
defined in the text-info record too.
windows 95
==========
the windows95-registry files:
inside the windows-directory (default: c:\windows) are 2 files which are
loaded to form the registry:
system.dat
and
user.dat
this files are mapped to the following hives:
hkey_local_machine in system.dat
and
hkey_users in user.dat
the file structure:
===================
both files have the same structure. each of them consists of 3 blocks where
1 of these blocks can be repeated.
every block has a 4 byte long signature to help identify its contents.
id block-contents max. size
creg header 32 bytes @ offset 0
rgkn directory information
(tree-structure) ??? @ offset 32
rgdb the real data
(values and data) max. 65535 bytes an offset ??
these blocks are "sticked together" with no space between them, but always
a multiple of 16 in size.
the creg-block
==============
offset size inhalt
0x00000000 d-word ascii-"creg" = 0x47455243
0x00000008 d-word offset of 1st rgdb-block
0x00000010 d-word # of rgdb-blocks
all other values are not needed to read the registry...
the rgkn-block
==============
i assume that rgkn stands for registry-key-navigation. this block contains
the information needed to built the tree-structure of the registry. this
block will be larger then 65536 bytes (0xffff)!
all offset-values are relative to the rgkn-block!
offset size contents
0x00000000 d-word ascii-"rgkn" = 0x4e4b4752
0x00000004 d-word size of the rgkn-block in bytes
0x00000008 d-word rel. offset of the root-record
0x00000020 ???? tree-records (often the 1st record)
the tree-record
===============
the tree-record is a "complete" registry-key. it contains the "hash"-info
for the real data stored in this key.
offset size contents
0x0000 d-word always 0
0x0004 d-word hash of the key-name
0x0008 d-word always -1 (0xffffffff)
0x000c d-word offset of the owner (parent)-records
0x0010 d-word offset of the 1st sub-sey record
0x0014 d-word offset of the next record in this level
0x0018 d-word id-number of the real key
the 1st entry in a "usual" registry file is a nul-entry with subkeys: the
hive itself. it looks the same like other keys. even the id-number can
be any value.
the "hash"-value is a value representing the key's name. windows will not
search for the name, but for a matching hash-value. if it finds one, it
will compare the actual string info, otherwise continue with the next key.
end of list-pointers are filled with -1 (0xffffffff)
the id-field has the following format:
bits 31..16: number of the corresponding rgdb-blocks
bits 15..0: continuous number inside this rgdb-block.
the hash-method:
================
you are looking for the key: software\microsoft
first you take the first part of the string and convert it to upper case
software
the "\" is used as a seperator only and has no meaning here.
next you initialize a d-word with 0 and add all ascii-values of the string
which are smaller than 0x80 (128) to this d-word.
software = 0x0000026b
now you can start looking for this hash-value in the tree-record.
if you want to modify key names, also modify the hash-values, since they
cannot be found again (although they would be displayed in regedit)
the rgdb-block
==============
header:
offset size contents
0x0000 d-word ascii-"rgdb" = 0x42444752
0x0004 d-word size of this rgdb-block
0x0020 ???? rgdb records
rgdb-record (key-information)
=============================
offset size contents
0x0000 d-word record length in bytes
0x0004 d-word id-number
0x0008 d-word ??? size ???
0x000c word text length of key name
0x000e word number of values inside this key
0x0010 d-word always 0
0x0014 ???? key-name
0x???? ???? values
the first size (record length) can be used to find the next record.
the second size value is only correct if the key has at least one value,
otherwise it is a little lower.
the key-name is not 0-terminated, its length is defined by the key-
text length field. the values are stored as records.
value-record
============
offset size contents
0x0000 d-word type of data
0x0004 d-word always 0
0x0008 word length of value-name
0x000a word length of value-data
0x000c ???? value-name
0x???? ???? data
data-types
==========
value contents
0x00000001 regsz - 0-terminated string (sometimes without the 0!)
0x00000003 regbin - binary value (a simple data-block)
0x00000004 regdword - d-word (always 4 bytes in size)
windows nt (version 4.0)
========================
whoever thought that the registry of windows 95 and windows nt are similar
will be surprised! they only look much the same, but have completely other
structures!
since the rgdb-blocks in the windows 95 registry are not larger than
0xffff, we can see that it is optimized for a 16-bit os...
windows nt stores its registry in a page-oriented format with blocks
of 4kb (4096 = 0x1000 bytes)
the windows nt registry has 2 different blocks, where one can occure many
times...
the "regf"-block
================
"regf" is obviosly the abbreviation for "registry file". "regf" is the
signature of the header-block which is always 4kb in size, although only
the first 64 bytes seem to be used and a checksum is calculated over
the first 0x200 bytes only!
offset size contents
0x00000000 d-word id: ascii-"regf" = 0x66676572
0x00000004 d-word ????
0x00000008 d-word ???? always the same value as at 0x00000004
0x0000000c q-word last modify date in winnt date-format
0x00000014 d-word 1
0x00000018 d-word 3
0x0000001c d-word 0
0x00000020 d-word 1
0x00000024 d-word offset of 1st key record
0x00000028 d-word size of the data-blocks (filesize-4kb)
0x0000002c d-word 1
0x000001fc d-word sum of all d-words from 0x00000000 to 0x000001fb
i have analyzed more registry files (from multiple machines running
nt 4.0 german version) and could not find an explanation for the values
marked with ???? the rest of the first 4kb page is not important...
the "hbin"-block
================
i don't know what "hbin" stands for, but this block is always a multiple
of 4kb in size.
inside these hbin-blocks the different records are placed. the memory-
management looks like a c-compiler heap management to me...
hbin-header
===========
offset size contents
0x0000 d-word id: ascii-"hbin" = 0x6e696268
0x0004 d-word offset from the 1st hbin-block
0x0008 d-word offset to the next hbin-block
0x001c d-word block-size
the values in 0x0008 and 0x001c should be the same, so i don't know
if they are correct or swapped...
from offset 0x0020 inside a hbin-block data is stored with the following
format:
offset size contents
0x0000 d-word data-block size
0x0004 ???? data
if the size field is negative (bit 31 set), the corresponding block
is free and has a size of -blocksize!
the data is stored as one record per block. block size is a multiple
of 4 and the last block reaches the next hbin-block, leaving no room.
records in the hbin-blocks
==========================
nk-record
the nk-record can be treated as a kombination of tree-record and
key-record of the win 95 registry.
lf-record
the lf-record is the counterpart to the rgkn-record (the hash-function)
vk-record
the vk-record consists information to a single value.
sk-record
sk (? security key ?) is the acl of the registry.
value-lists
the value-lists contain information about which values are inside a
sub-key and don't have a header.
datas
the datas of the registry are (like the value-list) stored without a
header.
all offset-values are relative to the first hbin-block and point to the block-
size field of the record-entry. to get the file offset, you have to add
the header size (4kb) and the size field (4 bytes)...
the nk-record
=============
offset size contents
0x0000 word id: ascii-"nk" = 0x6b6e
0x0002 word for the root-key: 0x2c, otherwise 0x20
0x0004 q-word write-date/time in windows nt notation
0x0010 d-word offset of owner/parent key
0x0014 d-word number of sub-keys
0x001c d-word offset of the sub-key lf-records
0x0024 d-word number of values
0x0028 d-word offset of the value-list
0x002c d-word offset of the sk-record
0x0030 d-word offset of the class-name
0x0044 d-word unused (data-trash)
0x0048 word name-length
0x004a word class-name length
0x004c ???? key-name
the value-list
==============
offset size contents
0x0000 d-word offset 1st value
0x0004 d-word offset 2nd value
0x???? d-word offset nth value
to determine the number of values, you have to look at the
owner-nk-record!
der vk-record
=============
offset size contents
0x0000 word id: ascii-"vk" = 0x6b76
0x0002 word name length
0x0004 d-word length of the data
0x0008 d-word offset of data
0x000c d-word type of value
0x0010 word flag
0x0012 word unused (data-trash)
0x0014 ???? name
if bit 0 of the flag-word is set, a name is present, otherwise the
value has no name (=default)
if the data-size is lower 5, the data-offset value is used to store
the data itself!
the data-types
==============
wert beteutung
0x0001 regsz: character string (in unicode!)
0x0002 expandsz: string with "%var%" expanding (unicode!)
0x0003 regbin: raw-binary value
0x0004 regdword: dword
0x0007 regmultisz: multiple strings, seperated with 0
(unicode!)
the "lf"-record
===============
offset size contents
0x0000 word id: ascii-"lf" = 0x666c
0x0002 word number of keys
0x0004 ???? hash-records
hash-record
===========
offset size contents
0x0000 d-word offset of corresponding "nk"-record
0x0004 d-word ascii: the first 4 characters of the key-name,
padded with 0's. case sensitiv!
keep in mind, that the value at 0x0004 is used for checking the
data-consistency! if you change the key-name you have to change the
hash-value too!
the "sk"-block
==============
(due to the complexity of the sam-info, not clear jet)
offset size contents
0x0000 word id: ascii-"sk" = 0x6b73
0x0002 word unused
0x0004 d-word offset of previous "sk"-record
0x0008 d-word offset of next "sk"-record
0x000c d-word usage-counter
0x0010 d-word size of "sk"-record in bytes
????
???? ???? security and auditing settings...
????
the usage counter counts the number of references to this
"sk"-record. you can use one "sk"-record for the entire registry!
windows nt date/time format
===========================
the time-format is a 64-bit integer which is incremented every
0,0000001 seconds by 1 (i don't know how accurate it realy is!)
it starts with 0 at the 1st of january 1601 0:00! all values are
stored in gmt time! the time-zone is important to get the real
time!
common values for win95 and win-nt
==================================
offset values marking an "end of list", are either 0 or -1 (0xffffffff).
if a value has no name (length=0, flag(bit 0)=0), it is treated as the
"default" entry...
if a value has no data (length=0), it is displayed as empty.
simplyfied win-3.?? registry:
=============================
+-----------+
| next rec. |---+ +-----> +------------+
| first sub | | | | usage cnt. |
| name | | +--> +------------+ | | length |
| value | | | | next rec. | | | text |-------> +-------+
+-----------+ | | | name rec. |--+ +------------+ | xxxxx |
+------------+ | | value rec. |--------> +------------+ +-------+
v | +------------+ | usage cnt. |
+-----------+ | | length |
| next rec. | | | text |-------> +-------+
| first sub |------+ +------------+ | xxxxx |
| name | +-------+
| value |
+-----------+
greatly simplyfied structure of the nt-registry:
================================================
+-------------------------------------------------------------------------+
v |
+---------------+ +-------------> +-----------+ +------> +---------+ |
| "nk" | | | lf-rec. | | | nk-rec. | |
| id | | | # of keys | | | parent |---+
| date | | | 1st key |--+ | .... |
| parent | | +-----------+ +---------+
| suk-keys |-------+
| values |---------------------> +----------+
| sk-rec. |---------------+ | 1. value |--> +----------+
| class |--+ | +----------+ | vk-rec. |
+---------------+ | | | .... |
v | | data |--> +-------+
+------------+ | +----------+ | xxxxx |
| class name | | +-------+
+------------+ |
v
+---------+ +---------+
+-----> | next sk |---> | next sk |--+
| +---| prev sk | <---| prev sk | |
| | | .... | | ... | |
| | +---------+ +---------+ |
| | ^ |
| +--------------------+ |
+------------------------------------+
--------------------------------------------------------------------------------
hope this helps.... (although it was "fun" for me to uncover this things,
it took me several sleepless nights ;)
http://www.moon-soft.com/program/FORMAT/windows/WinReg.htm
用命令行控制Windows的设备
首先呢，你要从微软网站上下载一个叫Devcon的工具：http://download.microsoft.com/download/1/1/f/11f7dd10-272d-4cd2-896f-9ce67f3e0240/devcon.exe 把它解出来（哪来的鸡蛋，我闪！）
如果你对它的实现感兴趣的话，你可以在DDK中找到它的源码：DDK root\Src\Setup\Devcon。如果只是用用它方便的话不妨接着看它的使用。
我们看看它都有些什么参数：
devcon.exe [-r] [-m:\\<machine>] <command> [<arg>
]
-r if specified will reboot machine after command is complete, if needed.
<machine> 目标机器名字.
<command> 命令(见下面).
<arg>传给命令的参数.
For help on a specific command, type: devcon.exe help <command>
classfilter 允许修改class filters.
classes 显示设备安装classes.
disable 用指定的硬件名称或者instance ID禁用设备
driverfiles 列出设备安装的驱动文件.
drivernodes 显示设备的所有节点的驱动.
enable 用指定的硬件名称或者instance ID启用设备.
find 用指定的硬件名称或者instance ID查找设备.
findall 查找所有硬件设备包括不显示的.
help 显示帮助信息.
hwids 显示设备硬件ID.
install 手动安装设备.
listclass 显示所有设备的安装 class.
reboot 重启本地机器.
remove 用指定的硬件名称或者instance ID删除设备.
rescan 从新扫描硬件信息.
resources 显示设备使用的硬件资源.
restart 用指定的硬件名称或者instance ID重启设备.
stack 列出设备的驱动堆栈.
status 列出设备的状态.
update 手动更新设备驱动.
UpdateNI 不显示用户界面的更新设备状态
SetHwID 添加、删除、编辑硬件ID的顺序. 现在看看例子：
devcon -m:\\test find pci\*
如果你开启了test机器上的IPC$的话，就可以列出test上所有知道的PCI设备
devcon -r install %WINDIR%\Inf\Netloop.inf *MSLOOP
安装一个新的Microsoft loopback adaptor实例，如果要重启的话，该命令会自动重启
devcon classes
显示所有知道的安装类。包括未认识的设备如： "USB" 和描述名字如："Universal Serial Bus controllers".
devcon classfilter upper !filter1 !filter2
删除两个指定的classfilter .
devcon classfilter lower !badfilter +goodfilter
用"goodfilter"替换"badfilter".
devcon driverfiles =ports
列出被ports安装类使用的设备驱动文件
devcon disable *MSLOOP
禁用所有硬件ID结尾有"MSLOOP"的设备
devcon drivernodes @ROOT\PCI_HAL\PNP0A03
列出所有 ROOT\PCI_HAL\PNP0A03的兼容驱动.
devcon enable '*MSLOOP
启用所有硬件ID有"*MSLOOP". 用'修饰的*不再是通配符，而是普通字符
devcon find *
列出所有设备实例.
devcon find pci\*
列出所有本地的PCI设备
devcon find =ports *pnp*
列出 ports 中包含"PNP"的硬件设备.
devcon find =ports @root\*
列出所有在顶层的 ports .
devcon listclass usb 1394
显示安装类是 USB 和 1394的设备.
devcon remove @usb\*
删除所有USB设备
devcon rescan
重新扫描即插即用设备.
devcon resources =ports
列出ports 使用的资源.
devcon restart =net @'ROOT\*MSLOOP\0000
重启 loopback adaptor ROOT\*MSLOOP\0000.
devcon hwids=mouse
显示所有鼠标设备.
devcon sethwid @ROOT\LEGACY_BEEP\0000 := beep
关联设备 beep和the legacy beep device.
devcon status @pci\*
列出所有PCI设备的状态.
Lists the status of all COM ports.
devcon update mydev.inf *pnp0501
强制更新硬件ID有pnp0501 的设备使用Mydev.inf 驱动.
执行该命令后可能返回结果1 级错误，除非你指定了 -r, 让机器自动重启.
错误等级：
0：表示成功
1：表示需要重启
2：表示失败
3：语法错误
昨天，在CSDN中看见
帖子寻求解决挂载盘符的问题，今天把它搞定了。
本文只要用最新的SDK(或者2k以上)然后定义Windows版本_WIN32_WINNT为0x0500以上就能编译通过了。 改变盘符主要是用
SetVolumeMountPoint和DeleteVolumeMountPoint 两个函数。DeleteVolumeMountPoint 很简单就不多说了。SetVolumeMountPoint 的使用主要是要找到被挂载设备的VolumeName。但是设备被卸载以后用GetVolumeNameForVolumeMountPoint根本取不到VolumeName，怎么办呢？
微软XP的系统文件夹里面有一个叫diskpart.exe的命令行工具，用它可以改变盘符。那么它是怎么做到的呢？简单的分析（用VC6自带的工具DEPENDS.EXE）就可以看见这个程序使用了很多Setup API函数，我判断使用SetupDiEnumDeviceInfo来取得VolumeName的ClassGUID，但是结果发现取到的ClassGUID和用GetVolumeNameForVolumeMountPoint获取的没有卸载前的VolumeName中的ClassGUID不一样。怎么办呢？
没关系，让我们祭出屠龙刀：IDA Pro。如何反汇编分析不在本文的介绍了（挺麻烦，而我这人又比较懒嘿嘿）。我一阵海扁它，发现关键是要通过DefineDosDevice 函数将设备Attach到盘符上，然后用GetVolumeNameForVolumeMountPoint取到VolumeName，之后就可以用SetVolumeMountPoint将设备挂载到盘符上了
。我把它写成了函数如果要加载盘符就可以使用（前提是盘符未被占用）：
ChangeMountPoint( _T("H:\\"), _T("\\Device\\HarddiskVolume2"),true);
卸载的话用：
ChangeMountPoint( _T("H:\\"),NULL, false);
下面是ChangeMountPoint函数的实现：
bool ChangeMountPoint(LPCTSTR lpDriveLetter,LPCTSTR lpDevice,bool bAddMountPoint)
{
bool bRet = false;
TCHAR szDriveLetterAndSlash[4] = {0};
TCHAR szDriveLetter[3] = {0};
TCHAR szUniqueVolumeName[MAX_PATH] = {0};
if(lpDriveLetter && lpDevice)
{
szDriveLetter[0] = lpDriveLetter[0];
szDriveLetter[1] = TEXT(':');
szDriveLetter[2] = TEXT('\0');
szDriveLetterAndSlash[0] = lpDriveLetter[0];
szDriveLetterAndSlash[1] = TEXT(':');
szDriveLetterAndSlash[2] = TEXT('\\');
szDriveLetterAndSlash[3] = TEXT('\0');
if ( bAddMountPoint )
{
//Try to Attach lpDevice to lpDriveLetter
bRet = DefineDosDevice (DDD_RAW_TARGET_PATH, szDriveLetter,
lpDevice);
if (bRet)
{
if (!GetVolumeNameForVolumeMountPoint (szDriveLetterAndSlash,
szUniqueVolumeName,
MAX_PATH))
{
//Can't Find Attached lpDevice 's VolumeName
szUniqueVolumeName[0] = '\0';
}
bRet = DefineDosDevice (
DDD_RAW_TARGET_PATH|DDD_REMOVE_DEFINITION|
DDD_EXACT_MATCH_ON_REMOVE, szDriveLetter,
lpDevice);
if (!bRet)
return bRet;
bRet = SetVolumeMountPoint(szDriveLetterAndSlash,
szUniqueVolumeName);
}
}
else
{
bRet = DeleteVolumeMountPoint (szDriveLetterAndSlash);
}
}
return bRet;
}
使用IID_IShellFolder之类的接口的ID时候，有时后会出现Linker Tools Error LNK1103。
此时可以在某个.cpp文件中使用：
#include <initguid.h>
#undef _SHLGUID_H_
#include <ShlGuid.h>
这样就有了IID_IShellFolder的实现。接着就能正确在工程里使用IID_IShellFolder了。
有时候在Realse编译的时候也会出现，此时尝试以下的解决方法：
1.关闭优化，即 /Od 选项
2.关闭最小编译，即/Gm选项
3.打开函数级别链接/Gy 选项
4.尝试使用其他级别的编译/G选项
5.改变函数或者全局变量的顺序。
原文：
Turn off optimization with the /Od (Disable) option.
Disable minimal rebuild with the /Gm– (Enable Minimal Rebuild) option.
Compile with the /Gy (Enable Function-Level Linking) option to package functions.
Use a different code generation option. See the /G (Optimize for Processor) options.
Change the order of functions and global variables.
PrintDesktop函数将桌面的内容全部打印出来。main函数演示了显示我得电脑。
// EnumShellDesk.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <shlobj.h>
#include <shlwapi.h>
#pragma comment(lib,"shlwapi.lib")
#pragma comment(lib,"shell32.lib")
//IID_IShellFolder
#define EXPAND_SHLGUID(name, l, w1, w2) EXPAND_GUID(name, l, w1, w2, 0xC0,0,0,0,0,0,0,0x46)
#define EXPAND_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \
EXTERN_C const GUID DECLSPEC_SELECTANY name \
= { l, w1, w2, { b1, b2, b3, b4, b5, b6, b7, b8 } }
EXPAND_SHLGUID(EXIID_IShellFolder, 0x000214E6L, 0, 0);
int PrintDesktop()
{
LPMALLOC pMalloc;
LPITEMIDLIST pidlProgFiles = NULL;
LPITEMIDLIST pidlItems = NULL;
IShellFolder *psfFirstFolder = NULL;
IShellFolder *psfDeskTop = NULL;
IShellFolder *psfProgFiles = NULL;
LPENUMIDLIST ppenum = NULL;
ULONG celtFetched;
HRESULT hr;
STRRET strDispName;
TCHAR pszDisplayName[MAX_PATH];
ULONG uAttr;
CoInitialize( NULL );
hr = SHGetMalloc(&pMalloc);
hr = SHGetDesktopFolder(&psfDeskTop);
hr = psfDeskTop->QueryInterface(EXIID_IShellFolder,(LPVOID *) &psfProgFiles);
psfDeskTop->Release();
hr = psfProgFiles->EnumObjects(NULL,SHCONTF_FOLDERS | SHCONTF_NONFOLDERS , &ppenum);
while( hr = ppenum->Next(1,&pidlItems, &celtFetched) == S_OK && (celtFetched) == 1)
{
psfProgFiles->GetDisplayNameOf(pidlItems, SHGDN_INFOLDER, &strDispName);
StrRetToBuf(&strDispName, pidlItems, pszDisplayName, MAX_PATH);
printf("%s\n",pszDisplayName);
if(!psfFirstFolder)
{
uAttr = SFGAO_FOLDER;
psfProgFiles->GetAttributesOf(1, (LPCITEMIDLIST *) &pidlItems, &uAttr);
if(uAttr & SFGAO_FOLDER)
{
//Here Can Do Enum Sub Folder.
//hr = psfProgFiles->BindToObject(pidlItems, NULL, IID_IShellFolder, (LPVOID *) &psfFirstFolder);
//psfFirstFolder->Release();
//psfFirstFolder = NULL;
}
}
pMalloc->Free(pidlItems);
}
printf("\n",pszDisplayName);
pMalloc->Free(pidlProgFiles);
pMalloc->Release();
psfProgFiles->Release();
CoUninitialize();
return 0;
}
int main(int argc, char* argv[])
{
PrintDesktop();
return 0;
LPMALLOC pMalloc = NULL;
LPITEMIDLIST pidlProgFiles = NULL;
LPITEMIDLIST pidlItems = NULL;
IShellFolder *psfFirstFolder = NULL;
IShellFolder *psfDeskTop = NULL;
IShellFolder *psfProgFiles = NULL;
LPENUMIDLIST ppenum = NULL;
ULONG celtFetched;
HRESULT hr;
STRRET strDispName;
TCHAR pszDisplayName[MAX_PATH];
ULONG uAttr;
CoInitialize( NULL );
hr = SHGetMalloc(&pMalloc);
hr = SHGetFolderLocation(NULL, CSIDL_DRIVES, NULL, NULL, &pidlProgFiles);
hr = SHGetDesktopFolder(&psfDeskTop);
hr = psfDeskTop->BindToObject(pidlProgFiles, NULL, EXIID_IShellFolder, (LPVOID *) &psfProgFiles);
psfDeskTop->Release();
hr = psfProgFiles->EnumObjects(NULL,SHCONTF_FOLDERS | SHCONTF_NONFOLDERS , &ppenum);
while( hr = ppenum->Next(1,&pidlItems, &celtFetched) == S_OK && (celtFetched) == 1)
{
psfProgFiles->GetDisplayNameOf(pidlItems, SHGDN_INFOLDER, &strDispName);
StrRetToBuf(&strDispName, pidlItems, pszDisplayName, MAX_PATH);
printf("%s\n",pszDisplayName);
if(!psfFirstFolder)
{
uAttr = SFGAO_FOLDER;
psfProgFiles->GetAttributesOf(1, (LPCITEMIDLIST *) &pidlItems, &uAttr);
if(uAttr & SFGAO_FOLDER)
{
//hr = psfProgFiles->BindToObject(pidlItems, NULL, EXIID_IShellFolder, (LPVOID *) &psfFirstFolder);
}
}
pMalloc->Free(pidlItems);
}
printf("\n",pszDisplayName);
ppenum->Release();
if(psfFirstFolder)
{
hr = psfFirstFolder->EnumObjects(NULL,SHCONTF_FOLDERS | SHCONTF_NONFOLDERS, &ppenum);
while( hr = ppenum->Next(1,&pidlItems, &celtFetched) == S_OK && (celtFetched) == 1)
{
psfFirstFolder->GetDisplayNameOf(pidlItems, SHGDN_INFOLDER, &strDispName);
StrRetToBuf(&strDispName, pidlItems, pszDisplayName, MAX_PATH);
printf("%s\n",pszDisplayName);
pMalloc->Free(pidlItems);
}
ppenum->Release();
psfFirstFolder->Release();
}
pMalloc->Free(pidlProgFiles);
pMalloc->Release();
psfProgFiles->Release();
CoUninitialize();
return 0;
}
摘要: 从HTTP服务器上下载一个文件有很多方法，“热心”的微软提供了 WinInet 类，用起来也很方便。当然，我们也可以自己实现这些功能，通过格式化请求头很容易就能实现断点续传和检查更新等等功能 。
连接主机
格式化请求头
...
阅读全文
今天在CSDN上看到有人问关于类似QQ那样崩溃时弹出的自己的崩溃提示框（
原文）想了想，挺有意思。所以自己查了一下资料写了个库，方便使用
使用起来应该是比较简单的，但是我没有进行严格的测试，弟兄们不要扁我
将文件中的头文件和lib文件复制到你的工程里，将两个Dll复制到执行目录或者System32目录，然后工程里用代码设定即可（不设定按默认方式：不弹出提示，而在后台记录）。一个程序只要主线程包含该头文件即可。
例图：
上文设置出现出错提示框，和出错后要执行的命令行。如果逆向显示崩溃文件的话，将上面的设置改为：
CString strCmdLine;
strCmdLine = _T("C:\\windows\\system32\\notepad.exe ");
strCmdLine += m_gExceptionRepot.GetLogFileName();
m_gExceptionRepot.SetErrorExcuteFile( strCmdLine );
我们现在输入会出现异常的代码：
这是一个除零异常，然后我们执行可以看到：
在和执行文件物理路径相同的位置，出现了同名的rpt文件，它的内容是：
出现详细的崩溃信息，当然前提条件是执行文件的相应路径下可以找到调试符号，否则只能看到如下信息：
看到了吧，比调试版本少了很多信息，不过没有关系，搭配map文件也能大概确定出错的位置了。
本文用到的库文件可以在我的Blog下载。如果由于使用我的库文件出现任何问题，本人不负任何责任，如果不同意，请不要下载使用。
库文件
下载地址