軟體編譯多少位好

Ⅰ 如何編譯64位dll程序，有幾種情況，在32位XP上用VC++6.0或者VS2010該怎麼編譯64位的dll。

在64位的操作系統上用vs軟體編譯的dll默認就是64位。
在32位XP上用VC++6.0編譯64位的dll，需要安裝sdk（最新版本是sdk2003），在開始菜單——sdk——open build environment window——windows server 2003 64-bit build environment——set win svr 2003 x64 build env進入命令行，從命令行調用msdev，將vc選項里的include和lib的第一個默認路徑設為sdk目錄下64位頭文件和庫的路徑，編譯出的dll似乎就是64位的了。這個是從網頁上看到的，沒實踐過。
在32位XP上使用vs2010就簡單多了，新建一個項目（解決方案），加入代碼，設置X64，編譯生成即可。

Ⅱ vs有沒有32位與64位的區別

visualstudio沒有專門的64位版，但32位版可以在64位系統上面正常使用。

由於操作系統內存分配的不同，導致軟體開發過程中，需要編譯不同版本的軟體。

編譯程序根據需要選擇不同的編譯環境，x86和win32為32位程序，x64為64位程序，可以選擇不同的編譯條件形成不同位的軟體。

代碼中的基本數據類型，會根據操作系統的位數來分類內存大小。

如int型在32位操作系統下為4位元組，在64位系統下為8位元組。

因此在64位上對int型數據操作，編譯生成32位的程序，有可能導致int型越界，軟體出現問題，32位的程序在64位操作系統上運行，由於64位操作系統的定址和偏移問題，也有可能導致程序在運行過程中，計算結果與32位系統不一致。

64位操作系統理論上能夠箭筒32位和64位軟體，32位操作系統不能運行64位程序。

在vs中，x64生成的程序只能在64位系統中運行。如果用戶用的是32位的系統（比如XP），則運行不了程序。

x32生成32位程序，由於64位系統也能運行32位的程序，所以這個選項跟AnyCPU一樣可以同時運行在兩種系統中，但效率沒有AnyCPU高，因為64位的軟體跟CPU交互的數據要比32位的接近大一倍。

所以當要把項目代碼轉移到另一台計數機時，就要考慮這個問題。假如原來選擇的目標平台是x64，新電腦的系統是32位，當你按F5調試運行時，則跑不起來，這時把目標平台改成AnyCPU或者x32就能解決了。

(2)軟體編譯多少位好擴展閱讀：

如果項目引用有32位的dll（c＋＋編譯生成的），則只能選擇32位平台，否則也會報錯，整個項目要保持一致。

在項目調試的過程中，可以看到32位與64位程序載入的dll不同。

32位程序從system32中載入dll；而64位程序從syswow64中載入dll。

64bit程序在x86－64處理器上並不會帶來明顯的性能提高，它只是增加了處理器的定址范圍，可以使用更大的內存。而對於VS這種並非內存敏感的程序，並不十分需要遷移到64bit下。

另外，還有一個歷史原因，就是微軟一直沒有完成64bit下的JIT調試器的EditandContinue功能，這是因為64bit的JIT是C＋＋團隊做的，和原生CLR團隊的32bitJIT有很多不同。

如果微軟推出了64bit的VS，那麼調試的體驗會受到限制，這也是為什麼微軟一直以來沒有推出64bitVS的原因。

Ⅲ 64位linux編譯32位程序

在64位的Linux下，gcc 編譯 32 位程序需要添加參數 -m32 ，ld需要添加參數是 -m elf_i386。
1、Along with the -m32 flag in gcc, you may need to include the -melf_i386 flag for ld to properly link the 32bit object files to the 32bit libraries if you have both the 32bit and 64bit libraries.
2、 ld命令 ld命令是GNU的連接器,將目標文件連接為可執行程序。
3、舉例：

gcc -m32 -o hello hello.c

gcc -m32 -c hello.o hello.c
ld -m elf_i386 -o kernel main.o hello.o

Ⅳ 編譯64位程序無法使用32位編譯的lib么

編譯64位程序，不一定要編譯機器是64位的，但是32位機器默認安裝的gcc編譯環境還是不能用來編譯64位程序。編譯64位程序，需要加上-m64編譯器參數，默認安裝的gcc已經支持該參數，但是缺少64位機器指令相關的文件，所以不能編譯，會出現下面的錯誤 In file included from /usr/include/features.h:378, from /usr/include/assert.h:37, from ../../../include/tinyxml/tinystr.h:42, from ../../../src/tinyxml/tinystr.cpp:32: /usr/include/gnu/stubs.h:9:27: error: gnu/stubs-64.h: 沒有那個文件或目錄這時候需要安裝 gcc所有支持文件 sudo apt-get install gcc-multilib 將會安裝下列額外的軟體包： cpp-4.4 g++-4.4 gcc-4.4 gcc-4.4-base gcc-4.4-multilib lib64gcc1 lib64gomp1 libc6-amd64 libc6-dev-amd64 libgcc1 libgomp1 libstdc++6 libstdc++6-4.4-dev 建議安裝的軟體包： gcc-4.4-locales g++-4.4-multilib gcc-4.4-doc libstdc++6-4.4-dbg libmudflap0-4.4-dev libgcc1-dbg libgomp1-dbg libmudflap0-dbg libcloog-ppl0 libppl-c2 libppl7 lib64mudflap0 libstdc++6-4.4-doc 下列【新】軟體包將被安裝： gcc-4.4-multilib gcc-multilib lib64gcc1 lib64gomp1 libc6-amd64 libc6-dev-amd64下列軟體包將被升級：

Ⅳ 為什麼好多軟體都區分32位和64位，到底有什麼區別

64位軟體和32位軟體最大的區別是：64位的軟體可以同時操作大於4GB的內存（注意這里的內存指的是地址空間，而不是物理內存）。

但是，上述過過程有幾個非常重要的地方：

1）動態鏈接庫

2）系統API首先，你32位的操作系統上一般是沒有64位的庫文件，如果你的應用程序源代碼中引用了只有64位的動態庫中才有的函數，很顯然你鏈接的時候就會出問題。

另外，我們很多程序肯定用到了read和write等C語言庫函數，而庫函數的實現是依賴於系統API的。如果你工作在windows上，程序大多數是以exe形式發布的，你得到的程序是目標文件以後的結果，本身是帶有位數的；如果你工作在linux上，本身大部分軟體包rpm等也是已經編譯好的，就是說，它們本身就是具有「位數」的。

如果你得到的是源碼，那麼基本上你的應用程序還沒有「位數」的概念，你用多少位的編譯器去編譯它，它就是多少位的應用程序。我們這里討論多少位的程序，都是針對已經編譯到目標文件以後的狀態。所以32位和64位軟體的並存是CPU、系統、編譯綜合決定的，而這些都是因為時代的需要。

對於Windows系統而言，64位的系統上往往有32位的庫和其他必要的信息，基本上能兼容32位的程序。以上是個人的一些經驗和總結，希望可以幫助到大家，如果有不同意見和建議，歡迎評論區留言討論。