Visual studio compiler configuration still use gcc.exe

[larienna]

Background

I am trying to make a small service program in plain C that is going to read bluetooth and TCP/IP. In order to do so, I need to use the Windows SDK, but I get compilation errors with due to invalid "__w64" constants. Considering I cannot find which value the compiler passes to the "__w64" constant, I decided to use Visual studio 2019 compiler into code blocks since I cannot successfully make a "Hello World" inside Visual Studio. (that's another story). It could fix my "__w64" issues else Using MinGW64 instead of 32 would be my next solution.

Problem

I found a PDF online that list a series of step consisting in defining Global variables with all the necessary path, and then changing the compiler settings with those variables. I used MSVC 2010 configuration,  I set the global variable in the "Toolchain executable" tab,  and all the programs have the right file name: "cl.exe", "link.exe", etc. In my project build option, I selected the "Microsoft Visual C++ 2010" compiler where my config should be.

Now when I try to compile the program, it stills try to compile the project with gcc.exe even if the executables are set to cl.exe. Here is an example of output, as a proof, it adds the "/wp64" option which is MSVC specific but with the gcc execuatable.

Code

gcc.exe /Wp64 -Wall -std=c99 -g -Isrc -c "C:\Program Files\Git\CVP\service\src\test.c" -o obj\Debug\src\test.o
gcc.exe  -o bin\Debug\cvps.exe obj\Debug\src\main.o obj\Debug\src\test.o   -lws2_32
gcc.exe: error: /Wp64: No such file or directory

How can I tell the C::B to use cl.exe, instead of gcc.exe?

[sodev]

Fix your code. The define __w64 is deprecated and got removed in Visual Studio 2013 (https://docs.microsoft.com/en-us/cpp/cpp/w64?view=msvc-160). If you can't compile with Visual Studio 2019 it is very likely you also can't compile with the MSVC compiler in CodeBlocks.

You must have messed up your CodeBlocks configuration badly, the command line shows the gcc call with gcc style parameters but the Wp64 parameter (which is also deprecated) uses MSVC style. Better start again from the MSVC 2010 configuration, create a copy of it and modify that one. And make sure your project actually uses that copy, by default it uses the gcc compiler.

[larienna]

The define __w64 is deprecated and got removed in Visual Studio 2013

This error happens when I try to use gcc, because I was not sure if I could do operating system programming with the WinSDK with gcc instead of MSVC, So I gave it a try and compilation fails due to the the Windows SDK headers have this __w64 definition. I used the Windows 7.1 SDK since I have windows 7. Visual studio 2019 wanted to install SDK 10. So I guess if I want to use SDK 7.1 to be able to run on windows 7, I'll need to deal with __w64. If I could just know what value __w64 should have, I could use the parameter "-D__w64" during compilation to set the value.

So this is why I thought that since Visual Studio is already installed, I could use it to compile with Code::Blocks instead. Maybe MSVC would define the appropriate missing variable. I found this guide to help me in the process.

https://github.com/arnholm/cpde_utils/blob/master/doc/toolchain/CodeBlocks_MSVC2019_setup.pdf

But it seems I did not passed entirely thought all the steps (Or I was missing pages). I take a look at it again, but there is a lot of things to setup, so it's easy to forget something. I also found this document from the same author but it seems older:

http://arnholm.org/org/archive/CodeBlocks_MSVC_setup.pdf

Still, if I could avoid using MSVC and stick only to GCC, I would gladly do it. But I doubt I would be able to do socket programming for TCP/IP and Bluetooth, with process forking using GCC and the WinSDK.

Better start again from the MSVC 2010 configuration, create a copy of it and modify that one.

So that is how you create a new config, you clone one that already exists.

And make sure your project actually uses that copy, by default it uses the gcc compiler.

In the top level target, I switched the compiler for MSVC.

[sodev]

I am not an expert about such Windows internals, but so far i always used the default Windows SDK shipped with MSVC and i didn't have any problems creating applications for older Windows releases. With MSVC 2015 even today i still target Windows XP. Your problem is that you are using an old SDK that uses features that are removed in your recent compiler. You don't have to use that old SDK to target Windows 7, you can use the latest Windows 10 SDK, but you might need to limit the API level by setting the proper define.

Looking at GCC, the problem is more difficult. GCC, or better the MinGW distribution, doesn't use the Windows SDK from Microsoft but uses an own variant. This does not offer the full abilities the Microsoft one offers. Socket programming works without problems (although i don't recommend using raw sockets in 2021), Bluetooth might work or not, i don't know.

Your referenced documentation to setup MSVC with CodeBlocks is kind of the premium variant, it tries to offer everything that MSVC offers with the flexibility to easily change version numbers. Most probably you don't need everything of that, you can also do it without all these global variables, at the price that you need to update quite a bunch of paths after most MSVC updates. I have posted my setup in the past, sadly its very outdated for MSVC 2019. I have a more recent configuration i am using now with MSVC 2019 (and Bluetooth works with that one because i'm using that in one of my applications ), but i didn't update my MSVC 2019 in a long time, so all paths are wrong again. I could post it as-is, but that configuration won't work without updating the paths.

[larienna]

Thank you for clarifying the WIndows SDK versionning.

It's interesting to know gcc has a partial SDk implementation, where can I download such SDK. Is it in the MinGW installer?

[cacb]

I am the one who wrote that MSVC configuration document.

I have been using MSVC with Code::Blocks since Visual Studio 2005 and now using Visual Studio 2019. The idea with the global variables is that it makes it possible to isolate the C::B project file from a particular MSVC version (to some degree) and also allow using MSVC Professional vs. Free editions on different computers without modifying the C::B project file.

If your project is still compiling with gcc it is likely your project compiler is declared as "gcc".

What I do is to create a generic MSVC compiler called "msvc" as described, and then use the "msvc" compiler in the projects. Btw. I also use a custom project file generator that simplifies this, it runs as a separate tool although it could have been made as a C::B plugin probably. It creates msvc and gcc build targets so I can build on Windows using msvc and gcc on linux https://github.com/arnholm/cpde_utils/tree/master/cpde_pwiz
It uses the UserTemplates folder to generate projects of different kinds by simple text search/replace

[larienna]

Instead of trying a bluetooth example, I compiled a TCP/IP example using gcc. It worked, but I had to add the following define before the includes for the compilation to work:

Code

#define _WIN32_WINNT 0x0501

So TCP/IP is supported by MinGW, but not bluetooth. Then I completed the tutorial made by cacb and it now called cl.exe correctly. But even if I set the includes path correctly, it cannot find "winsock2.h" and "corecrt.h". The second file does not seem to exist on my hard drive.

The next solution would be to try upgrading the Win SDK to 10 if I really need MSVC.