I'm new in Visual Studio and I tried to compile a code which uses the VirtualProtect function. Compilation failed, I was expecting a linking issue first but after further investigation, even the function's constants weren't initialized, so the problem seems to came from the header.
I've found the header file of VirtualProtect function (memoryapi.h included by winbase.h included by windows.h), and the function's declaration depend to this statement :
#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
It seems it's a macro used to define what APIs the compiler should use according to the platform.
Then, how can I change the configuration of my project to set it as a pure desktop app ? I don't know why VS insists to create a Windows Phone version of everything I'm compiling...
You may have taken the wrong Express: According to this page, there are "Express 2013 for Windows" and "Express 2013 for Windows Desktop"; you need the latter.
Related
I have an SDK for some Hardware I need to implement
I use The MFC Class they provide and created a windows console application.
They heavily rely on the Trace Macro so i cant simply comment them out.
I already manually installed the ATL + MFC Component for visual C++
I installed the 2015 Compiler (as i read they changed something ...)
I disabled precompiled headers
I tried "switching" some options in Project properties, but that did not yield anything different :(
TRACE(_T("PS10DLL not found\n"));
I would expect to compile smoothly but the Error (they used it alot) is:
error C3861: "TRACE": Identifier was not found.
According to your issue, you are creating a windows console application? TRACE is used in the MFC support program and cannot be used in the WIN32 Application program.
TRACE is a definition in MFC. In Win32 code, you can directly use OutputDebugString to achieve the same effect.
I suggest you could refer to the link: How can I use the TRACE macro in non-MFC projects?
I'm having a problem with a Visual Studio project and IntelliSense. Since upgrading to VS 2017 (it worked fine in 2010), IntelliSense has been complaining that standard library functions do not exist (For example: time, memcpy, rand) with the error identifier "time" is undefined.
Additionally, some (but not all) standard header files give the error that they cannot be opened. For example, the source file I'm viewing right now claims cannot open source file "direct.h", while header files like winsock2.h are not a problem.
I suspect the problem lies completely within IntelliSense, since the project compiles fine and all 'unindentified' functions run and perform as expected. However, I have no idea which setting to change or how to reset IntelliSense in order to once again recognise the different identifiers.
You know my question. Here is the longer version. Downloaded 2017RC, it took me a day to set it up to work with UCRT, CMake, Google test and all the goodies. Then I tried to associate the usual hpp, h, cpp extensions two ways:
Control panel -> Default Programs -> Set Default Programs, choose Visual Studio 2017RC and then -> Set Program Associations where all the possible extensions that can be handled by this program are listed. None of the usual C++ extensions are listed.
Right click on a .cpp file, Open with, visual studio 2017 RC doesn't show up in the apps list, hunt it down and click on it. A dialog box pops up saying that The program you have chosen cannot be associated with this file type.
FYI, currently all the c, C++ extensions are associated with Qt. Am I to think that RCs are not expected to have this feature? Or is it some other sub-program within VS, with which the association should be made? Thanks for your help
I had the same problem for Visual Studio 2015. The answer here is a good starting point:
https://superuser.com/questions/977271/windows-10-visual-studio-2015-xaml-file-association
Specifically, modifying "HKEY_CLASSES_ROOT.cpp". I changed the (Default) String value to VisualStudio.cs.14.0 and it now opens .cpp files in Visual Studio 2015.
You would have to use whatever version Microsoft has for Visual Studio 17. Take a look at an existing working file extension to see what it uses.
As usual, backup everything before messing around in the Windows registry.
For what it's worth, Microsoft appears to have fixed this bug, and will apparently be releasing the fix in the next release:
https://developercommunity.visualstudio.com/content/problem/3122/vc-file-association-not-correct.html
In my application I need to check windows version. I'm using Version Helper functions in Visual Studio 2013 (v120) platform toolset. But then the program does not work in Windows XP. error is:
'xxx.exe' is not a valid win32 application
So I changed platform toolset to Visual Studio 2013 - Windows XP (v120_xp). But in this case application will not compile.
The error is:
error C1083: Cannot open include file: 'VersionHelpers.h': No such file or directory
What can I do? Can I use old GetVersionEx function? MSDN says:
GetVersionEx may be altered or unavailable for releases after Windows 8.1. Instead, use the Version Helper APIs
But may be I should use it for now!
I've managed to solve it using Remmy Lebeau's comment.
I copied VersionHelpers.h from C:\Program Files (x86)\Windows Kits\8.1\Include\um and winapifamily.h and sdkddkver.h from C:\Program Files (x86)\Windows Kits\8.1\Include\shared into my project and changed some includes in them.
Now it compiles with Windows XP toolset.
I've tested it and it's working as expected in all versions of windows.
How about this: try to link the functions manually with GetProcAddress to see what is available, If the new API is not, then the old must be, so you can use the one you managed to link without errors.
I am assuming you are building 32bit or 64bit and the OS in both cases is compatible.
EDIT:
GetVersionEx(), here is exported from kerner32.dll in XP, so you can try to link it using
GetProcAddress() here also has a suggestion by Microsft using "GetNativeSystemInfo".
The new API function
IsWindowsXPOrGreater() // also exported from kernel32.dll and ntdll.dll
can also be linked the same way using GetProcAddress(). This function will return an error if the function you are trying to link is not found, so you will know which one you have available. Then you call the available one and get the version info you need.
You only need to define the function prototypes yourself instead of using the headers, then define two function pointers, one for each, then assign them a NULL value initially until you try to link the functions. Then one pointer (or both) will end up with a value, and you can use the latest one available to call the linked API.
I use Visual Studio 2012 to edit source code that is targeting Linux. The problem is that syntax highlighting gets it all wrong, because it thinks _WIN32, _MSC_VER, and similar macros are defined. What can I do to get rid of them?
I tried two methods:
added /u command in the property page for C++;
added /U"_WIN32" /U"_MSC_VER" and so on.
but without any effect. The problem is the same in Visual Studio 2013.
What should I do?
These are compiler-predefined macros. You can only #undef them in the code. Use a custom header file, probably.
Anyway, the requirement seems strange to me. Why do you use MSVC if you want to scan the Linux code? If the Linux code uses any GCC extensions (it often does), it can't compile under MSVC at all.
You can edit them in you're project's configuration.
Right click project->properties->C/C++->preprocessor->preprocessor definitions
I create a test project. The definitions only affected when the code be compiled.