Windows HOME - SHGet(Known)FolderPath - c++

I'm trying to write a function to get the Windows-equivalent of HOME. My C skills are rusty, so don't mind that my example code does not compile. I'm trying to use SHGetKnownFolderPath on Windows Vista and newer, and SHGetFolderPath on Server 2003 and older. Since I expect to encounter users running Windows XP (as it is still the number one deployed version of Windows), I am going to avoid having a reference to SHGetKnownFolderPath in the symbol table (as this would lead to a binary that won't even load on XP). I know to LoadLibrary() shell32 and to GetProcAddress() from there, but my skills on doing function pointers are, well, crap, to say the least.
When I write features, and they are difficult to handle, I isolate them into an separate example file. The broken example I have so far is:
#include <windows.h>
#include <stdio.h>
// Pointerizing this Vista-and-later call for XP/2000 compat, etc.
typedef HRESULT (WINAPI* lpSHGetKnownFolderPath)(
REFKNOWNFOLDERID rfid,
DWORD dwFlags,
HANDLE hToken,
PWSTR *ppszPath
) lpSHGetKnownFolderPath;
int main(int argc, char *argv[])
{
// SHGet(Known)FolderPath() method.
HMODULE hndl_shell32;
lpSHGetKnownFolderPath pSHGetKnownFolderPath;
hndl_shell32 = LoadLibrary("shell32");
pSHGetKnownFolderPath = GetProcAddress(hndl_shell32, "SHGetKnownFolderPathW");
if(pSHGetKnownFolderPath != NULL) {
} else {
}
}
My question is this: Knowing that I'm doing this wrong, how would I go about doing this right? And an explanation as to how to do it right in the future would be appreciated. Thanks.

Here is a small application that shows how to use LoadLibrary() and GetProcAddress() with advice provided in comments:
#include <windows.h>
#include <stdio.h>
#include <shlobj.h>
/* The name of the function pointer type is
'lpSHGetKnownFolderPath', no need for
additional token after ')'. */
typedef HRESULT (WINAPI* lpSHGetKnownFolderPath)(
REFKNOWNFOLDERID rfid,
DWORD dwFlags,
HANDLE hToken,
PWSTR *ppszPath
);
int main()
{
HMODULE hndl_shell32;
lpSHGetKnownFolderPath pSHGetKnownFolderPath;
/* Always check the return value of LoadLibrary. */
hndl_shell32 = LoadLibrary("shell32");
if (NULL != hndl_shell32)
{
/* There is no 'SHGetKnownFolderPathW()'.
You need to cast return value of 'GetProcAddress()'. */
pSHGetKnownFolderPath = (lpSHGetKnownFolderPath)
GetProcAddress(hndl_shell32, "SHGetKnownFolderPath");
if(pSHGetKnownFolderPath != NULL)
{
PWSTR user_dir = 0;
if (SUCCEEDED(pSHGetKnownFolderPath(
FOLDERID_Profile,
0,
NULL,
&user_dir)))
{
/* Use 'user_dir' - remember to:
CoTaskMemFree(user_dir);
when no longer required.
*/
}
}
else
{
fprintf(stderr, "Failed to locate function: %d\n",
GetLastError());
}
/* Always match LoadLibrary with FreeLibrary.
If FreeLibrary() results in the shell32.dll
being unloaded 'pSHGetKnownFolderPath' is
no longer valid.
*/
FreeLibrary(hndl_shell32);
}
else
{
fprintf(stderr, "Failed to load shell32.dll: %d\n", GetLastError());
}
return 0;
}
This was compiled on Windows XP.
Output on Windows XP:
Failed to locate function: 127
where 127 means The specified procedure could not be found.
Output on Windows Vista:
C:\Users\admin

You can always use getenv("HOMEDRIVE") and getenv("HOMEPATH") and concatenate the results.
std::string home = std::string(getenv("HOMEDRIVE")) + getenv("HOMEPATH");

The Windows equivalent of HOME is USERPROFILE. It is an ordinary environment variable just like in Linux. You can make the following call to retrieve it:
char *profilepath = getenv("USERPROFILE");

Related

get_accChildCount returns 0 when it shouldn't

I'm trying to enumerate tabs of IE from an extension and from a standalone application. For one of the MSAA nodes get_accChildCount returns 0 when called from extension, while it should return 1 according to inspect and a call from standalone application.
The problem was described previously at StackOverflow, yet it was solved via a hack that doesn't work for me. /clr and /MT are incompatible.
Also there was a topic on MSDN with the same issue. There's no single answer there.
If you run IE with administrator privileges, it works properly.
API Monitor shows several thousand calls in a minimal example, and it's unclear which of these are related. The minimal example is attached below.
What are the undocumented cases when get_accChildCount returns wrong child count?
What other method could I use to activate the tab by URL in most versions of IE?
#include <atlbase.h>
#include <atlcom.h>
#include <atlctl.h>
#include <atltypes.h>
#include <atlsafe.h>
#include <io.h>
#include <fcntl.h>
#include <windows.h>
#include <iostream>
#include <string>
#include <vector>
#include <boost/format.hpp>
#include <fstream>
using namespace std;
CComPtr<IAccessible> get_acc_by_hwnd(HWND hwnd) {
CComPtr<IAccessible> ret;
HRESULT hr = ::AccessibleObjectFromWindow(hwnd, OBJID_WINDOW, IID_IAccessible, (void**) &ret);
if (FAILED(hr) || !ret) {
wcout << L"Accessible::Accessible invalid hwnd" << endl;
}
return ret;
}
std::vector<CComPtr<IAccessible>> get_acc_children(CComPtr<IAccessible> acc) {
std::vector<CComPtr<IAccessible>> ret;
long count;
if (FAILED(acc->get_accChildCount(&count))) return ret;
long count_obtained = 0;
if (!count) return ret;
std::vector<CComVariant> accessors(count);
if (FAILED(::AccessibleChildren(acc, 0, count, &*accessors.begin(), &count_obtained))) return ret;
accessors.resize(count_obtained);
for (auto vtChild : accessors) {
if (vtChild.vt != VT_DISPATCH) continue;
CComQIPtr<IAccessible> pChild = vtChild.pdispVal;
if (pChild) ret.push_back(pChild);
}
return ret;
}
bool is_client(CComPtr<IAccessible> acc) {
CComVariant var;
HRESULT hr = acc->get_accRole(CComVariant(CHILDID_SELF), &var);
return SUCCEEDED(hr) && var.vt == VT_I4 && var.lVal == 0xA;
}
std::wstring get_descr(CComPtr<IAccessible> acc) {
CComBSTR str;
HRESULT hr = acc->get_accDescription(CComVariant(CHILDID_SELF), &str);
return SUCCEEDED(hr) && str ? std::wstring(str) : L"";
}
int main() {
::CoInitialize(nullptr);
_setmode(_fileno(stdout), _O_U16TEXT);
// put HWND of the window that contains tab labels
// it's hardcoded to minimize quantity of API calls
HWND hwnd = reinterpret_cast<HWND>(0x002D0696);
CComPtr<IAccessible> iaccessible;
HRESULT hr = ::AccessibleObjectFromWindow(hwnd, OBJID_WINDOW, IID_IAccessible, (void**) &iaccessible);
if (FAILED(hr) || !iaccessible) {
wcout << L"AccessibleBrowser::activate_tab " L"failed to get IAccessible for IE" << endl;
return EXIT_FAILURE;
}
wstring const sentinel = L"\r\n";
for (auto child : get_acc_children(iaccessible)) if (is_client(child)) {
for (auto child1 : get_acc_children(child)) { // fails here in extension
for (auto child2 : get_acc_children(child1)) {
std::wstring descr = get_descr(child2);
auto pos = descr.find(sentinel);
if (pos == string::npos) continue;
auto tab_url = descr.substr(pos + sentinel.size());
wcout << tab_url << endl;
}
}
}
}
I poked at your program for a while without having much to show for it. Perhaps I realized too late that it was not supposed to reproduce the problem :( I can only provide some possibly helpful hints to get you to look under the right kind of rock.
yet it was solved via a hack that doesn't work for me
These programmers made a simple mistake, they forgot to call CoInitialize/Ex(). A very common oversight. Using the /clr build option works around that mistake because it is now the CLR that calls it. You can easily repro this mishap, just comment out the CoInitialize() call. Unfortunately it works for a while without any loud errors being produced, but you do get 0 for certain accobjects. You'll notice your program no longer finds the tabs.
Not so sure I can cleanly explain this, certain COM-style object models don't actually use the COM infrastructure. DirectX is the best example, we can add UIAutomation to that list. I assume it will silently fail like this when the client app's component is COM-based. Unclear if it is, DirectUIHWnd is quite undocumented.
So stop looking for that as a workaround, you did not forget to call CoInitialize() and it will be taken care of by IE before it activates your extension.
If you run IE with administrator privileges, it works properly.
That's a better rock. Many programmers run VS elevated all the time, the roles might be reversed in the case of UIA. Do keep in mind that your extension runs in a sandbox inside IE. No real idea how elevating IE affects this. One thing you cannot do from code running in the low-integrity sandbox is poke at UI components owned by a code that runs in a higher integrity mode. Google "disable IE enhanced protected mode" and follow the guideline to see what effect that has on your addin.

Getfriendlyname of a secondary monitor

I need to get device name of a secondary monitor. However when I simply try to retrieve device name, the output is DISPLAY1, DISPLAYV1 and etc.
However I require the name displayed when we check the screen resolution like the Displayname mentioned here:
Firstly I am not sure from where I can obtain this string. On reading a bit I guess it is the friendlyname of the device. However I am not sure since on calling EnumDisplaySetting() has been giving me Unhandled Exception: Could not access memory location when this function is called. So I have not been able to verify what the friendly name is exactly. And I believe that the unhandled exception is caused due to improper allocation of memory to the DISPLAY_DEVICE for driverextra in the DISPLAY_DEVICE. I believe this is because of this:
The function fails if iModeNum is greater than the index of the display device's last graphics mode.
mentioned here
Also I did not understand how much memory needs to be allocated to to
DISPLAY_DEVICE->dmDriverExtra as it has been mention in the same link:
Before calling EnumDisplaySettings, set the dmSize member to sizeof(DEVMODE), and set the dmDriverExtra member to indicate the size, in bytes, of the additional space available to receive private driver data.
So my question is manifold:
1) How much memory needs to be allocated to dmDriverExtra?
2) Is friendlyname the right parameter I need for accessing the name provided in the Display Tab in screen resolution. Or if not what other parameter do I need?
3) Is this unhandled exception caused due to improper memory allocation or is there some other reason for this?
4) Are there any other ways to get access to friendlyname of the secondary monitor?
Updated
I switched to using The PhysicalMonitorAPI instead of GetMonitorInfo. I've combined by original solution with the first. This produces more reasonable output that you would expect (e.g. "Dell UH2313" instead of "\.\Display1").
Technically, you should allocate the array of monitors instead of using a hardcoded array - but I've never seen where dwCount will get initialized to anything greater than 1.
This program compiles just fine in Visual Studio, but you'll need to link with dxva2.lib to pick up the definitions for the PhysicalMonitor APIs.
#include <Windows.h>
#include <PhysicalMonitorEnumerationAPI.h>
#include <string>
#include <iostream>
#include <stdio.h>
BOOL __stdcall MyMonitorEnumProc
(
_In_ HMONITOR hMonitor,
_In_ HDC hdcMonitor,
_In_ LPRECT lprcMonitor,
_In_ LPARAM dwData
)
{
DWORD dwCount = 0;
std::wstring strName(L"Unknown monitor name");
PHYSICAL_MONITOR monitors[100] = {};
MONITORINFOEX info = {};
info.cbSize = sizeof(info);
if (GetMonitorInfo(hMonitor, (LPMONITORINFO)&info))
{
strName = info.szDevice;
}
if (GetNumberOfPhysicalMonitorsFromHMONITOR(hMonitor, &dwCount) && (dwCount > 0) && (dwCount < ARRAYSIZE(monitors)))
{
if (GetPhysicalMonitorsFromHMONITOR(hMonitor, dwCount, monitors))
{
strName = monitors[0].szPhysicalMonitorDescription;
DestroyPhysicalMonitors(dwCount, monitors);
}
}
std::wcout << L"Monitor: " << strName << std::endl;
return TRUE;
}
void printMonitorNames()
{
EnumDisplayMonitors(NULL, NULL, MyMonitorEnumProc, NULL);
}
int _tmain(int argc, _TCHAR* argv[])
{
printMonitorNames();
return 0;
}
And it's a good bet that the MyMonitorEnumProc will get invoked first for the primary monitor. All other monitors get enumerated next.

Can not format data in PWSTR variable to use in CopyFileW command

I am very new to this, sorry about the horrible code below. I am trying to get the default path for FOLDERID_Profile and then add "\test.exe" to the end of it. Then i need to use this as the path to copy a file to. I was able to use the pSHGetKnownFolderPath method to store the profiles directory in PWSTR user_dir . Problem is, this is not an acceptable string format for the copy function.
So i used the following code to very crudely attempt to convert it to something the copy function could use.
strcat((char *)user_dir,"\\test.exe");
test7 = (LPCWSTR)user_dir;
MessageBox(NULL,test7,L"WR test file",MB_OK);
i'm using a message box to check the path before using CopyFile(currentpath,test7,false); But this is giving me 㩃瑜獥⹴硥 . I am currently using
CopyFileW(currentpath,L"C:\\Users\\Jenia\\test.exe",false);
as a workaround, but I really need this to work on other computers too...
I know I am messing up my ANSI vs Unicode formatting again, please tell me how to best achieve this goal. Let me know if you would like me to post the entire code block, but until i run that strcat method user_dir has the correct path just no file name for copy method.
more complete code below:
#include <windows.h>
#include <shlwapi.h>
#include <stdio.h>
#include <Shlobj.h>
LPCWSTR test7 = 0;
PWSTR user_dir = 0;
HMODULE hndl_shell32;
lpSHGetKnownFolderPath pSHGetKnownFolderPath;
hndl_shell32 = LoadLibrary(L"shell32");
if (NULL != hndl_shell32)
{
pSHGetKnownFolderPath = (lpSHGetKnownFolderPath)
GetProcAddress(hndl_shell32, "SHGetKnownFolderPath");
if(pSHGetKnownFolderPath != NULL)
{
if (SUCCEEDED(pSHGetKnownFolderPath(
FOLDERID_Profile,
0,
NULL,
&user_dir)))
{
//I think this is the problem here
strcat((char *)user_dir,"\\test.exe");
test7 = (LPCWSTR)user_dir;
MessageBox(NULL,test7,L"WR test file",MB_OK);
}
}
else
{
fprintf(stderr, "Failed to locate function: %d\n",
GetLastError());
}
}
else
{
fprintf(stderr, "Failed to load shell32.dll: %d\n", GetLastError());
}
Too many errors here. You cannot strcat on pointer filled by SHGetKnownFolderPath. Assuming that all variables are Unicode, this should work with project with any character set:
LPWSTR test7 = 0;
WCHAR user_dir[MAX_PATH];
...
SHGetKnownFolderPath(... &test7);
...
wcscpy(user_dir, test7);
wcscat(user_dir, L"\\test.exe");
MessageBoxW(NULL,test7,L"WR test file",MB_OK);
Don't forget to release the pointer test7 filled by SHGetKnownFolderPath.
This shows the basic way to complete your task; you'll need to adapt it for your needs.
#include <ShlObj.h>
#include <strsafe.h>
void ShowTestPath()
{
PWCHAR user_dir = NULL;
WCHAR test_file_path[MAX_PATH];
if (FAILED(SHGetKnownFolderPath(FOLDERID_Profile, 0, NULL, &user_dir)))
return;
if (FAILED(StringCchCopyW(test_file_path, MAX_PATH, user_dir)))
{
CoTaskMemFree(user_dir);
return;
}
CoTaskMemFree(user_dir);
if (FAILED(StringCchCatW(test_file_path, MAX_PATH, L"\\test.exe")))
return;
MessageBoxW(NULL, test_file_path, L"WR test file", MB_OK);
}

My code doesn't work on Windows XP

since Win-7 drag and drop implementation has changed, to make it work I need to enable some stuff using ChangeWindowMessageFilter.
There is a problem. ChangeWindowMessageFilter is valid since Vista, however I need solution for XP as well.
Well, you should try call it dynamically, for that you need LoadLibrary and GetProcAddress.
Sample usage
if (/*IsVista()*/)
{
typedef BOOL (WINAPI *ChangeMessageFilter)(UINT message, DWORD dwFlag);
#define MSGFLT_ADD 1
#define MSGFLT_REMOVE 2
BOOL res = FALSE;
HMODULE user32 = LoadLibrary(L"User32.dll");
if (user32 != NULL)
{
ChangeMessageFilter filter = (ChangeMessageFilter)::GetProcAddress(user32, "ChangeWindowMessageFilter");
if (filter != NULL)
{
res = filter(/*your value*/, MSGFLT_ADD);
}
::FreeLibrary(user32);
}
}
Another thing, you should better use ChangeWindowMessageFilterEx as it is enables messages receiving for only one window, not all project.

Getting Base Address not working

I need the base Address of the exe "tibia.exe". This is what I got so far but it doesn't work. It always returns 0.
What's wrong?
DWORD MainWindow::getBaseAddress(DWORD dwProcessIdentifier)
{
TCHAR lpszModuleName[] = {'t','i','b','i','a','.','e','x','e','\0'}; //tibia.exe
HANDLE hSnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPMODULE,
dwProcessIdentifier);
DWORD dwModuleBaseAddress = 0;
if(hSnapshot != INVALID_HANDLE_VALUE)
{
MODULEENTRY32 ModuleEntry32;
ModuleEntry32.dwSize = sizeof(MODULEENTRY32);
if(Module32First(hSnapshot, &ModuleEntry32))
{
do
{
if( wcscmp(ModuleEntry32.szModule, lpszModuleName) == 0)
{
dwModuleBaseAddress = (DWORD)ModuleEntry32.modBaseAddr;
break;
}
}
while(Module32Next(hSnapshot, &ModuleEntry32));
}
CloseHandle(hSnapshot);
}
return dwModuleBaseAddress;
}
//Call it here
tibiaWindow = FindWindow( L"TibiaClient", NULL);
DWORD PID;
GetWindowThreadProcessId( tibiaWindow, &PID );
DWORD baseAddress = getBaseAddress( PID );
if( baseAddress == 0 )
return false ;
Perhaps it's just because I was using them before ToolHelp32 was available (at least on the NT-based operating systems), but I tend to use the PSAPI functions for this kind of task. Using them, the code would look like this:
#include <windows.h>
#include <string>
#include <psapi.h>
#include <iostream>
int main(int argc, char **argv) {
HANDLE process = GetCurrentProcess();
if (argc != 1)
process = OpenProcess(PROCESS_QUERY_INFORMATION | PROCESS_VM_READ, false, atoi(argv[1]));
HMODULE handles[2048];
DWORD needed;
EnumProcessModules(process, handles, sizeof(handles), &needed);
for (int i = 0; i < needed / sizeof(handles[0]); i++) {
MODULEINFO info;
char name[1024];
GetModuleBaseName(process, handles[i], name, sizeof(name));
if (std::string(name).find(".exe") != std::string::npos) {
GetModuleInformation(process, handles[i], &info, sizeof(info));
std::cout << name << ": " << info.lpBaseOfDll << "\n";
break;
}
}
}
As it stands right now, this will let you enter a process ID on the command line, and show the load address of the first module it finds in that process with a name that includes ".exe". If you don't specify a process ID, it'll search through its own process (demos how the functions work, but otherwise pretty much useless).
Using either ToolHelp32 or PSAPI, you end up with a similar limitation: you need to compile this into a 64-bit executable for it to be able to "see" other 64-bit processes (i.e., when compiled as 32-bit code, they see only other 32-bit processes).
There are also some processes (e.g., CSRSS.exe) that neither will be able to open/enumerate successfully. As far as I know, the same processes will succeed/fail with PSAPI vs. ToolHelp32.
PSAPI does have one bit of clumsiness compared to ToolHelp32: dealing (well) with processes that have lots of modules is clumsy (at best). You call EnumProcessModules, and if you haven't given room for enough modules, the "Needed" parameter will be set to the space needed for the number of modules it contains. There's a race condition though: between the time that returns and the time you call EnumProcessModules again, the process could have loaded more DLLs, so that second call could fail the same way.
For the moment, I've just assumed that no process will use more than 2048 modules. To be really correct, you should have a while loop (or maybe a do/while loop) that starts with zero space, calls EnumProcessModules to find out how much space is needed, allocate that (perhaps with a little extra in case it loads more DLLs) and repeat until it succeeds.