//
BOOL IsWow64(HANDLE ProcessHandle)
{
	typedef BOOL(WINAPI *LPFN_ISWOW64PROCESS) (HANDLE, PBOOL);
	LPFN_ISWOW64PROCESS fnIsWow64Process;
	BOOL bIsWow64 = FALSE;

	fnIsWow64Process = (LPFN_ISWOW64PROCESS)GetProcAddress(LoadLibraryA("kernel32.dll"), "IsWow64Process");
	if (NULL != fnIsWow64Process)
	{
		fnIsWow64Process(ProcessHandle, &bIsWow64);
	}

	return bIsWow64;
}

测试结果

• 用管理员权限运行，返回TRUE；
• 在UAC环境下直接运行，返回FALSE；
• 在SYSTEM权限服务进程中执行，返回TRUE。

//
BOOL IsAdmin()
{
	typedef BOOL(WINAPI *_LPFN_ISADMIN) (VOID);
	_LPFN_ISADMIN	fnIsAdmin;

	//	IsUserAnAdmin
	HMODULE	hShell32 = LoadLibraryA("Shell32.dll");

	fnIsAdmin = (_LPFN_ISADMIN)::GetProcAddress(hShell32, "IsUserAnAdmin");

	if (NULL != fnIsAdmin)
	{
		return fnIsAdmin();
	}
	return FALSE;
}

BOOL IsUserAdmin(VOID)
/*++ 
Routine Description: This routine returns TRUE if the caller's
process is a member of the Administrators local group. Caller is NOT
expected to be impersonating anyone and is expected to be able to
open its own process and process token. 
Arguments: None. 
Return Value: 
   TRUE - Caller has Administrators local group. 
   FALSE - Caller does not have Administrators local group. --
*/ 
{
	BOOL b;
	SID_IDENTIFIER_AUTHORITY NtAuthority = SECURITY_NT_AUTHORITY;
	PSID AdministratorsGroup; 
	b = AllocateAndInitializeSid(
	    &NtAuthority,
	    2,
	    SECURITY_BUILTIN_DOMAIN_RID,
	    DOMAIN_ALIAS_RID_ADMINS,
	    0, 0, 0, 0, 0, 0,
	    &AdministratorsGroup); 
	if (b) 
	{
		if (!CheckTokenMembership( NULL, AdministratorsGroup, &b)) 
		{
			b = FALSE;
		} 
		FreeSid(AdministratorsGroup); 
	}
	return(b);
}

编写程序main，在程序main中调用lib.so中的myprintf函数。
main.cc

//main.cc
#include <iostream>
#include <dlfcn.h> //dlopen等函数需要的头文件

int main(int argc,char* argv[])
{
    void* dlp = dlopen("./lib.so",RTLD_NOW);
    if (dlp)
    {
    	std::cout << "dlopen is OK!" << std::endl;
    	typedef void (*pf_myprintf)(const char* str);
		pf_myprintf myprintf = (pf_myprintf)dlsym(dlp,"myprintf");
		if (myprintf)
		{
			char txtbuf[100];
			std::cin.get(txtbuf,100);
			myprintf(txtbuf);
		}
		else
		{
			std::cout << "dlsym is failed!" << std::endl;
		}
    }
    else
    {
    	std::cout << "dlopen is failed!" << std::endl;
    	return 0;
    }
	return 1;
}

lib.cc

//lib.cc
#include <iostream>

extern "C"__attribute__((visibility("default"))) void myprintf(const char* str)
{
	std::cout << "-----myprintf begin-----" << std::endl;
	std::cout << str << std::endl;
	std::cout << "------myprintf end------" << std::endl;
}

extern "C" void test_export1()
{
	std::cout << "-----test_export-----" << std::endl;
}

__attribute__((visibility("default"))) void test_export2()
{
	std::cout << "-----test_export-----" << std::endl;
}

makefile

#main lib makefile
main:main.cc
	g++ main.cc -o main -ldl
lib:lib.cc
	g++ -o lib.so lib.cc -shared -fPIC -fvisibility=hidden
clean:
	-rm main *.so

使用make来编译生成主调程序，使用make lib来生成库程序lib.so，而后执行main即可调用动态库中的函数，如图1所示。

下面我们看看lib.cc中的三个函数都哪个导出了，使用命令readelf -s lib.so，结果如图2所示。

可以看到，三个函数只有test_export2没有被导出，也只有这个函数没有用extern "C"标注，另外，该函数使用了__attribute__((visibility("default")))。由此可以得出以下假设：

1. 使用g++编译动态库，会导出具有extern "C"标识的函数，在gcc中有效的__attribute__((visibility("default")))标识在g++中无效。原因可能是因为__attribute__是Linux C中特有的标识，在C++中很有可能没有作用。
2. 另外从lib.so的导出符号表中可以看到一些C++形式的导出函数，所以一定是还有其它方法可以直接导出C++形式的函数。

可以用open-vm-tools替代传统的VMware tools，直接apt-get就可以。

• sudo apt-get install open-vm-tools
• sudo apt-get install open-vm-tools-desktop

必须有open-vm-tools-desktop才能支持真机与虚拟机之间的文件拖拽等操作。

总共分两步，都在磁盘配置界面中完成：

1. 添加efi分区，大小100MB~200MB，另外使用其他分区工具也可以创建该分区，格式为FAT32；
2. “安装启动引导器的设备”处选择这个efi分区。

Google 经常会发布一些开源项目,意味着会接受来自其他代码贡献者的代码。但是如果代码贡献者的编程风格与 Google 的不一致，会给代码阅读者和其他代码提交这造成不小的困扰。Google 因此发布了这份自己的编程风格, 使所有提交代码的人都能获知 Google 的编程风格。包含C++、Objective-C、Python的相关规范。

• 中文翻译版：

http://zh-google-styleguide.readthedocs.org/en/latest/contents/

• 英文原版：

https://google.github.io/styleguide/cppguide.html

从刚进大学开始学习 C 语言，就听说了实际开发中会用到的各种变量命名方法，例如常见的匈牙利命名法、骆驼命名法、Pascal 命名法等。

后来自己真正开始用 C/C++ 写程序，开始使用匈牙利命名法，总觉得十分别扭。好好的变量名 name，严格按照命名规则，非得在前面加类型前缀，改写成 lpszName。

如今的 IDE 都会自动检查变量类型，而且类型错误在编译时也比较容易发现，在变量名前面强制加上类型信息实在不知道有什么意义。

直到无意中在《More Joel on Software》[1] 这本书第 23 章看到匈牙利命名法作者——Charles Simonyi 的本意。

1. 应用型匈牙利命名法——鲜为人知的正统

Simonyi 的匈牙利命名法的原型在微软公司内部最初被叫做“应用型匈牙利命名法”（Apps Hungarian），因为它是在“应用程序部”（Applications Division）中使用的，也就是用在 Word 和 Excel 身上。在 Excel 的源码中，你可以看到大量的 rw 和 col 。

使用这种“应用型匈牙利命名法”，我们可以在看到变量后很快理解其含义，并很容易发现代码中的问题。

例如在代码中看到 xl = cb，

xl 表示“相对于页面的横坐标”，horizontal coordinates relatives to the layout；cb 表示“字节个数”，count of bytes

显然是有问题的，虽然 xl 和 cb 都是整数，但是这二者之间的赋值基本一定会导致 bug。

2. 系统型匈牙利命名法——广为流传的冒牌货

然而，一定程度上由于 Simonyi 自己在编写文档时，用了“type”这个词，而不是“kind”，于是被人误以为 Simonyi 指的是数据类型。尽管 Simonyi 很详细、很准确地解释了他所说的“type”到底是什么意思。可惜于事无补，危害已经酿成了。悲剧的结果就是产生了我们现在熟悉的“系统型匈牙利命名法”（System Hungarian）。

还是上面的例子，改用“系统型匈牙利命名法”以后，可以改成 nWidth = nCount，看起来好像还不错哈～bug 就是这样隐藏起来的。

1. “应用型匈牙利命名法”的前缀是非常有用的、有含义的，比如：
   • “ix” 表示数组的索引值（index）
   • “c” 表示一个计数器（count）
   • “d” 表示两个数量之间的差（difference），“dx” 就可以表示宽度
2. “系统性匈牙利命名法”的前缀就差远了，比如：
   • “l” 表示长整型（long）
   • “ul” 表示无符号长整型（unsigned long）
   • “dw” 表示双精度值（double word），这实际上也是一个无符号的长整型

这种差别虽然细微，但是完全误解了 Simonyi 的意图和做法。“系统型匈牙利命名法”传播的又远又广，在 Windows 编程文档中，它是标准的变量命名法。难怪很多人都觉得匈牙利命名法很奇怪、很别扭。

参考文章：
[1] Joel Spolsky 著，阮一峰 译，中文名《软件随想录》http://book.douban.com/subject/4163938/
[2] 匈牙利命名法的衰落和建议 http://blog.kingsamchen.com/archives/618#comment-1310
[3] lifeicd的读书笔记

原文地址：
http://www.cnblogs.com/xuxn/archive/2012/05/16/real-hungarian-notation.html

我本可以“无可奉告”，但是你们又不高兴，所以今天（2015年的最后一天）我建立了这个WordPress博客，用于记录平时的工作和生活中的经验和教训，好让大家跟我一起学习一个。最后奉劝你们一句：闷声大发财，这是最好的。