C # migration from a 32-bit system to a 64-bit System

I used C # in the previous section.ProgramNow we need to support the 64-bit system.

The first step is to support the program to Windows Server 2003 and Windows Server 2008 systems. Because my program is tested and compiled on XP, it won't be a problem to take it directly.

However, errors are always reported during running. No way. I installed vs on Server 2003 for step-by-step debugging and found that every time I run the DLL that calls C ++, an error will be reported:

"Try to read or write the protected memory. This usually indicates that other memory is damaged"

However, I have passed the execution of several previous DLL calls, and it also runs well on XP.

If you try N for a long time, it will not work, and the methods for changing parameters will also fail.

No matter what you do first, use the most stupid method. If you do not pass the execution, I will bypass it. Fortunately, you can use other methods to achieve your goal. In this way, all the 32 platforms have passed.

Generally, 32-bit programs can run 64-bit systems. However, there is still a problem during actual transplantation. When calling the C ++ DLL

"Try to read or write the protected memory. This usually indicates that other memory is damaged"

But this time, it's hard to understand.

What the hell is going on? A 64-bit database won't work either. Is the memory mechanism different?

After searching for N long, I saw an article in my despair.ArticleIn this article, we will talk about some problems when porting a 32-bit system to a 64-bit system ". Slave, since it is running in 64-bit, why should it be set to "x86?

I tried again without reporting hope, and the result was actually successful.

The cause of the problem is here. Then I checked some information and put it here.

Vs compilation target platform has three options: anycpu, x86, and x64. if a program is compiled into anycpu, the program will contain two sets of programs with the same logic and one set is used on a 32-bit system, the other is used in a 64-bit system. The cause of the problem is here.

If you use anycpu to compile a 32-bit systemCodeIf the Code calls 32-bit COM, it runs in 32-Bit mode on the 32-bit system, and the 32-bit app calls 32-bit COM, of course there is no problem. However, if someone else calls your program on a 64-bit system, the program uses a 64-bit app to call 32-bit COM.

Of course, here I set platform to "x86" during compilation, but only generated code specific to the 32-bit intel X86 compatible processor platform. The generated assembly is based on the pe32 format, it can be run in the wow64 subsystem, so of course it can run in a 64-bit system.

It takes a lot of effort to write programs in a native 64-bit system.