32位和64位系统编程的区别

[LubinLew]

笔试题:求答案

①在32位和64位系统编程有什么区别?
②写一个函数识别当前系统是32位的还是64位的(bu允许用sizeof)

[qq120848369]

#include <iostream>

bool is_system64()
{
    unsigned long n = 1UL << 63;
    return n;
}

int main(int argc, char *const argv[])
{
    std::cout << is_system64() << std::endl;
    return 0;
}

这样可以吗.

[绯红女王]

1.字长不同 2.定义一种类型的变量（或者常量），给他赋值，然后转化为二进制，看是多少位的喽~~~

[bluewanderer]

引用 1 楼 qq120848369 的回复:

#include <iostream>

bool is_system64()
{
    unsigned long n = 1UL << 63;
    return n;
}

int main(int argc, char *const argv[])
{
    std::cout << is_system64() << std::endl;
    return 0;
}

这样可以吗.

1UL << 63应该不关什么系统上都是0吧。另外long也不总是64位的。应该除了预定义宏没有绝对可靠的办法判断。

[bluewanderer]

仔细想想long是64位的话，1l应该也是64位的...

[qq120848369]

引用 3 楼 bluewanderer 的回复:

[quote=引用 1 楼 qq120848369 的回复:]

#include <iostream>

bool is_system64()
{
    unsigned long n = 1UL << 63;
    return n;
}

int main(int argc, char *const argv[])
{
    std::cout << is_system64() << std::endl;
    return 0;
}

这样可以吗.

1UL << 63应该不关什么系统上都是0吧。另外long也不总是64位的。应该除了预定义宏没有绝对可靠的办法判断。[/quote] ...可以判断的吧, 32平台long<<63肯定是越界成0了, 64没越界就非0.

[bluewanderer]

long的长度并非确定的。VC里64位环境下long还是32位的，1ul << 63还是0。相对来说指针的可靠性大概还稍微高点 (void *)(1ll << 63) != 0，不过依然是没准的事。

[qq120848369]

引用 6 楼 bluewanderer 的回复:

long的长度并非确定的。VC里64位环境下long还是32位的，1ul << 63还是0。相对来说指针的可靠性大概还稍微高点 (void *)(1ll << 63) != 0，不过依然是没准的事。

原来如此, 那真心蛋疼了.

[LubinLew]

引用 7 楼 qq120848369 的回复:

[quote=引用 6 楼 bluewanderer 的回复:] long的长度并非确定的。VC里64位环境下long还是32位的，1ul << 63还是0。相对来说指针的可靠性大概还稍微高点 (void *)(1ll << 63) != 0，不过依然是没准的事。

原来如此, 那真心蛋疼了.[/quote] 版主帮忙顶一下啊,别让这个帖子沉了,现在正是32到64位系统转换的时期,我觉得这2道笔试题很有意义的。

[bluewanderer]

源码真正要知道的并不是目标到底是32位环境还是64位环境，而是诸如long到底是多少位的，指针到底是多少位的，有多少虚拟地址可用这样的具体信息。因为反过来即便知道环境是32位或者64位的，那些真正有用的具体的信息依然是不确定的。

[AnYidan]

引用 9 楼 bluewanderer 的回复:

源码真正要知道的并不是目标到底是32位环境还是64位环境，而是诸如long到底是多少位的，指针到底是多少位的，有多少虚拟地址可用这样的具体信息。因为反过来即便知道环境是32位或者64位的，那些真正有用的具体的信息依然是不确定的。

所以编译时用 #if ...#else...#end 配合 typedef 定义一套自己的数据类型才可靠

[vincelo]

引用 11 楼 u010211892 的回复:

除了argc,argv[],还有个env[]，不知行不行

env linux??/

[wuchuan53]

伪代码： unsigned int m = ~0; unsigned int n = 0x01 << 33; if (m^n) //64bit else //32bit 不知道这样可以么？

[www_adintr_com]

1. 对高级语言来说, 其实区别挺小的. 2. 你是要判断操作系统的位数, 还是要判断当前的编译系统的使用的位数?

[lsjfdjoijvtghu]

除了argc,argv[],还有个env[]，不知行不行

[赵4老师]

ms-help://MS.MSDNQTR.v80.chs/MS.MSDN.v80/MS.VisualStudio.v80.chs/dv_vs64/html/fd4026bc-2c3d-4b27-86dc-ec5e96018181.htm Visual Studio 64 位应用程序 请参见 语言筛选器： 全部 语言筛选器： 多个 语言筛选器： Visual Basic 语言筛选器： C# 语言筛选器： C++ 语言筛选器： J# 语言筛选器： JScript Visual Basic（声明） Visual Basic（用法） C# C++ J# JScript 从 Visual Studio 2005 开始，您可以对应用程序进行编译，并将其指定为在 64 位操作系统上作为本机应用程序或在 WOW64 下运行。WOW64 是一个由操作系统提供的兼容性环境，它使得 32 位应用程序能够在 Windows 64 位操作系统上运行。 备注 在 64 位操作系统上，所有使用 .NET Framework 1.0 和 1.1 版生成的应用程序都被视为 32 位应用程序，并始终在 32 位公共语言运行库 (CLR) 上的 WOW64 下运行。此外，使用 .NET Framework 2.0 版生成的 32 位特定应用程序将可以在 64 位平台上的 WOW64 下运行。 在 x86 计算机上，Visual Studio 2005 将安装 32 位的 CLR 2.0 版，而在 64 位 Windows 计算机上，它将同时安装 32 位和合适的 64 位 CLR 2.0 版。（Visual Studio 2005 是一个 32 位应用程序，当安装到 64 位 Windows 操作系统上时，它将在 WOW64 下运行。） 注意 由 x86 模拟和 Itanium 处理器系列的 WOW64 子系统的设计所决定，应用程序只限于在一个处理器上执行。单处理器执行和 x86 模拟降低了 32 位 .NET Framework 应用程序在基于 Itanium 的系统上运行时的性能和伸缩性。建议将使用 .NET Framework 1.1 版的应用程序用作交互式客户端应用程序，而不要用作要求高性能或伸缩性的应用程序，如高负载 ASP.NET 应用程序。您应当考虑使用 .NET Framework 2.0 版，该版本包括对基于 Itanium 的系统的本机 64 位支持，并改进了性能和伸缩性。 就像 32 位 Windows 操作系统一样，在 64 位 Windows 操作系统上运行 64 位托管应用程序时，可以创建的对象的大小也有一个 2GB 的限制。 许多情况下，程序集在 32 位或 64 位 CLR 上可以同等地运行。在 64 位 CLR 上运行时，导致程序的行为发生改变的一些原因有： 结构中包含大小随平台而改变的成员，例如任何指针类型。 指针算法中包含固定大小。 不正确的平台调用或 COM 声明，对句柄使用 Int32，而不是 IntPtr。 将 IntPtr 强制转换为 Int32。 有关移植 32 位应用程序以便在 64 位 CLR 上运行的更多信息，请参见 http://msdn.microsoft.com/library/?url=/library/en-us/dndotnet/html/64migrate.asp。 一般 64 位编程信息 有关 64 位编程问题的一般信息，请参见 http://msdn.microsoft.com/netframework/programming/64bit/ Introducing 64-bit Windows（Platform SDK 文档，也可以在 MSDN 网站上找到） 有关下载公共语言运行库的 64 位版本的信息，请参见 http://www.microsoft.com/china/msdn/download/default.mspx。 有关 Visual Studio 开发环境中对创建 64 位应用程序的支持的信息，请参见 Visual Studio 开发环境 64 位支持。 创建 64 位应用程序的编译器支持 默认情况下，使用 .NET Framework 2.0（在 32 位或 64 位计算机上）生成的应用程序将在 64 位计算机上作为本机应用程序运行（而不是在 WOW64 下运行）。下表列出的主题探讨了如何使用 Visual Studio 编译器来创建 64 位应用程序，使之可以作为本机应用程序运行或在 WOW32 下运行，或者兼具这两种运行形式： 编译器 编译器选项 Visual Basic /platform (Visual Basic) Visual C# /platform（指定输出平台）（C# 编译器选项） Visual C++ 您可以使用 /clr:safe 创建平台不可知的 MSIL 应用程序；有关更多信息，请参见 /clr（公共语言运行库编译）。 Visual C++ 附带了针对每种 64 位操作系统的不同编译器。有关使用 Visual C++ 创建可在 64 位 Windows 操作系统上运行的本机应用程序的附加信息，请参见 Visual C++ 64 位编程。 Visual J# 在 Visual Studio 2005 中，Visual J# 编译器仅可以创建 32 位应用程序。在 64 位 Windows 操作系统上运行时，使用 Microsoft Visual J# 2005 编译的应用程序将在 WOW64 下运行。（即使对于不发出 JDK 调用的应用程序，Visual J# 编译器所依赖的 JDK 二进制文件仍是 32 位。） 如果平台不可知的映像在 64 位 Windows 操作系统上加载了 Visual J# .dll，则发出调用的应用程序将在运行时失败。 JScript /platform (JScript) 确定 .exe 或 .dll 的状态 在命令行使用 corflags.exe 可以确定某个 .exe 或 .dll 是仅可以在特定平台上运行，还是可以在 WOW64 下运行。还可以使用 corflags.exe 来更改 .exe 或 .dll 的平台状态。有关更多信息，请参见 CorFlags 转换工具 (CorFlags.exe)。Visual Studio 2005 程序集的 CLR 头（或 COM+ 运行库头）的主运行库版本号设置为 2，次运行库版本号设置为 5。在 Visual Studio 2003 程序集中，它们分别为 2 和 0。所有次运行库版本设置为 0 的应用程序都将被视为旧版应用程序，在 64 位计算机上它们将始终在 WOW64 下执行。 使用 GetPEKind 可以通过编程方式查询 .exe 或 .dll，以确定它是仅可以在特定平台上运行，还是可以在 WOW64 下运行。 请参见 其他资源 基于 Windows 的应用程序、组件和服务 要提出有关“帮助”或本产品其他功能的建议或错误报告，请转到反馈站点。

[CCDDzclxy]

楼上太长了... 只知道 vs 里面 sizeof(void*) 就可以看出 是多少位的os

[CCDDzclxy]

引用 16 楼 CCDDzclxy 的回复:

楼上太长了... 只知道 vs 里面 sizeof(void*) 就可以看出 是多少位的os

晕 没注意 不准用 sizeof ，当我没来过...

[CCDDzclxy]

那就将 1楼 的 unsigned long 改成 void* ，在vs里应该可以

[赵4老师]

在虚拟机环境下不可能识别出系统到底是32位还是64位。

[CCDDzclxy]

// _vs08_consol_test.cpp : 定义控制台应用程序的入口点。
//

#include "stdafx.h"
#include <windows.h>
#include <iostream>

bool is_system64()
{
    //unsigned long n = 1UL << 63;
	ULONGLONG ull = 1;
	void* n = (void*)(ull << 63);
    return n;
}

int main(int argc, char *const argv[])
{
    std::cout << is_system64() << std::endl;
    return 0;
}

这段代码，测试了下： XP_Home sp2 32位os ，打印出来是 0 vmware server 中 Win2003 Enterprise x64 Edition sp2 ，打印出来是 1 不知是否可以...