I'm very confused about the status of persistent handlers in Windows for searching. On the one hand, the MSDN documentation on the subject implies at the top of the page that they are unavailable in Windows 8:
Note Indexing Service is no longer supported as of Windows XP and is
unavailable for use as of Windows 8. Instead, use Windows Search for
client side search and Microsoft Search Server Express for server side
search.
On the other hand, I have an application whose code I'm looking through that still goes through the registry to find a file extension's persistent handler, load the DLL, and get the info through the IFilter interface. Whatsmore, in Windows Server 2012 (which is the server equivalent of Windows 8), registry keys in the form of HKEY_LOCAL_MACHINE\Software\Classes\.docx\CLSID\{PersistentHandlerGUID}\PersistentAddinsRegistered still exist, and still have values set that point to persistent handlers. So what's the deal? Are they deprecated? Is it just a lie that they are unavailable in Windows 8?
No they are not deprecated, but they have been renamed to "Filter handlers". When Windows (Desktop) Search was just a standalone add-on it also used the IFilter interfaces present on most machines. Windows Search is now part of Windows and has relieved the Indexing Service of its duty as the system wide "extracted text from files" indexer.
The PersistentHandlerGUID registration documentation under the Windows Search part of MSDN is located here.
Related
I am trying to install a legacy VB6 app on a Windows 10 Enterprise PC. The app has an install program and it is installed on many Windows server 2016 machines. This program uses active user documents (dob files) that load in a webbrowser control. The install is successful but when I run the program instead of loading the user document in the webbrowser control i get a dialog box asking me if I want to download or save a 'vbd' file with the same name as the active x dll the user document creates.
My question is if anyone knows if there is a prerequisite to having the vb6 webbrowser control or active x documents work on a Windows 10 machine? I have the dll registered and the registry entries match the Windows 2016 server.
Thanks in advance,
Hank
Here's the relevant (I think) part of the VB6 help for ActiveX Documents:
A few of the more common problems in Internet Component Download and their solutions are listed in this section. These include: [...] Prompt: "Opening file DocumentName.VBD. What would you like to do with this file? Open it or save it to disk?
The proposed solution to this is
This error occurs when the Visual Basic runtime library (MSVBVM60.DLL) is not installed. Generally, this occurs when the safety level in Internet Explorer is set to High. To correct this, you must set the safety level in Internet Explorer to Medium or None.
Note sure when this help entry was written, but with the latest IEs, you add the site in question to the Intranet zone and change the setting there. If that actually resolves the problem, you then should try turning security up again by going into "Customized" and add restrictions again that don't cause it to break again.
I have a Windows desktop C++ application that currently uses ::PathCanonicalizeW. As you can see from the documentation, it was introduced in Windows 2000 and is located in shlwapi.dll. In order to support long paths on Win 10+, I need to start using ::PathAllocCanonicalize (or one of it's friends - ::PathCchCanonicalize or ::PathCchCanonicalizeEx).
This function was added in Windows 8, but I still need to support the older OS's. In order to support all OS's, I need to dynamically load ::PathAllocCanonicalize by calling ::LoadLibrary at runtime. The problem is that the documentation doesn't provide the DLL that includes this function.
After doing some searching, I found this documentation that includes all 3 of the new PathCanonicalize functions and it claims that they are in api-ms-win-core-path-l1-1-0.dll. After more searching, it appears that this is not a traditional DLL because there is no file anywhere in the OS with that name. This application has always loaded system libraries using the full path to the file in the system directory (typically C:\Windows\system32) to make sure that it's not loading malicious DLLs, but for this it will be impossible without a physical file to point to.
I have been able to test that calling ::LoadLibrary("api-ms-win-core-path-l1-1-0.dll") does work, but the fact that that documentation mentions UWP worries me. Is there any documentation for the supported way to dynamically load these kinds of functions at runtime in a desktop app? Is there a more secure way to load this DLL?
P.S. This app cannot be deployed with that DLL, and even if it were possible there's no point since any OS that doesn't have that function wouldn't have full support for long paths anyway. Using the documented pathcch.lib would require upgrading the target Windows version. Dropping support for the older OS's is also completely out of the question. The function must be manually dynamically loaded at runtime.
As pointed out by Hans, api-ms-win-core-path-l1-1-0 is known as an API set along with many others starting with api-ms-win-core. Based on the documentation there, it appears that the documentation for PathAllocCanonicalize is incomplete. It should list the API set on that page along with the DLL for desktop apps. Looking at the source on GitHub, it looks like there is a bug with that page and the other pathcch functions where that information is in the header but not rendered onto the page. That header lists api-ms-win-core-path-l1-1-0.dll and KernelBase.dll.
If for some reason I wanted to continue to load the API set instead of KernelBase.dll, ::LoadLibraryExW(L"api-ms-win-core-path-l1-1-0.dll", NULL, LOAD_LIBRARY_SEARCH_SYSTEM32) worked which would be just as secure as specifying the full path to a DLL in the system32 folder. Note that LOAD_LIBRARY_SEARCH_SYSTEM32 was not supported without KB2533623 on RTM versions of Vista, Windows 7, Server 2008, and Server 2008 R2 so that might not actually be secure on those OS's.
We have code that adds Debugger.Launch() and Debugger.Break() on certain condition, and this functionality doesn't seem to work in Windows 8 / Windows Server 2012
In previous versions of Windows this worked just fine, launching a window that would show the Visual Studio Debug dialog.
Is this a new breaking change in Windows8/Windows Server 2012?
There is an open ticket with microsoft connect that contains a temporary workaround for this issue.
Just-In-Time debugging, operation attempted is not supported
From comment below:
Just change HKCR\AppID\{E62A7A31-6025-408E-87F6-81AEB0DC9347}\AppIDFlag from 0x28 to 0x8.
This is indeed a change in Windows 8. I couldn't find any public documentation yet (albeit Win8 hasn't yet shipped to customers). However, I'll ask someone on the relevant team to make this information available on MSDN as appropriate.
This is part of Session 0 isolation work that started in Windows Vista.
To go back to Win7/2008R2 settings you need to do the following:
For the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Windows, set the "NoInteractiveServices" value to 0, which is (in Windows 8) defaulted to 1. This allows you to manually start the service that facilitates the visual dialog to you in your session, "Interactive Services Detection" (ui0detect). Without setting this key, the ui0detect service will fail to start with an error such as "Function not supported".
net start ui0detect
Of course, you can choose to make this service start automatically with Windows and always boot into being able to debug Session 0 Processes.
I have some free-standing C++ code (i.e. not a Windows program) that needs to identify the version of Windows that is installed on a PC.
I can easily differentiate between the different Windows client releases by kernel version (e.g. GetFileVersionInfo on ntoskrnl.exe), however I'm wondering if there's a reliable way to distinguish between a client and server installation.
A problem arises when using this method to distinguish between Windows Vista SP2 and Windows Server 2008 SP2 (6.0 build 6002 the both of them) and Windows 7 and Windows Server 2008 R2 (6.1 build 7600 for RTM and 6.1 build 7601 for SP2, both). What is a reliable (and preferably as straight forward as possible, avoiding the registry would be great as access to Win32 API is not available) method of identifying client vs server OSes correctly for code running outside the environment?
I suppose I could check for files only present on the server edition (what's a good file guaranteed to be on any server edition install, regardless of configuration?), check the Panther folder (which is safe to delete, so no guarantees there), etc. but I'm sure this is a problem that people have run into before and (hopefully) solved more elegantly?
(Sidenote: this question has been asked on SO before, but the solution (WMI) is inapplicable for out-of-band checking)
I'm not entirely sure what you mean about out of band checking, so I'm going to ignore that for the moment.
The normal way would be to call GetVersionEx, and look at the wProductType member of the OSVERSIONINFOEX.
A PE image does NOT specify whether the image should work on a client or server. It only specifies the runtime requirements regarding subsystem, dependencies, memory, affinity, etc...
I ended up searching for a number of binaries in the system32 directory that are generally associated with the Server Edition of Windows. It's not very clean, but in practice it works very well.
In order to find out what the default email client is, I found the same information over and over again: Look at the default string in HKLM\Software\Clients\Mail. (see for example this related question)
However, this seems not to be true for all OSs and/or situations:
I have two machines running Win7 64bit, let's call them A and B.
A has Outlook 2010 64bit and Thunderbird 3 32bit installed.
B has Outlook 2007 32bit and Thunderbird 3 32bit installed.
Both A and B have Thunderbird set as their default mail client.
However, the state of the registry is not as I expected it:
On machine A, both HKLM\Software\Clients\Mail and HKLM\Software\Wow6432Node\Clients\Mail have an empty string as the default string value.
On B, both those keys contain Microsoft Outlook as the default string value, which is clearly wrong.
Further investigation revealed that the correct value seems to be written to HKCU\Software\Clients\Mail on both machines.
I want my application to handle this correctly for all cases. It makes kinda sense, that Win7 now seems to hold a separate default mail client for each user, but it appears rather inconsistent. When looking at the plethora of information that points to HKLM\Software\Clients\Mail, it seems obvious that previous versions of Windows handled this differently and always wrote to that location. So when did this change? Has the wrong value on machine B any meaning? If not, why does it get written there in the first place? Does the mix of 64bit and 32bit email clients on the same computer change anything?
I would most appreciate if anyone would share reliable information or documentation that explains this topic! Maybe there is a Win32 API function that returns the correct value?
Does this MSDN article help you?
How to Register an Internet Browser or E-mail Client With the Windows Start Menu
Registrations made in the HKEY_CURRENT_USER subtree have higher precedence for the console user than corresponding registrations made in the HKEY_LOCAL_MACHINE. For new users on the system, the settings stored in HKEY_LOCAL_MACHINE are used.
For Windows XP a special article: How to modify the default Web browser and e-mail client programmatically in Windows XP and How to implement a per-user default mail client in Windows XP?
Sorry, can't help you with the Win32 API.
For Windows 10, this seems to be different - see the discussion here: https://superuser.com/q/1045349/176339
Quoting the relevant paragraph for your question, from papo's answer:
Registry entries for mailto protocol are under HKLM\SOFTWARE\Classes\mailto and as it is with other Classes, they could be overridden by entries for CURRENT_USER, under HKCU\SOFTWARE\Classes\mailto
BUT
There were changes in recent Windows versions and now, there are more places in registry which will further override shell associations from Classes. Moreover, in case of mailto they are mandatory and so rendering the Classes values for mailto useless.
Next in line of importance is Key:
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts\mailto]
which in turn is overridden by:
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\Roaming\OpenWith\UrlAssociations\mailto]
which is also used only if it's not overridden by:
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\Shell\Associations\UrlAssociations\mailto]
GOOD JOB Microsoft :)
Values under these Keys have the same format, a Key UserChoice with a ProgId valuename pointing to shell association Key from Classes.
But you can all but forget about editing these values, as there also is the Hash value. It's a protection against such registry edits.
User MUST click himself at least once to select an App on a standard Windows Open With dialog popup, if he also check the Always option, the Hash value is generated and the choice is remembered and written to last two Keys from the list above. Another option is to use the Settings as shown in the picture above.
It's a safeguard against malicious Apps, viruses and bad programmed Apps.
To troubleshoot a problem with default mailto association, you can delete mailto Keys from under all of these locations, except LOCAL_MACHINE.
Windows will re-create them on next use of the mailto protocol.