SetProcessDPIAware seems not to work under windows 10 - c++

I am trying to get the real screen resolution (in pixels) in a windows C++ app. When the windows dpi setting is changed, I get the virtual (adjusted) resolution instead of the real one. I have tried using SetProcessDPIAware, SetProcessDpiAwareness (with all three enumerated values as arguments) and a true setting in a manifest. In all three cases, the code works fine (i.e. shows the real resolution) in my windows 7 PC but not in a Win 10 one (here it ignores the DPI Aware setting and returns the adjusted resolution).
#define WIN32_LEAN_AND_MEAN // Exclude rarely-used stuff from Windows headers
// Windows Header Files:
#include <windows.h>
#include <winuser.h>
#include <VersionHelpers.h>
#include <ShellScalingAPI.h>
#include <stdlib.h>
#include <stdio.h>
int APIENTRY WinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow)
{
char *cBuffer2 ;
cBuffer2 = (char *)malloc(3000) ;
if (IsWindowsVistaOrGreater())
{
// SetProcessDpiAwareness(PROCESS_SYSTEM_DPI_AWARE);
int result = SetProcessDPIAware();
sprintf(cBuffer2,"SetProcessDPIAware() result: [%i]\n",result) ;
int height = GetSystemMetrics(SM_CYSCREEN);
int width = GetSystemMetrics(SM_CXSCREEN);
sprintf(cBuffer2,"%s#1:\nHeight: [%i]\nwidth: [%i]\n",cBuffer2,height,width) ;
HWND hwnd = (HWND)atoi(lpCmdLine) ;
HMONITOR monitor = MonitorFromWindow(hwnd, MONITOR_DEFAULTTONEAREST);
MONITORINFO info;
info.cbSize = sizeof(MONITORINFO);
GetMonitorInfo(monitor, &info);
int monitor_width = info.rcMonitor.right - info.rcMonitor.left;
int monitor_height = info.rcMonitor.bottom - info.rcMonitor.top;
sprintf(cBuffer2,"%s#2:\nHeight: [%i]\nwidth: [%i]\n",cBuffer2,monitor_height,monitor_width) ;
}
MessageBox(0,cBuffer2,"SHOWRES.EXE",MB_OK) ;
return 0 ;
}
The manifest I tried using is the following one:
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" >
<asmv3:application>
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<dpiAware>true</dpiAware>
</asmv3:windowsSettings>
</asmv3:application>
</assembly>
Any ideas?

I finally found out what is happening, with the help of Jonathan Potter and Barmak Shemirani: Windows 10, unlike previous versions of windows, allows the user to change the dpi settings 'on the fly', without the need to log out and login again. I was running the tests on a win 10 machine which normally has standard (100%) settings. So I would change the setting to 150%, run the app and get the wrong results.
Jonathan and Barmak's answers indicated that there is something in the specific PC's settings, not in the program or win 10 in general, that was causing my problems. So I tried the following:
- changed DPI settings to 150%
- logged out
- logged in again
- ran the program
And I got the correct results (real screen resolution, vs adjusted one).
So it seems that in order for SetProcessDPIAware (and the related approaches: SetProcessDpiAwareness() and manifest with true) to work correctly, one has to log out and login again after changing the DPI setting and before running the program.
Thanks again, Jonathan and Barmak!

Related

Random crashes on Windows 10 64bit with ATL subclassing

Just from the start: Since March 1st 2017 this is a bug confirmed by Microsoft. Read comments at the end.
Short description:
I have random crashes in larger application using MFC, ATL. In all such cases after ATL subclassing was used for a window upon simple actions with a window (moving, resizing, setting the focus, painting etc.) I get a crash on a random execution address.
First it looked like a wild pointer or heap corruption but I narrowed the complete scenario down to a very simple application using pure ATL and only Windows API.
Requirements / my used scenarios:
The application was created with VS 2015 Enterprise Update 3.
The program should be compiled as 32bit.
Test application uses CRT as a shared DLL.
The application runs under Windows 10 Build 14393.693 64bit (but we have repros under Windows 8.1 and Windows Server 2012 R2, all 64bit)
atlthunk.dll has version 10.0.14393.0
What the application does:
It simply creates a frame window and tries to create many static windows with the windows API.
After the static window is created, this window is subclassed with the ATL CWindowImpl::SubclassWindow method.
After the subclass operation a simple window message is sent.
What happens:
Not on every run, but very often the application crashes upon SendMessage to the subclassed window.
On the 257 window ( or another multiple of 256+1) the subclass fails in some way. The ATL thunk that is created is invalid. It seems that the stored execution address of the new subclass-function isn't correct.
Sending any the message to the window causes a crash.
The callstack is always the same. The last visible and known address in the callstack is in the atlthunk.dll
atlthunk.dll!AtlThunk_Call(unsigned int,unsigned int,unsigned int,long) Unknown
atlthunk.dll!AtlThunk_0x00(struct HWND__ *,unsigned int,unsigned int,long) Unknown
user32.dll!__InternalCallWinProc#20() Unknown
user32.dll!UserCallWinProcCheckWow() Unknown
user32.dll!SendMessageWorker() Unknown
user32.dll!SendMessageW() Unknown
CrashAtlThunk.exe!WindowCheck() Line 52 C++
The thrown exception in the debugger is shown as:
Exception thrown at 0x0BF67000 in CrashAtlThunk.exe:
0xC0000005: Access violation executing location 0x0BF67000.
or another sample
Exception thrown at 0x2D75E06D in CrashAtlThunk.exe:
0xC0000005: Access violation executing location 0x2D75E06D.
What I know about atlthunk.dll:
Atlthunk.dll seems to be only part of 64bit OS. I found it on a Win 8.1 and Win 10 systems.
If atlthunk.dll is available (all Windows 10 machines), this DLL cares about the thunking. If the DLL isn't present, thunking is done in the standard way: allocating a block on the heap, marking it as executable, adding some load and a jump statement.
If the DLL is present. It contains 256 predefined slots for subclassing. If 256 subclasses are done, the DLL reloads itself a second time into memory and uses the next 256 available slots in the DLL.
As far as I see, the atlthunk.dll belongs to the Windows 10 and isn't exchangeable or redistributable.
Things checked:
Antivirus system was turned of or on, no change
Data execution protection doesn't matter. (/NXCOMPAT:NO and the EXE is defined as an exclusion in the system settings, crashes too)
Additional calls to FlushInstructionCache or Sleep calls after the subclass doesn't have any effect.
Heap integrity isn't a problem here, I rechecked it with more than one tool.
and a thousands more (I may already forgot what I tested)... ;)
Reproducibility:
The problem is somehow reproducible. It doesn't crashes all the time, it crashes randomly. I have a machine were the code crashes on every third execution.
I can repro it on two desktop stations with i7-4770 and a i7-6700.
Other machines seem not to be affected at all (works always on a Laptop i3-3217, or desktop with i7-870)
About the sample:
For simplicity I use a SEH handler to catch the error. If you debug the application the debugger will show the callstack mentioned above.
The program can be launched with an integer on the command line.In this case the program launches itself again with the count decremented by 1.So if you launch CrashAtlThunk 100 it will launch the application 100 times. Upon an error the SEH handler will catch the error and shows the text "Crash" in a message box. If the application runs without errors, the application shows "Succeeded" in a message box.
If the application is started without a parameter it is just executed once.
Questions:
Does anybody else can repro this?
Does anybody saw similar effects?
Does anybody know or can imagine a reason for this?
Does anybody know how to get around this problem?
Notes:
2017-01-20 Support case at Microsoft opened.
The code
// CrashAtlThunk.cpp : Defines the entry point for the application.
//
// Windows Header Files:
#include <windows.h>
// C RunTime Header Files
#include <stdlib.h>
#include <malloc.h>
#include <memory.h>
#include <tchar.h>
#define _ATL_CSTRING_EXPLICIT_CONSTRUCTORS // some CString constructors will be explicit
#include <atlbase.h>
#include <atlstr.h>
#include <atlwin.h>
// Global Variables:
HINSTANCE hInst; // current instance
const int NUM_WINDOWS = 1000;
//------------------------------------------------------
// The problematic code
// After the 256th subclass the application randomly crashes.
class CMyWindow : public CWindowImpl<CMyWindow>
{
public:
virtual BOOL ProcessWindowMessage(_In_ HWND hWnd, _In_ UINT uMsg, _In_ WPARAM wParam, _In_ LPARAM lParam, _Inout_ LRESULT& lResult, _In_ DWORD dwMsgMapID) override
{
return FALSE;
}
};
void WindowCheck()
{
HWND ahwnd[NUM_WINDOWS];
CMyWindow subclass[_countof(ahwnd)];
HWND hwndFrame;
ATLVERIFY(hwndFrame = ::CreateWindow(_T("Static"), _T("Frame"), SS_SIMPLE, 0, 0, 10, 10, NULL, NULL, hInst, NULL));
for (int i = 0; i<_countof(ahwnd); ++i)
{
ATLVERIFY(ahwnd[i] = ::CreateWindow(_T("Static"), _T("DummyWindow"), SS_SIMPLE|WS_CHILD, 0, 0, 10, 10, hwndFrame, NULL, hInst, NULL));
if (ahwnd[i])
{
subclass[i].SubclassWindow(ahwnd[i]);
ATLVERIFY(SendMessage(ahwnd[i], WM_GETTEXTLENGTH, 0, 0)!=0);
}
}
for (int i = 0; i<_countof(ahwnd); ++i)
{
if (ahwnd[i])
::DestroyWindow(ahwnd[i]);
}
::DestroyWindow(hwndFrame);
}
//------------------------------------------------------
int APIENTRY wWinMain(_In_ HINSTANCE hInstance,
_In_opt_ HINSTANCE hPrevInstance,
_In_ LPWSTR lpCmdLine,
_In_ int nCmdShow)
{
hInst = hInstance;
int iCount = _tcstol(lpCmdLine, nullptr, 10);
__try
{
WindowCheck();
if (iCount==0)
{
::MessageBox(NULL, _T("Succeeded"), _T("CrashAtlThunk"), MB_OK|MB_ICONINFORMATION);
}
else
{
TCHAR szFileName[_MAX_PATH];
TCHAR szCount[16];
_itot_s(--iCount, szCount, 10);
::GetModuleFileName(NULL, szFileName, _countof(szFileName));
::ShellExecute(NULL, _T("open"), szFileName, szCount, nullptr, SW_SHOW);
}
}
__except (EXCEPTION_EXECUTE_HANDLER)
{
::MessageBox(NULL, _T("Crash"), _T("CrashAtlThunk"), MB_OK|MB_ICONWARNING);
return FALSE;
}
return 0;
}
Comment after answered by Eugene (Feb. 24th 2017):
I don't want to change my original question, but I want to add some additional information how to get this into a 100% Repro.
1, Change the main function to
int APIENTRY wWinMain(_In_ HINSTANCE hInstance,
_In_opt_ HINSTANCE hPrevInstance,
_In_ LPWSTR lpCmdLine,
_In_ int nCmdShow)
{
// Get the load address of ATLTHUNK.DLL
// HMODULE hMod = LoadLibrary(_T("atlThunk.dll"));
// Now allocate a page at the prefered start address
void* pMem = VirtualAlloc(reinterpret_cast<void*>(0x0f370000), 0x10000, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);
DWORD dwLastError = ::GetLastError();
hInst = hInstance;
WindowCheck();
return 0;
}
Uncomment the LoadLibrary call. Compile.
Run the programm once and stop in the debugger. Note the address where the library was loaded (hMod).
Stop the program. Now comment the Library call again and change the VirtualAlloc call to the address of the previous hMod value, this is the prefered load address in this window session.
Recompile and run. CRASH!
Thanks to eugene.
Up to now. Microsoft ist still investigating about this. They have dumps and all code. But I don't have a final answer. Fact is we have a fatal bug in some Windows 64bit OS.
I currently made the following changes to get around this
Open atlstdthunk.h of VS-2015.
Uncomment the #ifdef block completely that defines USE_ATL_THUNK2. Code lines 25 to 27.
Recompile your program.
This enables the old thunking mechanism well known from VC-2010, VC-2013... and this works crash free for me. As long as there are no other already compiled libraries involved that may subclass or use 256 windows via ATL in any way.
Comment (Mar. 1st 2017):
Microsoft confirmed that this is a bug. It should be fixed in Windows 10 RS2.
Mircrosoft agrees that editing the headers in the atlstdthunk.h is a workaround for the problem.
In fact this says. As long as there is no stable patch I can never use the normal ATL thunking again, because I will never know what Window versions out in the world will use my program. Because Windows 8 and Windows 8.1 and Windows 10 prior to RS2 will suffer on this bug.
Final Comment (Mar. 9th 2017):
Builds with VS-2017 are affected too, there is no difference between VS-2015 and VS-2017
Microsoft decided that there will be no fix for older OS, regarding this case.
Neither Windows 8.1, Windows Server 2012 RC2 or other Windows 10 builds will get a patch to fix this issue.
The issue is to rare and the impact for our company is to small. Also the fix from our side is to simple. Other reports of this bug are not known.
The case is closed.
My advice for all programers: Change the the atlstdthunk.h in your Visual Studio version VS-2015, VS-2017 (see above). I don't understand Microsoft. This bug is a serious problem in the ATL thunking. It may hit every programmer that uses a greater number of windows and/or subclassing.
We only know of a fix in Windows 10 RS2. So all older OS are affected! So I recommend to disable the use of the atlthunk.dll by commenting out the define noted above.
This is the bug inside atlthunk.dll. When it loads itself second time and further this happens manually via MapViewOfFile call. In this case not every address relative to the module base is properly changed (when DLL loaded by LoadLibarary/LoadLibraryEx calls system loader does this automatically). Then if the first time DLL was loaded on preferred base address everything works fine as unchanged addresses point to the similar code or data. But if not you got crash when 257th subclassed window handles messages.
Since Vista we have "address space layout randomization" feature this explains why your code crashes randomly. To have crash every time you have to discover atlthunk.dll base address on your OS (it differs on different OS versions) and do one memory page address space reservation at this address using VirtualAlloc call before the first subclass. To find the base address you can use dumpbin /headers atlthunk.dll command or parse PE headers manually.
My test shows that on Windows 10 build 14393.693 x32 version is affected but x64 is not. On Server 2012R2 with latest updates both (x32 and x64) versions are affected.
BTW, atlthunk.dll code has around 10 times more CPU instructions per thunk call as previous implementation. It may be not very significant but it slows down the message processing.
Slightly more automatic form of what was already described:
// A minimum ATL program with more than 256 windows. In practise they would not be toplevel, but e.g. buttons.
// Thanks to https://www.codeguru.com/cpp/com-tech/atl/article.php/c3605/Using-the-ATL-Windowing-Classes.htm
// for helping with ATL.
// You need to be up to date, like have KB3030947 or KB3061512. Otherwise asserts will fail instead.
#undef _DEBUG
#include <atlbase.h>
ATL::CComModule _Module;
#include <atlwin.h>
#include <assert.h>
#include <string>
BEGIN_OBJECT_MAP(ObjectMap) END_OBJECT_MAP()
struct CMyWindow : CWindowImpl<CMyWindow>
{
BEGIN_MSG_MAP(CMyWindow) END_MSG_MAP()
};
int __cdecl wmain()
{
// Exacerbate the problem, which can happen more like if by chance.
PROCESS_INFORMATION process = { 0 };
{
// Be sure another process has atlthunk loaded.
WCHAR cmd[] = L"rundll32 atlthunk,x";
STARTUPINFOW startup = { sizeof(startup) };
BOOL success = CreateProcessW(0, cmd, 0, 0, 0, 0, 0, 0, &startup, &process);
assert(success && process.hProcess);
CloseHandle(process.hThread);
// Get atlthunk's usual address.
HANDLE file = CreateFileW((std::wstring(_wgetenv(L"SystemRoot")) + L"\\system32\\atlthunk.dll").c_str(), GENERIC_READ,
FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, 0, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);
assert(file != INVALID_HANDLE_VALUE);
HANDLE mapping = CreateFileMappingW(file, 0, PAGE_READONLY | SEC_IMAGE, 0, 0, 0);
assert(mapping);
void* view = MapViewOfFile(mapping, 0, 0, 0, 0);
assert(view);
UnmapViewOfFile(view);
VirtualAlloc(view, 1, MEM_COMMIT | MEM_RESERVE, PAGE_NOACCESS);
}
_Module.Init(0, 0);
const int N = 300;
CMyWindow wnd[N];
for (int i = 0; i < N; ++i)
{
wnd[i].Create(0, CWindow::rcDefault, L"Hello", (i < N - 1) ? 0 : (WS_OVERLAPPEDWINDOW | WS_VISIBLE));
wnd[i].DestroyWindow();
}
TerminateProcess(process.hProcess, 0);
CloseHandle(process.hProcess);
MSG msg;
while (GetMessageW(&msg, 0, 0, 0))
{
TranslateMessage(&msg);
DispatchMessageW(&msg);
}
_Module.Term();
}

Win32 program crashes on Windows 8 when calling GetSaveFileName() or SHBrowseForFolder()

I'm maintaining a C++ program that uses Win32. It's been working fine for years, but now I am having problems with the "select file" or "select folder" functions on 2 computers both running Windows 8, yet not on 2 other computers running Windows 8.
The problem is that the program crashes in the "select file" or "select folder" functions, deep in Microsoft code. It crashes immediately after displaying the dialog, before the user has a chance to touch anything.
I've done a lot of experimentation, and I've got it to randomly work, but then recompiling the same code will make the bug reappear. Finally I produced a tiny program that calls the function 10 times in succession, without any other code, and the first time always succeeds but the 2nd time the program crashes. Linked in with my full program, it sometimes crashes on the first call, sometimes on the 2nd. My code is below:
#include <windows.h>
int WINAPI WinMain(HINSTANCE _hInstance, HINSTANCE hPrevInstance,
LPSTR args, int nCmdShow)
{
for (int i=0; i < 10; i++) {
OPENFILENAME OFN;
char buf[1024];
memset(&OFN, 0, sizeof(OFN));
OFN.lStructSize = sizeof(OFN);
OFN.hwndOwner = NULL;
OFN.hInstance = NULL;
OFN.lpstrFilter = "PTN files\0*.ptn\0\0\0";//overkill
OFN.lpstrCustomFilter = NULL;
OFN.nMaxCustFilter = 0;
OFN.nFilterIndex = 1;
OFN.nMaxFile = sizeof(buf);
OFN.lpstrFileTitle = NULL;
OFN.nMaxFileTitle = 0;
OFN.lpstrTitle = NULL;
OFN.nFileOffset = 0;
OFN.nFileExtension = 0;
OFN.lpstrDefExt = "ptn";
OFN.lCustData = 0;
OFN.lpfnHook = 0;
OFN.lpTemplateName = NULL;
OFN.lpstrInitialDir = NULL;
strcpy(buf, "\0");//overkill
OFN.lpstrFile = buf;
OFN.Flags = OFN_LONGNAMES | OFN_HIDEREADONLY | OFN_EXPLORER;
//NB: tried both with and without OFN_EXPLORER
GetSaveFileName(&OFN);
}
return 0;
}
Any ideas?
I cannot see any error in your code.
I doubt that anybody will be able to answer your question.
Just some ideas:
1.)
You compile your project as MBCS ?
Does Windows 8 still support that Ansi stuff ?
Did you try if the same happens with the Unicode version?
2.)
I have had also a lot of troubles with these functions already in Windows XP.
They are definitely buggy and it seems that in Windows 8 they are still or even more. I found out for example that an invalid value for lpstrFile may result in the dialog not opening. Also other parameters are critical.
3.)
What value did you define for _WIN32_WINNT ?
I recommend at least 0x0502 or higher to assure that OPENFILENAME structure is not a version from the age of Windows NT which might not be supported on Windows 8.
4.)
What happens if you try out the MFC version:
CFileDialog dlg(FALSE);
dlg.DoModal();
Let all parameters in their default value. If this works you know that it is not a Windows 8 bug. Then study what parameters differ in the OFN from your code. Also have a look at the value of sizeof(OFN) which may influence the behavior of Windows 8.
5.) It may be required that your application / Dll has an embedded manifest for Shell32 to work correctly.
#pragma comment(linker,"\"/manifestdependency:type='win32' processorArchitecture='X86' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' publicKeyToken='6595b64144ccf1df' language='*'\"")
6.)
If all this does not help you have to experiment until you found what parameter causes the problem: Is hwndOwner required on Windows 8 ? Is hInstance required on Windows 8 ? Is there a flag missing ? Is lpstrInitialDir required ?
7.) I have had very very weird crashes that happened from time to time, very difficult to reproduce. After WEEKS of frustrating search I finally found out that this is a bug in Visual Studio. The solution to avoid the crashy code was to select "*Re*build Solution" in the menu of Visual Studio. I have this effect only in one of my projects.
I'm writing up David Heffernan's answer which he provided as a question comment. (David, if you provide a proper answer, I'll upvote it and try to delete this one).
"Try disabling shell extensions on the machines which fail. There are tools around that allow you to temporarily disable shell extensions. For instance: nirsoft.net/utils/shexview.html It's just a hunch that a shell extension is screwing with your program."

On release mode cout does not print anything

I have a very weird problem. I am working with visual studio in C++ and suddenly cout does not work on release mode (It worked until now) and on debug mode it works fine. I have no idea why thats happans. I have tried to delete some code And I deleted almost all my program (I have backup). Here is my code:
#include "stdafx.h"
#include <stdio.h>
#include <iostream>
using namespace std;
int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR szCmdLine, int iCmdShow )
{
AllocConsole();
cout<<"asdasd"<<endl;
cin.get();
return 1;
}
In debug mode the program wait for the user for pressing Enter. In release mode it doesn't. The window just close.
I think that it might be a problem in the setting of visual. Can it be?
iostreams require initialization that's normally carried out by the startup code for a console application -- but since you're using WinMain instead of main as your entry point, it's being linked as a Windows-mode application instead of a console-mode application, so that initialization isn't happening (dependably, anyway). Under some (poorly defined) circumstances, things work anyway, but it's undependable at best.
Unless you're feeling so masochistic that you're willing to do a lot of extra work just to make your code non-portable, write your code the standard way:
#include <iostream>
int main() {
std::cout<<"asdasd\n";
std::cin.get();
return 1;
}
Short, simple, and dependable are all good things. Portable is kind of nice too.

Basic dialog box input for a strobe light implementation

I have connected a photographic flash unit to my computer using a relay switch connected to the serial port. The following code causes the strobe to flash at 4Hz for 10 flashes:
#include <windows.h>
//Initialise Windows module
int WINAPI WinMain (HINSTANCE hThisInstance, HINSTANCE hPrevInstance, LPSTR lpszArgument, int nFunsterStil)
{
//Define the serial port precedure
HANDLE hSerial;
int freq = 4;
int iterations = 10;
int x;
for ( x = 0; x < iterations; x++)
{
//Fire the flash (open the serial port, and immediately close it)
hSerial = CreateFile("COM1",GENERIC_WRITE, 0, 0, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);
CloseHandle(hSerial);
//Sleep in between flashes for specified duration
Sleep (1000/freq);
}
return 0;
}
How do I implement dialog boxes at the beginning of the program so that the user can input the values of 'freq' and 'iterations'?
Open Visual Studio, New, Project,
Visual C++, Windows Forms
Application. This will give you a
GUI where you can drag and drop what
you need. If you don't have Visual
Studio then perhaps your IDE has
something similar?
Make this a console app that accepts the data in the command line. Call the app with an appropriate command line from a GUI created in any other programming language/ framework.
Make the GUI in C# and use P/Invoke to call CreateFile; it's not that hard.
Btw, does the CreateFile/CloseHandle approach really work? I find it to be a bit "hacky" and I'm not sure it's the best approach. Perhaps another answer or a comment will touch this aspect as well.

Create an Application without a Window

How would you program a C/C++ application that could run without opening a window or console?
When you write a WinMain program, you automatically get the /SUBSYSTEM option to be windows in the compiler. (Assuming you use Visual Studio). For any other compiler a similar option might be present but the flag name might be different.
This causes the compiler to create an entry in the executable file format (PE format) that marks the executable as a windows executable.
Once this information is present in the executable, the system loader that starts the program will treat your binary as a windows executable and not a console program and therefore it does not cause console windows to automatically open when it runs.
But a windows program need not create any windows if it need not want to, much like all those programs and services that you see running in the taskbar, but do not see any corresponding windows for them. This can also happen if you create a window but opt not to show it.
All you need to do, to achieve all this is,
#include <Windows.h>
int WinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPTSTR lpCmdLine,
int cmdShow)
{
/* do your stuff here. If you return from this function the program ends */
}
The reason you require a WinMain itself is that once you mark the subsystem as Windows, the linker assumes that your entry point function (which is called after the program loads and the C Run TIme library initializes) will be WinMain and not main. If you do not provide a WinMain in such a program you will get an un-resolved symbol error during the linking process.
In windows:
#include <windows.h>
int APIENTRY WinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPTSTR lpCmdLine,
int nCmdShow)
{
// <-- Program logic here
return 0;
}
Be sure to use the /SUBSYSTEM linker switch as mentioned by Adam Mitz.
On other platforms:
int main(int argc, char**argv)
{
// <-- Program logic here
return 0;
}
If you have a need to contiguously run your program without having console or window you might find useful deamon on *NIX or services on Windows, this .NET example if you need plain win32 just google a little bit for sample.
Since your question tagged as win32 i assume that services are more relevant for you.
This also processes messages:
#include <windows.h>
#include <stdio.h>
int CALLBACK WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) {
MSG msg;
DWORD curThreadId;
curThreadId = GetCurrentThreadId();
// Send messages to self:
PostThreadMessage(curThreadId, WM_USER, 1, 2);
PostThreadMessage(curThreadId, WM_USER+1, 3, 4);
PostThreadMessage(curThreadId, WM_USER+2, 5, 6);
PostThreadMessage(curThreadId, WM_USER+3, 7, 8);
PostThreadMessage(curThreadId, WM_QUIT, 9, 10);
while (GetMessage(&msg, NULL, 0, 0)) {
printf("message: %d; wParam: %d; lParam: %d\n", msg.message, msg.wParam, msg.lParam);
}
return (int) msg.wParam;
}
In Visual Studio Express 2010 after setting the subsystem to windows (as suggested by user17224), alternatively to changing the main to WinMain (as suggested by user17224 and Brian R. Bondy), one can set the entry function to main in properties, linker, advanced, entry point: just type main in the text box.
Use Visual Studio wizard to create the Win32 Application. But don't create the window i.e., you remove the window creation function.
Alternatively we can create Win Service application.
If you are using MSVC or Visual Studio just use the new Project Wizard and select the Console Application.