Guys that is code copied from a book (Programming Windows 5th edition):
#include <windows.h>
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
PSTR szCmdLine, int iCmdShow)
{
MessageBox (NULL, TEXT ("Hello, Windows 98!"), TEXT ("HelloMsg"), 0) ;
return 0 ;
}
Link to the topic in which this book is recommended.
Can't compile it with VS2010. What am I doing wrong?
Error 1 error LNK2001: unresolved external symbol _WinMainCRTStartup
Thanks.
It will depend on how you set up the project. In VS2010, if I create a new project via File->New->Project, Visual C++, Empty Project, then add a new C++ file, and copy your code in, it compiles and runs just fine.
If you've created a different type of project, it may be using different link libraries. Try right-clicking on your project in Solution Explorer, going to Properties->Linker->System, and setting SubSystem to "Windows (/SUBSYSTEM:WINDOWS)
The Win32 APIs are old, but for the most part are perfectly usable if you want to do native Windows programming. Windows has done a great deal of work to ensure that as long as you've followed the documentation, old APIs will not change. You can still compile 16-bit Windows 3.1 code from 1992 and run it on 32-bit Windows 7.
Edit:
It could also be that in Properties->C/C++->Advanced, you have Omit Default Library Name set to "Yes", you probably want it set to "No"
Or also Properties->Linker->Input->Ignore Default Libs should be set to No.
You need to set the project's linker settings to create a Windows GUI program rather than a console program:
"Linker/System/SubSystem" should be set to "Windows (/SUBSYSTEM:WINDOWS)"
Usually this setting gets set properly when you create the project and choose a Windows GUI Application template. Unfortunately, if the project is set to the incorrect application type, the setting is a bit buried (it took me bit of digging to find it).
Make sure you have actually added the source file to the project. This worked for me.
Related
Using VS2022, I created a c++ (ver 14) console app. This app needs to have no UI or console window, which is working. In order to implement no UI or console window, I changed the default 'Main' to
int WINAPI wWinMain(HINSTANCE hInst,HINSTANCE hPrevInst,LPTSTR lpCmdLine, int cmdShow) However, I'm having issues when switching to Release mode, which I could use some assistance with.
The first problem is a link error, when I change to Release mode, LNK2001 'unresolved external symbol _main. A google search I found suggested adding back the default int main(int argc, char argv)**, in addition to the wWinMain. This did allow for a successful compile/build. The issue is, in debug mode, the entry point is wWinMain, in Release mode, the entry point is main(...). I'm not sure why this is occurring or how to go about fixing it. Help is appreciated.
I'm unable to run the app in Release mode but I am in Debug mode.
As comments pointed out, /SUBSYSTEM specifies the Windows subsystem targeted by the executable. You can set this linker option in the Visual Studio development environment.
The /SUBSYSTEM option specifies the environment for the executable.
The choice of subsystem affects the entry point symbol (or entry point
function) that the linker will select.
I have searched for an answer on the Internet, but with exceptions of the difference between modal and modaless dialog boxes, I couldn't find anything useful for my question.
As written in the title, my question is - how can I implement/use a Windows version specific design for my dialog box? IOW, use the Windows 10 button style on a Windows 10 system.
I am using Visual Studio, and I have created a simple resource for my dialog using the integrated resource editor.
Here is my programm:
int CALLBACK WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
DialogBox(hInstance, MAKEINTRESOURCE(IDD_DIALOG1), NULL, NULL);
system("pause");
return 0;
}
Right now, when I compile this code, the console and the dialog box appear on the screen, but the dialog box controls (buttons) seem to be shown in the Windows 2000 style. I'm using Windows 10.
I have this style:
I want this style:
You need to opt in to comctl32 v6 in your manifest: Enabling Visual Styles.
To enable your application to use visual styles, you must use
ComCtl32.dll version 6 or later. Because version 6 is not
redistributable, it is available only when your application is running
on a version of Windows that contains it. Windows ships with both
version 5 and version 6. ComCtl32.dll version 6 contains both the user
controls and the common controls. By default, applications use the
user controls defined in User32.dll and the common controls defined in
ComCtl32.dll version 5. For a list of DLL versions and their
distribution platforms, see Common Control Versions.
If you want your application to use visual styles, you must add an
application manifest or compiler directive that indicates that
ComCtl32.dll version 6 should be used if it is available.
An application manifest enables an application to specify which
versions of an assembly it requires. In Microsoft Win32, an assembly
is a set of DLLs and a list of versionable objects that are contained
within those DLLs.
I have one project whose .SLN file is there and we are able to run the project on Visual Studio 2008 and In which we have qt extension added that we are using In our project.
I have tried to create .pro and pri using following link:
Converting .Sln Project to .pro Project
I have able see related lib and manage to add required file. But the Code is too specific to VS.
I am getting Issue Like :
1) Cannot Convert from TCHAR to Const Char*
2)cc1plus.exe: error: one or more PCH files were found, but they were invalid
3)cc1plus.exe: error: use -Winvalid-pch for more information
4)cc1plus.exe: fatal error: release\StdAfx.h: No such file or directory
5) error: conflicting declaration of C function 'int WinMain(HINSTANCE, HINSTANCE, LPTSTR, int)'
int _tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow)
From these I came to conclusion that the code is more specific to Visual Studio.
I am using following tools pls correct me If I am not using correct version:
1)Qt Creator 3.6.1
Based on Qt 5.6.0 (MSVC 2013, 32 bit)
Is there any specific way to port code from VS2008 to Qt 5.6 or 5.7.
What you already did - I guess - is to migrate the visual studio project file to a Qt one. However, if you want to fully migrate to Qt and write a cross-platform application, you should replace all MFC-specific code to Qt, which is very different. For instance WinMain is (as expected) specific to windows: you should have a simple main. In there, you would need to define a QApplication, and so on...
My advice would probably be to start with some small Qt samples before tackling a full-fledged migration. You can then come back with more specific questions to stackoverflow if you get stuck.
Using MSVC compiler Could solved the Problem !!!!
It's just trivia.
Microsoft tried to introduce international characters to Windows too early, before the Unicode consortium had done its work, and got everything in a twist. So the Windows functions can be passing string about as various things, plain ascii, w_chars, TCHARS and so on. You need to make everything consistent. Every Windows function that takes a string has two forms, A for ascii or W for wide.
You need to make everything consistent and make sure the the functions are getting the right forms. Which might involve inserting a few glue functions to convert strings from wide to ascii and back.
There's nothing deeply wrong, but it is a bit of a job.
I keep getting this error message as a result after every Debug run I have done on any of my projects in VS2003.
I have browsed around many forums and they all provide an answer that does not fit to the actual problem.
LINK : fatal error LNK1201: error writing to program database 'd:\Coding\Flyff\Projects\GUI System 20110721\Debug\GUI System 20110721.pdb'; check for insufficient disk space, invalid path, or insufficient privilege
I'm using Windows 7 Ultimate x64 with Visual Studio 2003 .NET (service pack VS7.1sp1-KB918007-X86.exe).
What I have tried already:
Run in compatible mode for several other operative systems and service packs.
Set project folders write permission to full.
Run Visual Studio as Administrator.
Edited Debug Information Format to several other formats.
To reproduce this bug, you must have Windows 7 x64 (probably Ultimate).
Visual Studio 2003 (with VS7.1sp1-KB918007-X86.exe update).
I have over 150 GB space so it has nothing to do with that.
Visual Studio simple locks the PDB file when debugging, and after debug it cannot unlock it.
You must also run a code piece that is running for a few seconds, such as this:
int APIENTRY WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow )
{
Sleep( 5000 );
MessageBox( NULL, "Test", "", 0 );
return 0;
}
Hope anyone have a solution, as I'm currently required to use this environment configuration.
Cheers, Nicco.
I have finally found a workaround solution for this problem that has been plaguing me for quite sometime:
1) Download and install LockHunter (free utility to unlock locked files):
http://lockhunter.com/download.htm
2) Add the install directory of LockHunter to your environment variable "path" to avoid annoying administrator privilege popups every time you run the utility. For me (using x64 version) it was:
"C:\Program Files\LockHunter"
3) Add the following pre-build event to your Visual Studio project that is experiencing the issue:
"LockHunter.exe /silent /unlock $(TargetDir)$(TargetName).pdb"
The only time I have encountered this issue with VS2003 is when it crashes during a debug session. Usually the problem can be remedied by restarting VS. If that doesn't work you have to restart the debugger service and in some cases Windows.
You can try adding the following to command line of the pre-build event
net stop "Machine Debug Manager"
net start "Machine Debug Manager"
Since either VS or the debug manager is keeping the file locked I fear this problem is caused by a much deeper issue. There is a good chance that either a problem exists in your VS installation or there is another service or application causing the debug manager and/or VS to behave badly.
I encounter this error with VS2010 and tried fixing it using methods suggested in forums but they never worked for me. At the end I exited VS2010 and restarted as Admin and that did the trick!
I have the same inssue with winXP SP3 and VS C++ 2010 Express, and i solved changing the MyProject folder Access Permissions, uncheking "read-only" and apply to all folders, subfolders and files.
Non of the above answer work in my case, But finally I found my Solution.
When scale of the project grows and size of the ".pdb" file exceed 300MB, the error accrued.
I change debugging info properties in my project and successfully compile it.
You just need to change "Debug information format" in your project to "C7 compatible (/Z7)" in the following path.
Configuration properties >> C/C++ >> General >> Debug Information
Format
Had similar problem on Windows 10. This answer provides a solution using a tool called FreePDB.
We've just recently switched our C++ MFC Application from VS2005 to VS2008. Unfortunately in doing so our UI has appearance problems, with things like group boxes appearing blue rather than black, properties dialogs having a white background etc. I presume that in VS2008, MFC has been changed to respect the OS theme (in my case XP default theme). Unfortunately, changing all our controls and our custom toolbars to make the app look decent again is going to require a lot of work.
So, does anyone know if there is a way in code to put the app back in VS2005 mode? I found the following code
typedef void (WINAPI *tSetThemeAppProperties)( DWORD );
tSetThemeAppProperties pSetThemeAppProperties=0;
HINSTANCE handle = ::LoadLibrary("UxTheme.dll");
if (handle)
pSetThemeAppProperties = (tSetThemeAppProperties) ::GetProcAddress(handle,"SetThemeAppProperties");
if ( pSetThemeAppProperties)
{
// call function
pSetThemeAppProperties(0/*dwFlags*/);
}
::FreeLibrary(handle);
Which does stop the XP theme being picked up, but turns off ALL themes and leaves the application looking more dated than it did in VS2005.
thanks
It may be that VS2008 is including a Manifest file in the project that loads the version 6.0 comctl32.dll rather than the 5.82 comctl32.dll... both ship with Windows XP and newer.
Under "Properties->Configuration Properties->Linker->Manifest File", set the "Generate Manifest" option to "No".
Then add your own manifest file if you like, and set it under "Properties->Configuration Properties->Manifest Tool->Input and Output", "Input Resource Manifest".
Just make sure that if you add your own manifest file that it doesn't contain the reference to commctl32 v6.