• 判断当前进程是否具有管理员权限

    ·

    发布于

    修改于

    测试结果

    • 用管理员权限运行,返回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);
    }

  • Linux调用动态库及g++动态库函数导出方法

    ·

    发布于

    修改于

    编写程序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所示。

    ubuntu_amd64-2016-01-30-13-00-46
    图1

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

    ubuntu_amd64-2016-01-30-13-01-08
    图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++形式的函数。

  • Ubuntu安装VMware tools

    ·

    发布于

    修改于

    可以用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才能支持真机与虚拟机之间的文件拖拽等操作。


  • 编译boost

    ·

    发布于

    修改于

    • 最常用的两个编译命令
    1. b2 –toolset=msvc-14.2 –layout=versioned –build-type=complete variant=release link=static threading=multi runtime-link=static –address-model=32,64

    这个生成的是静态库,并且是静态链接到标准库,用于Release版本。

    1. b2 –toolset=msvc-14.2 –layout=versioned –build-type=complete variant=debug link=static threading=multi runtime-link=shared –address-model=32,64

    这个生成的也是静态库,但是是动态链接到标准库,用于Debug版本。

    • 参数具体含义
    1. –layout指定生成库的文件名 tagged不包含编译器信息和boost版本信息 versioned包含编译器信息和boost版本信息以上两者都会按照参数包含编译信息。
    2. –build-type=complete:编译所有库。
    3. install:表示需要将头文件拷贝到指定目录,如果使用stage代替install则不拷贝头文件,需要开发者自己到boost目录中去找。
    4. threading=multi:支持多线程, 生成的库文件名称中包含”-mt”标识。
    5. variant=release|debug debug:库文件名中包含”-gd”标识 release:库文件名中无特殊标识(不包含”-gd”)。
    6. runtime-link=shared|static static:生成的库文件名称包含”-s” shared:库文件名中无特殊标识(不包含”-s”)。
    7. msvc-14.2是vs2019,14.1是vs2017,msvc-14.1_xp是vs2017的xp编译模式(存疑)。
    8. –address-model=32,64 编译32和64位版本。
    9. –std=c++14是指定C++版本 //有可能是错的。


  • Ubuntu EFI模式安装

    ·

    发布于

    修改于

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

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

    ubuntu efi


  • Google开源项目风格指南

    ·

    发布于

    修改于

    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


  • 男星最喜欢Johnny Sins,女星最喜欢Jenni Lee

    ·

    发布于

    修改于

    男星最喜欢Johnny Sins,女星最喜欢Jenni Lee


  • Hello,World!

    ·

    发布于

    修改于

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


最新