C++博客-RTY 实践出真知-随笔分类-C/C++

Dynamic Library Design Guidelines (Xcode)

RTY — Thu, 13 Sep 2012 00:58:00 GMT

摘要: Dynamic Library Design Guidelines Dynamic libraries, in addition to grouping common functionality, help reduce an app’s launch time. However, when designed improperly, dynamic libraries can deg... 阅读全文

RTY 2012-09-13 08:58 发表评论

Qt internal error: qt_menu.nib could not be loaded.

RTY — Wed, 06 Jun 2012 06:55:00 GMT

"Qt internal error: qt_menu.nib could not be loaded. The .nib file should be placed in QtGui.framework/Versions/Current/Resources/ or in the resources directory of your applicaiton bundle."

RTY 2012-06-06 14:55 发表评论

Cocoa读取和写入plist文件

RTY — Sun, 27 May 2012 01:09:00 GMT

http://www.cocoachina.com/b/?p=237

plist文件是标准的xml文件，在cocoa中可以很简单地使用。这里介绍一下使用方法：

以下代码在Mac和iPhone中均适用。

写入plist文件：

NSMutableDictionary* dict = [ [ NSMutableDictionary alloc ] initWithContentsOfFile:@"/Sample.plist" ];
[ dict setObject:@"Yes" forKey:@"RestartSpringBoard" ];
[ dict writeToFile:@"/Sample.plist" atomically:YES ];

读取plist文件：

NSMutableDictionary* dict =  [ [ NSMutableDictionary alloc ] initWithContentsOfFile:@"/Sample.plist" ];
NSString* object = [ dict objectForKey:@"RestartSpringBoard" ];

RTY 2012-05-27 09:09 发表评论

什么叫IOC（编程术语)

RTY — Tue, 15 May 2012 05:11:00 GMT

什么叫IOC（编程术语)

IoC就是Inversion of Control，控制反转。在Java开发中，IoC意味着将你设计好的类交给系统去控制，而不是在你的类内部控制。这称为控制反转。

下面我们以几个例子来说明什么是IoC

假设我们要设计一个Girl和一个Boy类，其中Girl有kiss方法，即Girl想要Kiss一个Boy。那么，我们的问题是，Girl如何能够认识这个Boy？

在我们中国，常见的MM与GG的认识方式有以下几种

1 青梅竹马； 2 亲友介绍； 3 父母包办

那么哪一种才是最好呢？

青梅竹马：Girl从小就知道自己的Boy。

public class Girl {

void kiss(){

Boy boy = new Boy();

}

然而从开始就创建的Boy缺点就是无法在更换。并且要负责Boy的整个生命周期。如果我们的Girl想要换一个怎么办？（严重不支持Girl经常更换Boy,#_#）

亲友介绍：由中间人负责提供Boy来见面

public class Girl {

void kiss(){

Boy boy = BoyFactory.createBoy();

}

亲友介绍，固然是好。如果不满意，尽管另外换一个好了。但是，亲友BoyFactory经常是以Singleton的形式出现，不然就是，存在于Globals，无处不在，无处不能。实在是太繁琐了一点，不够灵活。我为什么一定要这个亲友掺和进来呢？为什么一定要付给她介绍费呢？万一最好的朋友爱上了我的男朋友呢？

父母包办：一切交给父母，自己不用费吹灰之力，只需要等着Kiss就好了。

public class Girl {

void kiss(Boy boy){

// kiss boy

boy.kiss();

}

Well，这是对Girl最好的方法，只要想办法贿赂了Girl的父母，并把Boy交给他。那么我们就可以轻松的和Girl来Kiss了。看来几千年传统的父母之命还真是有用哦。至少Boy和Girl不用自己瞎忙乎了。

这就是IOC，将对象的创建和获取提取到外部。由外部容器提供需要的组件。

我们知道好莱坞原则：“Do not call us, we will call you.” 意思就是，You, girlie, do not call the boy. We will feed you a boy。

我们还应该知道依赖倒转原则即 Dependence Inversion Princinple，DIP

Eric Gamma说，要面向抽象编程。面向接口编程是面向对象的核心。

组件应该分为两部分，即 Service, 所提供功能的声明 Implementation, Service的实现

好处是：多实现可以任意切换，防止 “everything depends on everything” 问题．即具体依赖于具体。

所以，我们的Boy应该是实现Kissable接口。这样一旦Girl不想kiss可恶的Boy的话，还可以kiss可爱的kitten和慈祥的grandmother。

二、IOC的type

IoC的Type指的是Girl得到Boy的几种不同方式。我们逐一来说明。

IOC type 0：不用IOC

public class Girl implements Servicable {

private Kissable kissable;

public Girl() {

kissable = new Boy();

}

public void kissYourKissable() {

kissable.kiss();

}

Girl自己建立自己的Boy，很难更换，很难共享给别人，只能单独使用，并负责完全的生命周期。

IOC type 1，先看代码：代码

public class Girl implements Servicable {

Kissable kissable;

public void service(ServiceManager mgr) {

kissable = (Kissable) mgr.lookup(“kissable”);

}

public void kissYourKissable() {

kissable.kiss();

}

这种情况出现于Avalon Framework。一个组件实现了Servicable接口，就必须实现service方法，并传入一个ServiceManager。其中会含有需要的其它组件。只需要在service方法中初始化需要的Boy。

另外，J2EE中从Context取得对象也属于type 1。它依赖于配置文件。

IOC type 2：

public class Girl {

private Kissable kissable;

public void setKissable(Kissable kissable) {

this.kissable = kissable;

}

public void kissYourKissable() {

kissable.kiss();

}

Type 2出现于Spring Framework，是通过JavaBean的set方法来将需要的Boy传递给Girl。它必须依赖于配置文件。

IOC type 3:

public class Girl {

private Kissable kissable;

public Girl(Kissable kissable) {

this.kissable = kissable;

}

public void kissYourKissable() {

kissable.kiss();

}

这就是PicoContainer的组件。通过构造函数传递Boy给Girl

PicoContainer container = new DefaultPicoContainer();

container.registerComponentImplementation(Boy.class);

container.registerComponentImplementation(Girl.class);

Girl girl = (Girl) container.getComponentInstance(Girl.class);

girl.kissYourKissable();

参考资料

1 http://www.picocontainer.org/presentations/JavaPolis2003.ppt

http://www.picocontainer.org/presentations/JavaPolis2003.pdf

2 DIP， Robert C Martin, Bob大叔的优秀论文

http://www.objectmentor.com/resources/articles/dip.pdf

3 Dependency Injection 依赖注射，Matrin Fowler对DIP的扩展

http://www.martinfowler.com/articles/injection.html

4 IOC框架

PicoContainer 优秀的IOC框架

http://picocontainer.org/

Avalon

http://avalon.apache.org/

Spring Framework

http://www.springframework.org/

HiveMind

http://jakarta.apache.org/commons/hivemind

分类: C#

什么叫IOC（编程术语

RTY 2012-05-15 13:11 发表评论

otool 与dylib

RTY — Mon, 07 May 2012 15:25:00 GMT

Shared by eric
mac osx的dyld是挺烦的

所谓dylib，就是bsd风格的动态库。基本可以认为等价于windows的dll和linux的so。mac基于bsd，所以也使用的是dylib。

如果你需要引用一个第三方的dylib，在xcode下编译出cocoa程序，在本机上运行是不会出问题的。但是发布出来，给其他用户用，就可能出问题。因为用户不一定有这个库。

这个问题给我造成了相当的困扰，我到现在也没找到正规的方法。但是我确实解决了这个问题，虽然方法不一定正宗。不管怎么说，写下来，如果暂时没有更好的办法，那么先这样做。如果谁有更好的办法，也请一定不吝留言或邮件给我。

我的办法是这样的:

1 otool -L yourapp.app/Contents/MacOS/yourapp

这一步的意思是对你编译出的app使用otool命令，以便获得依赖哪些dylib的信息。注意这个路径。cocoa的app在命令行下表现为目录。所有相关的东西都在里面。
结果如下所示：
yourapp.app/Contents/MacOS/yourapp:
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 12.0.0)
/usr/local/lib/lib01.dylib (compatibility version 0.0.0, current version 0.1.0)
/usr/local/lib/lib02.dylib (compatibility version 0.0.0, current version 0.1.0)
/usr/local/lib/lib03.dylib (compatibility version 0.0.0, current version 0.1.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 476.0.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 949.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 677.12.0)

注意我标红的地方。假如lib01,lib02,lib03是本程序引用的第三方库，那么在这个程序里面，他们的引用地址是位于/usr/local/lib上的。这是开发机上的安装情况。而使用这个程序的客户机未必安装这些东西，所以程序就要出错。

显然，我们需要做2件事。a 把这些库附带在app上 b 把他们的引用地址修改到正确的位置。

2 mkdir yourapp.app/Contents/dylib

在编译出来的app中，创建dylib目录

然后把所有需要的库复制过去

cp /usr/local/lib/lib01.dylib yourapp.app/Contents/dylib/
cp /usr/local/lib/lib02.dylib yourapp.app/Contents/dylib/
cp /usr/local/lib/lib03.dylib yourapp.app/Contents/dylib/

3 install_name_tool -change /usr/local/lib/lib01.dylib @loader_path/../dylib/lib01.dylib "yourapp.app/Contents/MacOS/yourapp"

install_name_tool 是苹果提供的用来修改dylib安装名称的命令。这个命令执行之后，再用otool -L 就可以看到变化了

yourapp.app/Contents/MacOS/yourapp:
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 12.0.0)
@loader_path/../dylib/lib01.dylib (compatibility version 0.0.0, current version 0.1.0)
/usr/local/lib/lib02.dylib (compatibility version 0.0.0, current version 0.1.0)
/usr/local/lib/lib03.dylib (compatibility version 0.0.0, current version 0.1.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 476.0.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 949.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 677.12.0)

注意标红的位置。已经变化了。@loader_path 指的是应用程序运行的位置，也就是yourapp.app/Contents/MacOS/yourapp，所以要用一个..，以便定位到第2步创建的dylib目录。
重复这个命令，修改lib02,lib03

4 otool -L yourapp.app/Contents/dylib/*.dylib

继续用otool 来检查dylib下面使用的第三方库是否还有其他依赖，install_name是否正确，重复1，2，3的步骤，把所需要的dylib复制过来，修改install_name。

如果都改对了，那么这个app就附带上了dylib，可以在其他机器上正确运行了，不用非要寻找/usr/local/lib下面的库了。

刚才我们修改的结果是一个build的结果。当然，每次build都这么折腾一下很麻烦。所以继续这样做：

1 前面的步骤得到了一个完整的dylib目录。把这个dylib复制一份备用。比如放在你的xcode项目下面。

2 编写一个脚本：

mkdir "$TARGET_BUILD_DIR/$PRODUCT_NAME.app/Contents/dylib"
cp -f /your/path/to/xcode_project_name/dylib/*.dylib "$TARGET_BUILD_DIR/$PRODUCT_NAME.app/Contents/dylib/"

install_name_tool -change /usr/local/lib/lib01.dylib @loader_path/../dylib/lib01.dylib "$TARGET_BUILD_DIR/$PRODUCT_NAME.app/Contents/MacOS/$PRODUCT_NAME"
(用这个格式重复前面对app使用过的dylib)

3 在xcode中，展开targets节点，右键点工程名称，在菜单中选Add->New Build Phasa->New Run Script Build Phasa，在打开的对话框里面，把刚才的脚本贴进去。如图所示。

这个脚本会在build之后自动运行。不过我这里有个奇怪的问题，如果Shell里面写了/bin/sh，会报告找不到这个文件(实际上存在)，而让shell为空，反而可以正确的运行shell命令。

经过这些处理，每次编译出来的app就可以拿到其他机器上运行了。可真够麻烦的...

RTY 2012-05-07 23:25 发表评论

找不到 dirent.h 文件

RTY — Fri, 27 Apr 2012 22:42:00 GMT

转载：http://www.cnblogs.com/fzzl/archive/2009/07/14/1522913.html

【转】vs2005下的dirent.h 该方法同样适用于VS2008 及VS2010

http://www.analogcn.com/Article/wz3/200802/20080202211037.html

dirent.h是gcc下的一个头文件，而在VS2005中是没有的。这个文件中封装了几个对目录进行操作函数：

static DIR *opendir (const char *dirname);
static struct dirent *readdir (DIR *dirp);
static int closedir (DIR *dirp);

对于在linux->windows之间进行程序移植来讲常常会造成一些困扰，在网上仔细搜了一下，发现原来已经有位好同志写了相应的移植代码，如下所示：

typedef struct dirent {
/* name of current directory entry (a multi-byte character string) */
char d_name[MAX_PATH + 1];

/* file attributes */
WIN32_FIND_DATA data;
} dirent;

typedef struct DIR {
/* current directory entry */
dirent current;

/* is there an un-processed entry in current? */
int cached;

/* file search handle */
HANDLE search_handle;

/* search pattern (3 = zero terminator + pattern "\\*") */
TCHAR patt[MAX_PATH + 3];
} DIR;

static DIR *opendir (const char *dirname);
static struct dirent *readdir (DIR *dirp);
static int closedir (DIR *dirp);

/* use the new safe string functions introduced in Visual Studio 2005 */
#if defined(_MSC_VER) && _MSC_VER >= 1400
# define STRNCPY(dest,src,size) strncpy_s((dest),(size),(src),_TRUNCATE)
#else
# define STRNCPY(dest,src,size) strncpy((dest),(src),(size))
#endif

/*
* Open directory stream DIRNAME for read and return a pointer to the
* internal working area that is used to retrieve individual directory
* entries.
*/
static DIR*
opendir(
const char *dirname)
{
DIR *dirp;
assert (dirname != NULL);
assert (strlen (dirname) < MAX_PATH);

/* construct new DIR structure */
dirp = (DIR*) malloc (sizeof (struct DIR));
if (dirp != NULL) {
    TCHAR *p;

    /* prepare search pattern */
#ifdef _UNICODE

    /* convert directory name to wide character string */
    MultiByteToWideChar(
        CP_ACP,                                /* code page */
        0,                                     /* conversion flags */
        dirname,                               /* mb-string to convert */
        -1,                                    /* length of mb-string */
        dirp->patt,                            /* wc-string to produce */
        MAX_PATH);                             /* max length of wc-string */
    dirp->patt[MAX_PATH] = '\0';

    /* append search pattern to directory name */
    p = wcschr (dirp->patt, '\0');
    if (dirp->patt < p && *(p-1) != '\\' && *(p-1) != ':') {
      *p++ = '\\';
    }
    *p++ = '*';
    *p = '\0';

#else /* !_UNICODE */

    /* take directory name... */
    STRNCPY (dirp->patt, dirname, sizeof(dirp->patt));
    dirp->patt[MAX_PATH] = '\0';

    /* ... and append search pattern to it */
    p = strchr (dirp->patt, '\0');
    if (dirp->patt < p && *(p-1) != '\\' && *(p-1) != ':') {
      *p++ = '\\';
    }
    *p++ = '*';
    *p = '\0';

#endif /* !_UNICODE */

    /* open stream and retrieve first file */
    dirp->search_handle = FindFirstFile (dirp->patt, &dirp->current.data);
    if (dirp->search_handle == INVALID_HANDLE_VALUE) {
      /* invalid search pattern? */
      free (dirp);
      return NULL;
    }

    /* there is an un-processed directory entry in memory now */
    dirp->cached = 1;

}
return dirp;
}

/*
* Read a directory entry, and return a pointer to a dirent structure
* containing the name of the entry in d_name field. Individual directory
* entries returned by this very function include regular files,
* sub-directories, pseudo-directories "." and "..", but also volume labels,
* hidden files and system files may be returned.
*/
static struct dirent *
readdir(
DIR *dirp)
{
assert (dirp != NULL);

if (dirp->search_handle == INVALID_HANDLE_VALUE) {
/* directory stream was opened/rewound incorrectly or it ended normally */
return NULL;
}

/* get next directory entry */
if (dirp->cached != 0) {
    /* a valid directory entry already in memory */
    dirp->cached = 0;
} else {
    /* read next directory entry from disk */
    if (FindNextFile (dirp->search_handle, &dirp->current.data) == FALSE) {
      /* the very last file has been processed or an error occured */
      FindClose (dirp->search_handle);
      dirp->search_handle = INVALID_HANDLE_VALUE;
      return NULL;
    }
}

/* copy directory entry to d_name */
#ifdef _UNICODE

/* convert entry name to multibyte */
WideCharToMultiByte(
      CP_ACP,                                  /* code page */
      0,                                       /* conversion flags */
      dirp->current.data.cFileName,            /* wc-string to convert */
      -1,                                      /* length of wc-string */
      dirp->current.d_name,                    /* mb-string to produce */
      MAX_PATH,                                /* max length of mb-string */
      NULL,                                    /* use sys default character */
      NULL);                                   /* don't care */
dirp->current.d_name[MAX_PATH] = '\0';

#else /* !_UNICODE */

/* copy as a multibyte character string */
STRNCPY (dirp->current.d_name, dirp->current.data.cFileName, sizeof(dirp->current.d_name));
dirp->current.d_name[MAX_PATH] = '\0';

#endif /* !_UNICODE */

return &dirp->current;
}

/*
* Close directory stream opened by opendir() function. Close of the
* directory stream invalidates the DIR structure as well as any previously
* read directory entry.
*/
static int
closedir(
    DIR *dirp)
{
assert (dirp != NULL);

/* release search handle */
if (dirp->search_handle != INVALID_HANDLE_VALUE) {
    FindClose (dirp->search_handle);
    dirp->search_handle = INVALID_HANDLE_VALUE;
}

/* release directory handle */
free (dirp);
return 0;
}

此文件可从http://www.softagalleria.net/dirent/index.en.html下载得到，直接将它放在VS2005的include目录就OK 了！

开网店 http://www.5678520.com/怎么样开网店

RTY 2012-04-28 06:42 发表评论

vc调试窗口表达式格式化资料

RTY — Tue, 24 Apr 2012 14:37:00 GMT

摘要: 2011-04-15 11:09 46人阅读评论(0) 收藏举报摘自msdn，列在这里方便查阅。The following tables show the format specifiers recognized by the debugger. SpecifierFormatExpressionValue Displayedd,isigned... 阅读全文

RTY 2012-04-24 22:37 发表评论

Context Operator (C/C++ Language Expressions)

RTY — Tue, 24 Apr 2012 13:42:00 GMT

摘要: HomeLibraryLearnDownloadsSupportCommunitySign in | 中国（简体中文） | | MSDN LibraryDevelopment Tools and LanguagesVisual Studio 2008Visual StudioApplication Development in Visu... 阅读全文

RTY 2012-04-24 21:42 发表评论

Managed Expressions in C++ (VC 2010 调试)

RTY — Tue, 24 Apr 2012 13:39:00 GMT

摘要: HomeLibraryLearnDownloadsSupportCommunitySign in | 中国（简体中文） | | MSDN LibraryDevelopment Tools and LanguagesVisual Studio 2010Visual StudioApplication Development in Visu... 阅读全文

RTY 2012-04-24 21:39 发表评论

Find path of an application

RTY — Wed, 18 Apr 2012 14:44:00 GMT

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Find path of an application

Subject: Re: Find path of an application
From: Terry Lambert <email@hidden>
Date: Tue, 16 Dec 2008 02:01:54 -0800
Delivered-to: email@hidden
Delivered-to: email@hidden

On Dec 16, 2008, at 1:00 AM, Rakesh Singhal wrote:

I am done with finding the process is running or not. Thanks a lot. Still I am stuck with second issue to find the path to my application in my system. Actually there are 3 steps:

1. To know that application is running or not?  Now it is done. 2. If not then get the path of application where it was installed (user can change the path during installation). 3. Launch the application.

My code is standard C++ tool so I want to use only C and C++ APIs. Please suggest me.

You said this was a GUI app that you didn't control the sources to. So control it anyway by renaming the binary in the bundle and putting a stub in there that will save off the id for you and then reexec the real binary:

--- example with no error checking --- #include 	/* _NSGetExecutablePath */ #include 		/* PATH_MAX */ #include 		/* execve */ #include 		/* dirname */ #include 		/* strcpy */

#define BINARYNAME	"myreal_executable"

int main(int ac, char *av[]) { 	char pathbuf[PATH_MAX + 1]; 	char real_executable[PATH_MAX + 1]; 	char *bundle_id; 	int  bufsize = sizeof(pathbuf);

	_NSGetExecutablePath( pathbuf, &bufsize);

	bundle_id = dirname(pathbuf);

	strcpy(real_executable, bundle_id); 	strcat(real_executable, "/"); 	strcat(real_executable, BINARYNAME);

	execv(real_executable, av); } --------------------

Then write the path into /var/run/program. before you do the execv call to give control to the real binary.

Then in your other program go looking for /var/run/program.*. When you find one, take the pid and do an atoi() on it to get the integer pid back. Then end it a kill(pid, 0).

This function will return one of three things:

(1) 0, indicating that the process exists and you have the right to send it signals

(2) -1, with errno set to EPERM, indicating that the process exists and you do not have rights to send it a signal

(3) -1, with errno set to ESRCH, indicating that the process does not (yet) exist

Ideally, all this would be unnecessary because you put your daemon and the program you want to give it a UI into the same bundle, which ,means either one of them can find the other by looking at the dirname() from their own call to _NSGetExecutablePath().

No grovelling around trying to find out where something came from, because it tells you.

-- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list      (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden  
 Follow-Ups:  Re: Find path of an application From: Eli Bach 
 
 References:  
  >Find path of an application (From: "Rakesh Singhal" )
  >Re: Find path of an application (From: Jean-Daniel Dupas )
  >Re: Find path of an application (From: "Rakesh Singhal" )
  >Re: Find path of an application (From: Jean-Daniel Dupas )
  >Re: Find path of an application (From: "Rakesh Singhal" )
 
  Prev by Date: Re: Find path of an application 
 Next by Date: Re: Find path of an application 
 Previous by thread: Re: Find path of an application 
 Next by thread: Re: Find path of an application 
 Index(es):  Date
 Thread

RTY 2012-04-18 22:44 发表评论

XCODE 4.3 WITH NO GCC?

RTY — Sat, 07 Apr 2012 13:50:00 GMT

真的坑爹，今天才开始玩MAC OX，装了个最新版本的10.7.3，只能装XCODE 4.3 这个月刚发行的版本。

安装时发现没有install过程，直接双击就进入开发环境了。而且装完后没有gcc 等各种编译工具，在TERMINAL下各种命令不识别，想装ruby的各种开发工具，都不行了。

查了半天才发现：

Apple announced Xcode 4.3 for OSX Lion and 4.4 for OSX Mountain Lion last week. The major difference is that Xcode no longer provide an installer which is good thing because you now could update Xcode with AppStore in the future, plus it is much easier to carry the development environment with you. However, there is a little problem with this new version of Xcode, is that all command line toolsets and compilers are not visible in terminal.

解决方案一：
A simple fix is to update your PATH env:

export PATH=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:$PATH

Please be noted that clang does not reside in /Developer/usr/bin, it is now in /Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Now you could access to gcc, g++, git or any toolsets bundled with Xcode. For your convenience, it is recommended to include it in your .bash_profile.

解决方案二：

You can install these additional tools directly in Xcode :
Preferences > Downloads > Command Line Tools > Install

SO. What a fUUUcking day！

RTY 2012-04-07 21:50 发表评论

error C2143: syntax error : missing ';' before 'type' in Visual C++ 可能的原因

RTY — Thu, 05 Apr 2012 11:53:00 GMT

今天偶然写了下面的程序(原来我写的程序不一样，下面的只是为了把问题简化)

[cpp] view plain copy

void foo()
{
int p = 0;
if ( p == 0 )
int i = 0;
int a;
}
int main()
{
foo();
}

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/fancylea/archive/2009/06/10/4256793.aspx

不幸的是偶然将这个文件保存成了test.c，然后编译的时候出现了

error， error C2143: syntax error : missing ';' before 'type'

感觉很奇怪,细细看来所有的语法都似乎都是对的，更奇怪的是把文件改成cpp或者cc能正常编译，把int a;和if调换下也能正常编译。这样的错误可能发生在当变量的声明放在可执行代码之后。而这个是在K&R C中规定的，但在ANSI C中废除。

MSDN (http://support.microsoft.com/kb/58559)给出的解释如下：

In Microsoft C, compiler errors C2143 and C2144 are defined as follows:

C2143: syntax error : missing 'token1' before 'token2'
C2144: syntax error : missing 'token' before type 'type'

You may receive this error message if your program places executable code before a data declaration, an acceptable practice in Kernighan-and-Ritchie C. This practice has been outlawed in later versions of the ANSI drafts.

This error message will normally occur if a required closing curly brace (}), right parenthesis [)], or semicolon (;) is missing.

注: The C Programming Language的作者简称K&R，也是C语言之父, 经常用K&R C来和ANSI C做对比。这本书的第二版已经用ANSI.

我用的编译器是VS2008, 看来微软向来无视标准。

总结：

在 ANSI C或者C++中，在可执行代码中随时定义变量是允许的，但是在K&R C中是不允许的，VS2008实现的C竟然是K&R C。注意这样的错误也体现在VS中要是用for (int i = 0; i++; i<10)同时你的文件名是.c的也会出现这样的错误。

Code complete中讨论过变量名的最迟绑定有利于增加代码的可读性等。所以在VS中写c要注意了。

RTY 2012-04-05 19:53 发表评论

C++查缺补漏4，赶紧的

RTY — Thu, 05 Apr 2012 06:54:00 GMT

请说出const与#define 相比，有何优点？
答案：1） const 常量有数据类型，而宏常量没有数据类型。编译器可以对前者进行类型安全检查。而对后者只进行字符替换，没有类型安全检查，并且在字符替换可能会产生意料不到的错误。
2） 有些集成化的调试工具可以对const 常量进行调试，但是不能对宏常量进行调试。

在8086 汇编下，逻辑地址和物理地址是怎样转换的？（Intel）
答案：通用寄存器给出的地址，是段内偏移地址，相应段寄存器地址*10H+通用寄存器内地址，就得到了真正要访问的地址。

当一个类A 中没有生命任何成员变量与成员函数,这时sizeof(A)的值是多少，如果不是零，请解释一下编译器为什么没有让它为零。（Autodesk）
答案：肯定不是零。举个反例，如果是零的话，声明一个class A[10]对象数组，而每一个对象占用的空间是零，这时就没办法区分A[0],A[1]…了。

描述内存分配方式以及它们的区别?
1） 从静态存储区域分配。内存在程序编译的时候就已经分配好，这块内存在程序的整个运行期间都存在。例如全局变量，static 变量。
2） 在栈上创建。在执行函数时，函数内局部变量的存储单元都可以在栈上创建，函数执行结束时这些存储单元自动被释放。栈内存分配运算内置于处理器的指令集。
3） 从堆上分配，亦称动态内存分配。程序在运行的时候用malloc 或new 申请任意多少的内存，程序员自己负责在何时用free 或delete 释放内存。动态内存的生存期由程序员决定，使用非常灵活，但问题也最多。

main 函数执行以前，还会执行什么代码？
答案：全局对象的构造函数会在main 函数之前执行。

C++是不是类型安全的？
答案：不是。两个不同类型的指针之间可以强制转换（用reinterpret cast)。C#是类型安全的。

有哪几种情况只能用intialization list 而不能用assignment?

答案：当类中含有const、reference 成员变量；基类的构造函数都需要初始化表。

define DOUBLE(x) x+x ，i = 5*DOUBLE(5)； i 是多少？
答案：i 为30

New delete 与malloc free 的联系与区别?
答案：都是在堆(heap)上进行动态的内存操作。用malloc函数需要指定内存分配的字节数并且不能初始化对象，new 会自动调用对象的构造函数。delete 会调用对象的destructor，而free 不会调用对象的destructor.

1、写一个“标准”宏，这个宏输入两个参数并返回较小的一个。
.#define Min(X, Y) ((X)>(Y)?(Y):(X))//结尾没有;
2、嵌入式系统中经常要用到无限循环，你怎么用C编写死循环。
while(1){}或者for(;;)
3、关键字static的作用是什么？
定义静态变量
4、关键字const有什么含意？
表示常量不可以修改的变量。
5、关键字volatile有什么含意？并举出三个不同的例子？
提示编译器对象的值可能在编译器未监测到的情况下改变。

int (*s[10])(int) 表示的是什么啊
int (*s[10])(int) 函数指针数组，每个指针指向一个int func(int param)的函数。

1.有以下表达式：
int a=248; b=4;int const c=21;const int *d=&a;
int *const e=&b;int const *f const =&a;
请问下列表达式哪些会被编译器禁止？为什么？
*c=32;d=&b;*d=43;e=34;e=&a;f=0x321f;
*c 这是个什么东东，禁止
*d 说了是const，禁止
e = &a 说了是const 禁止
const *f const =&a; 禁止
2.交换两个变量的值，不使用第三个变量。即a=3,b=5,交换之后a=5,b=3;
有两种解法, 一种用算术算法, 一种用^(异或)
a = a + b;
b = a - b;
a = a - b;
or
a = a^b;// 只能对int,char..
b = a^b;
a = a^b;
or
a ^= b ^= a;
3.c和c++中的struct有什么不同？
c和c++中struct的主要区别是c中的struct不可以含有成员函数，而c++中的struct可以。c++中struct和class的主要区别在于默认的存取权限不同，struct默认为public，而class默认为private
4.＃i nclude
＃i nclude
void getmemory(char *p)
{
    p=(char *) malloc(100);
    strcpy(p,"hello world");
}
int main( )
{
    char *str=NULL;
    getmemory(str);
    printf("%s/n",str);
    free(str);
    return 0;
   }
程序崩溃，getmemory中的malloc 不能返回动态内存， free（）对str操作很危险
5.char szstr[10];
strcpy(szstr,"0123456789");
产生什么结果？为什么？
长度不一样，会造成非法的OS
6.列举几种进程的同步机制，并比较其优缺点。
   原子操作
信号量机制
   自旋锁
   管程，会合，分布式系统

7.进程之间通信的途径
共享存储系统
消息传递系统
管道：以文件系统为基础
11.进程死锁的原因
资源竞争及进程推进顺序非法
12.死锁的4个必要条件
互斥、请求保持、不可剥夺、环路
13.死锁的处理
鸵鸟策略、预防策略、避免策略、检测与解除死锁
15. 操作系统中进程调度策略有哪几种？
FCFS(先来先服务)，优先级，时间片轮转，多级反馈
8.类的静态成员和非静态成员有何区别？
类的静态成员每个类只有一个，非静态成员每个对象一个
9.纯虚函数如何定义？使用时应注意什么？
virtual void f()=0;
是接口，子类必须要实现
10.数组和链表的区别
数组：数据顺序存储，固定大小
连表：数据可以随机存储，大小可动态改变

12.ISO的七层模型是什么？tcp/udp是属于哪一层？tcp/udp有何优缺点？
应用层
表示层
会话层
运输层
网络层
物理链路层
物理层
tcp /udp属于运输层
TCP 服务提供了数据流传输、可靠性、有效流控制、全双工操作和多路复用技术等。
与 TCP 不同， UDP 并不提供对 IP 协议的可靠机制、流控制以及错误恢复功能等。由于 UDP 比较简单， UDP 头包含很少的字节，比 TCP 负载消耗少。
tcp: 提供稳定的传输服务，有流量控制，缺点是包头大，冗余性不好
udp: 不提供稳定的服务，包头小，开销小

1：(void *)ptr 和 (*(void**))ptr的结果是否相同？其中ptr为同一个指针
.(void *)ptr 和 (*(void**))ptr值是相同的
2：int main()
   {
    int x=3;
    printf("%d",x);
    return 1;

   }
问函数既然不会被其它函数调用，为什么要返回1？
mian中，c标准认为0表示成功，非0表示错误。具体的值是某中具体出错信息

1，要对绝对地址0x100000赋值，我们可以用
(unsigned int*)0x100000 = 1234;
那么要是想让程序跳转到绝对地址是0x100000去执行，应该怎么做？
*((void (*)( ))0x100000 ) ( );
首先要将0x100000强制转换成函数指针,即:
(void (*)())0x100000
然后再调用它:
*((void (*)())0x100000)();
用typedef可以看得更直观些:
typedef void(*)() voidFuncPtr;
*((voidFuncPtr)0x100000)();
2，已知一个数组table，用一个宏定义，求出数据的元素个数
#define NTBL
#define NTBL (sizeof(table)/sizeof(table[0]))

面试题: 线程与进程的区别和联系? 线程是否具有相同的堆栈? dll是否有独立的堆栈?
进程是死的，只是一些资源的集合，真正的程序执行都是线程来完成的，程序启动的时候操作系统就帮你创建了一个主线程。

每个线程有自己的堆栈。
DLL中有没有独立的堆栈，这个问题不好回答，或者说这个问题本身是否有问题。因为DLL中的代码是被某些线程所执行，只有线程拥有堆栈，如果DLL中的代码是EXE中的线程所调用，那么这个时候是不是说这个DLL没有自己独立的堆栈？如果DLL中的代码是由DLL自己创建的线程所执行，那么是不是说DLL有独立的堆栈？

以上讲的是堆栈，如果对于堆来说，每个DLL有自己的堆，所以如果是从DLL中动态分配的内存，最好是从DLL中删除，如果你从DLL中分配内存，然后在EXE中，或者另外一个DLL中删除，很有可能导致程序崩溃

unsigned short A = 10;
printf("~A = %u\n", ~A);

char c=128;
printf("c=%d\n",c);

输出多少？并分析过程
第一题，～A ＝0xfffffff5,int值为－11，但输出的是uint。所以输出4294967285
第二题，c＝0x10,输出的是int，最高位为1，是负数，所以它的值就是0x00的补码就是128，所以输出－128。
这两道题都是在考察二进制向int或uint转换时的最高位处理。

分析下面的程序：
void GetMemory(char **p,int num)
{
    *p=(char *)malloc(num);

}
int main()
{
    char *str=NULL;

    GetMemory(&str,100);

    strcpy(str,"hello");

    free(str);

    if(str!=NULL)
    {
        strcpy(str,"world");
    }

    printf("\n str is %s",str);
    getchar();
}
问输出结果是什么？希望大家能说说原因，先谢谢了
输出str is world。
free 只是释放的str指向的内存空间,它本身的值还是存在的.
所以free之后，有一个好的习惯就是将str=NULL.
此时str指向空间的内存已被回收,如果输出语句之前还存在分配空间的操作的话,这段存储空间是可能被重新分配给其他变量的,
尽管这段程序确实是存在大大的问题（上面各位已经说得很清楚了），但是通常会打印出world来。
这是因为，进程中的内存管理一般不是由操作系统完成的，而是由库函数自己完成的。
当你malloc一块内存的时候，管理库向操作系统申请一块空间（可能会比你申请的大一些），然后在这块空间中记录一些管理信息（一般是在你申请的内存前面一点），并将可用内存的地址返回。但是释放内存的时候，管理库通常都不会将内存还给操作系统，因此你是可以继续访问这块地址的，只不过。。。。。。。。楼上都说过了，最好别这么干。

char a[10],strlen(a)为什么等于15？运行的结果

＃i nclude "stdio.h"
＃i nclude "string.h"

void main()
{

char aa[10];
printf("%d",strlen(aa));
}

sizeof()和初不初始化，没有关系；
strlen()和初始化有关。

char (*str)[20];/*str是一个数组指针，即指向数组的指针．*/
char *str[20];/*str是一个指针数组，其元素为指针型数据．*/

long a=0x801010;
a+5=?
0x801010用二进制表示为：“1000 0000 0001 0000 0001 0000”，十进制的值为8392720，再加上5就是8392725罗

1)给定结构struct A
{
       char t:4;
       char k:4;
       unsigned short i:8;
       unsigned long m;
};问sizeof(A) = ?
给定结构struct A
{
       char t:4; 4位
       char k:4; 4位
       unsigned short i:8; 8位
       unsigned long m; // 偏移2字节保证4字节对齐
}; // 共8字节
2)下面的函数实现在一个数上加一个数，有什么错误？请改正。
int add_n ( int n )
{
    static int i = 100;
    i += n;
    return i;
}
当你第二次调用时得不到正确的结果，难道你写个函数就是为了调用一次？问题就出在 static上？

// 帮忙分析一下
＃i nclude
＃i nclude
＃i nclude
＃i nclude
＃i nclude
＃i nclude
typedef struct AA
{
        int b1:5;
        int b2:2;
}AA;
void main()
{
        AA aa;
        char cc[100];
         strcpy(cc,"0123456789abcdefghijklmnopqrstuvwxyz");
       memcpy(&aa,cc,sizeof(AA));
        cout << aa.b1 <        cout << aa.b2 <}
答案是 -16和１
首先sizeof(AA)的大小为4,b1和b2分别占5bit和2bit.
经过strcpy和memcpy后,aa的4个字节所存放的值是:
0,1,2,3的ASC码，即00110000,00110001,00110010,00110011
所以，最后一步：显示的是这４个字节的前５位，和之后的２位
分别为：10000,和01
因为int是有正负之分　　所以：答案是-16和１

求函数返回值，输入x=9999;
int func （ x ）
{
    int countx = 0;
    while ( x )
    {
        countx ++;
        x = x&(x-1);
    }
    return countx;
}
结果呢？
知道了这是统计9999的二进制数值中有多少个1的函数，且有
9999＝9×1024＋512＋256＋15

9×1024中含有1的个数为2；
512中含有1的个数为1；
256中含有1的个数为1；
15中含有1的个数为4；
故共有1的个数为8，结果为8。
1000 - 1 = 0111，正好是原数取反。这就是原理。
用这种方法来求1的个数是很效率很高的。
不必去一个一个地移位。循环次数最少。

int a,b,c 请写函数实现C=a+b ,不可以改变数据类型,如将c改为long int,关键是如何处理溢出问题
bool add (int a, int b,int *c)
{
*c=a+b;
return (a>0 && b>0 &&(*ca || *c>b)));
}

分析：
struct bit
{   int a:3;
    int b:2;
    int c:3;
};
int main()
{
bit s;
char *c=(char*)&s;
   cout<*c=0x99;
   cout << s.a <     int a=-1;
   printf("%x",a);
return 0;
}
输出为什么是
4
1
-1
-4
ffffffff
因为0x99在内存中表示为 100 11 001 , a = 001, b = 11, c = 100
当c为有符合数时, c = 100, 最高1为表示c为负数，负数在计算机用补码表示，所以c = -4;同理
b = -1;
当c为有符合数时, c = 100,即 c = 4,同理 b = 3

位域：
有些信息在存储时，并不需要占用一个完整的字节，而只需占几个或一个二进制位。例如在存放一个开关量时，只有0和1 两种状态，用一位二进位即可。为了节省存储空间，并使处理简便，Ｃ语言又提供了一种数据结构，称为“位域”或“位段”。所谓“位域”是把一个字节中的二进位划分为几个不同的区域，并说明每个区域的位数。每个域有一个域名，允许在程序中按域名进行操作。这样就可以把几个不同的对象用一个字节的二进制位域来表示。一、位域的定义和位域变量的说明位域定义与结构定义相仿，其形式为：
struct 位域结构名
{ 位域列表 };
其中位域列表的形式为：类型说明符位域名：位域长度
例如：
struct bs
{
int a:8;
int b:2;
int c:6;
};
位域变量的说明与结构变量说明的方式相同。可采用先定义后说明，同时定义说明或者直接说明这三种方式。例如：
struct bs
{
int a:8;
int b:2;
int c:6;
}data;
说明data为bs变量，共占两个字节。其中位域a占8位，位域b占2位，位域c占6位。对于位域的定义尚有以下几点说明：

1. 一个位域必须存储在同一个字节中，不能跨两个字节。如一个字节所剩空间不够存放另一位域时，应从下一单元起存放该位域。也可以有意使某位域从下一单元开始。例如：
struct bs
{
unsigned a:4
unsigned :0 /*空域*/
unsigned b:4 /*从下一单元开始存放*/
unsigned c:4
}
在这个位域定义中，a占第一字节的4位，后4位填0表示不使用，b从第二字节开始，占用4位，c占用4位。

2. 由于位域不允许跨两个字节，因此位域的长度不能大于一个字节的长度，也就是说不能超过8位二进位。

3. 位域可以无位域名，这时它只用来作填充或调整位置。无名的位域是不能使用的。例如：
struct k
{
int a:1
int :2 /*该2位不能使用*/
int b:3
int c:2
};
从以上分析可以看出，位域在本质上就是一种结构类型，不过其成员是按二进位分配的。

二、位域的使用位域的使用和结构成员的使用相同，其一般形式为：位域变量名•位域名位域允许用各种格式输出。
main(){
struct bs
{
unsigned a:1;
unsigned b:3;
unsigned c:4;
} bit,*pbit;
bit.a=1;
bit.b=7;
bit.c=15;
pri

改错：
＃i nclude

int main(void) {

int **p;
int arr[100];

p = &arr;

return 0;
}
解答：
搞错了,是指针类型不同,
int **p; //二级指针
&arr; //得到的是指向第一维为100的数组的指针
＃i nclude
int main(void) {
int **p, *q;
int arr[100];
q = arr;
p = &q;
return 0;
}

下面这个程序执行后会有什么错误或者效果:
#define MAX 255
int main()
{
   unsigned char A[MAX],i;//i被定义为unsigned char
   for (i=0;i<=MAX;i++)
      A[i]=i;
}
解答：死循环加数组越界访问（C/C++不进行数组越界检查）
MAX=255
数组A的下标范围为:0..MAX-1,这是其一..
其二.当i循环到255时,循环内执行:
A[255]=255;
这句本身没有问题..但是返回for (i=0;i<=MAX;i++)语句时,
由于unsigned char的取值范围在(0..255),i++以后i又为0了..无限循环下去.

struct name1{
   char str;
   short x;
   int   num;
}

struct name2{
   char str;
   int num;
   short x;
}

sizeof(struct name1)=8,sizeof(struct name2)=12
在第二个结构中，为保证num按四个字节对齐，char后必须留出3字节的空间；同时为保证整个结构的自然对齐（这里是4字节对齐），在x后还要补齐2个字节，这样就是12字节。

intel：
A.c 和B.c两个c文件中使用了两个相同名字的static变量,编译的时候会不会有问题?这两个static变量会保存到哪里（栈还是堆或者其他的）?
static的全局变量，表明这个变量仅在本模块中有意义，不会影响其他模块。
他们都放在数据区，但是编译器对他们的命名是不同的。
如果要使变量在其他模块也有意义的话，需要使用extern关键字。

struct s1
{
int i: 8;
int j: 4;
int a: 3;
double b;
};

struct s2
{
int i: 8;
int j: 4;
double b;
int a:3;
};

printf("sizeof(s1)= %d\n", sizeof(s1));
printf("sizeof(s2)= %d\n", sizeof(s2));
result: 16, 24
第一个struct s1
{
int i: 8;
int j: 4;
int a: 3;
double b;
};
理论上是这样的，首先是i在相对0的位置，占8位一个字节，然后，j就在相对一个字节的位置，由于一个位置的字节数是4位的倍数，因此不用对齐，就放在那里了，然后是a，要在3位的倍数关系的位置上，因此要移一位，在15位的位置上放下，目前总共是18位，折算过来是2字节2位的样子，由于double是8字节的，因此要在相对0要是8个字节的位置上放下，因此从18位开始到8个字节之间的位置被忽略，直接放在8字节的位置了，因此，总共是16字节。

第二个最后会对照是不是结构体内最大数据的倍数，不是的话，会补成是最大数据的倍数

上面是基本问题，接下来是编程问题：

本人很弱，这几个题也搞不定，特来求救：
1）读文件file1.txt的内容（例如）：
12
34
56
输出到file2.txt：
56
34
12
（逆序）
2）输出和为一个给定整数的所有组合
例如n=5
5=1+4；5=2+3（相加的数不能重复）
则输出
1，4；2，3。
望高手赐教！！

第一题,注意可增长数组的应用.
＃i nclude
＃i nclude

int main(void)
{
int MAX = 10;
int *a = (int *)malloc(MAX * sizeof(int));
int *b;

FILE *fp1;
FILE *fp2;

fp1 = fopen("a.txt","r");
if(fp1 == NULL)
{printf("error1");
exit(-1);
}

fp2 = fopen("b.txt","w");
if(fp2 == NULL)
{printf("error2");
exit(-1);
}

int i = 0;
int j = 0;

while(fscanf(fp1,"%d",&a[i]) != EOF)
{
i++;
j++;
if(i >= MAX)
{
MAX = 2 * MAX;
b = (int*)realloc(a,MAX * sizeof(int));
if(b == NULL)
{
printf("error3");
exit(-1);
}
a = b;
}
}

for(;--j >= 0;)
fprintf(fp2,"%d\n",a[j]);

fclose(fp1);
fclose(fp2);

return 0;
}

第二题.
＃i nclude

int main(void)
{
unsigned long int i,j,k;

printf("please input the number\n");
scanf("%d",&i);
if( i % 2 == 0)
j = i / 2;
else
j = i / 2 + 1;

printf("The result is \n");
for(k = 0; k < j; k++)
printf("%d = %d + %d\n",i,k,i - k);
return 0;
}

＃i nclude
void main()
{
unsigned long int a,i=1;
scanf("%d",&a);
if(a%2==0)
{
for(i=1;i printf("%d",a,a-i);
}
else
for(i=1;i<=a/2;i++)
printf(" %d, %d",i,a-i);
}

兄弟,这样的题目若是做不出来实在是有些不应该, 给你一个递规反向输出字符串的例子,可谓是反序的经典例程.

void inverse(char *p)
{
    if( *p = = '\0' )
return;
    inverse( p+1 );
    printf( "%c", *p );
}

int main(int argc, char *argv[])
{
inverse("abc\0");

return 0;
}

借签了楼上的“递规反向输出”
＃i nclude
void test(FILE *fread, FILE *fwrite)
{
char buf[1024] = {0};
if (!fgets(buf, sizeof(buf), fread))
}

奶茶加盟 http://www.lianzhiwei.com/奶茶店加盟

RTY 2012-04-05 14:54 发表评论

SDL入门教程（六）：SDL读取其它格式的图片

RTY — Wed, 04 Apr 2012 00:25:00 GMT

http://www.cppblog.com/lf426/archive/2008/03/19/44831.html

SDL入门教程（六）：SDL读取其它格式的图片

作者：龙飞

1：扩充库（Extension Libraries）

        SDL本身所支持的，仅仅是读取bmp格式的图片。要使用其它格式的图片，我们需要使用SDL的扩充库。在下面地址，我们可以下载到相关文件SDL_image-devel-1.2.6-VC8.zip。
http://www.libsdl.org/projects/SDL_image/
        与SDL本身的设置一样，将include下的*.h文件拷贝到：
C:\MinGW\include\SDL （MinGW）
C:\Program Files\Microsoft Visual Studio 9.0\VC\include\SDL （VC2008）
        将*.lib文件拷贝到：
C:\MinGW\lib （MinGW）
C:\Program Files\Microsoft Visual Studio 9.0\VC\lib （VC2008）
        将*.dll文件拷贝到：
C:\WINDOWS\system32

        在编译的时候，gcc注意增加共同编译的库文件-lSDL_image，比如，我设置了一个批处理文件g++img.bat内容如下：

g++ -o MySDL.exe main.cpp -lmingw32 -lSDLmain -lSDL -lSDL_image -mwindows

在VC2008中，需要在projec属性中，Configuration Properties -- Linker -- Input -- Additional Dependencies 下增加SDL_image.lib。

在程序的头文件中，需要增加：

#include "SDL/SDL_image.h"

2：更加通用的Display Surface构造函数

我们现在可以回头过来修改我们在SDL入门教程（五）：6、对C++异常机制的思考，代码重写中的Display Surface类的构造函数，使其能够更加通用的读取其它格式的图片。

DisplaySurface::DisplaySurface(std::string file_name, const ScreenSurface& screen):
fileName(file_name)
{
    SDL_Surface* pSurfaceTemp = IMG_Load(file_name.c_str());
    if ( pSurfaceTemp == 0 )
        throw ErrorInfo(SDL_GetError());
    pSurface = SDL_DisplayFormat(pSurfaceTemp);
    if ( pSurface == 0 )
        throw ErrorInfo(SDL_GetError());
    SDL_FreeSurface(pSurfaceTemp);
    pScreen = screen.point();
}

IMG_Load()可以读取多种格式的图片文件，包括BMP, PNM, XPM, LBM, PCX, GIF, JPEG, TGA和PNG。

3：将图片修改为适合显示的格式

SDL_Surface *SDL_DisplayFormat(SDL_Surface *surface);

在上面的程序中，我们使用到了函数SDL_DisplayFormat()。在之前的教程中，我一直没有用到这个函数，是因为我还没有发现用SDL_LoadBMP()的时候会出现格式兼容性的问题——即使是图片位深与显示不一致。但是使用IMG_Load()的时候，小小的bug出现了。所以，这里我必须使用SDL_DisplayFormat()，将读取的图片文件转换为适合显示的格式。
如果转换失败，或者内存溢出，这个函数将返回空指针。

RTY 2012-04-04 08:25 发表评论

Configure，Makefile.am, Makefile.in, Makefile文件之间关系

RTY — Tue, 03 Apr 2012 14:20:00 GMT

Configure，Makefile.am, Makefile.in, Makefile文件之间关系

2009-08-12 12:14

1.autoscan (autoconf): 扫描源代码以搜寻普通的可移植性问题，比如检查编译器，库，头文件等，生成文件configure.scan,它是configure.ac的一个雏形。

your source files --> [autoscan*] --> [configure.scan] --> configure.ac

2.aclocal (automake):根据已经安装的宏，用户定义宏和acinclude.m4文件中的宏将configure.ac文件所需要的宏集中定义到文件 aclocal.m4中。aclocal是一个perl 脚本程序，它的定义是：“aclocal - create aclocal.m4 by scanning configure.ac”

user input files   optional input     process          output files
================   ==============     =======          ============

                    acinclude.m4 - - - - -.
                                          V
                                      .-------,
configure.ac ------------------------>|aclocal|
                 {user macro files} ->|       |------> aclocal.m4
                                      `-------'
3.autoheader(autoconf): 根据configure.ac中的某些宏，比如cpp宏定义，运行m4，声称config.h.in

user input files    optional input     process          output files
================    ==============     =======          ============

                    aclocal.m4 - - - - - - - .
                                             |
                                             V
                                     .----------,
configure.ac ----------------------->|autoheader|----> autoconfig.h.in
                                     `----------'

4.automake: automake将Makefile.am中定义的结构建立Makefile.in，然后configure脚本将生成的Makefile.in文件转换为Makefile。如果在configure.ac中定义了一些特殊的宏，比如AC_PROG_LIBTOOL，它会调用libtoolize，否则它会自己产生config.guess和config.sub

user input files   optional input   processes          output files
================   ==============   =========          ============

                                     .--------,
                                     |        | - - -> COPYING
                                     |        | - - -> INSTALL
                                     |        |------> install-sh
                                     |        |------> missing
                                     |automake|------> mkinstalldirs
configure.ac ----------------------->|        |
Makefile.am  ----------------------->|        |------> Makefile.in
                                     |        |------> stamp-h.in
                                 .---+        | - - -> config.guess
                                 |   |        | - - -> config.sub
                                 |   `------+-'
                                 |          | - - - -> config.guess
                                 |libtoolize| - - - -> config.sub
                                 |          |--------> ltmain.sh
                                 |          |--------> ltconfig
                                 `----------'

5.autoconf:将configure.ac中的宏展开，生成configure脚本。这个过程可能要用到aclocal.m4中定义的宏。

user input files   optional input   processes          output files
================   ==============   =========          ============

aclocal.m4 ,autoconfig.h.in - - - - - - -.
                                         V
                                     .--------,
configure.ac ----------------------->|autoconf|------> configure

6. ./configure的过程


                                           .-------------> [config.cache]
     configure* --------------------------+-------------> config.log
                                          |
              [config.h.in] -.            v            .--> [autoconfig.h]
                             +-------> config.status* -+                   
              Makefile.in ---'                         `-->   Makefile

7. make过程

[autoconfig.h] -.
                     +--> make* --->  程序
        Makefile   ---'

.---------,
                   config.site - - ->|         |
                  config.cache - - ->|configure| - - -> config.cache
                                     |         +-,
                                     `-+-------' |
                                       |         |----> config.status
                   config.h.in ------->|config-  |----> config.h
                   Makefile.in ------->|  .status|----> Makefile
                                       |         |----> stamp-h
                                       |         +--,
                                     .-+         |  |
                                     | `------+--'  |
                   ltmain.sh ------->|ltconfig|-------> libtool
                                     |        |     |
                                     `-+------'     |
                                       |config.guess|
                                       | config.sub |
                                       `------------' 
.--------,
                   Makefile ------>|        |
                   config.h ------>|  make  |
{project sources} ---------------->|        |--------> {project targets}
                                 .-+        +--,
                                 | `--------'  |
                                 |   libtool   |
                                 |   missing   |
                                 |  install-sh |
                                 |mkinstalldirs|
                                 `-------------'

实例：
在/hello/目录下创建一个hello.c文件，并编译运行它：

#cd /hello/

(1) 编写源文件hello.c：

#include
int main(int argc, char** argv)
{
printf("Hello, GNU!n");
return 0;
}

[litao@vm0000131 hello]$ ll
total 4
-rw-rw-r-- 1 litao litao 68 Aug 12 12:02 hello.c

一、autoscan

[litao@vm0000131 hello]$ autoscan
autom4te: configure.ac: no such file or directory
autoscan: /usr/bin/autom4te failed with exit status: 1
[litao@vm0000131 hello]$ ll
total 8
-rw-rw-r-- 1 litao litao 0 Aug 12 12:03 autoscan.log
-rw-rw-r-- 1 litao litao 457 Aug 12 12:03 configure.scan
-rw-rw-r-- 1 litao litao 68 Aug 12 12:02 hello.c

已经生成了configure.scan，autoscan.log文件

将configure.scan 修改为 configure.in，最后修改的内容如下：

[litao@vm0000131 hello]$ mv configure.scan configure.in
[litao@vm0000131 hello]$ vim configure.in

# -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.

AC_PREREQ(2.59)
AC_INIT(FULL-PACKAGE-NAME, VERSION, BUG-REPORT-ADDRESS)
AC_CONFIG_SRCDIR([hello.c])
#AC_CONFIG_HEADER([config.h])
AM_INIT_AUTOMAKE(hello, 1.0)
# Checks for programs.
AC_PROG_CC

# Checks for libraries.

# Checks for header files.

# Checks for typedefs, structures, and compiler characteristics.

# Checks for library functions.
AC_OUTPUT(Makefile)

二、acloacl

[litao@vm0000131 hello]$ aclocal

生成 aclocal.m4 和 autom4te.cache (生成aclocal.m4的过程中涉及到configure.in)

[litao@vm0000131 hello]$ ll
total 44
-rw-rw-r-- 1 litao litao 31120 Aug 12 12:08 aclocal.m4
drwxr-xr-x 2 litao litao 4096 Aug 12 12:08 autom4te.cache
-rw-rw-r-- 1 litao litao 0 Aug 12 12:03 autoscan.log
-rw-rw-r-- 1 litao litao 496 Aug 12 12:08 configure.in
-rw-rw-r-- 1 litao litao 68 Aug 12 12:02 hello.c

三、antoconf

[litao@vm0000131 hello]$ autoconf
生成 configure (根据 configure.in, 和 aclocal.m4)
[litao@vm0000131 hello]$ ll
total 168
-rw-rw-r-- 1 litao litao 31120 Aug 12 12:08 aclocal.m4
drwxr-xr-x 2 litao litao 4096 Aug 12 12:11 autom4te.cache
-rw-rw-r-- 1 litao litao 0 Aug 12 12:03 autoscan.log
-rwxrwxr-x 1 litao litao 122297 Aug 12 12:11 configure
-rw-rw-r-- 1 litao litao 496 Aug 12 12:08 configure.in
-rw-rw-r-- 1 litao litao 68 Aug 12 12:02 hello.c

四、编写Makefile.am：

AUTOMAKE_OPTIONS= foreign
bin_PROGRAMS= hello
hello_SOURCES= hello.c

五、automake

生成 Makefile.in， depcomp， install-sh，和 missing (根据 Makefile.am, 和 aclocal.m4)

[litao@vm0000131 hello]$ automake
configure.in: required file `./install-sh' not found
configure.in: required file `./missing' not found
Makefile.am: required file `./depcomp' not found
[litao@vm0000131 hello]$ automake --add-missing
configure.in: installing `./install-sh'
configure.in: installing `./missing'
Makefile.am: installing `./depcomp'
[litao@vm0000131 hello]$ ll
total 192
-rw-rw-r-- 1 litao litao 31120 Aug 12 12:08 aclocal.m4
drwxr-xr-x 2 litao litao 4096 Aug 12 12:14 autom4te.cache
-rw-rw-r-- 1 litao litao 0 Aug 12 12:03 autoscan.log
-rwxrwxr-x 1 litao litao 122297 Aug 12 12:11 configure
-rw-rw-r-- 1 litao litao 496 Aug 12 12:08 configure.in
lrwxrwxrwx 1 litao litao 31 Aug 12 12:16 depcomp -> /usr/share/automake-1.9/depcomp
-rw-rw-r-- 1 litao litao 68 Aug 12 12:02 hello.c
lrwxrwxrwx 1 litao litao 34 Aug 12 12:16 install-sh -> /usr/share/automake-1.9/install-sh
-rw-rw-r-- 1 litao litao 69 Aug 12 12:15 Makefile.am
-rw-rw-r-- 1 litao litao 16561 Aug 12 12:16 Makefile.in
lrwxrwxrwx 1 litao litao 31 Aug 12 12:16 missing -> /usr/share/automake-1.9/missing

六、configure
生成 Makefile， config.log，和 config.status

竹林英客

zxjlwt

jazeltq

RTY 2012-04-03 22:20 发表评论

CL.exe的全部命令开关(摘) - 酱坛子 - C++博客

RTY — Fri, 30 Mar 2012 12:46:00 GMT

导读：

/C:在预处理输出中保留注释语句
/c:只编译，不连接，相当于在"Build"菜单下选择了"Compile"
/D:定义常量和宏，与源程序里的#define 有相同效果
/E:预处理C、C＋＋源文件，将源文件中所有的预编译指令及宏展开，将注释去掉，然后将预处理器的输出拷贝至标准输出设备输出，并且在每个文件的开头和末尾加入#line
/EH:指定编译器用何种异常处理模型
/EP:同/E,只是去掉了#line
/F:设置程序的堆栈大小
/FA:设置生成何种列表文件（汇编、汇编与机器码、汇编与源码、汇编与机器码以及源码）
/Fa:指定用/FA设置的列表文件的存放路径及（或）文件名
/FD:生成文件的相互依赖信息
/Fd:设置程序数据库文件（PDB）的存放路径及（或）文件名
/Fe:设置最终可执行文件的存放路径及（或）文件名
/FI:预处理指定的头文件，与源文件中的＃include有相同效果
/Fm:创建map文件
/Fo:设置编译后Obj文件的存放路径及（或）文件名
/Fp:设置预编译文件（pch）的存放路径及（或）文件名
/FR:生成浏览信息（sbr）文件
/Fr:同/FR,不同之处在于/Fr不包括局部变量信息
/G3:为80386处理器优化代码生成
/G4:为80486处理器优化代码生成
/G5:为Pentium处理器优化代码生成
/G6:为Pentium Pro处理器优化代码生成
/GA:为Windows应用程序作优化
/GB:为Pentium处理器优化代码生成，使用80386、80486、Pentium、Pentium Pro的混合指令集，是代码生成的默认选项（程序属性选项中Processor对应Blend）
/GD:为Windows动态库（dll）作优化，此开关在VC6中没有实现
/Gd:指定使用__cdecl的函数调用规则
/Ge:激活堆栈检测
/GF:消除程序中的重复的字符串，并将她放到只读的缓冲区中
/Gf:消除程序中的重复字符串
/Gh:在每个函数的开头调用钩子（hook）函数--penter
/Gi:允许渐进编译
/Gm:允许最小化rebuild
/GR:允许运行时类型信息(Run-Time Type Infomation)
/Gr:指定使用__fastcall的函数调用规则
/Gs:控制堆栈检测所用内存大小
/GT:支持用__declspec(thread)分配的数据的fier-safety
/GX:允许同步异常处理，与/EHsc开关等价
/Gy:允许编译器将每一个函数封装成COMDATs的形式，供连接器调用
/GZ:允许在Debug build 的时候捕捉Release build的错误
/Gz:指定使用__stdcall的函数调用规则
/H:限制外部名字的长度
/HELP:列出编译器的所有的命令开关
/I:指定头文件的搜索路径
/J:将char的缺省类型从signed char改成unsigned char
/LD:创建一个动态连接库
/LDd:创建一个Debug版本的动态链接库
/link:将指定的选项传给连接器
/MD:选择多线程、DLL版本的C Run－Time库
/MDd:选择多线程、DLL、Debug版本的C Run－Time库
/ML:选择单线程版本的C Run—Time库
/MLd:选择单线程、Debug版本的C Run—Time库
/MT:选择多线程版本的C Run-Time库
/MTd:选择多线程、Debug版本的C Run—Time库
/nologo:不显示程序的版权信息
/O1:优化使产生的可执行代码最小
/O2:优化使产生的可执行代码速度最快
/Oa:指示编译器程序里没有使用别名，可以提高程序的执行速度
/Ob:控制内联（inline）函数的展开
/Od:禁止代码优化
/Og:使用全局优化
/Oi:用内部函数去代替程序里的函数调用，可以使程序运行的更快，但程序的长度变长
/Op:提高浮点数比较运算的一致性
/Os:产生尽可能小的可执行代码
/Ot:产生尽可能块的可执行代码
/Ow:指示编译器在函数体内部没有使用别名
/Ox:组合了几个优化开关，达到尽可能多的优化
/Oy:阻止调用堆栈里创建帧指针
/Q1f:对核心级的设备驱动程序生成单独的调试信息
/QI0f:对Pentium 0x0f错误指令作修正
/Qifdiv:对Pentium FDIV错误指令作修正
/P:将预处理输出写到指定文件里，文件的后缀名为I
/TC:将命令行上的所有文件都当作C源程序编译，不管后缀名是否为.c
/Tc:将指定的文件当作C源程序编译，不管后缀名是否为.c
/TP:将命令行上的所有文件都当作C＋＋源程序编译，不管后缀名是否为.cpp
/Tp:将指定文件当作C＋＋源程序编译，不管后缀名是否为.cpp
/U:去掉一个指定的前面定义的符号或常量
/u:去掉所有前面定义的符号或常量
/V:在编译的obj文件里嵌入版本号
/vd:禁止/允许构造函数置换
/vmb:选择指针的表示方法，使用这个开关，在声明指向某个类的成员的指针之前，必须先定义这个类
/vmg:选择指针的表示方法，使用这个开关，在声明指向某个类的成员的指针之前，不必先定义这个类，但要首先指定这个类是使用何种继承方法
/vmm:设置指针的表示方法为Single Inheritance and Multiple Inheritance
/vms:设置指针的表示方法为Single Inheritance
/vmv:设置指针的表示方法为Any class
/W:设置警告等级
/w:禁止所有警告
/X:阻止编译器搜索标准的include 目录
/Yc:创建预编译头文件（pch）
/Yd:在所有的obj文件里写上完全的调试信息
/Yu:在build过程中使用指定的预编译头文件
/YX:指示编译器若预编译头文件存在，则使用它，若不存在，则创建一个
/Z7:生成MSC7.0兼容的调试信息
/Za:禁止语言扩展(Microsoft Extensions to C)
/Zd:调试信息只包含外部和全局的符号信息以及行号信息
/Ze:允许语言扩展(Microsoft Extensions to C)
/Zg:为源文件里面定义的每个函数生成函数原型
/ZI:生成程序库文件（Pdb）并支持Edit and Continue调试特性
/Zi:生成程序库文件（pdb），包含类型信息和符号调试信息
/ZL:从obj文件里去掉缺省的库文件名
/Zm:设置编译器的内存分配xianzhi
/Zn:禁止浏览信息文件里面的封装
/Zp:设置结构成员在内存里面的封装格式
/Zs:快速检查语法错误
－－－－－－－－－－－－－－－－－－－－－－－－－－
vc所支持的文件类型

DSW:全称是Developer Studio Workspace，最高级别的配置文件，记录了整个工作空间的配置信息，她是一个纯文本的文件，在vc创建新项目的时候自动生成
DSP:全称是Developer Studio Project，也是一个配置文件，不过她记录的是一个项目的所有配置信息，纯文本文件
OPT：与DSW、DSP配合使用的配置文件，她记录了与机器硬件有关的信息，同一个项目在不同的机器上的opt文件内容是不同的
CLW：记录了跟ClassWizard相关的信息，如果丢失了clw文件，那么在Class View面板里就没有类信息
PLG：实际上是一个超文本文件，可以用Internet Explorer打开，记录了Build的过程，是一个日志型文件
RC：资源描述文件，记录了所有的资源信息，在资源编辑器里作的修改，实际上都是对RC文件的修改
RC2：附加的资源描述文件，不能直接资源编辑器修改，只能手工添加，可以用来添加额外的资源
RES：经过资源编辑器编译之后的资源文件，以二进制方式存放
SBR：编译器生成的浏览信息文件，在代码导航的时候非常有用，她需要在编译时指定/FR或者/Fr开关
BSC：BSCMAKE.EXE将所有的SBR文件作为输入，经过处理之后输出一个BSC文件，在代码导航的时候实际用到的是BSC文件
ILK：当选定渐增型编译连接时，连接器自动生成ILK文件，记录连接信息
PDB：全称是Program DataBase，即程序数据库文件，用来记录调试信息，是一个相当重要的文件，没有他，程序无法正常调试
LIB：如果项目输出是Dll的话，一般会输出一个跟项目同名的Lib文件，记录输出的函数信息
EXP：同Lib，是跟Dll一起生成的输出文件
PCH：全称是PreCompiled Header，就是预先编译好的头文件，在编译时指定/Yu开关时编译器自动生成

本文转自
http://www.cppblog.com/sunraiing9/archive/2007/11/26/37323.html

RTY 2012-03-30 20:46 发表评论

Windows平台下的调试技术 - 小夜曲的孤伤 - 博客大巴

RTY — Fri, 30 Mar 2012 12:45:00 GMT

导读：

版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明
 http://chenshine.blogbus.com/logs/4414354.html

刚进入计算机相关专业领域时，大家最先用过的调试器大多会是Turbo C。它虽然古老但用过的人却很多，然而严格的讲，Turbo C是一个集成开发环境，虽然拥有独立的编译器，链接器，却没有独立的调试器，这和Visual Studio一样。如果你做过DOS，早期Windows下的汇编，也许你会对Debug，CodeView等调试工具熟悉，但这些工具太老了，Debug甚至不能调试32位程序，介绍它们与这篇文章的主旨不符，如果你对它们感兴趣，可以去查阅相关资料。本文主要是介绍与调试技术相关的理论知识以及常用调试器的使用，Windows设备驱动程序与内核的调试等。具体的讲解方法是理论结合实践，并且是站在给新手看的角度，循序渐进的，用一个一个调试会话向你展示每个重要命令的使用。

目录

1。调试器
2。调试信息
3。用户模式程序的调试
4。驱动程序与内核的调试

1 调试器

1。1 概览

调试器，与编译器，链接器一样，都属于基础软件，它们在制作上都有很大的难度，但尽管如此，现实中还是有不少专业级的调试器，微软官方的就有 cdb，ntsd，WinDbg，kd等，还有SoftIce，OllyDbg等来自于其它公司的优秀调试器。本文不可能对这几个调试器一一介绍，一个是限于篇幅，另一个是上面列举的这几个调试器无论是哪一个都需要你花很长的时间去完全掌握（在市面上有很多书籍甚至专门讲解某一个调试器的使用，比如 SoftIce）。虽然本文不会讲解SoftIce的详细使用，但我还是要对它进行简短的介绍，因为它太有名了，甚至比Windows出生的早。

1。2 SoftIce

SoftIce 是NuMega公司生产的调试器，产于80年代后期，直到今天为止，这个软件已经变革过好几次了，因为处理器的体系结构在更新，操作系统也在更新，所以调试器也必须相应的更新。它之所以有名，那是与历史有关的，在Intel推出386 Cpu的时候，NuMega立即让SoftIce支持了386 Cpu的新特性，同时吸引了大量黑客的使用，使它在黑客界产生了一定的地位(功能强大的调试器可以对软件的保护机制进行破解，如突破序列号之类的)。在 Windows推出时，所有的调试器都不适用这种新的系统软件体系结构了，唯一能用的就是微软自己生产的调试器，却很拙劣，这时NuMega又对 SoftIce进行了变革，不仅让它可以在新的系统上很好的工作，甚至还可以调试Windows的内核，这是当时是不敢想象的。也正是因为它很好的性能，卓越的功能，它成为了黑客们的宠儿，并且培养了几代的黑客。读完本文后，你自己应该有能力去探索它，或许你也可以在这几款调试器里找到适合自己的。

1。3 微软的调试工具

本文主要介绍的是微软官方的调试器，并且MS微软也最积极，调试工具包一直在更新中。在微软的调试器里，大家可能最为熟悉Visual Studio Debugger，就是你在Visual C++里使用的那个，它并不是一个单独可运行的程序，而是内嵌在Visual Studio中的，它的功能相对于上面几个调试器来说要弱很多，这里并不会对它进行介绍，如果你想全方面的了解它的话，你可以去参考MSDN，那里专门有几章讲解它，是一份很好的文档化的资源(而且还是中文的)。其它的微软调试工具cdb，ntsd，WinDbg，kd都在微软的一个安装包里，被称作Debugging Tools for Windows(10 多M的大小，请通过这个链接下载并安装，一会儿就要用到)。这些调试器在下文中会分别介绍，这里先做一个简单的区别，cdb与ntsd几乎是一样的程序，唯一的不同是cdb是一个CUI程序，即Console程序，而ntsd是GUI程序，但ntsd并没有产生窗口，而是又分配了一个Console窗口，这个Console窗口就相当于是cdb。它与真正的cdb执行完全一样的功能(官方如是说，然而实际上还有一些个不同)。在命令行中启动它们时下面两句命令有一样的效果(C:/Progs/Debug是调试工具包的安装位置)：

C:/Progs/Debug/>start cdb
C:/Progs/Debug/>ntsd

cdb 与ntsd是用来调试用户模式应用程序的。kd调试器也是一个命令行程序，不过正如其名kernel debugger所描述的一样，它是内核调试器的，是驱动程序开发者，系统Hacker的最爱。WinDbg是一个称职的GUI程序，它有菜单，有工具栏，还有多个子窗口，可以分别显示源代码，调用栈，命令等，它既可以调试ring 0程序，也可以调试ring 3程序，其实它只是一个壳而已，当调试ring 3级程序时它实际上是用cdb/ntsd，而当调试ring 0级程序时是用kd。WinDbg的到来吸引了很多的人使用，你也将会发现，它确实是一款优秀的调试器。

2 调试信息

调试器之所以能够工作，完全是依赖于编译和链接程序时所生成的调试信息，当然调试信息是具有一定的格式的。

2。1 格式

微软的调试信息格式经过了几代变化，最终形成了Program DataBase这种格式，并且这种格式还在进行版本上的更新，VS.Net所用的新的Program DataBase版本与Visual C++ 6.0所用的老的版本是不兼容的，并且你也可以用编译器和链接器明确指定你想要生成的调试信息格式，这一点下文中有阐述。

2。2 内容

关于调试信息我们还必须知道两件事，一是调试信息包括哪些内容，二是调试信息储存在什么地方。其实调试信息所应该包括的内容正是调试信息格式变化的原因，从 COFF格式，到CodeView格式，到Program DataBase格式，调试信息变得越来越丰富了，并且是只多不少。Program DataBase格式的调试信息中主要包括了所有全局函数，static 函数，全局变量，static变量，局部变量，函数形参的名字及其位置，源代码与可执行文件中指令的映射信息，每个函数与变量的类型，以及FPO信息，编辑和继续信息。编辑与继续信息主要用于在Visual Studio中调试时，可以在调试的同时编辑源代码，并在接下来的调试中得到体现。Program DataBase格式的调试信息包含了这么多的内容，所以用这种调试信息来调试程序时，你将能够得到更多，更准确，更深入的反馈。

2。3 存储位置

调试信息的存储位置是与其格式相关的，Program DataBase格式的调试信息存储在一个单独的文件里，扩展名为pdb。像以前的CodeView格式的调试信息即可存储在单独的文件里，又可存储在编译时所生成的obj文件中。知道了这些知识后，我们就可以正确地生成调试信息了。在后面的内核调试中我们还要继续谈到它。

3 用户模式程序的调试

根据上面的讲述，我们可以用cdb或WinDbg来进行ring 3程序的调试，这里先讲解cdb。cdb允许你启动某个被调试程序(以下称debugee)的一个新的实例来进行调试，即先创建cdb，然后cdb再把你所指定的程序创建为一个新进程进而对其调试，也允许debugee在已经运行的情况下被cdb attach上。cdb还可以对Crash Dump(程序崩溃时的内存Copy，下文将会说明)进行调试，只需要加上-z选项，后面再加上Crash Dump的文件名即可。这几种调试方式下面将会一一讲述。

3。1 调试前的准备

第 2节中对调试信息进行了理论上的说明，接下来我们来看看在实际中应该如何操作。首先我们的程序必须要经过编译，链接，并且在编译和链接时还要指定一些选项以正确地生成调试信息。这里所使用的编译器是cl.exe，链接器是link.exe，都是微软官方的，Visual Studio就是用的这两个(CTRL+F5就是顺序调用cl和link的快捷键)，如果你安装了Visual C++或Visual Studio，就会有它们，另外一种选择是安装SDK，也能够得到它们。本文所用的cl.exe和link.exe是Visual C++ 6.0的版本。若要生成调试信息，编译时我们需要加上的选项应是/Zi，而链接时则要加上/debug。在下面的调试中，我们将用C语言来写程序，所以你有必要知道用C语言写出来的程序与用汇编写出来的有什么不同。首先，每个程序都有一个入口函数，它的地址需要在链接时指定，并被链接器放到最终可执行文件的头部，通常用汇编语言写的程序，有选择的，你可以在源代码中指定入口函数，而用C语言写的程序则需要在链接的时候来指定入口函数，说到这你可能不以为然，“C语言写的程序的入口函数不就是main吗？“。实际上，控制台C程序的入口函数默认情况下是C运行时的启动函数：mainCRTStartup。然后由这个函数调用你写的main函数，所以可执行文件的头部存放的入口地址是mainCRTStartup的地址，而不是你写的main函数地址。 mainCRTStartup主要做了一些为了正确执行C/C++程序的初始化工作。它已经由微软写好了，由链接器自动链接到可执行文件中。如果你在程序中不使用C语言的库以及一些ANSI规定的全局变量，只是单纯地使用C语言这种语法，那么你也可以不链接mainCRTStartup，直接指定你自己写的某个函数为入口函数，这也是我们在下文中所使用的方法，具体的做法是在链接时加入如下选项：/subsystem:console /entry:你的入口函数名称。这个入口函数应该是不带参数的。现在我们来总结一下上面所讲的内容，假定你的源程序名为exam.c，你想指定的入口函数为main，那么应该如下生成可执行程序：

C:/Pro/>cl /Zi exam.c /link /debug /subsystem:console /entry:main

另外，就算你不链接mainCRTStartup(它会调用很多的Win32 API)，也不在源程序中调用任何的系统函数。那么系统还是会把一些动态链接库，如kernel32.dll，Ntdll.dll等动态链接到你的程序所对应的进程里，即把它们映射到你的程序对应的进程地址空间里。这是因为在你所指定的入口函数运行之前，还会有一系列的 Kernel32.dll，Ntdll.dll中的函数要运行。即在用户空间中你指定的入口函数，例如上面的main，根本不是第一个运行的函数。那么那些函数是做什么的呢，通过大量的反汇编和调试能够推断出它们是做一些进程，线程在用户空间的初始化，设置一些异常桢等。在下面的调试中我们将会用一些手段来研究它们。这些函数是操作系统的一部分，因些我们必须从官方网站下载它的符号文件，当然不下载也行，那么你将面临的会是一大堆的警告。说到下载，没有比这更简单的了，你不需要预先的下载，只需要添加一个环境变量_NT_SYMBOL_PATH即可，而真正的下载工作由调试器来做，这个环境变量的值与已存在的PATH环境变量类似，是由分号分隔的一系列的路径组成。这些路径应该包括你的调试信息文件(pdb文件)所在地，如前面的C:/Pro/。如果要下载系统文件如Kernel32.dll，Ntdll.dll的pdb文件，你仅仅需要再加一个这样的路径：SRV*D:/Symbols*http: //msdl.microsoft.com/download/symbols，其中D:/Symbols是可更换的，你可以换成任何一个其它的路径，这个D:/Symbls是用来存放从后面的URL路径所下载下来的系统调试信息文件的。其实你也可以预先下载系统调试信息文件到一个路径里，然后在 _NT_SYMBOL_PATH里指定那个目录，但这样一来有两个缺点，一是你必须得进行版本的匹配，做这件事简直太乏味了，二是你一次需要把整个操作系统的调试信息文件都下载下来，可能会需要1G的空间。而通过前面设置环境变量的方式，调试器会根据需要只下载这次调试会话所需要的调试信息文件，并且它会自动给你匹配版本。由于我们将要编写的源代码都在C:/Pro/文件夹中，生成的pdb文件也在C:/Pro/中，所以我们的 _NT_SYMBOL_PATH环境变量应该如下设置，假设你希望系统pdb文件下载到D:/Symbols：

C:/Pro/>set _NT_SYMBOL_PATH=SRV*D:/Symbols*http://msdl.microsoft.com/download/symbols;C:/Pro/

最后，我们需要在命令行中启动cdb调试器，但当前目录通常是源代码文件夹C:/Pro/，为了避免如下冗余的键入：

C:/Pro/>C:/Progs/Debug/cdb example1.exe

应该为cdb，ntsd，WinDbg设置PATH环境变量：

C:/Pro/>set PATH=%PATH%;C:/Progs/Debug/

这里的C:/Progs/Debug是Debugging Tools for Windows的安装目录。以后就可以这样来调试了：

C:/Pro/>cdb example1.exe

3。2 cdb启动新实例的调试

3。2。1 编写一源程序，启动cdb

首先我编写了下面的C程序，先用这个程序来介绍一些基本的命令，并且来验证一下调试信息中是否确切包含了上面所说的那些内容:

[example1.c]

int 		gVar;
static 	int	sgVar;
int 		Inc(int Param);
static	int	sDec(int sParam);
void main(void)
{
	int lVar;
	static int slVar;
	lVar = 3;
	slVar = 4;
	gVar = Inc(lVar);
	sgVar = sDec(slVar);
}
int Inc(int Param)
{
	return (Param+1);
}
int sDec(int sParam)
{
	return (sParam-1);
}

对这个程序用上面所讲的方法编译链接：

C:/Pro/>cl /Zi example1.c /link /debug /subsystem:console /entry:main

接下来启动cdb调试器：

C:/Pro/>cdb example1.exe

Microsoft (R) Windows Debugger 
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: example1.exe
Symbol search path is: SRV*D:/Symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 00400000 00406000   example1.exe
ModLoad: 7c920000 7c9b4000   ntdll.dll
ModLoad: 7c800000 7c91c000   C:/WINDOWS/system32/kernel32.dll
(c94.c24): Break instruction exception - code 80000003 (first chance)
eax=00251eb4 ebx=7ffd4000 ecx=00000001 edx=00000002 esi=00251f48 edi=00251eb4
eip=7c921230 esp=0012fb20 ebp=0012fc94 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
ntdll!DbgBreakPoint:
7c921230 cc              int     3
0:000>

cdb 输出了此时主线程的上下文信息(这个例子中也只有这一个线程)以及程序断点信息后便会进入一个新的提示符：0:000>。以后我们会一直工作在这种类型的提示符上，下面在这个提示符上输入一个命令来加载所有的调试信息文件，此时可能会慢一些，因为要下载系统DLL的pdb文件，所以要确保你能上网。

0:000>.reload /f

看到这个以"."号做为前缀的命令，可能你会觉得怪怪的，但实际上还有用"!"号做前缀的呢，用"."号做前缀的命令表示元命令，而用"!“号做前缀的命令表示扩展命令，这里只做一个简单的区分即可。

其实这时我们所要调试的程序已经运行起来了，不过停在了某处，主线程处于冻结状态。这一点和Linux的Gnu调试器GDB不一样，对于GDB调试器，你先要设置一个断点，然后再键入运行命令(如果自己不手动设置一个断点，那么程序将会一直运行直到结束，你根本没有调试的机会。)，这时程序才处于运行状态。没有运行和运行之后处于冻结状态是两个完全不同的概念。那么我们这个example1.exe停在了什么地方呢。下面我将介绍一个很重要的命令，用它我们可以来研究这方面的问题。

3。2。2 查看堆栈及用户空间的初始化

用kb命令可以来查看堆栈，它显示栈上一些重要的信息。

0:000>kb
ChildEBP RetAddr  Args to Child
0012fb1c 7c95edc0 7ffdf000 7ffd4000 00000000 ntdll!DbgBreakPoint
0012fc94 7c941639 0012fd30 7c920000 0012fce0 ntdll!LdrpInitializeProcess+0xffa
0012fd1c 7c92eac7 0012fd30 7c920000 00000000 ntdll!_LdrpInitialize+0x183
00000000 00000000 00000000 00000000 00000000 ntdll!KiUserApcDispatcher+0x7

这个命令所列出来的信息后面还要详细介绍，这里先关注一下函数的调用关系。从上面的列表可以看到有四个函数，这四个函数都是ntdll模块里的，从下至上函数依次被调用。要注意这是当前线程的用户栈里所有的东西，就四个函数，KiUserApcDispatcher是第一个，上面已经提到过，在你指定的入口函数执行之前还有很多的函数被调用，KiUserApcDispatcher是第一个被调用的，接下来它再调用_LdrpInitialize，_LdrpInitialize调用LdrpInitializeProcess，再调用DbgBreakPoint。至于是谁调用的KiUserApcDispatcher，我现在只能简单的告诉你是操作系统调度例程调度的结果。深入地探讨它就离开本文的主题了。现在我们可以肯定的是程序停在了DbgBreakPoint里，因为它是栈上最后一个函数。从cdb调试器的输出可以看到example1.exe停在了DbgBreakPoint函数里的int 3语句上，int 3是一个异常，它将会通知操作系统挂起这个线程，并且通知调试器，这是操作系统对调试的一个支持。其实DbgBreakPoint函数只有一条语句，那就是int 3。敏感点的人可能会想到，这样一来，所有的程序，无论是否被调试，在运行的时候最初都会执行DbgBreakPoint函数了，这也太傻了吧？情况并非如此，当我们键入cdb example1.exe时，cdb在启动example1.exe的时候会加一个特殊的标记，在这种情况下LdrpInitializeProcess才会调用DbgBreakPoint，这又是操作系统对调试的一个支持。

本文转自
http://chenshine.blogbus.com/logs/4414354.html

RTY 2012-03-30 20:45 发表评论

Google Breakpad 完全解析（二） —— Windows前台实现篇

RTY — Mon, 07 Nov 2011 13:36:00 GMT

Google Breakpad 完全解析（二） —— Windows前台实现篇

2011年02月7日 — Asp J

Table of contents for Google Breakpad 完全解析

Google Breakpad 完全解析（一） —— Windows入门篇
Google Breakpad 完全解析（二） —— Windows前台实现篇

原创文章，转载请标明出处：Soul Apogee (http://bigasp.com)，谢谢。

好，看完了如何使用breakpad，我们现在看看breakpad在Windows下到底是如何实现的呢？

代码结构

在我们来看breakpad是如何实现其强大的功能之前，我们先来看一下他的代码结构吧。

Google breakpad的源代码都在src的目录下，他分为如下几个文件夹：
client：这下面包含了前台应用程序中捕捉dump的部分代码，里面按照平台分成各个子文件夹
common：前台后台都会用到的部分基础代码，字符串转换，内存读写，md5神马的
google_breakpad：breakpad中公共的头文件
processor：用于在后台处理崩溃的核心代码
testing：测试工程
third_party：第三方库
tools：一些小工具，用于处理dump文件和符号表

我们先来看Windows下前台实现的部分，也就是client文件夹下的代码。

breakpad的崩溃捕获机制

在Windows下捕获崩溃，大家很容易会想到那个捕获结构化异常的Api：SetUnhandledExceptionFilter。

breakpad中也使用了这个Api来实现的崩溃捕获，另外，breakpad还捕获了另外两种C++运行库提供的崩溃，一种是使用_set_purecall_handler捕获纯虚函数调用产生的崩溃，还有一种是使用_set_invalid_parameter_handler捕获错误的参数调用产生的崩溃。

if (handler_types & HANDLER_EXCEPTION)

previous_filter_ = SetUnhandledExceptionFilter(HandleException);

#if _MSC_VER >= 1400 // MSVC 2005/8

if (handler_types & HANDLER_INVALID_PARAMETER)

previous_iph_ = _set_invalid_parameter_handler(HandleInvalidParameter);

#endif // _MSC_VER >= 1400

if (handler_types & HANDLER_PURECALL)

previous_pch_ = _set_purecall_handler(HandlePureVirtualCall);

另外由于C++运行库提供的崩溃回调中，并不会提供当前的线程现场和崩溃信息，所以breakpad会自己生成好这些信息，然后请求生成dump。
这里值得一说的是，在非异常崩溃处理中，breakpad获取线程现场使用的函数是RtlCaptureContext而不是GetThreadContext。
RtlCaptureContext只能捕获当前线程的现场，而GetThreadContext可以捕获任意线程的现场，只要有这个线程的句柄即可。
但是GetThreadContext有两个不好的地方：不能获取当前线程的现场；获取现场前必须先用SuspendThread暂停目标线程。
而RtlCaptureContext虽然只能获取当前线程的现场，但是调用他时可以不用暂停线程的运行。
对于breakpad来说，崩溃发生后越早获取现场就越好，所以breakpad使用RtlCaptureContext函数作为他的线程获取函数。

breakpad中的C/S结构

由于breakpad是在进程外抓取dump，所以breakpad需要实现一个C/S结构来处理崩溃进程抓取dump的请求。

1. breakpad跨进程通信的实现
breakpad中使用了命名管道来实现IPC。

在客户端，初始化ExceptionHandler的时候，如果指定了PipeName，也就表示此时需要使用进程外的dump抓取，ExceptionHandler，会建立一个 CrashGenerationClient的对象，由这个对象连接服务端，将自己注册到服务端上去。
大家可以参看exception_handler.cc中的ExceptionHandler::Initialize函数。

在服务端，初始化CrashGenerationServer的时候，就会建立一个命名管道，并等待客户端来连接。一旦有客户端连接上来，服务端会为每一个客户端生成一个ClientInfo的对象，之后用这个对象来管理所有的客户端，一旦有崩溃发生，服务端都会从这个对象中取出dump所需要的信息。
大家可以参看crash_generation_server.cc中的CrashGenerationServer::HandleReadDoneState函数。

2. breakpad捕获崩溃生成dump的流程
breakpad进程外生成dump的流程大概如下：
google-breakpad-out-of-process-dump:

这段流程的代码就是crash_generation_client.cc和crash_generation_server.cc。

有两个简单的问题，这里说明一下，高手们就请直接忽略吧，咩哈哈：
在服务端如何为客户端生成事件句柄？
使用DuplicateHandle，即可把任意一个内核对象的句柄复制到其他进程，并且可以指定产生的句柄的权限。

如何异步的等待一个事件？
使用RegisterWaitForSingleObject，即可异步的等待一个事件，当事件发生的时候，就可以回调到一个指定的回调函数中，但是要注意的是，RegisterWaitForSingleObject会在一个新的线程中来等待这个事件，此处很容易产生多线程的调用，需要注意线程问题。

3. 服务端关键数据结构：ClientInfo
ClientInfo是服务端中最重要的数据结构，服务端通过它来管理所有的客户端。客户端注册时，会保存或生成里面所有的信息，在客户端请求生成dump的时候，服务端就会通过ClientInfo获取所有客户端的信息。ClientInfo中保存了如下信息：

客户端进程pid和句柄
生成Minidump的类型
自定义的客户端信息
客户端崩溃的线程ID
客户端崩溃的信息
客户端请求崩溃所使用的事件句柄

这里有一个问题：在客户端发生崩溃时，服务器如何通过ClientInfo获取到客户端的崩溃信息呢？

客户端中有几个用于保存崩溃信息的变量，在注册时，客户端会将这几个变量的地址发送至服务端，服务端将其保存在ClientInfo中，然后当崩溃发生的时候，服务端就可以通过ReadProcessMemory读取客户端中的信息，从而生成dump。这样做就避免了每次发生崩溃，都要通过Pipe 将崩溃信息传递到服务端中去了。

这些变量分别是：崩溃的线程ID，EXCEPTION_POINTERS和MDRawAssertionInfo。
EXCEPTION_POINTERS和MDRawAssertionInfo的区别在于，异常崩溃的信息会被写入EXCEPTION_POINTERS，非异常崩溃（非法参数和纯虚函数调用）的信息会被写入MDRawAssertionInfo中。

dump文件的上传

在breakpad的工程中，有一个工程叫做：crash_report_sender，里面是一个上传崩溃文件的类，他的实现很简单，他使用Windows Internet Api来完成dump文件的上传。
在使用crash_report_sender时，可以为其指定一个checkpoint_file。

1	`explicit` `CrashReportSender(const` `wstring &checkpoint_file);`

这个文件只有一个作用，就是用来保存上次上传崩溃的时间和今天上传过的崩溃的次数。通过这个文件，我们就可以来设置每日上传的崩溃的最大数量。

CrashReportSender::CrashReportSender(const wstring &checkpoint_file)

: checkpoint_file_(checkpoint_file),

max_reports_per_day_(-1),

last_sent_date_(-1),

reports_sent_(0) {

FILE *fd;

if (OpenCheckpointFile(L"r", &fd) == 0) {

ReadCheckpoint(fd);

fclose(fd);

}

ReportResult CrashReportSender::SendCrashReport(

const wstring &url, const map ¶meters,

const wstring &dump_file_name, wstring *report_code) {

int today = GetCurrentDate();

if (today == last_sent_date_ &&

max_reports_per_day_ != -1 &&

reports_sent_ >= max_reports_per_day_) {

return RESULT_THROTTLED;

}

// 上传文件部分代码，省略

}

调整每日上传崩溃的最大数量的函数是set_max_reports_per_day。

需要注意的是：在上传dump文件的时候，crash_report_sender并不会对dump文件进行分析，而是直接上传整个dump文件，如果你需要上传的dump文件非常大的话，可以考虑把崩溃分析处理的逻辑放入前台，通过去重或者直接上传分析结果，减少上传的文件大小。

breakpad存在的问题

进程外生成dump有很多好处，其中最大的好处就是不会被崩溃进程影响，这样dump的过程就不容易出错，但是这样也有一定的弊端。

1. 部分崩溃无法抓取
在一些极端的崩溃，如堆栈溢出之类的崩溃，进程外抓取dump有时候会失败。

2. 无法抓取死锁或者其他原因导致的进程僵死
breakpad现在没有检测进程死锁的代码，也没有在服务端控制客户端请求dump的代码，所以现在breakpad无法抓取死锁等进程僵死的问题。不过因为breakpad的定位是处理崩溃，如果有这种需要的童鞋，可以自行修改breakpad的代码，添加这些功能。

3. 对服务端有依赖
如果指定了在使用进程外抓取dump，breakpad对服务端就有依赖。主要体现在抓取dump时，如果服务端不存在，客户端将无法正常抓取dump，甚至有时会出现阻塞。

当然对于这些问题，随着breakpad的发展肯定会越来越完善。如果，你遇到了了这些问题，而又绕过不了，那就改代码，并且提交给breakpad吧，开源项目就是这么发展的。

好，到此breakpad的Windows实现就已经说完了，如果有神马问题，还请多多指教。谢谢大家。

北京德胜门中医院 http://www.0531jsk.com/德胜门中医院

RTY 2011-11-07 21:36 发表评论

Google Breakpad 完全解析（一） —— Windows入门篇

RTY — Mon, 07 Nov 2011 13:34:00 GMT

Google Breakpad 完全解析（一） —— Windows入门篇

2011年01月23日 — Asp J

Table of contents for Google Breakpad 完全解析

Google Breakpad 完全解析（一） —— Windows入门篇
Google Breakpad 完全解析（二） —— Windows前台实现篇

原创文章，转载请标明出处：Soul Apogee (http://bigasp.com)，谢谢。

Google breakpad是一个非常实用的跨平台的崩溃转储和分析模块，他支持Windows，Linux和Mac和Solaris。由于他本身跨平台，所以很大的减少我们在平台移植时的工作，毕竟崩溃转储，每个平台下都不同，使用起来很难统一，而Google breakpad就帮我们做到了这一点，不管是哪个平台下的崩溃，都能够进行统一的分析。现在很多工程都在使用他：最著名的几个如 Chrome，Firefox，Picasa和Google Earth。另外他的License是BSD的，也就是说，我们即便是在商业软件中使用，也是合法的，哈哈，这么好的东西，我们能放过么？现在就让我们来看看这个神奇的软件吧。

原理简介

breakpad抓取dump的方式和一般我们抓取dump的方式不一样。在breakpad的wiki上有一幅图可以很好的概括他的原理。

breakpad把应用程序分成三个部分，代码，breakpad客户端和调试信息。

1. 在build system中，通过symbol dumper用平台相关的调试信息生成平台无关的symbol文件。这样做的好处很明显，一旦平台无关了，所有平台的崩溃就可以做统一的分析了。
2. breakpad采取进程外转储和分析崩溃的方式，他使用C/S结构，客户端用来捕获当前进程中发生的崩溃，并通知服务端崩溃发生。服务端用来响应客户端，抓取dump文件。这样做的目的是为了减少崩溃进程对dump的影响。
3. Dump生成后转发到崩溃分析器中，这个部分可以在本地也可以在服务器上，他对Dump文件进行解析，生成可读的堆栈信息。

这就是breakpad处理dump大概的流程。

对于原理的介绍google写的已经相当好了。更多的详细信息，可以直接移步到breakpad的wiki。

安装和编译

breakpad的编译比较曲折，所以在此记录一下。

编译breakpad，请确认你的机器上装有以下的软件：
1. python 2.4.3
请不要使用python3，会报错。另外python2中推荐这个版本，使用新的版本在编译其他google的工程时有时会报错

2. Windows SDK 7
如果没有这个，编译会报错。另外这个是在线安装，时间很久，最好并行做其他的事情。

3. VS2005的补丁
KB918559
KB926601
KB935225
KB943969
KB947315

已经安装了以上软件的童鞋，就可以开始进行下面的工作鸟

1. 使用svn把代码checkout下来

1 2	`# Non-members may check out a read-only working copy anonymously over HTTP.` `svn checkout http://google-breakpad.googlecode.com/svn/trunk/` `google-breakpad-read-only`

2. 设置Windows SDK 7
装过其他版本Windows SDK的童鞋，记得一定要进行这一步，SDK的安装程序，并不会帮你设置VS。
运行开始菜单->程序->Microsoft Windows SDK v7.0->Visual Studio Registration->Windows SDK Configuration Tool，选择v7.0，点击Make Current。

3. 为python设置环境变量
由于breakpad使用python来生成Windows下的工程文件，所以需要将python所在目录，设置到环境变量PATH中去。

4. 生成Windows工程文件

cd "源码目录/src/tools/gyp"

# 注意，此处不能使用全路径，不然会出错

gyp.bat "../../client/windows/breakpad_client.gyp"

此时，在src/client/windows下就可以看到生成好的breakpad_client.sln了。运行吧！

5. Hello World!
编译build all，现在一般是不会报错了，如果报错，请检查是不是漏了什么步骤，特别是补丁。
编译完成之后，运行crash_generation_app吧，这是他的测试程序，dump的默认位置保存在C:Dumps下，请注意先建立好目录，不然会无法使用。
启动测试程序之后，此时还不能抓取dump，因为这个是breakpad中的服务器端，需要再启动一个测试程序，在第二个测试程序中，我们就可以试验Client菜单中的各种崩溃了。这些崩溃都会被抓住转存到C:Dumps目录下。

如何使用breakpad

在Windows下使用breakpad的方法很简单，只需要创建一个ExceptionHandler的类即可，大家可以在crash_generation_app这个工程中找到示例代码，也可以直接移步Wiki，上面说的也很详细。

1.进程内抓取Dump文件

进程内抓取Dump文件是最简单的breakpad的用法。使用方法很简单：

const std::wstring s_strCrashDir = L"c:\dumps";

bool

InitBreakpad()

{

google_breakpad::ExceptionHandler *pCrashHandler =

new google_breakpad::ExceptionHandler(s_strCrashDir,

onExceptionFilter,

onMinidumpDumped,

NULL,

google_breakpad::ExceptionHandler::HANDLER_ALL,

MiniDumpNormal,

NULL,

NULL);

if(pCrashHandler == NULL) {

return false;

}

return true;

}

2.进程外抓取Dump文件

使用进程外抓取Dump时，需要指定服务端和客户端，在服务端中需要创建CrashGenerationServer的实例，而在客户端中则只需要创建ExceptionHandler即可。此外，如果服务端自己需要抓进程内的Dump，请将pipe的参数置为NULL。

const wchar_t s_pPipeName[] = L"\\.\pipe\breakpad\crash_handler_server";

const std::wstring s_strCrashDir = L"c:\dumps";

bool

InitBreakpad()

{

google_breakpad::CrashGenerationServer *pCrashServer =

new google_breakpad::CrashGenerationServer(s_pPipeName,

NULL,

onClientConnected,

NULL,

onClientDumpRequest,

NULL,

onClientExited,

NULL,

true,

&s_strCrashDir);

if(pCrashServer == NULL) {

return false;

}

// 如果已经服务端已经启动了，此处启动会失败

if(!pCrashServer->Start()) {

delete pCrashServer;

pCrashServer = NULL;

}

google_breakpad::ExceptionHandler *pCrashHandler =

new google_breakpad::ExceptionHandler(s_strCrashDir,

onExceptionFilter,

onMinidumpDumped,

NULL,

google_breakpad::ExceptionHandler::HANDLER_ALL,

MiniDumpNormal,

(pCrashServer == NULL) ? s_pPipeName : NULL, // 如果是服务端，则直接使用进程内dump

NULL);

if(pCrashHandler == NULL) {

return false;

}

return true;

}

使用breakpad的时候，有两个地方需要注意：
1. 记得把breakpad的solution下的几个工程，包含到你开发的工程中，或者直接包含他们的lib。
common：基础功能，包含一个对GUID的封装和http上传的类。
exception_handler：用来捕获崩溃的类。
crash_generation_server：breakpad的服务端，用来在产生崩溃时抓取dump。
crash_generation_client：breakpad的客户端，用来捕获当前进程的崩溃。

2. 在初始化breakpad之前，记得先创建好dump文件的目录，不然breakpad服务端将不能正常的写dump，这会导致breakpad客户端在崩溃时无限等待服务端dump写完的消息，最后失去响应。

RTY 2011-11-07 21:34 发表评论

调试Release发布版程序的Crash错误（转）

RTY — Mon, 07 Nov 2011 13:15:00 GMT

调试Release发布版程序的Crash错误（转）

调试Release发布版程序的Crash错误

http://blog.sina.com.cn/s/blog_48f93b530100fsln.html

在Windows平台下用C++开发应用程序，最不想见到的情况恐怕就是程序崩溃，而要想解决引起问题的bug，最困难的应该就是调试release版本了。因为release版本来就少了很多调试信息，更何况一般都是发布出去由用户使用，crash的现场很难保留和重现。本文将给出几个解决方案，完成对release版应用程序crash错误的调试。（本文只讨论Windows平台MSVC环境下的调试，对于其他平台和开发环境没有关注，请大家自己借鉴和尝试。）

方案一：崩溃地址 + MAP文件

这种方案只能对VC7以前的版本开发的程序使用。

1、崩溃地址

所谓崩溃地址就是引起程序崩溃的内存地址，在WinXP下应用程序crash的对话框如下图：

上面第2张图中画红线的值为crash的代码偏移地址，第3张图为即crash绝对地址；一般引起crash的原因多为内存操作错误，我们用这两个地址和MAP文件就能定位出错的代码行。

2、MAP文件

MAP文件是记录应用程序信息的文件（文本文件），里面大概包含了程序的全局符号、源码模块名、源码文件和行号等信息，而这些信息能够帮助我们定位出错的代码行。

怎样生成MAP文件呢？以VC6为例，在 Project Settings -> C/C++ -> Debug info中，选择 Line Numbers Only ；在 Project Settings -> Link 中，选择 Generate mapfile项，并在Project Options 里面输入 /MAPINFO:LINES 和 /MAPINFO:EXPORTS，重新编译程序就会生成.map文件。

以上设置对应的编译链接选项分别分：

/Zi — 表示生成pdb调试信息；

/MAP[:filename] — 表示生成map文件名；

/MAPINFO:EXPORTS — 表示生成的map文件中加入exported functions（生成DLL文件时）；

/MAPINFO:LINES — 表示生成的map文件中加入代码行信息。

由于/MAPINFO:LINES选项在VC8以后的版本中不再支持，因此通过MAP文件中的信息和crash地址定位出错代码行就比较困难了，所以这种方案只能在VC7及以前的版本中使用。

一个MAP文件片段示例如下：

图中Rva+Base列的地址为该行函数对应的函数绝对地址，Address列中冒号后面的地址为函数相对偏移地址。

3、定位crash代码

有了上面的介绍，定位crash代码就很简单了。用下面的公式来进行定位：

崩溃行偏移 = 崩溃地址 - 崩溃函数绝对地址 + 函数相对偏移

我们首先根据崩溃地址（绝对地址），按照找到第2张图中Rva+Base列的地址找到发生崩溃的函数（即崩溃地址大于该函数行的Rva+Base地址且小于下个函数的地址），然后找到该行对应的函数相对偏移地址，带入公式中，就得到了崩溃行偏移，该值表示崩溃行的代码相对于代码所在函数的偏移量。用该值去与第3张图中对应函数冒号后面的偏移量去比较，最接近的值前面的那个十进制数即为代码所在函数中的行号。

ok，到此我们已经成功找到了崩溃的代码行，只不过这种方法还是比较费力，并且限制比较多，我们看看下面的方案。

上篇给出的方案一还要补充几句。通过“crash地址 + MAP文件”来定位出错代码位置虽然需要经过比较复杂的地址计算，但却是最简单实现的方式。如果仅仅想通过崩溃地址定位出错的函数，就更加方便了。我在网上找到一个解析MAP文件的小工具，可以非常清晰的列出每个函数的地址，并且可以将分析表格导出为Excel文件。工具下载地址：http://e.ys168.com/?tinyfun，工具目录下VCMapper.exe。

另外上篇主要参考两篇文章：

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

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

方案二：崩溃地址 + MAP文件 + COD文件

由于VC8以后的版本都不再支持MAP文件中产生代码行信息，因此我们寻找另一种定位方式：COD文件。

1、COD文件

COD文件是一个包含了汇编码、二进制机器码和源代码对应信息的文件，每一个cpp都对应一个COD文件。通过这个文件，我们可以非常方便地进行定位。

在VC6中生成COD文件的设置方式为：Project Settings -> C/C++，在 Category 中选 Listing Files，在 Listing file type 组合框中选 Assembly，Machine code，and source。在VC8中生成COD文件的设置方式为：Project Properties -> C/C++ -> Output Files -> Assembler Output 项，选择 Assembly，Machine code，and Source(/Facs)。

2、定位崩溃行

下面通过举例进行说明。现在我有一个基于对话框的MFC应用程序CrashTest，在CCrashTestDlg::OnInitDialog函数中写入导致crash的代码语句（第99行），源文件如下：

根据崩溃地址（0x004012A3）以及MAP文件（定位片段图片如下），定位crash函数为OnInitDialog；并且我们可以很容易地计算出崩溃地址相对于崩溃函数的偏移量为 0x004012A3 - 0x004011E0 = 0xC3。

再来看看CrashTestDlg.cod文件，我们根据文件中源码信息找到OnInitDialog函数信息片段：

可以看到图片中第一行为OnInitDialog函数汇编代码的起始行；找到“int * p = NULL;”这一句源码，其前面的98表示这行代码在源文件中的行号，下面的000c1表示相对于函数开始位置的偏移量，后面的“33 c0”为机器码，“xor eax，eax”为汇编码。那么我们根据前面算出来的偏移量0xC3，找到对应出错的语句为99行：“*p = 5;”。

总结一下定位步骤：

1) 根据公式 崩溃语句在函数中偏移地址 = 崩溃地址 - 崩溃函数地址 计算出偏移量X；

2) 根据公式 崩溃语句在COD文件中地址 = 崩溃函数在COD文件中地址 + X 计算出地址Y。其中崩溃函数在COD文件中地址为COD文件中函数起始括号“{”后面表明的地址，一般情况下为0x0000；

3) 根据Y在COD文件中找到对应代码行。

ok，方案二介绍完了。这种方法最大的好处是没有VC开发环境版本限制，而且COD文件里面包含的信息更加丰富，不但可以帮助我们定位crash，还能帮我们分析很多东西。当然，这也导致编译生成了很多信息文件。

根据前面两篇博文，我们要定位崩溃行代码，必须要自己根据相关信息文件进行计算。如果需要处理的量比较大，恐怕会很费力气。有没有更简单快速的办法呢？

最直接的想法就是写一个小工具，根据规则和信息进行自动定位，不过开发起来也是要费一番功夫的。令人开心的是，我们可以找到类似的工具，而且是开源免费的！程序员的世界也许很多时候都是这么单纯而乐于分享！

方案三：崩溃地址 + PDB文件 + CrashFinder

CrashFinder是一个开源工具，作者是John Robbin，大家可以去他的blog上去找关于CrashFinder的信息。我们这里以CrashFinder2.5版本为例介绍，相关文章链接为：http://www.wintellect.com/CS/blogs/jrobbins/archive/2006/04/19/crashfinder-returns.aspx

1、PDB文件

PDB（Program Database）文件中包含了exe程序所有的调试相关信息，具体可以查阅MSDN。当编译选项设置为/Zi，链接选项设置为/DEBUG，/OPT:REF时，就会生成工程的.pdb文件。具体到VC2005中，就是 Project Propertise -> C/C++ -> General -> Debug Information Format 项设置为 Program Database（/Zi），Linker -> Debugging -> Generate Debug Info 项设置为 Yes（/Debug），Linker -> Optimization -> References 项设置为 Eliminate Unreferenced Data（/OPT:REF）。

只要设置以上选项，release版本也能生成PDB文件。当然，对应的应用程序也会稍大。

2、CrashFinder

CrashFinder能够运行需要两个条件：一是系统必须要有dbghelp.dll文件；二是PDB文件必须与exe文件在一个路径下。对于dbghelp.dll，一般在系统system32路径下都有，如果没有下载一个放到这个目录下就可以了。

先看一下CrashFinder的界面。

用起来也非常简单。首先选择File->New或点击工具栏新建按钮，选择要调试的exe文件打开，会发现exe及所依赖的dll文件信息都已经加载进来。在下半部分的编辑框中输入崩溃地址（16进制），点右边的“Find”按钮，就会在下面显示崩溃的源文件路径、名称以及崩溃所在行号了，如下图所示。

用CrashFinder进行crash定位真的非常方便。但是我在使用过程中发现了一个bug，每次启动程序后，直接新建的话加载进来的exe模块都显示叉，提示找不到debug symbols。但是用打开按钮随便打开一个文件失败后，再新建就能成功。猜测可能是直接新建，定位PDB文件时的路径不对引起的。有源码，但是懒的看了呵呵，大家感兴趣可以试一下。

好了，方案三就介绍到这里，后面还有更加强大的方案 : )

前面几个方案都是直接定位crash的代码位置，但是在比较大型的程序中，只知道这个信息还是远远不够的，我们希望知道更多关于调用函数顺序及变量值等信息，也就是crash时调用堆栈信息。

方案四：SetUnhandledExceptionFilter + StackWalker

这个方案需要自己动手往工程里添加代码了。要实现上面的想法，需要做两件事情：1、需要在crash时有机会对程序堆栈进行处理；2、对堆栈信息进行收集。

1、SetUnhandleExceptionFilter函数

Windows平台下的C++程序异常通常可分为两种：结构化异常（Structured Exception，可以理解为与操作系统相关的异常）和C++异常。对于结构化异常处理（SEH），可以找到很多资料，在此不细说。对于crash错误，一般由未被正常捕获的异常引起，Windows操作系统提供了一个API函数可以在程序crash之前有机会处理这些异常，就是SetUnhandleExceptionFilter函数。（C++也有一个类似函数set_terminate可以处理未被捕获的C++异常。）

SetUnhandleExceptionFilter函数声明如下：

    LPTOP_LEVEL_EXCEPTION_FILTER WINAPI SetUnhandledExceptionFilter(
      __in          LPTOP_LEVEL_EXCEPTION_FILTER lpTopLevelExceptionFilter
    );

其中 LPTOP_LEVEL_EXCEPTION_FILTER 定义如下：

    typedef LONG (WINAPI *PTOP_LEVEL_EXCEPTION_FILTER)(
        __in struct _EXCEPTION_POINTERS *ExceptionInfo
    );
    typedef PTOP_LEVEL_EXCEPTION_FILTER LPTOP_LEVEL_EXCEPTION_FILTER;

简单来说，SetUnhandleExceptionFilter允许我们设置一个自己的函数作为全局SEH过滤函数，当程序crash前会调用我们的函数进行处理。我们可以利用的是 _EXCEPTION_POINTERS 结构类型的变量ExceptionInfo，它包含了对异常的描述以及发生异常的线程状态，过滤函数可以通过返回不同的值来让系统继续运行或退出应用程序。

关于 SetUnhandleExceptionFilter 函数的具体用法和示例请参考MSDN。

2、StackWalker
现在我们已经有机会可以在crash之前对程序状态信息进行处理了，只需要生成并保存堆栈信息就大功告成了。Windows的dbghelp.dll库提供了一个函数可以得到当前堆栈信息：StackWalk64（在Win2K以前版本中为StackWalk）。该函数声明如下：

    BOOL WINAPI StackWalk64(
      __in          DWORD MachineType,
      __in          HANDLE hProcess,
      __in          HANDLE hThread,
      __in_out      LPSTACKFRAME64 StackFrame,
      __in_out      PVOID ContextRecord,
      __in          PREAD_PROCESS_MEMORY_ROUTINE64 ReadMemoryRoutine,
      __in          PFUNCTION_TABLE_ACCESS_ROUTINE64 FunctionTableAccessRoutine,
      __in          PGET_MODULE_BASE_ROUTINE64 GetModuleBaseRoutine,
      __in          PTRANSLATE_ADDRESS_ROUTINE64 TranslateAddress
    );
    该函数的具体用法可以参考MSDN。在这里推荐一个牛人写好的StackWalker，可以直接拿来用，开源的。StackWalker提供了一个基类，给出了几个简单的接口，可以方便地生成堆栈信息，并且支持一系列VC版本，非常好用。我们可以自己写一个子类，并重载虚函数OnOutput，就可以将堆栈信息输出为特定格式了。StackWalker的地址为：http://www.codeproject.com/KB/threads/StackWalker.aspx。

不过对于Release版本来说，StackWalk64函数获得的堆栈信息有可能不完整。如果异常是由MFC的模块抛出，那么获得的堆栈可能缺少前面调用模块信息。另外，StackWalk64需要最新的dbghelp.dll文件支持才能工作；要正确输出crash的函数名和行号，需要要pdb文件支持。以上不足有可能影响输出信息的完整性和效果，而对于发布在外的程序，要带上pdb文件几乎不可能，因此这个方案还是有缺憾的，比较适用于本地的release版本调试。

下一篇我们将介绍一个更加完善的解决方案

当我们把自己的release版本程序发布出去以后，一般都是在用户的机器上运行。这种情况下，对于第四种方案，因为需要pdb文件才能够正确生成堆栈调用的函数行号及代码行号，因此方案四只适用于本地release版的调试，否则只能生成不完整的堆栈信息。对于前三种方案，其实只需要用户告知崩溃地址，然后在本地查找crash地址就可以了，但是定位crash的过程非常不方便，如果crash的情况比较多，前三种方案都不合适。而且，前三种方案均不能生成堆栈调用信息，对于debug的作用有限。

下面我们就来看一个更加完善的解决方案。

方案五：SetUnhandledExceptionFilter + Minidump

SetUnhandleExceptionFilter函数我们已经介绍过了，本方案的思路还是要利用我们自己的异常处理函数，来生成minidump文件。

1、Minidump概念

minidump（小存储器转储）可以理解为一个dump文件，里面记录了能够帮助调试crash的最小有用信息。实际上，如果你在系统属性 -> 高级 -> 启动和故障恢复 -> 设置 -> 写入调试信息中选择“小内存转储(64 KB)”的话，当系统意外停止时都会在C:\Windows\Minidump\路径下生成一个.dmp后缀的文件，这个文件就是minidump文件，只不过这个是内核态的minidump。

我们要生成的是用户态的minidump，文件中包含了程序运行的模块信息、线程信息、堆栈调用信息等。而且为了符合其mini的特性，dump文件是压缩过的。

2、生成minidump文件

生成minidump文件的API函数是MiniDumpWriteDump，该函数需要dbghelp.lib支持，其原型如下:

    BOOL WINAPI MiniDumpWriteDump(
      __in          HANDLE hProcess,
      __in          DWORD ProcessId,
      __in          HANDLE hFile,
      __in          MINIDUMP_TYPE DumpType,
      __in          PMINIDUMP_EXCEPTION_INFORMATION ExceptionParam,
      __in          PMINIDUMP_USER_STREAM_INFORMATION UserStreamParam,
      __in          PMINIDUMP_CALLBACK_INFORMATION CallbackParam
    );

在我们的异常处理函数中加入以下代码：

    HANDLE hFile = ::CreateFile( _T("E:\\dumpfile.dmp"), GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
     if( hFile != INVALID_HANDLE_VALUE)
     {
         MINIDUMP_EXCEPTION_INFORMATION einfo;
         einfo.ThreadId = ::GetCurrentThreadId();
         einfo.ExceptionPointers = pExInfo;
         einfo.ClientPointers = FALSE;

        ::MiniDumpWriteDump(::GetCurrentProcess(), ::GetCurrentProcessId(), hFile, MiniDumpNormal, &einfo, NULL, NULL);
        ::CloseHandle(hFile);
     }

其中，pExInfo变量为异常处理函数PEXCEPTION_POINTERS类型的参数。具体请参考MSDN。

3、调试minidump

调试dump文件首先需要pdb文件，因此我们build程序时需要设置 Debug Infomation Format 为 “Program Database（/Zi）”。其次，我们还要确保所用的dump文件与源代码、exe、pdb文件版本是一致的，这要求我们必须维护好程序版本信息。

调试minidump最方便的环境就是VS了，我们只要将.dmp、.exe、.pdb文件放在一个路径下，保证源代码文件的路径与编译时的路径一致就可以了，剩下的就是VS帮我们完成。双击.dmp文件或者在文件打开工程中选择“dump files”，加载dump文件，然后按F5运行就能直接恢复crash时的现场了，你可以定位crash的代码，可以查看调用堆栈，可以查看线程和模块信息...一切都跟你设置断点调试一样，太强大了！看个截图吧。

需要注意的是，对于release版的程序来说，很多代码是经过编译器优化过的，因此定位的时候可能会有所偏差，大家可以考虑设置选项去掉代码优化。

其他可以调试minidump的工具还有WinDbg等，大家可以查阅相关资料。

本文主要参考了这篇文章：http://vicchina.51.net/research/other/seh/minidumps/intro.htm。

下一篇，我们将给出一个调试release发布程序的完美解决方案，适合用户量较大的应用发布程序的调试。

上一篇我们已经给出了方案，能够非常方便的通过dump文件对crash错误进行调试和定位；从整个流程上看还差最后一步，即怎样拿到crash时产生的dump文件。如果可以让用户把文件发送过来自然不错，但对于类似免费共享软件等在互联网上发布的程序呢？我们的用户是不确定的，而且用户量有可能非常大，即使我们能想办法联系到用户，总不能挨个去收集crash信息吧。

我们需要一种方案，能够提供crash信息汇报功能。

我们可以架设一台服务器专门进行信息收集，只要客户端在crash时正确汇报即可，但是相应的维护成本和开发难度也不可忽视。有没有更简单的方法呢？还记得我的博文“为程序添加自动发送Email功能”吗？这就是简单有效的方法！

方案六：minidump + email

我们只需要在异常处理时，先生成minidump信息文件，再用email方式将文件发送到指定邮箱就行了。剩下的就是我们每天查看邮箱，提取dump文件进行调试了。

1、Email功能

首先我们来看一下email发送都需要哪些相关信息。

a、发送端邮箱帐户；

b、接收端邮箱帐户；

c、email标题，一般应有软件名称及版本信息；

d、email正文，一般应有简单的crash信息提示，以区别不同原因造成的crash；

e、email附件，当然就是我们的dump文件了，还可以加上软件生成的log文件等。

当然，对于标题应该尽量多加一些信息区别引起crash的原因，比如将crash的地址信息加到标题中；因为当每天有成百上千的crash汇报上来，重复的crash占大多数，把时间都花在区分它们身上有点太浪费。由此看来，前面方案中提到的StackWalker还是有些用处的，我们可以用它来生成一些crash的文字描述信息，写到标题或正文中去。

dump文件的大小是否适合作为邮件的附件呢？实际上minidump产生的文件一般在几K到几十K之间，作为email的附件没有任何问题。

关于发送email相关技术细节，已经在“为程序添加自动发送Email功能”文中介绍了，大家可以参考。其实，对接受邮箱中邮件的处理还是很费时费力的，大家可以考虑写一些脚本将处理流程自动化，提高效率。

2、google breakpad

google breakpad是一个开源的跨平台crash report系统，光从开源和跨平台这两个特点上来看，它就足以称的上是一个完善而有效的工具了。其实，breakpad在整个crash report层次上给出了一个系统级的解决方案，也就是说它几乎能适应各种软件、各种平台的应用要求。

breakpad的整体思路跟上面介绍的方案是相似的，只不过最后提交dump文件的方式更加完善。大家有兴趣可以去它的官方网址查阅相关资料：http://code.google.com/p/google-breakpad/。

ok，关于调试release发布程序的crash错误系列文章就写完了。这几篇文章给出的方案由简单到复杂，由简陋到完善，对crash调试有了一个比较全面的总结。当然，其中涉及到的概念和技术还很多，需要我们去不断学习和领悟，也希望大家能够互相交流。

RTY 2011-11-07 21:15 发表评论

Google Test Primer ：开始使用Google C++ 测试框架

RTY — Fri, 16 Sep 2011 13:59:00 GMT

摘要: http://ray-leex.iteye.com/blog/212024Google C++ Testing Framework Primer 翻译：Ray Li (ray.leex@gmail.com) 修改日期：2008年7月6日原文参见：http://code.google.com/p/googletest/wiki/GoogleTestPrimer ... 阅读全文

RTY 2011-09-16 21:59 发表评论

VC编译Swig例子注意

RTY — Fri, 02 Sep 2011 15:58:00 GMT

使用VC编译程序示例源码的时候，碰到一些变量，这些变量需要说明一下。

$(PYTHON_INCLUDE)

$(PYTHON_LIB)

一般，在WIndows或者Linux上设置PYTHON_INCLUDE、PYTHON_LIB的变量就可以。如Windows的环境变量设置

PYTHON_INCLUDE=C:\Python27\include

PYTHON_LIB=C:\Python27\libs\python27.lib

RTY 2011-09-02 23:58 发表评论

从dll文件或者def文件生成lib文件

RTY — Wed, 17 Aug 2011 16:02:00 GMT

http://www.cnblogs.com/mxly/archive/2011/04/01/2002438.html

1、dll导出def文件。使用vs2005开发工具中自带的命令dumpbin，如下图所示

具体命令如下

这样就能在指定目录生成def文件了

2、def文件生成lib文件。使用vs2005开发工具中自带的命令lib，如下图所示

具体命令如下

这样就能在指定目录生成lib文件了

RTY 2011-08-18 00:02 发表评论

VC调试器高级应用----高级断点篇

RTY — Fri, 12 Aug 2011 15:37:00 GMT

VC调试器高级应用----高级断点篇

一.高级断点语法

高级断点语法由两部分组成:1.上下文部分.2.位置,表达式,变量或Windows消息条件.

用函数,源文件和二进制模块来指定上下文,上下文的表示方法:

{[函数],[源文件],[二进制模块]}

必须指定唯一的,足够的上下文信息才能获取断点位置.如在TEST.CPP的20行设一位置断点,语法为:{,TEST.CPP,}.20,如A.DLL或B.DLL都使用了该行,又只想在B.DLL的调用中触发,则必须使用:{,TEST.CPP,B.DLL}.20.

VC调试器中可直接输入上下文语法:Breakpoints对话框的Location选项卡BreakAt编辑框中.更容易的方法是使用BreatAt框右的箭头打开菜单,选择Advanced项,然后在Context框中输入断点的相应信息.

如想在一个绝对地址上中断,直接在BreakAt框中输入地址就行.

二.任何函数上快速中断

将函数名输入BreadAt框中.如果是C++代码,同时还需要类限定符.支持重载了的函数,调试器会列出所有满足条件的函数供选择,如输入时提供足够的信息,完全可略过选择过程.如输入:"CString::operator=(const char *)"可唯一确定要中断的函数.

三.在系统或DLL输出的函数中设置断点

在程序中从DLL输入的函数中设置一个断点可能是毫无作用的,调试器需要知道在何处可以找到该函数上下文信息,同时,函数名取决于是否加载了DLL的符号.只有在W2K以上版本中才能在系统DLL中设置断点--原因在于其它系统没有提供边写入边复制保护的功能,若一定要启用这种方法,必须要有COFF(Common Object File Format),并在调试器中输出启动的装载----在Options对话框的Debug页,将Load COFF & Exports选中.

VC调试器用分级的符号信息法,完整的符号的级别高于不太完整的.PDB(Program Database)文件具有所有可能的源码行,函数,变量和类型信息,优先级便高于COFF/DBG文件,后者只有公用函数符号,而COFF/DBG文件高于输出名称,输入的名称是一种伪符号.
调试时,如DEBUG窗口输出:装载DLL的符号,则说明符号已被装入;否则说明没有装载DLL的符号.

没有装入符号时,使用的位置字符串是DLL输出的名称,可能用DUMPBIN程序查看这个名称:DUMPBIN /EXPORTS DLLname.例:在LoadLibraryA中设置中断:"{,,Kernel32.dll}LoadLibraryA".

如装入了符号,则要根据输出函数和调用协议来计算函数名.如上例,LoadLibraryA使用__stdcall调用协议,据该协议,函数名以下划线为前缀,所跟有进栈的字节数为后缀的@号.一般说来,参数个数*4,就是参数占用栈空间的总字节数,LoadLibary的名称便是:_LoadLibraryA@4,故最后的语法是:或"{,,Kernel32.dll}_LoadLibraryA@4"

附:常用的调用协议

1、__stdcall调用约定相当于16位动态库中经常使用的PASCAL调用约定。在32位的VC++5.0中PASCAL调用约定不再被支持（实际上它已被定义为__stdcall。除了__pascal外，__fortran和__syscall也不被支持），取而代之的是__stdcall调用约定。两者实质上是一致的，即函数的参数自右向左通过栈传递，被调用的函数在返回前清理传送参数的内存栈，但不同的是函数名的修饰部分（关于函数名的修饰部分在后面将详细说明）。

_stdcall是Pascal程序的缺省调用方式，通常用于Win32 Api中，函数采用从右到左的压栈方式，自己在退出时清空堆栈。VC将函数编译后会在函数名前面加上下划线前缀，在函数名后加上"@"和参数的字节数。

2、C调用约定（即用__cdecl关键字说明）按从右至左的顺序压参数入栈，由调用者把参数弹出栈。对于传送参数的内存栈是由调用者来维护的（正因为如此，实现可变参数的函数只能使用该调用约定）。另外，在函数名修饰约定方面也有所不同。

_cdecl是C和C＋＋程序的缺省调用方式。每一个调用它的函数都包含清空堆栈的代码，所以产生的可执行文件大小会比调用_stdcall函数的大。函数采用从右到左的压栈方式。VC将函数编译后会在函数名前面加上下划线前缀。是MFC缺省调用约定。

3、__fastcall调用约定是“人”如其名，它的主要特点就是快，因为它是通过寄存器来传送参数的（实际上，它用ECX和EDX传送前两个双字（DWORD）或更小的参数，剩下的参数仍旧自右向左压栈传送，被调用的函数在返回前清理传送参数的内存栈），在函数名修饰约定方面，它和前两者均不同。

_fastcall方式的函数采用寄存器传递参数，VC将函数编译后会在函数名前面加上"@"前缀，在函数名后加上"@"和参数的字节数。

4、thiscall仅仅应用于“C++”成员函数。this指针存放于CX寄存器，参数从右到左压。thiscall不是关键词，因此不能被程序员指定。

5、naked call采用1-4的调用约定时，如果必要的话，进入函数时编译器会产生代码来保存ESI，EDI，EBX，EBP寄存器，退出函数时则产生代码恢复这些寄存器的内容。naked call不产生这样的代码。naked call不是类型修饰符，故必须和_declspec共同使用。

关键字 __stdcall、__cdecl和__fastcall可以直接加在要输出的函数前，也可以在编译环境的Setting...C/C++ Code Generation项选择。当加在输出函数前的关键字与编译环境中的选择不同时，直接加在输出函数前的关键字有效。它们对应的命令行参数分别为/Gz、/Gd和/Gr。缺省状态为/Gd，即__cdecl。

要完全模仿PASCAL调用约定首先必须使用__stdcall调用约定，至于函数名修饰约定，可以通过其它方法模仿。还有一个值得一提的是WINAPI宏，Windows.h支持该宏，它可以将出函数翻译成适当的调用约定，在WIN32中，它被定义为__stdcall。使用WINAPI宏可以创建自己的APIs。

四.位置断点修饰符

1.跳跃计数.

功能是执行断点但不在断点处停止,直到执行完了一个特定的次数为止.

使用中首先设置一个标准的位置断点,打开BreadPoint对话框,选中该断点,单击Condition,然后在弹出的对话框最下面的编辑控件中输入次数.

只有当程序全速运行时,未执行的循环次数才有用.单步执行跨过断点时不会更新跳跃计数.

例:已知循环可能崩溃,但不清楚在哪次循环时,输入远远大于总循环次数的跳跃计数修饰符,则在崩溃时可打开Breakpoint框,其中将列出还未执行的循环次数,与总次数相减就可得已执行的次数.

2.条件表达式.

只有表达式为真时触发.Breakpoint框Condition按钮,选第一个编辑框,输入表达式即可.规则:

.只可使用C类型比较运算符.
.表达式中不能调用任何函数.
.表达式中不能包含任何宏值.

表达式为@TIB=Thread Infomation Block Linear Address,则程序只在该特定线程中才会中断.例:线程@TIB地址值为0E000,则输入"@TIB==0xE000",则在切换到该线程时中断.对W98,可用@FS=thread specific value.

如在某特定错误后中断,则可用@ERR,如"@ERR=2"表示在最后错误为ERROR_FILE_NOT_FOUND.除@CLK外,所有可在WATCH窗口中使用的伪寄存器均可用于条件表达式.

条件表达式可与跳跃断点组合使用.

3.变量更改

在变量更改时中断程序.只有当位置断点执行时才能检查变量.常用用调用栈高层的函数中发现出错,需要深入调用栈,压缩范围找出根源时.

添加时在Breakpoint框第一个编辑框中输入变量名(可以是指针指向听对象:*p),在第二个编辑框中输入要查看的项目数量.

五.全局表达式和条件断点.

调试器可监控某一地址和该地址上的1,2或4字节的内容.如可用硬件调试寄存器,则不影响速度;否则程序将单步执行ASM指令并在每一步中检查条件,这将严重影响程序运行速度.

总共有4个调试寄存器.硬件调试寄存器不能处理超过1个双字长的引用.确保利用硬件调试寄存器的最好方法是使用表达式和数据更改位置的实际地址值.例如:g_szGlobal是全局数组指针,地址为0x5000,则在Breakpoint对话框中DATA选项卡中将表达式断点设为"*(char*))0x5000=='G'",但如果写为"WO(0x5000)=='G',则用不到硬件调试寄存器,会单步执行每条指令.

与全局表达式断点类似,使用变量的16进制地址给定长指针计算地址,并将要查看的单元数设为1,则全局变量断点可发挥最付佳功效.如上例要在变量改动时中断,则输入:"*(long*)0x5000".

六.WINDOWS消息断点.

Breakpoint框的Message页.需要指定一个窗口过程,注意:MFC世界中AfxWndProc是多数窗口的一个窗口过程,所以总会在该断

RTY 2011-08-12 23:37 发表评论

Qt的插件机制

RTY — Tue, 09 Aug 2011 23:34:00 GMT

摘要: http://yanboo.ycool.com/post.2749491.html(来自Qt文档)Qt有两种与插件有关的API。一种用来扩展Qt本身的功能，如自定义数据库驱动，图像格式，文本编解码，自定义分格，等等，称为Higher-Level API。另一种用于应用程序的功能扩展，称为Lower-Level API。前一种是建立在后一种的基础之上的。这里讨论的是后一种，即用来扩展应用程序的Low... 阅读全文

RTY 2011-08-10 07:34 发表评论

C++ const 用法

RTY — Tue, 09 Aug 2011 23:25:00 GMT

http://www.diybl.com/course/3_program/c++/cppjs/20091022/179910.html

1. const修饰普通变量和指针

const修饰变量，一般有两种写法：

const TYPE value;

TYPE const value;

这两种写法在本质上是一样的。它的含义是：const修饰的类型为TYPE的变量value是不可变的。

对于一个非指针的类型TYPE，无论怎么写，都是一个含义，即value只不可变。

例如：

const int nValue； //nValue是const

int const nValue； // nValue是const

但是对于指针类型的TYPE，不同的写法会有不同情况，例如：

A. const char *pContent;

B. char * const pContent;

C. char const *pContent;

D. const char* const pContent;

对于前三种写法，我们可以换个方式，给其加上括号

A. const (char) *pContent;

B. (char*) const pContent;

C. (char) const *pContent;

这样就一目了然。根据对于const修饰非指针变量的规则，很明显，A=C.

- 对于A,C, const修饰的类型为char的变量*pContent为常量，因此，pContent的内容为常量不可变.

- 对于B, 其实还有一种写法： const (char*) pContent;

含义为：const修饰的类型为char*的变量pContent为常量，因此，pContent指针本身为常量不可变.

- 对于D, 其实是A和B的混合体，表示指针本身和指针内容两者皆为常量不可变

总结:

(1) 指针本身是常量不可变

(char*) const pContent;

const (char*) pContent;

(2) 指针所指向的内容是常量不可变

const (char) *pContent;

(char) const *pContent;

(3) 两者都不可变

const char* const pContent;

还有其中区别方法：

沿着*号划一条线，

如果const位于*的左侧，则const就是用来修饰指针所指向的变量，即指针指向为常量；

如果const位于*的右侧，const就是修饰指针本身，即指针本身是常量。
2. const修饰函数参数

const修饰函数参数是它最广泛的一种用途，它表示函数体中不能修改参数的值(包括参数本身的值或者参数其中包含的值)。它可以很好
void function(const int Var); //传递过来的参数在函数内不可以改变(无意义，因为Var本身就是形参)

void function(const char* Var); //参数指针所指内容为常量不可变

void function(char* const Var); //参数指针本身为常量不可变(也无意义，因为char* Var也是形参)

参数为引用，为了增加效率同时防止修改。

修饰引用参数时：

void function(const Class& Var);//引用参数在函数内不可以改变

void function(const TYPE& Var); //引用参数在函数内为常量不可变

3. const 修饰函数返回值

const修饰函数返回值其实用的并不是很多，它的含义和const修饰普通变量以及指针的含义基本相同。

(1) const int fun1() 这个其实无意义，因为参数返回本身就是赋值。

(2) const int * fun2()

调用时 const int *pValue = fun2();

我们可以把fun2()看作成一个变量，那么就是我们上面所说的1.(1)的写法，即指针内容不可变。

(3) int* const fun3()

调用时 int * const pValue = fun2();

我们可以把fun2()看作成一个变量，那么就是我们上面所说的1.(2)的写法，即指针本身不可变。

4. const修饰类对象/对象指针/对象引用

const修饰类对象表示该对象为常量对象，其中的任何成员都不能被修改。对于对象指针和对象引用也是一样。

const修饰的对象，该对象的任何非const成员函数都不能被调用，因为任何非const成员函数会有修改成员变量的企图。

例如：

class AAA

{
void func1();

void func2() const;

}

const AAA aObj;

aObj.func1(); ×

aObj.func2(); 正确

const AAA* aObj = new AAA();

aObj->func1(); ×

aObj->func2(); 正确
5. const修饰成员变量

const修饰类的成员函数，表示成员常量，不能被修改，同时它只能在初始化列表中赋值。
class A

{

…

const int nValue; //成员常量不能被修改

…

A(int x): nValue(x) {}; //只能在初始化列表中赋值

}
6. const修饰成员函数

const修饰类的成员函数，则该成员函数不能修改类中任何非const成员函数。一般写在函数的最后来修饰。
class A

{

…

void function()const; //常成员函数, 它不改变对象的成员变量. 也不能调用类中任何非const成员函数。

}

对于const类对象/指针/引用，只能调用类的const成员函数，因此，const修饰成员函数的最重要作用就是限制对于const对象的使用。
7. const常量与define宏定义的区别

(1) 编译器处理方式不同

define宏是在预处理阶段展开。

const常量是编译运行阶段使用。

(2) 类型和安全检查不同

define宏没有类型，不做任何类型检查，仅仅是展开。

const常量有具体的类型，在编译阶段会执行类型检查。

(3) 存储方式不同

define宏仅仅是展开，有多少地方使用，就展开多少次，不会分配内存。

const常量会在内存中分配(可以是堆中也可以是栈中)。

RTY 2011-08-10 07:25 发表评论

DLL导出类的问题

RTY — Tue, 09 Aug 2011 23:23:00 GMT

DLL导出类的问题

http://www.diybl.com/course/3_program/c++/cppjs/200833/102641.html
DLL动态链接库是程序复用的重要方式，DLL可以导出函数，使函数被多个程序复用，DLL中的函数实现可以被修改而无需重新编译和连接使用该DLL的应用程序。作为一名面向对象的程序员，希望DLL可以导出类，以便在类的层次上实现复用。所幸的是，DLL确实也可以导出类。

然而事实却没这么简单，导出类的DLL在维护和修改时有很多地方必需很小心，增加成员变量、修改导出类的基类等操作都可能导致意想不到的后果，也许用户更新了最新版本的DLL库后，应用程序就再也不能工作了。这就是著名的DLL Hell（DLL地狱）问题。

DLL地狱问题是怎么产生的呢？看下面的例子，假设DLL有一个导出类ClassD1：
class ClassD
{
       public:
int GetInt();
              private:
int m_i;
};
int ClassD::GetInt()
{
       return m_i;
}

应用程序使用现在的代码来使用这个类：
ClassD d;
printf(“%d”, d.GetInt());

程序进行正正常，没有什么问题。后来DLL需要升级，对ClassD进行了修改，增加了一个成员变量，如下：
class ClassD // 修改后
{
       public:
int GetInt();
              private:
                     int m_i2;
int m_i;
};

把新的DLL编译连接完成后，复制到应用程序目录，这个倒楣的应用程序调用GetInt方法恐怕再也无法得正确的值了。事实上它还算幸运的，如果GetInt的实现改成如下这样，那么它马上就要出错退出了。
int ClassD::GetInt() // 修改后
{
       return m_i++;
}

这样的事情，称它是个地狱（Hell）一点也不夸张。为什么会出错呢？我们要先从类实例的创建开始，看看使用一个类的工作过程。

首先，程序语句“ClassD d；”为这个类申请一块内存。这块内存保存该类的所有成员变量，以及虚函数表。内存的大小由类的声明决定，在应用程序编译时就已经确定。

然后，当调用“d.GetInt()”时，把申请的这一块内存做为this指针传给GetInt函数，GetInt函数从this指向的位置开始，加上m_i应有的偏移量，计算m_i所在的内存位置，并从该位置取数据返回。m_i相对this的偏移量是由m_i在类中定义的位置决定的，定义在前的成员变量在内存中也更靠前。这个偏移量在DLL编译时确定。

当ClassD的定义改为修改后的状态时，有些东西变了。

第一个变的是内存的大小。因为修改后的ClassD多了一个成员变量，所以内存也变大了。然而这一点应用程序并不知道。

第二个变的是m_i的偏移地址。因为在m_i之前定义了一个m_i2，m_i的实现偏移地址实际已经靠后了。所以d.GetInt()访问的将是原来m_i后面的那个位置，而这个位置已经超出原来那块内存的后部范围了。

很显然，在更换了DLL后，应用程序还按原来的大小申请了一块内存，而它调用的方法却访问了比这块内存更大的区域，出错再在所难免。

同样的情形还会发生在以下这些种情况中：

1）应用程序直接访问类的公有变量，而该公有变量在新DLL中定义的位置发生了变化；
2）应用程序调用类的一个虚函数，而新的类中，该虚函数的前面又增加了一个虚函数；
3）新类的后面增加了成员变量，并且新类的成员函数将访问、修改这些变量；
4）修改了新类的基类，基类的大小发生了变化；

等等，总言而之，一不小心，你的程序就会掉进地狱。通过对这些引起出错的情况进行分析，会发现其实只有三点变化会引起出错，因为这三点是使用这个DLL的应用程序在编译时就需要确定的内容，它们分别是：
1）类的大小；
2）类成员的偏移地址；
3）虚函数的顺序。

要想做一个可升级的DLL，必需避免以上三个问题。所以以下三点用来使DLL远离地狱。

1，不直接生成类的实例。对于类的大小，当我们定义一个类的实例，或使用new语句生成一个实例时，内存的大小是在编译时决定的。要使应用程序不依赖于类的大小，只有一个办法：应用程序不生成类的实例，使用DLL中的函数来生成。把导出类的构造函数定义为私有的(privated)，在导出类中提供静态(static)成员函数(如NewInstance())用来生成类的实例。因为NewInstance()函数在新的DLL中会被重新编译，所以总能返回大小正确的实例内存。

2，不直接访问成员变量。应用程序直接访问类的成员变量时会用到该变量的偏移地址。所以避免偏移地址依赖的办法就是不要直接访问成员变量。把所有的成员变量的访问控制都定义为保护型(protected)以上的级别，并为需要访问的成员变量定义Get或Set方法。Get或Set方法在编译新DLL时会被重新编译，所以总能访问到正确的变量位置。

3，忘了虚函数吧，就算有也不要让应用程序直接访问它。因为类的构造函数已经是私有(privated)的了，所以应用程序也不会去继承这个类，也不会实现自己的多态。如果导出类的父类中有虚函数，或设计需要（如类工场之类的框架），一定要把这些函数声明为保护的(protected)以上的级别，并为应用程序重新设计调用该虑函数的成员函数。这一点也类似于对成员变量的处理。

如果导出的类能遵循以上三点，那么以后对DLL的升级将可以认为是安全的。

如果对一个已经存在的导出类的DLL进行维护，同样也要注意：不要改动所有的成员变量，包括导出类的父类，无论定义的顺序还是数量；不要动所有的虚函数，无论顺序还是数量。

总结起来，其实是一句话：导出类的DLL不要导出除了函数以外的任何内容。听起来是不是有点可笑呢！

事实上，建议你在发布导出类的DLL的时候，重新定义一个类的声明，这个声明可以不管原来的类里的成员变量之类的，只把接口函数列在类的声明里，如下面的例子：
class ClassInterface
{
       privated:
              ClassInterface();
       public:
              static ClassInterface * NewInstance();
              int GetXXX();
              void SetXXX();
              void Function();
};

使用该DLL的应用程序用上面的定义作为ClassInterface的头文件，便不会有任何可能导致的安全问题。

DLL地狱问是归根结底是因为DLL当初是作为函数级共享库设计的，并不能真正提供一个类所必需的信息。类层上的程序复用只有Java和C#生成的类文件才能做到。

RTY 2011-08-10 07:23 发表评论

用OllDbg中断在dll的入口

RTY — Tue, 09 Aug 2011 23:11:00 GMT

用OllDbg中断在dll的入口

http://www.pediy.com/bbshtml/bbs7/pediy7-613.htm

标题: Diy OllyDbg's Loaddll.exe
发帖人:jingulong
时间: 2005-08-13 13:02
原文链接:http://bbs.pediy.com/showthread.php?threadid=16140
详细信息:

目的：用OllDbg中断在dll的入口
程序下载：http://bbs.pediy.com/showthread.php?s=&threadid=16082

一、编写plugin :
1.  DllEntryPoint如图：

2．ODBG_Plugininit如图：新启一个线程，由此线程的函数WinMain创建一个（隐藏）窗口。

3．窗口回调函数如图：

至此，plugin设计完成，它所起的作用是：
1．  当得到WM_USER消息时返回dll入口地址（在MyLdrpCallInitRoutine中）
2．  当得到WM_USER＋1消息时在wParam指示的地址（就是你调试点dll入口点）设置临时断点（Tempbreakpoint）。

二、  在dll的加载进程中与plugin通讯。
    为此，可以写一个加载程序（就好像DLL_Loader），我这里选择diy llyDbg配套的loaddll.exe，因为只有它可与OD“无缝对接”。用LordPE打开程序看看结构，当看到它的ExportTable时，感觉实在妙！下面是其截图：

    每个导出函数名称叫人看了都如此受用，特别是PatchArea！Oleh Yuschuk为我们考虑得实在周到。Thanks
Diy 过程：
1．  把ImportTable中的GetCommandLineA改成GetProcAddress
2．  Patch

   为：

并在Patcharea（410298）处键入：

以完成原语句的功能。这里程序中原来没有的字符串（如“GetCommandLineA”）等在data区或rsrc区段空白处录入。
3．Patch

为 call  4102B5，并在4102B5开始写入如下代码：

以上代码完成的主要任务是hook dll entrypoint，当程序查到入口处是调试点dll oep 时通知plugin设置断点，使OllyDbg中断在那里，这样我们可以少飞许多手脚。

RTY 2011-08-10 07:11 发表评论

dll中非导出函数的调用

RTY — Tue, 09 Aug 2011 23:08:00 GMT

http://hi.baidu.com/51634780/blog/item/6e99de041d682689e850cd2a.html

dll中非导出函数的调用
这几天在学习pe，对输出表特别兴趣。程序对导出函数调用，最终是对导出
函数入口地址的调用，非导出函数的入口地址不在导出表里，所以其他程序

无法

调用非导出函数。
本人刚开始的想法是在内存里修改dll的导出表，使非导出函数变成导出函

数，

供自己的程序调用。后来想到可不可以直接调用非导出函数的入口地址呢？

感觉

应该可以，有了这个想法后就马上开始动手试验。

自己写了个简单的dll，其中有2个导出函数a1,b1，1个内部函数c1
先用call的方法调用导出函数：a1
invoke LoadLibrary,CTEXT('testdll.dll')
mov @var1,eax        ;模块句柄（也是模块的基址）存入@var1
invoke GetProcAddress,@var1,CTEXT('a1')
mov @lpProc,eax ;导出函数的入口地址存入@lpProc
push 5      ;函数参数3
push 9      ;函数参数2
push hWnd      ;函数参数1
call @lpProc      ;函数调用
一切正常。

再调用非导出函数试试，在调用非导出函数c1前，必须找到c1的相对虚拟
地址，
先用程序装入dll
invoke LoadLibrary,CTEXT('testdll.dll')
mov @var1,eax    ;模块句柄，也是模块的基址
然后运行程序，用OD调试，找到c1的入口地址：1000100C
1000100C           55            push ebp
1000100D           8BEC          mov ebp,esp
1000100F           8B45 08       mov eax,dword ptr ss:[ebp+8]
10001012           0345 0C       add eax,dword ptr ss:[ebp+C]
10001015           C9            leave
10001016           C2 0800       retn 8

通过 @var1获得模块的基址是10000000
那末c1的相对虚拟地址就是：1000100C－10000000＝100c
做好了这一步后，就可以在自己的程序里调用非导出函数了。
调用非导出函数：
invoke LoadLibrary,CTEXT('testdll.dll')
mov @var1,eax       ;模块句柄（也是模块的基址）存入@var1
add @var1,100ch    ;得到c1的入口地址
push 5      ;函数参数2
push 9      ;函数参数1
call @var1      ;函数调用
得到了想要的结果，一切ok!

用这种方法可以调用别人dll的非导出函数。

RTY 2011-08-10 07:08 发表评论

load dll 简单方式（收集）

RTY — Tue, 09 Aug 2011 23:04:00 GMT

http://blog.csdn.net/aca_jingru/article/details/2524697

view plain

本文转自codeprojcet "http://www.codeproject.com/kb/dll/dllease.aspx">http://www.codeproject.com/KB/DLL/dllease.aspx

load dll也就是load dll中的函数,一般是loadlibrary,GetProcAddress,每一步都要判断函数返回是否正确,比较繁琐,

该作者干脆做了个封装,将这些重复步骤封装到一个bool的函数中,这样只要在if语句中调用一下可以了,具体来看代码:这里用到了c语言的可变参数,对此俺也不是很了解

view plain

//GetProcAddresses
//Argument1: hLibrary - Handle for the Library Loaded
//Argument2: lpszLibrary - Library to Load
//Argument3: nCount - Number of functions to load
//[Arguments Format]
//Argument4: Function Address - Function address we want to store
//Argument5: Function Name - Name of the function we want
//[Repeat Format]
//
//Returns: FALSE if failure
//Returns: TRUE if successful
BOOL GetProcAddresses( HINSTANCE *hLibrary,
LPCSTR lpszLibrary, INT nCount, ... )
{
va_list va;
va_start( va, nCount );
if ( ( *hLibrary = LoadLibrary( lpszLibrary ) )
!= NULL )
{
FARPROC * lpfProcFunction = NULL;
LPSTR lpszFuncName = NULL;
INT nIdxCount = 0;
while ( nIdxCount < nCount )
{
lpfProcFunction = va_arg( va, FARPROC* );
lpszFuncName = va_arg( va, LPSTR );
if ( ( *lpfProcFunction =
GetProcAddress( *hLibrary,
lpszFuncName ) ) == NULL )
{
lpfProcFunction = NULL;
return FALSE;
}
nIdxCount++;
}
}
else
{
va_end( va );
return FALSE;
}
va_end( va );
return TRUE;
}

view plain

使用的例子:

view plain

class="csharp" name="code">class="csharp" name="code">#include
typedef int ( WINAPI *MESSAGEBOX )
( HWND , LPCSTR, LPCSTR, DWORD );
typedef int ( WINAPI *MESSAGEBOXEX )
( HWND , LPCSTR, LPCSTR, DWORD , WORD );
void main(void)
{
MESSAGEBOX lpfMsgBox = NULL;
MESSAGEBOXEX lpfMsgBoxEx = NULL;
HINSTANCE hLib;
if(GetProcAddresses( &hLib, "User32.dll", 2,
&lpfMsgBox, "MessageBoxA",
&lpfMsgBoxEx, "MessageBoxExA" ) )
{
lpfMsgBox( 0, "Test1", "Test1", MB_OK );
lpfMsgBoxEx( 0, "Test2", "Test2", MB_OK,
MAKELANGID( LANG_ENGLISH, SUBLANG_ENGLISH_US ) );
}
if ( hLib != NULL )
FreeLibrary( hLib );
}

view plain

是不是很好用呢囧

RTY 2011-08-10 07:04 发表评论

References:
	>Find path of an application (From: "Rakesh Singhal" )
	>Re: Find path of an application (From: Jean-Daniel Dupas )
	>Re: Find path of an application (From: "Rakesh Singhal" )
	>Re: Find path of an application (From: Jean-Daniel Dupas )
	>Re: Find path of an application (From: "Rakesh Singhal" )

C++博客-RTY 实践出真知-随笔分类-C/C++

Dynamic Library Design Guidelines (Xcode)

Qt internal error: qt_menu.nib could not be loaded.

Cocoa读取和写入plist文件

什么叫IOC（编程术语)

什么叫IOC（编程术语

otool 与dylib

找不到 dirent.h 文件

【转】vs2005下的dirent.h 该方法同样适用于VS2008 及VS2010

vc调试窗口表达式格式化资料

Context Operator (C/C++ Language Expressions)

Managed Expressions in C++ (VC 2010 调试)

Find path of an application

Re: Find path of an application

XCODE 4.3 WITH NO GCC?

error C2143: syntax error : missing ';' before 'type' in Visual C++ 可能的原因

C++查缺补漏4，赶紧的

SDL入门教程（六）：SDL读取其它格式的图片

Configure，Makefile.am, Makefile.in, Makefile文件之间关系

CL.exe的全部命令开关(摘) - 酱坛子 - C++博客

Windows平台下的调试技术 - 小夜曲的孤伤 - 博客大巴

Google Breakpad 完全解析（二） —— Windows前台实现篇

Google Breakpad 完全解析（二） —— Windows前台实现篇

Table of contents for Google Breakpad 完全解析

代码结构

breakpad的崩溃捕获机制

breakpad中的C/S结构

dump文件的上传

breakpad存在的问题

进程外生成dump有很多好处，其中最大的好处就是不会被崩溃进程影响，这样dump的过程就不容易出错，但是这样也有一定的弊端。

Google Breakpad 完全解析（一） —— Windows入门篇

Google Breakpad 完全解析（一） —— Windows入门篇

Table of contents for Google Breakpad 完全解析

原理简介

安装和编译

如何使用breakpad

调试Release发布版程序的Crash错误 （转）

调试Release发布版程序的Crash错误 （转）

调试Release发布版程序的Crash错误

Google Test Primer ：开始使用Google C++ 测试框架

VC编译Swig例子注意

从dll文件或者def文件生成lib文件

VC调试器高级应用----高级断点篇

Qt的插件机制

C++ const 用法

DLL导出类的问题

用OllDbg中断在dll的入口

dll中非导出函数的调用

load dll 简单方式 （收集）

调试Release发布版程序的Crash错误（转）

调试Release发布版程序的Crash错误（转）

load dll 简单方式（收集）