GetWindowLong (GetTopWindow(NULL),GWL_HINSTANCE) returns 0 ...
(Also tried with GetWindowLongPtr)
Does anyone have an idea why is that?
Also how do you convert LONG to HINSTANCE?
GetTopWindow(NULL) does not return null
EDIT: The check is for a keylogger that is injected inside the application I want to log from.
Using GetModuleHandle(0) I get the HINSTANCE of my injected app and if I could have the top window's HINSTANCE I could check to see if the input I get is for my application or not.
Related
In my understanding currently there are two ways to copy virtual files from a Shell Namespace Extension with the Explorer so that Copy GUI will be shown to the user:
Via IDataObject interface:
Reading a file is done via IDataObject::GetData that should support CFSTR_FILEDESCRIPTORW, CFSTR_FILECONTENTS and CFSTR_SHELLIDLIST clipboard formats at very minimum. Requesting CFSTR_FILECONTENTS from IDataObject::GetData should create an IStream that is used to access the data. UI is enabled via setting FD_PROGRESSUI flag when CFSTR_FILEDESCRIPTORW is requested.
Via ITransferSource interface:
Reading a file is done via ITransferSource::OpenItem requesting for IShellItemResources. Then IShellItemResources should report {4F74D1CF-680C-4EA3-8020-4BDA6792DA3C} resource as supported (GUID indicating that there is an IStream for the item). Finally an IStream is requested via parent ShellFolder::BindToObject for accessing the data. UI is handled by the Explorer itself, it is always shown.
My problem is: these two mechanisms are working just fine separately (as you can see from the screenshots). But once I enable both IDataObject from IShellFolder::GetUIObjectOf and ITransferSource from IShellFolder::CreateViewObject - the approach via IDataObject is always used leading to the old copy GUI (as on the first screenshot). I see from the trace logs that ITransferSource is requested several times, but no actions are performed, it just gets Released and destroyed right away.
So how may I force Explorer to show fancy copy GUI when copying from my Shell Namespace Extension?
A minimal reproducible example may be found here: https://github.com/BilyakA/SO_73938149
While working on Minimal Reproducible example I somehow managed to make it work as expected with both IDataObject and ITranfserSource interfaces enabled. It happened after:
unregistred x64 build SNE example (regsvr32 /u)
registred x32 build SNE example (it was not working in x64 explorer, root was not opening)
unregistred x32
registred x64 again.
Somehow new copy UI was shown to me when copying the files.
But I was not able to reproduce this result constantly after I have unregistred x64 SNE, restarted explorer and registered SNE x64 again.
What I have tried:
Registred both x32 and x64 SNE - still old GUI
Removed Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Shell Extensions\Cached value with my NSE GUID and restarted Explorer afterwards. Still old GUI.
I suspect there is some kind of cache (other than Registry) that keeps track if NSE supports ITransferSource. And since I have developed and tested without ITransferSource at the beginning - it is cached that my NSE does not support it even that I have added it later. And somehow registering 32bit reset that cache value.
The current code is doing something like this when asked for an IDataObject:
HRESULT CFolderViewImplFolder::GetUIObjectOf(HWND hwnd, UINT cidl, PCUITEMID_CHILD_ARRAY apidl, REFIID riid, UINT rgfReserved, void **ppv)
{
....
if (riid == IID_IDataObject)
{
CDataObject* dataObject = new (std::nothrow) CDataObject(this, cidl, apidl);
return ::SHCreateDataObject(m_pidl, cidl, apidl, dataObject, riid, ppv);
}
...
}
SHCreateDataObject already creates already a full-blown IDataObject with everything needed from the (optional) input PIDL(s), including all Shell formats for items in the Shell namespace (CFSTR_SHELLIDLIST, etc.).
Passing an inner object 1) will probably conflict with what the Shell does and 2) requires a good implementation (I've not checked it).
So you can just replace it like this:
HRESULT CFolderViewImplFolder::GetUIObjectOf(HWND hwnd, UINT cidl, PCUITEMID_CHILD_ARRAY apidl, REFIID riid, UINT rgfReserved, void **ppv)
{
....
if (riid == IID_IDataObject)
{
return ::SHCreateDataObject(m_pidl, cidl, apidl, NULL, riid, ppv);
}
...
}
In fact, the IDataObject provided by the Shell is complete (supports SetData method, etc.) so you should never need to implement it yourself, it's more complex than it seems. You can reuse it as a general purpose IDataObject (you can pass nulls and 0 for the 4 first arguments).
PS: the Shell also provides the "reverse" method: SHCreateShellItemArrayFromDataObject that gets a list of Shell items from an IDataObject (if the data object contains the expected clipboard formats).
For those who need to use inner IDataObject within SHCreateDataObject for additional format:
Inner IDataObject should support CFSTR_SHELLIDLIST clipboard format in GetData() as well as report this format in EnumFormatEtc(). Supporting SetData() with CFSTR_SHELLIDLIST format is really useful here since DefDataObject sets inner data object with already fully constructed CIDA and you may just store a copy of it.
Once inner data object will report CFSTR_SHELLIDLIST in EnumFormatEtc() and return valid CIDA in GetData() - modern Copy UI will be used since it relies only on PIDL of the items.
I'm looking for a way to make a Registry Change take affect right away.
Specifically the value I want to touch is:
HKEY_CURRENT_USER/Control\ Panel/Desktop/WindowArrangementActive
When you change this setting directly from the Control Panel it takes effect immediately, but when I'm changing it manually, it is not registered before rebooting.
I'm trying to make a script to disable/enable window snapping in Windows 10.
I've currently tried running the following command after the change with no luck:
RUNDLL32.EXE USER32.DLL,UpdatePerUserSystemParameters ,1 ,True
I ended up getting the job done in C# using the SystemParametersInfo:
[DllImport("user32.dll", EntryPoint = "SystemParametersInfo")]
public static extern bool SystemParametersInfo(int uiAction, int uiParam, IntPtr pvParam, int fWinIni);
and calling it with the following params:
SystemParametersInfo(0x0083, 0, IntPtr.Zero, 0x001A);
The final param is the one informing the system that the variable has changed in accordance with this documentation by Microsoft:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms725497(v=vs.85).aspx
Is it OK to initialize the Win32 HANDLE to NULL? Or are there any better or recommended way to initialize HANDLEs?
For example,
void foo()
{
HANDLE hFile;
hFile = CreateFile(/* necessary arguments*/);
}
What shall i initialize the hFile with?
In your example code you don't need to initialise hFile to anything since it is initialised by the CreateFile function.
The Windows API is not completely consistent on what it considers a "null" handle. Some APIs (like CreateFile) return INVALID_HANDLE_VALUE on failure, whereas others return NULL on failure. So the way you test if a HANDLE is valid or not depends on the function you are getting it from - check the actual documentation for the function and see what it says is the return value on failure.
I am trying out accessing the information in (Windows only) Firefox / Thunderbird using the IAccessible2 API: http://www.linuxfoundation.org/collaborate/workgroups/accessibility/iaccessible2
However I'm failing at almost the first step. I can obtain the IAccessible interface for either application, and then the IServiceProvider interface. But when I call QueryService to obtain the IAccessible2 interface, as described here: http://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/_generalinfo.html#_dicoveringInterfaces it always returns E_INVALIDARG.
AccProbe successfully returns IA2 information for both applications. The MS documentation for QueryService doesn't list E_INVALIDARG as a possible return value. However browsing for the mozilla source it appears that it returns this if the first parameter (service ID) is unexpected, and otherwise calls through to QueryInterface (which would return E_NOINTERFACE for a bad interface ID). So... that implies the first parameter to QueryService is wrong; but I've tried pretty much every value I think mozilla expects with no difference.
I started off in c# and then tried again in c++ in case I was losing something in InterOp. Same result in both languages. Here's my current c++ test code:
HWND hw = GetForegroundWindow();
IAccessible *pIA;
HRESULT hr = AccessibleObjectFromWindow(hw, OBJID_WINDOW, IID_IAccessible, (void**)&pIA);
if (!SUCCEEDED(hr))
return -1;
// SNIP - calls pIA->get_accName to check correct window is being accessed. This works OK.
const IID IID_IAccessible2 = {0xE89F726E, 0xC4F4, 0x4c19, 0xbb, 0x19, 0xb6, 0x47, 0xd7, 0xfa, 0x84, 0x78};
::IServiceProvider *pService = NULL;
hr = pIA->QueryInterface(IID_IServiceProvider, (void **)&pService);
if(SUCCEEDED(hr))
{
IAccessible2 *pIA2 = NULL;
hr = pService->QueryService(IID_IAccessible2, IID_IAccessible2, (void**)&pIA2);
if (SUCCEEDED(hr) && pIA2)
{
// Always fails with E_INVALIDARG
pIA2->Release();
}
pService->Release();
}
This is all on Win7 - both 32-bit and 64-bit used. Firefox 3.6.24 and Thunderbird 8.0. Visual Studio 2005
Am I doing something wrong?
HRESULT hr = AccessibleObjectFromWindow(hw, OBJID_WINDOW, IID_IAccessible, (void**)&pIA);
if (!SUCCEEDED(hr))
return -1;
I think the problem is here - replace OBJID_WINDOW with OBJID_CLIENT, and it seems to work. (I don't have the typelib registered, but I can QS for IID_IAccessible and the IUnknown interface, and it seems to work. Also, be sure to CoInitialize() also.)
IAccessible has an interesting hierarchy: every HWND has both a 'window' part and a 'client' part. This is partially due to how Win32 works internally; a Win32 HWND can have items like titlebar, menu, scrollbars, and so on, that all share the same HWND - along with the content area aka client area where the actual control content lives. To allow these items to have their own representation, the designers of MSAA picked a two-level structure, where OBJID_WINDOW represents the entire window, and it has children that then represent things like scrollbars, menubar, titlebar, and so on - if they are present.
The part of a window that implements the accessiblity, however, is generally the client part, so you usually need to ask for OBJID_CLIENT to get the 'real' IAccessible.
Reading Microsoft's documentation on RegOpenKeyEx and RegCloseKey I am unsure of whether or not I need to call the close function if RegOpenKeyEx fails.
Please point me to a definitive source indicating if I need to always call RegCloseKey or if it only needs to be called when RegOpenKeyEx returns ERROR_SUCCESS.
References:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724897%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724837%28v=vs.85%29.aspx
RegOpenKeyEx will only return a valid key handle if ERROR_SUCCESS is the returned value. This is where the caller is responsible for closing the key, otherwise no closing required and key is not opened. This is the the assumed agreement regarding responsibility to close the opened handle, though not explicitly mentioned in RegOpenKeyEx function documentation.
This is also consistent across API samples. If you are unsure after checking sample code in the MSDN article, here is another one: http://msdn.microsoft.com/en-us/library/aa384182%28VS.85%29.aspx
I think if you look at the example listed under your reference links you can see that it does not call RegCloseKey if lResult does not return ERROR_SUCCESS
This is the link to it:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724235(v=vs.85).aspx