大家都帮帮忙啦!如何实现分析.res和.dcr的资源结构！！！up有分哦！

[Cappuccino]

比如
分析出来

bitmap
-- 1.bmp
-- 2.bmp
wave
-- 1.wav
-- 2.wav

只求基本的分析算法.

[Cappuccino]

自己沙发先!哈哈

[FigoZhu]

呵呵!
Delphi自带的Demo里有的，叫Res什么的，或者叫什么Res的。
自己去看看。

[shepengtao]

有专门的工具的，去搜索吧！！

[liuzq]

Delphi Resource Edit-Dred,网上可找到源码

[Cappuccino]

up

[zijida]

win32 resource file format


--------------------------------------------------------------------------------

by marco cocco, of d3k - the artisan of ware, italy

introduction

preface
welcome to the win32 resource file format reference guide !
this document is a guide to reading/writing windows 95 and windows nt resource files (res extension).
this guide has been written by m.cocco (of d3k - the artisan of ware, italy) while developing the makeres resource editor, a tool of the "photoshop plug-in toolkit" for delphi 2.0.

copyright (c) 1997, marco cocco. all rights reserved.
copyright (c) 1997, d3k - the artisan of ware. all rights reserved.


audience
this guide is for any programmers who have written applications for windows systems and wish to understand how to work with standalone binary resource file (res files, not in-exe resources). this guide assumes you are proficient in the windows programming and have worked in any development environments such as borland delphi 2.0, borland delphi 3.0, borland c++ builder, microsoft visual c++ (on windows 95 or windows nt).
you should have a working knowledge of the different resource types, and understand how handle binary files. this guide assumes you understand terminology such as records (structures), word and dword types, strings (ansi and unicode), record (structure) alignment, etc.

remarks
this documentation is made to provide specific information on implementation and structuring issues for win32 resource files only. win16 resource files are not explained in this guide.
the best way to use this guide is to read it all without skipping any chapter.

should you have any question, feel free to contact the author.

getting started

this document details the structure of the resource binary file (.res) format for win32 platforms (w95 and wnt). the structure is very similar to the existing win16 (w3/w3.1/3.11) structure, but it supports some new data types and data structures.
one important enhancement is the dword/word alignment of structures/fields which increases performance of new 32 bit microprocessors but makes resource reading/writing a bit more complex (structures are of dynamic size). the order of the fields of resource data structures is not changed due to alignment, but some padding is required between fields.

the win32 resource file contains one or more binary resources merged in a single file and aligned on dword boundaries. each resource has its own header structure followed by resource data. immediately after the resource data comes the header for the next resource followed by resource data, and so on.

to read/write resource files you must have knowledge of binary files handling. resource files cannot be read using text mode file routines.

the resource header

the structure of the header is as follows:



offset field data type description
0 datasize dword
4 bytes, 32 bit unsigned integer the size of the data that follows the header (not including any padding).
4 headersize dword
4 bytes, 32 bit unsigned integer the size of the header structure.
8 restype ordinal or unicode string
array of 16 bit unsigned integers (2 bytes each) resource type id (standard or custom).
ofsof(restype)+sizeof(restype)+padding resname ordinal or unicode string
array of 16 bit unsigned integers (2 bytes each) resource name.
ofsof(resname)+sizeof(resname)+padding dataversion dword
4 bytes, 32 bit unsigned integer determines the format of the information within the resource header that follows. not currently used. should be zeroed.
ofsof(dataversion)+4 memoryflags word
2 bytes, 16 bit unsigned integer the state of the resource.
ofsof(memoryflags)+2 languageid word
2 bytes, 16 bit unsigned integer the language that the strings are written with.
ofsof(languageid)+2 version dword
4 bytes, 32 bit unsigned integer it has no significance to the system. used by resource editors. usually zeroed.
ofsof(version)+4 characteristics dword
4 bytes, 32 bit unsigned integer it has no significance to the system. used by resource editors. usually zeroed.


- resource header structure is not of fixed length. you have to read/write header fields one at a time.
- resource headers ever start on a dword boundary.
- when reading a res file you must move the file pointer to next nearest dword boundary (only if current file pointer is not already on a dword boundary).
- when writing a res file you must write as much padding bytes as it is required to let the header be dword aligned (only if current file pointer is not already on a dword boundary).

more about the resource header fields:



field additional information
datasize the size of the data that follows the header. this value does not include any file padding bytes added after the actual data.
the format of the data is different for any of the possible resource types. data size is expressed in bytes (8 bit unsigned integer).
headersize the size of the resource header structure. this value includes the size of the datasize and headersize fields.
the value of headersize is expressed in bytes and can be used to seek directly to resource data following the resource header (seek to filepos(datasize) + headersize).
the win32 sdk wrongly says: "the headersize field gives the size of the resource header structure that follows". this should be read: "the headersize field gives the size of the resource header structure, including the datasize field and the headersize field itself".
restype specifies the resource type (its integer code or its alphabetic name).
further explanation of this field can be found in "the restype field" chapter.
resname specifies the name of resource (its integer name-code or its alphabetic name).
further explanation of this field can be found in "the resname field" chapter.
dataversion determines the format of the information within the resource header that follows. reserved for future expansion.
this field is always zeroed but is supposed to change on next version of win32.
resource editors should check this field and maintan unchaged the resource data if the format is not supported.
memoryflags contains flags about the state of the resource.
further explanation of this field can be found in "the memoryflags field" chapter.
languageid specifies the language that the strings are written. by providing different values for this field it is possible to store different language versions of the same resource. the application can then choose the set of resources to load based on the currently system language.
further explanation of this field can be found in "language ids" chapter.
version this field can be used to store custom version information. this lets resource editors to keep backward compatibility whith other version of the same resource editor.
this value is stripped out when the resource is linked to the application executable file.
characteristics like the version field, this field can be used to store custom information flags.
this value is stripped out when the resource is linked to the application executable file.

[zijida]

the restype field

the restype field can either be:


1) a number
2) a null-terminated unicode string
# description
1) the first word of the restype field is 0xffff and the second word contains the resource type id.
the restype field is always 4 bytes long (0xffff word + id word), thus it doesn't require any padding for dword boundary alignment.
this kind of restype field is used for system defined resources (menu, dialogs, icons,...) but is can also be used for custom resource types.
if you are going to use this kind of restype for your custom resources, be sure to use id values not already reserved for standard resources (i suggest you using ids greater than 0x8000 or like). or better: never use non numeric ids for your custom resources.

all standard windows resource types have been assigned numeric ids as follows:


0x0001 = cursor 0x0002 = bitmap 0x0003 = icon 0x0004 = menu 0x0005 = dialog 0x0006 =
string table 0x0007 = font directory 0x0008 = font 0x0009 = accelerators table 0x000a = rc
data (custom binary data) 0x000b = message table 0x000c = group cursor 0x000e = group icon
0x0010 = version information 0x0011 = dialog include 0x0013 = plug'n'play 0x0014 = vxd
0x0015 = animated cursor 0x2002 = bitmap (new version) 0x2004 = menu (new version) 0x2005
= dialog (new version)

2) the first word of the restype field is not 0xffff.
the restype field is an array of unicode characters (a string) terminated by a null (0x0000 word). an additional word may be inserted after the terminating null to make next field (resname) start on a dword boundary.

if your application is not using the set of unicode api calls you have to convert the resource name to ansi encoding.

standard resources never use this kind of restype field.

the resname field

the resname field can either be:


1) a number
2) a null-terminated unicode string
# description
1) the first word of the resname field is 0xffff and the second word contains the resource name id.
the resname field is always 4 bytes long (0xffff word + id word), thus it doesn't require any padding for dword boundary alignment.

notice: string table resources are not allowed to be named using a unicode string: they must be have a numeric name id (case 1).
2) the first word of the resname field is not 0xffff.
the resname field is an array of unicode characters (a string) terminated by a null (0x0000 word). an additional word may be inserted after the terminating null to make next field (dataversion) start on a dword boundary.

if your application is not using the set of unicode api calls you have to convert the resource name to ansi encoding.

notice: string table resources are not allowed to be named using a unicode string: they must be have a numeric name id (case 1).

the memoryflags field

the memoryflags field contains flags about the state of a the resource.

this field is a "bit set", that is, each single bit of its value have a different meaning as follows:


bit # bit mask description
4 0x0010 if set: the resource is moveable, that is, the system can move the resource in memory.
if not set: the resource is fixed, that is, the system cannot move the resource in memory.
5 0x0020 if set: the resource is pure, that is, the resource contains dword aligned data (padding is not needed).
if not set: the resource is impure, that is, the resource contains non dword aligned data (padding is needed).
6 0x0040 if set: the resource must to be preloaded, that is, the resource must be loaded in memory just after the application has been loaded from disk.
if not set: the resource must not be preloaded, that is, the resource must be loaded in memory only when the application requires it.
10 0x1000 if set: the resource is discardable, that is, on low memory conditions, the resource can be removed from memory and then reloaded when the application needs it.
if not set: the resource isn't discardable, that is, on low memory conditions, the resource cannot be removed from memory.


notice:
winnt ignores the setting of the moveable, impure, and preload flags.

language ids

the languageid field, included in each resource header, specifies the language that the strings (of string tables and message tables) are written with.
the system must be informed of the language because it needs to know how to convert characters from unicode to ansi (from double-byte to single-byte characters).

the languageid field (found in any resource header) if a 16 bin unsigned integer (word) containing not only the language id but also a sub-language id. the lower 10 bits (bits 0-9) of this value contain the languageid, remaining bits contain the sublanguageid (bits 11-15).
the languageid specifies the code of the primary language. the sublanguageid specifies a variation of the primary language (a dialect).

[astrohadn]

学习。。