Build errors in visual studio win32 and x64

Asked 1 years ago, Updated 1 years ago, 30 views

I implemented C++ using visual studio 2017 professional, and when I loaded the existing solution, I built/rebuilt it. If I set the configuration manager to win32, the build itself will be successful.

 Unable to start 〇 ddll.〇 ddll is not a valid win32 application.

and error dialogs appear.So when I made it x64 and built it, it was an error that didn't output earlier.

 Invalid type conversion

The build fails with some errors.

I would like to know the cause and solution of why the build went through with win32 but the build doesn't go through with x64.

c++

2022-09-30 19:47

1 Answers

WPARAM is a 32-bit value in 32-bit environments and a 64-bit value in 64-bit environments, while UINT is a 32-bit value in both environments.Therefore, if you force the cast to receive WPARAM from a function that originally takes the UINT as an argument, the purpose of passing the pointer will not be achieved and will not work.

intg(UINTw,LONGu) {return 0;}
int(*p)(WPARAM,LONG)=g;//C2440
p=static_cast<int(*)(WPARAM,LONG)>(g);//C2440
// Reinterpret_cast doesn't work as expected, so there's no point.

The source code is probably before x64 became popular, and it is written without being aware of the 64-bit version.Many of the source codes at that time were written with the same assumption that the integer and pointer sizes were the same (I have also written Oira).

https://www.wdic.org/w/TECH/LLP64
The 64-bit version of Windows uses the LLP64 model, so the int and UINT are 32-bit and the pointer is 64-bit.Therefore, the code written on the assumption that the integer and pointer types are the same size will need to be corrected.

  • When exchanging pointers in window messages, INT_PTR instead of INT
  • Using SetWindowLongPtr instead of
  • SetWindowLong

and so on.

Judging from the presented error message, it seems to work if the code changes the temporary argument type of the function to UINT to UINT_PTR (although it's delusional level because there's no source code presentation)

I don't think it's just one place, so I think we need to review the whole project.If the project properties show "Yes" for 64-bit porting (isn't it supposed to be, right?), a warning will be issued in the incompatible parts of the project, so if everything is dealt with, it will be 64bit.Changing the model name, changing it to a compatible extension function, and if you know it, it can be simple, but if you don't know it, it's very difficult and the amount can be enormous.

First of all, it would be better to have someone who has experience with 32-bit/64-bit transplants and who has knowledge of them look at them.

You need EXE to run DLLs, but that's OK, right?


2022-09-30 19:47

If you have any answers or tips


© 2024 OneMinuteCode. All rights reserved.