Precautions for program development on Windows x64

From: http://hi.baidu.com/cshacker/blog/item/bd13fff989cf8950242df268.html

Plus http://school.cnd8.com/windows-xp/jiaocheng/38341.htm

In Windows, the differences between 32-bit and 64-bit are as follows:

1. Differences in Pointer size. sizeof (int *) contains 4 bytes under 32 bits and 8 bytes under 64 bits.
2. size_t difference. size_t has a range of 4 bytes under 32 bits and 8 bytes under 64 bits.
3. What is the difference between address spaces? Under 32 bits, the maximum address space is 4 GB, and under 64 bits, it can be larger than 4 GB.
A 4.32-bit program runs on a 64-bit windows system with a wow64 sub-system. By default, access to the registry and some folders is redirected.
5. pointer difference also means handle difference
6. The only msvc compiler that supports windows original 64-bit compilation does not support 64bit inline assembly. If you want to use assembly, you need to compile it separately and then link
7. The function call methods of pure 64bit programs no longer distinguish between cdecl and stdcall, because there is only one method.
8.64bit programs no longer use ESP, but use the added 64bit registers, because ESP does not support 64 bit space stacks.

The latest work involves 64-bit Linux work. I found that I didn't know much about the differences between 32-bit and 64-bit:
1. Long in windows, both 32bit and 64bit, are 4 bytes, but in Linux, 32bit is 4 bytes, and 64bit is 8 bytes. (Long is 8 bytes at 64 bits)
2. GCC does not support _ attribute (cdecl) _ and _ attribute (stdcall) __under 64 bits. This is a bit similar to Windows, I thought it was not supported by GCC later versions. Later I found the difference between x86 and x64

Development Suggestions for 64-bit windows:

1. Avoid system. badimageformatexception

Generally, programmers encounter this situation: "an unprocessed type exception occurs, 'System. badimageformatexception '". If you want to delve into the details of the exception, you may find the system prompts: "The program to be loaded, the format is incorrect ".

This problem occurs because a 64-bit process tries to load a 32-bit component. Although you can run 64-bit and 32-bit processes on Windows x64, 64-bit and 32-bit codes cannot run on the same process. Your code is either 64-bit or 32-bit. The components to be loaded must also comply with this rule.

VS 2005 and. NET 2.0 provide a choice for compiling. NET applications, and setting the input to "any CPU" is also optional. "Any CPU" is the default platform. If the component uses any CPU as the platform for compilation, it runs in 32-bit or 64-Bit mode based on the process load. Using any CPU, the same component can run in 32-bit or 64-Bit mode on 64-bit windows: it does not really specify a 64-bit CPU or operating system, but a call process.

To solve the problem of unqualified image exceptions, we need to change it to the Target Platform of all components of any CPU. If you cannot do this for some reason-maybe a component cannot provide a source-you need to set all components to the same platform, either x86 or x64. If you have. NET 1.0 or 1.1 components, it is best to use. NET 2.0 to re-compile them. If you cannot compile. NET 1.0 or 1.1 Components, compile other code to reach the x86 Platform for compatibility.

2. Size issues

An important difference between 64-bit and 32-bit windows is the handle size. If your code has any Windows API calls, make sure that your instructions are correct for 64-bit windows. If the code is upgraded from VB6, you cannot distinguish between the handle and 32-bit integer. Therefore, you must find the source file or header file. Identifies which parameters and fields are handles and uses these types of intptr. Generally, the file is identified by int_ptr or long_ptr, or the name is only a certain type of handle, such as hwnd. Parameters defined with a prefix, such as PTR or lptr, are usually indicators, so they need to be considered intptr or use byref grouping. You can check the value of intptr. size at runtime to determine whether you are running 64-bit or 32-bit.

3. com can be 64-bit

The common misunderstanding is that com and ActiveX are limited to 32-bit, but with VB. NET, you can use 64-bit COM and ActiveX controls. Windows does not have a 64-bit compiled control, but one of the notable exceptions is the sysmon. ocx ActiveX control, which allows you to create a system monitoring chart.

You can use the 64-bit ActiveX control in the windows. Forms Application, but there is a buffer when compilation is involved. VS is currently a 32-bit application. It requires a 32-bit ActiveX Control during assembly so that the COM component packaging that can be enabled at runtime can be created. To compile in Vs, you need a 32-bit version. Once the program is compiled, you only need to select the platform.

If you do not have a 32-bit or similar version, you can use the command line to run a 64-bit tool to create an InterOP assembly for ActiveX controls. See the tlblmp.exe file for details.

4. Be aware of the problem

When a 32-bit application runs on Windows 64, it runs with the simulator. The simulator is called wow64. It is short for Windows on windows64 and allows 32-bit applications to be viewed according to the 32-bit operating system. The wow64 simulator loads an x86 version of NTDLL. dll, provides the entry point and replacement program, and captures the most important registry and file system operations.

The wow64 simulator also exposes different environment variables suitable for 32-bit applications. Therefore, a 32-bit application converts the environment variable of ProgramFiles to ProgramFiles (x86 ). When running in 64-Bit mode, if you write code similar to msgbox (Environ ("ProgramFiles"), you will get "C: \ Program Files". If you run in 32-Bit mode, obtain "C: \ Program Files (x86 )".

What the simulator does is similar to the Registry and system directory. For compatibility and performance considerations, the % Windir % \ system32 folder is a 64-bit folder. That is to say, there is no interception in the 64-bit application. The default 32-bit operation folder for redirection is % WinDir % \ syswow64. The name syswow64 indicates that it will be used by the 32-bit simulator wow64. This may be confusing.

The Registry under wow64 is used in combination with redirection and reflection. Redirection exists under keys such as HKEY_LOCAL_MACHINE \ SOFTWARE \ wow6432node. At least the naming style in the registry is better. A ing is a 32-bit process and a 64-bit process that can both edit the common key, such as file association. On the other hand, the redirection is to ensure 32-bit isolation from 64-bit.

The key is that execution does not affect you unless you plan to obtain details about the 32-bit program from the 64-bit program, and vice versa. It is much easier to compile data to the same target. For example, if you want to use Vs and lock the program to x86, you do not need to worry about the file or registry simulation process. If you want to run a program with any CPU, it depends on how it is started. Maybe you want to use redirection and call APIs similar to getsystemwow64directory, and use regopenkeyex API, including the access illusion of key_wow64_32key. It may become a chaotic and complex test. This is the best Compilation Method for the same platform and locking information so far.

One problem that I accidentally discovered was the combination of registry reflection and Windows Vista UAC. In the HKLM beehive used for write permission, the author opens a key, and the API is successful, but when the author writes to the key, it fails. The application runs on Windows 64 in 32-Bit mode, so the problematic key is mapped. The author wasted a lot of time to determine what happened, because the Registry API will not work as usual. Finally, I include a shipping ticket to the application to make it run normally. This vulnerability can be fixed even if requestedexecutionlevel has a level setting for asinvoker.

UAC provides Registry virtualization. I think there are too many combinations of wow64 redirection or reflection and UAC virtualization. Now I usually make sure that there is a carry order in the application. In vs 2008, you can obtain the carrying ticket from the program tag in the Project Properties dialog box. Make sure you include the requestedexecutionlevel option.

5. Activate edit and continue

Although you can debug 64-bit applications, you cannot use Edit and continue during debugging. This means that you cannot change the source code during debugging. On the contrary, you need to stop, change the application, re-compile and start debugging. But you can use the 32-bit program to use Edit and continue, even on 64-bit windows. This is another example of manual configuration building.

Create an x86 build configuration and use this configuration during development so that you can use Edit and continue. Switch the configuration to x64 or any CPU for testing.

Windows 32 or Windows 64 is not as difficult as VB 8 or vB 9. When vs is used and the configuration is built, the task becomes simple.