As per the suggestion for the previous question I am trying to use the GetDefaultPrinter() and then to the CreateDC(), but the VC6 is consistently saying
error C2065: 'GetDefaultPrinter' : undeclared identifier
I tried Google but many faced the same problem, but none of them were fruitful. Is this a correct way to use the GetDefaultPrinter().
Winspool.h and Windows.h are included.
You probably have a very old SDK. Check if GetDefaultPrinter is defined in your winspool.h file. If not, here are the definitions:
BOOL
WINAPI
GetDefaultPrinterA (
LPSTR pszBuffer,
LPDWORD pcchBuffer
);
BOOL
WINAPI
GetDefaultPrinterW (
LPWSTR pszBuffer,
LPDWORD pcchBuffer
);
#ifdef UNICODE
#define GetDefaultPrinter GetDefaultPrinterW
#else
#define GetDefaultPrinter GetDefaultPrinterA
#endif // !UNICODE
BOOL
WINAPI
SetDefaultPrinterA (
LPCSTR pszPrinter
);
BOOL
WINAPI
SetDefaultPrinterW (
LPCWSTR pszPrinter
);
#ifdef UNICODE
#define SetDefaultPrinter SetDefaultPrinterW
#else
#define SetDefaultPrinter SetDefaultPrinterA
#endif // !UNICODE
Related
per https://en.wikibooks.org/wiki/Windows_Programming/Handles_and_Data_Types#HANDLE,
HANDLEs are defined as being unsigned 32-bit quantities in windows.h
However, in WinDef.h, we see the following:
DECLARE_HANDLE (HWND);
and in winnt.h, we see the following:
#ifdef STRICT
typedef void *HANDLE;
#if 0 && (_MSC_VER > 1000)
#define DECLARE_HANDLE(name) struct name##__; typedef struct name##__ *name
#else
#define DECLARE_HANDLE(name) struct name##__{int unused;}; typedef struct name##__ *name
#endif
#else
typedef PVOID HANDLE;
#define DECLARE_HANDLE(name) typedef HANDLE name
#endif
This tells me that window handles are simple pointers. It seems to me this means that the max size of a window handle depends on the max size of addressable memory, which is 64 bits in most new machines. What am I missing?
I am trying to use NtOpenProcess() I have not find any example in town.
I am getting an error any help is much appreciated.
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE prevInstance, PSTR szCmdLine, int showCmd)
{
HANDLE handle;
HWND myWindow =FindWindow(NULL, L"Notepad");
PCLIENT_ID PID;
GetWindowThreadProcessId(myWindow, (LPDWORD)&PID);
ZwOpenProcess(&handle, PROCESS_VM_OPERATION | PROCESS_VM_READ | PROCESS_VM_WRITE, NULL,PID);
return 0;
}
The errors are
1>c:\users\asus\source\repos\windowsproject2\windowsproject2\windowsproject2.cpp(14): error C2065: 'PCLIENT_ID': undeclared identifier
1>c:\users\asus\source\repos\windowsproject2\windowsproject2\windowsproject2.cpp(14): error C2146: syntax error: missing ')' before identifier 'PID'
1>c:\users\asus\source\repos\windowsproject2\windowsproject2\windowsproject2.cpp(14): error C3861: 'NtOpenProcess': identifier not found
1>c:\users\asus\source\repos\windowsproject2\windowsproject2\windowsproject2.cpp(14): error C2146: syntax error: missing ';' before identifier 'PID'
1>c:\users\asus\source\repos\windowsproject2\windowsproject2\windowsproject2.cpp(14): error C2059: syntax error: ')'
This are my include files.
#include <Windows.h>
#include <ntddk.h>
#include <Ntifs.h>
#include "stdafx.h"
at first look at code:
FindWindow(NULL, L"Notepad");
faster of all you want
FindWindow(L"Notepad", 0);
because L"Notepad" is class name (not window name) and class name first parameter.
PCLIENT_ID PID;
GetWindowThreadProcessId(myWindow, (LPDWORD)&PID);
the GetWindowThreadProcessId wait pointer to DWORD memory, where it store process id. but you pass to it uninitialized pointer, to random memory. need use this:
CLIENT_ID pid = { };
if (GetWindowThreadProcessId(myWindow, (PDWORD)&pid.UniqueProcess))
finally ObjectAttributes in call NtOpenProcess is mandatory parameter and can not be 0.
about undeclared identifiers - all this declared in ntifs.h and it sub-headers (ntifs.h include ntddk.k - so you not need include it direct). problem that windows.h and ntifs.h is conflict - many common declarations. if you include both - you got a lot of errors. but solution exist - include ntifs.h in some namespace. but even after this you got some errors. but this also can be fixed, if deep understand source of errors. also you will be need include own code to this namespace too, for have easy access to ntifs declarations. and finally you need use ntdll.lib or ntdllp.lib (will be conflict with CRT libs if you use it) as linker input.
so if you want use native api in own code, without add custom headers, where you copy-paste some nt definitions and call it without resolve api in runtime, but use static linking - this is possible, but require deep knowledge and understanding what you doing. example
#define DECLSPEC_DEPRECATED_DDK
#define _XX_BEGIN namespace XX {
#define _XX_END }
_XX_BEGIN
struct _SECURITY_QUALITY_OF_SERVICE;
struct _CONTEXT;
_XX_END
#define _INC_MMSYSTEM /* Prevent inclusion of mmsystem.h in windows.h */
#include <windows.h>
#pragma warning(disable : 4005)
_XX_BEGIN
#ifdef _RTL_RUN_ONCE_DEF
#undef _RTL_RUN_ONCE_DEF
#endif
#define RtlCompareMemory ::RtlCompareMemory
#include <ntifs.h>
_XX_END
#undef _INC_MMSYSTEM /* Prevent inclusion of mmsystem.h in windows.h */
#include <MMSystem.h>
_XX_BEGIN
void demo()
{
if (HWND myWindow = FindWindow(L"Notepad", 0))
{
CLIENT_ID pid = { };
if (GetWindowThreadProcessId(myWindow, (PDWORD)&pid.UniqueProcess))
{
HANDLE handle;
static OBJECT_ATTRIBUTES zoa = { sizeof(zoa) };
if (0 <= NtOpenProcess(&handle,
PROCESS_VM_OPERATION | PROCESS_VM_READ | PROCESS_VM_WRITE,
&zoa, &pid))
{
NtClose(handle);
}
}
}
}
_XX_END
In winbase.h I see the following code, marking OutputDebugStringA/W as procedures rather than conditional macros. Does this mean it is best to wrap calls to these procedures in debug-only conditional blocks to keep production code tight, especially in tight loops?
WINBASEAPI
VOID
WINAPI
OutputDebugStringA(
__in LPCSTR lpOutputString
);
WINBASEAPI
VOID
WINAPI
OutputDebugStringW(
__in LPCWSTR lpOutputString
);
#ifdef UNICODE
#define OutputDebugString OutputDebugStringW
#else
#define OutputDebugString OutputDebugStringA
#endif // !UNICODE
Usually we do something like this:
#if defined (DEBUG) | defined (_DEBUG)
#define DebugOutput(x) OutputDebugString(x)
#else
#define DebugOutput(x)
#endif
DebugOutput will be expanded to nothing in release mode, keeping release binary clean and without #idfef/#endif everywhere in the code.
Note, that it is a good idea to also check if compiler is MSVC (_MSC_VER), so your code could be more portable
I am trying to hide the WinMain function inside a DLL in order to avoid typing again much of the code over and over again.
I exported wWinMain from the DLL by declaring it as
extern "C" int WINAPI wWinMain( ... )
{
// repetitive code here
}
and used the linker option /EXPORT:wWinMain, but when I try to use the import library in another project I get the error
LIBCMTD.lib(wincrt0.obj) : error LNK2019: unresolved external symbol _WinMain#16 referenced in function __tmainCRTStartup
Remark I do want to use the GUI interface and I know this is common error when you define a main instead of a WinMain function. Also, I enabled the UNICODE support in both projects. What should I do?
This is not possible as-is, the linker can only set the entrypoint for an EXE to a function that's inside the EXE. Rename the wWinMain() in the DLL to something else. Write a wWinMain() in a source code file that gets linked into your EXE, simply call the DLL's exported function.
// ...somewhere in a .cpp file within my .dll's sources...
#define WinMain WinMainOld // ...to suppress Win32 declaration of WinMain
#include <windows.h>
#undef WinMain // ...so that WinMain below is not replaced
. . .
#pragma comment(linker, "/export:_WinMain#16") // ...to export it from .dll
extern "C" // ...to suppress C++ name decoration
int CALLBACK WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
PSTR pCmdLine, int nCmdShow)
{
. . .
}
Should you be using WinMain in a DLL? Should it not be DllMain?
If you want to call the WinMain of the dll, you need to replace the CRTWinMainStartup function(_tmainCRTStartup in your liked CRT lib), and make it call your exported WinMain, this stops the linker looking for a local WinMain and still keeps correct flow of the program(the source for the CRT startups should be in the crt source of any compiler)
I find one way to put WinMain inside DLL.
You need to use WinMain instead of wWinMain (I don't know why)
Append a def file into your project and,
append EXPORTS WinMain in def file.
Like this
EXPORTS
WinMain
From the observation, all need exported functions generated, not only WinMain.
After test, the way of __declspec(dllexport) is invalid for WinMain.
Link your program to the DLL library
use #pragma comment(lib, "testDll.lib")
or modify setting in the project.
EXPORT int WINAPI _WinMain_(int (*_main_)(int argc, char **argv), HINSTANCE hInst, HINSTANCE hPrevInstance, LPSTR commandLine, int nCmdShow);
int _XMain( int argc, char **argv );
#define XMain WINAPI WinMain(HINSTANCE hInst, HINSTANCE hPrevInstance, LPSTR commandLine, int nCmdShow)\
{return _WinMain_( _XMain, hInst, hPrevInstance, commandLine, nCmdShow );} \
int _XMain
Then _WinMain_() calls or schedules _XMain().
Over in your application source:
int XMain( int argc, char **argv )
{
}
Are there no constant references in MIDL method declarations????
eg.
[id(1), helpstring("My Method")]
HRESULT MyMethod(
[in] IID & const rclsid
);
for
HRESULT MyMethod(
IID const &rclsid
);
MIDL doesn't really support reference parameters, it only supports "in" and "out" parameters. So if you DO pass in a reference, it's just syntactic sugar for a pointer to the value (the issue is observability - if you have a callback function or interface in our method signature, changes to a reference would be observable from the callback, but changes to an [out] parameter aren't visible until the function returns.
In addition, the difference between "& const" and "const &" are lost. If you look at the definition of REFGUID, you'll see that they only use one form of "const" for C++ code:
#ifdef __midl_proxy
#define __MIDL_CONST
#else
#define __MIDL_CONST const
#endif
#ifndef _REFGUID_DEFINED
#define _REFGUID_DEFINED
#ifdef __cplusplus
#define REFGUID const GUID &
#else
#define REFGUID const GUID * __MIDL_CONST
#endif
#endif