Setting device identifier using LoadKeyboardLayout() - windows

The problem is this: I must set the user's language to Simplified Chinese and the keyboard to "Chinese (Simplified) - Microsoft Pinyin New Experience Input st".
By setting this combo manually in the Control Panel (Region -> Keyboards and languages) and then running a small test program which calls GetKeyboardLayoutName(), I've found out that the KLID is 00000804 (supposedly). If I remove Chinese from Keyboards and languages in the Control Panel and run this:
HKL hKeyboardLayout = ::LoadKeyboardLayout(_T("00000804"), KLF_ACTIVATE | KLF_SETFORPROCESS);
Then the language is indeed changed to Chinese, but the keyboard settings are wrong. The little "IME box" is missing when typing something.
The MSDN page for LoadKeyboardLayout() says this about the pwszKLID parameter:
The name of the input locale identifier to load. This name is a string composed of the hexadecimal value of the Language Identifier (low word) and a device identifier (high word). For example, U.S. English has a language identifier of 0x0409, so the primary U.S. English layout is named "00000409". Variants of U.S. English layout (such as the Dvorak layout) are named "00010409", "00020409", and so on.
So it appears as if GeyKeyboardLayout() only reports the language identifier (0x0804 for Chinese), but the "device identifier" is missing. How can I find out the device identifier for "Microsoft Pinyin New Experience Input st"?

Found the solution. Apparently in Vista (and onwards) you must use InstallLayoutOrTip() with the correct GUID (not KLID) to install the proper language-keyboard combo. Then you can call LoadKeyboardLayout() to load it.
typedef HRESULT (WINAPI *PTF_INSTALLLAYOUTORTIP)(LPCWSTR psz, DWORD dwFlasg);
// Install.
HMODULE hInputDLL = LoadLibrary(_T("input.dll"));
BOOL bRet = FALSE;
if(hInputDLL == NULL)
{
// Error
}
else
{
PTF_INSTALLLAYOUTORTIP pfnInputLayoutOrTip;
pfnInputLayoutOrTip = (PTF_INSTALLLAYOUTORTIP)GetProcAddress(hInputDLL, "InstallLayoutOrTip");
if(pfnInputLayoutOrTip)
{
bRet = (*pfnInputLayoutOrTip)(_T("0804:{81D4E9C9-1D3B-41BC-9E6C-4B40BF79E35E}{F3BA9077-6C7E-11D4-97FA-0080C882687E}"), 0);
if(! bRet)
{
// Error
}
}
else
{
// Error
}
FreeLibrary(hInputDLL);
}
// Load.
HKL hKeyboardLayout = ::LoadKeyboardLayout(_T("00000804"), KLF_ACTIVATE | KLF_SETFORPROCESS);
References:
http://msdn.microsoft.com/library/bb847909.aspx
http://www.siao2.com/2007/12/01/6631463.aspx

Related

IShellLink - how to get the original target path

I created a shortcut in a Windows PC with a target path of:
C:\Users\b\Desktop\New Text Document.txt
Then I copied the shortcut to another PC with a different user name, and I want to retrieve the original target path.
If you open the shortcut file with a text editor, you can see the original path is preserved, so the goal is definitely possible.
The following code does not work, despite the presence of SLGP_RAWPATH. It outputs:
C:\Users\a\Desktop\New Text Document.txt
It is changing the user folder name to the one associated with the running program.
I understand that the problem is not about environment variables, because no environment variable name can be seen in the file. But I can't find any documentation about this auto-relocation behavior.
IShellLinkW*lnk;
if (CoCreateInstance(CLSID_ShellLink, NULL, CLSCTX_INPROC_SERVER, IID_IShellLinkW, (LPVOID*)&lnk) == 0){
IPersistFile* file;
if (lnk->QueryInterface(IID_IPersistFile, (void**)&file) == 0){
if (file->Load(L"shortcut", 0) == 0){
wchar_t path[MAX_PATH];
if (lnk->GetPath(path, _countof(path), 0, SLGP_RAWPATH) == 0){
_putws(path);
}
IShellLinkDataList* sdl;
if (lnk->QueryInterface(IID_IShellLinkDataList, (void**)&sdl) == 0){
EXP_SZ_LINK* lnkData;
if (sdl->CopyDataBlock(EXP_SZ_LINK_SIG, (void**)&lnkData) == 0){
_putws(lnkData->swzTarget);
LocalFree(lnkData);
}
sdl->Release();
}
}
file->Release();
}
lnk->Release();
}
The Windows Shell Link class implements a property store, so you can get access to this with code like this (with ATL smart pointers):
int main()
{
// note: error checking omitted!
CoInitialize(NULL);
{
CComPtr<IShellLink> link;
link.CoCreateInstance(CLSID_ShellLink);
CComPtr<IPersistFile> file;
link->QueryInterface(&file);
file->Load(L"shortcut", STGM_READ);
// get the property store
CComPtr<IPropertyStore> ps;
link->QueryInterface(&ps);
// dump all properties
DWORD count = 0;
ps->GetCount(&count);
for (DWORD i = 0; i < count; i++)
{
PROPERTYKEY pk;
ps->GetAt(i, &pk);
// get property's canonical name from pk
CComHeapPtr<wchar_t> name;
PSGetNameFromPropertyKey(pk, &name);
PROPVARIANT pv;
PropVariantInit(&pv);
ps->GetValue(pk, &pv);
// convert PropVariants to a string to be able to display
CComHeapPtr<wchar_t> valueAsString;
PropVariantToStringAlloc(pv, &valueAsString); // propvarutil.h
wprintf(L"%s: %s\n", name, valueAsString);
PropVariantClear(&pv);
}
}
CoUninitialize();
return 0;
}
It will output this:
System.ItemNameDisplay: New Text Document.txt
System.DateCreated: 2021/06/03:14:45:30.000
System.Size: 0
System.ItemTypeText: Text Document
System.DateModified: 2021/06/03:14:45:29.777
System.ParsingPath: C:\Users\b\Desktop\New Text Document.txt
System.VolumeId: {E506CEB2-0000-0000-0000-300300000000}
System.ItemFolderPathDisplay: C:\Users\b\Desktop
So, you're looking for System.ParsingPath, which you can get directly like this:
...
ps->GetValue(PKEY_ParsingPath, &pv); // propkey.h
...
Your shortcut is a .lnk file, just without the .lnk file extension present. According to Microsoft's latest "Shell Link (.LNK) Binary File Format" documentation, your shortcut appears to be configured as a relative file target. The relative name is just New Text Document.txt. I didn't dig into the file too much, but I'm guessing that it is relative to the system's Desktop folder, so it will take on whatever the actual Desktop folder of the current PC is. Which would explain why querying the target changes the relative root from C:\Users\b\Desktop to C:\Users\a\Desktop when you change PCs.
As for being able to query the original target C:\Users\b\Desktop\New Text Document.txt, that I don't know. It is also present in the file, so in theory there should be a way to query it, but I don't know which field it is in, without taking the time to fully decode this file. You should try writing your own decoder, using the above documentation.

CopyPipe of DriverKit IOUSBHostInterface fails with kIOReturnError (0xe00002bc)

For my own edification, I'm trying to read some audio data from a USB audio interface using a DriverKit System Extension.
My IOProviderClass is IOUSBHostInterface. I can successfully Open() the interface, but CopyPipe() returns kIOReturnError (0xe00002bc). Why can't I copy the pipe?
To be able to open the interface at all, I had to outmatch AppleUSBAudio so my IOKitPersonalities explicitly match the bConfigurationValue, bInterfaceNumber, idVendor, idProduct, and bcdDevice keys. This list may not be minimal.
In ioreg I can normally see the interfaces (sometimes only my matching one is there, although I think this is a degenerate situation). I see a AppleUserUSBHostHIDDevice child on some of my other interfaces. Could this be the problem? Normally the device has no problem being both USBAudio and HID. I am trying unsuccessfully to out match HID too.
I was passing the wrong endpoint address to CopyPipe().
To find an endpoint address you need to enumerate through the IOUSBDescriptorHeaders in the IOUSBConfigurationDescriptor and examine the descriptors with bDescriptorType equal to kIOUSBDescriptorTypeEndpoint.
IOUSBGetNextDescriptor() from USBDriverKit/AppleUSBDescriptorParsing.h is made for this and will save you from having think about pointer manipulation.
If the endpoint is in a different alternate setting, then you need to switch the interface to that one with SelectAlternateSetting().
void
enumerate_configs(const IOUSBConfigurationDescriptor *configDesc) {
const IOUSBDescriptorHeader *curHeader = NULL;
while ((curHeader = IOUSBGetNextDescriptor(configDesc, curHeader))) {
switch (curHeader->bDescriptorType) {
case kIOUSBDescriptorTypeEndpoint: {
auto endpoint = (const IOUSBEndpointDescriptor *)curHeader;
os_log(OS_LOG_DEFAULT, "Endpoint bLength: %{public}i, bDescriptorType: %i, bEndpointAddress: %i, bmAttributes: 0x%x, wMaxPacketSize: %i, bInterval: %i",
endpoint->bLength,
endpoint->bDescriptorType,
endpoint->bEndpointAddress, // pass this to CopyPipe()
endpoint->bmAttributes,
endpoint->wMaxPacketSize,
endpoint->bInterval);
}
break;
default:
os_log(OS_LOG_DEFAULT, "some other type: %{public}i", curHeader->bDescriptorType);
break;
}
}
}

Enabling Closed-Display Mode w/o Meeting Apple's Requirements

EDIT:
I have heavily edited this question after making some significant new discoveries and the question not having any answers yet.
Historically/AFAIK, keeping your Mac awake while in closed-display mode and not meeting Apple's requirements, has only been possible with a kernel extension (kext), or a command run as root. Recently however, I have discovered that there must be another way. I could really use some help figuring out how to get this working for use in a (100% free, no IAP) sandboxed Mac App Store (MAS) compatible app.
I have confirmed that some other MAS apps are able to do this, and it looks like they might be writing YES to a key named clamshellSleepDisabled. Or perhaps there's some other trickery involved that causes the key value to be set to YES? I found the function in IOPMrootDomain.cpp:
void IOPMrootDomain::setDisableClamShellSleep( bool val )
{
if (gIOPMWorkLoop->inGate() == false) {
gIOPMWorkLoop->runAction(
OSMemberFunctionCast(IOWorkLoop::Action, this, &IOPMrootDomain::setDisableClamShellSleep),
(OSObject *)this,
(void *)val);
return;
}
else {
DLOG("setDisableClamShellSleep(%x)\n", (uint32_t) val);
if ( clamshellSleepDisabled != val )
{
clamshellSleepDisabled = val;
// If clamshellSleepDisabled is reset to 0, reevaluate if
// system need to go to sleep due to clamshell state
if ( !clamshellSleepDisabled && clamshellClosed)
handlePowerNotification(kLocalEvalClamshellCommand);
}
}
}
I'd like to give this a try and see if that's all it takes, but I don't really have any idea about how to go about calling this function. It's certainly not a part of the IOPMrootDomain documentation, and I can't seem to find any helpful example code for functions that are in the IOPMrootDomain documentation, such as setAggressiveness or setPMAssertionLevel. Here's some evidence of what's going on behind the scenes according to Console:
I've had a tiny bit of experience working with IOMProotDomain via adapting some of ControlPlane's source for another project, but I'm at a loss for how to get started on this. Any help would be greatly appreciated. Thank you!
EDIT:
With #pmdj's contribution/answer, this has been solved!
Full example project:
https://github.com/x74353/CDMManager
This ended up being surprisingly simple/straightforward:
1. Import header:
#import <IOKit/pwr_mgt/IOPMLib.h>
2. Add this function in your implementation file:
IOReturn RootDomain_SetDisableClamShellSleep (io_connect_t root_domain_connection, bool disable)
{
uint32_t num_outputs = 0;
uint32_t input_count = 1;
uint64_t input[input_count];
input[0] = (uint64_t) { disable ? 1 : 0 };
return IOConnectCallScalarMethod(root_domain_connection, kPMSetClamshellSleepState, input, input_count, NULL, &num_outputs);
}
3. Use the following to call the above function from somewhere else in your implementation:
io_connect_t connection = IO_OBJECT_NULL;
io_service_t pmRootDomain = IOServiceGetMatchingService(kIOMasterPortDefault, IOServiceMatching("IOPMrootDomain"));
IOServiceOpen (pmRootDomain, current_task(), 0, &connection);
// 'enable' is a bool you should assign a YES or NO value to prior to making this call
RootDomain_SetDisableClamShellSleep(connection, enable);
IOServiceClose(connection);
I have no personal experience with the PM root domain, but I do have extensive experience with IOKit, so here goes:
You want IOPMrootDomain::setDisableClamShellSleep() to be called.
A code search for sites calling setDisableClamShellSleep() quickly reveals a location in RootDomainUserClient::externalMethod(), in the file iokit/Kernel/RootDomainUserClient.cpp. This is certainly promising, as externalMethod() is what gets called in response to user space programs calling the IOConnectCall*() family of functions.
Let's dig in:
IOReturn RootDomainUserClient::externalMethod(
uint32_t selector,
IOExternalMethodArguments * arguments,
IOExternalMethodDispatch * dispatch __unused,
OSObject * target __unused,
void * reference __unused )
{
IOReturn ret = kIOReturnBadArgument;
switch (selector)
{
…
…
…
case kPMSetClamshellSleepState:
fOwner->setDisableClamShellSleep(arguments->scalarInput[0] ? true : false);
ret = kIOReturnSuccess;
break;
…
So, to invoke setDisableClamShellSleep() you'll need to:
Open a user client connection to IOPMrootDomain. This looks straightforward, because:
Upon inspection, IOPMrootDomain has an IOUserClientClass property of RootDomainUserClient, so IOServiceOpen() from user space will by default create an RootDomainUserClient instance.
IOPMrootDomain does not override the newUserClient member function, so there are no access controls there.
RootDomainUserClient::initWithTask() does not appear to place any restrictions (e.g. root user, code signing) on the connecting user space process.
So it should simply be a case of running this code in your program:
io_connect_t connection = IO_OBJECT_NULL;
IOReturn ret = IOServiceOpen(
root_domain_service,
current_task(),
0, // user client type, ignored
&connection);
Call the appropriate external method.
From the code excerpt earlier on, we know that the selector must be kPMSetClamshellSleepState.
arguments->scalarInput[0] being zero will call setDisableClamShellSleep(false), while a nonzero value will call setDisableClamShellSleep(true).
This amounts to:
IOReturn RootDomain_SetDisableClamShellSleep(io_connect_t root_domain_connection, bool disable)
{
uint32_t num_outputs = 0;
uint64_t inputs[] = { disable ? 1 : 0 };
return IOConnectCallScalarMethod(
root_domain_connection, kPMSetClamshellSleepState,
&inputs, 1, // 1 = length of array 'inputs'
NULL, &num_outputs);
}
When you're done with your io_connect_t handle, don't forget to IOServiceClose() it.
This should let you toggle clamshell sleep on or off. Note that there does not appear to be any provision for automatically resetting the value to its original state, so if your program crashes or exits without cleaning up after itself, whatever state was last set will remain. This might not be great from a user experience perspective, so perhaps try to defend against it somehow, for example in a crash handler.

MAPI and Outlook address book

I'm developing one project using VC++ (MSDEV 2008), which has one function to send EMAIL with some attachments. I used MAPI functions to achieve this task.
I build the project with project setting "Character set: use Unicode character set" for UNICODE compatible support and file type is EXE extension. Here everything works fine.
Same project I build as OCX file extension. And I can display "new send mail" window with some attachments. Here the problem is
When I click address book icon ("To" button) to select the receiver mail id from the list. It displays the Address book dialog with title only "S" instead "Select Name: *". But this also works fine in EXE project.
Code:
HWND hWnd = this->GetSafeHwnd();
MAPIINIT_0 tMapInit = { 0, MAPI_MULTITHREAD_NOTIFICATIONS };
HRESULT hResult = MAPIInitialize( &tMapInit );
HMODULE hMapiMod = LoadLibrary(_T("mapi32.dll"));
ProcMapiLogon = (LPMAPILOGON)GetProcAddress( hMapiMod, "MAPILogon" );
(ProcMapiLogon)( (ULONG)hWnd, NULL, NULL, MAPI_LOGON_UI | MAPI_NEW_SESSION, 0, &hCurrentSession );
LPMAPISENDMAIL ProcMapiSendMail = NULL;
ProcMapiSendMail = (LPMAPISENDMAIL)GetProcAddress(hMapiMod, "MAPISendMail");
(ProcMapiSendMail)(hCurrentSession, (ULONG)hWnd, &myMsg, MAPI_DIALOG | MAPI_LOGON__UI, 0);
The question is why Address Book dialog’s title shows only “S” in OCX project. Same it works in exe project.
Kindly help me how to resolve the issue.
Additional note:
Thanks for your reply.
With Simple MAPI code, everything works fine (means I can display new send mail window and send it when I click ‘Send” button) except the “Address Book” dialog’s title (caption).
I tried extended MAPI functionalities also. When the project is built as .OCX file extension like “SendMail.ocx” still Address Book dialog’s title shows only “S”.
Extended MAPI Code:
HMODULE hMapiMod = LoadLibrary(_T("mapi32.dll"));
LPMAPISESSION lppSession;
LPMAPILOGONEX ProcMapiLogonEx = NULL;
ProcMapiLogonEx = (LPMAPILOGONEX)GetProcAddress( hMapiMod, "MAPILogonEx" );
ProcMapiLogonEx)( (ULONG)hWnd, NULL, NULL, MAPI_USE_DEFAULT | MAPI_UNICODE | MAPI_EXTENDED | MAPI_LOGON_UI | MAPI_NEW_SESSION, &lppSession );
Simple MAPI is ANSI only. The external MAPI dll has no idea that you complied as Unicode, all it sees is a string that it expects to be 0x0 terminated. Your Unicode (2 byte) strings have 0x0 for each ANSI character and double 0x0 at the end. Hence your string is terminated at the first 0x0.

Determine the registered application for an extension

I've got a file extension and I'd like to get the name of the application (if there is one) that will be invoked when I ShellExecute a file of that type. This is a WTL/C++ app. Is there any sample code out there that does this?
Thanks!
twk,
You're probably looking for the Win32 AssocQueryStringByKey Function.
http://msdn.microsoft.com/en-us/library/bb773473(VS.85).aspx
The ASSOCSTR value that specifies the type of string that is to be returned:
typedef enum {
ASSOCSTR_COMMAND = 1,
ASSOCSTR_EXECUTABLE,
ASSOCSTR_FRIENDLYDOCNAME,
ASSOCSTR_FRIENDLYAPPNAME,
ASSOCSTR_NOOPEN,
ASSOCSTR_SHELLNEWVALUE,
ASSOCSTR_DDECOMMAND,
ASSOCSTR_DDEIFEXEC,
ASSOCSTR_DDEAPPLICATION,
ASSOCSTR_DDETOPIC,
ASSOCSTR_INFOTIP,
ASSOCSTR_QUICKTIP,
ASSOCSTR_TILEINFO,
ASSOCSTR_CONTENTTYPE,
ASSOCSTR_DEFAULTICON,
ASSOCSTR_SHELLEXTENSION,
ASSOCSTR_DROPTARGET,
ASSOCSTR_DELEGATEEXECUTE,
ASSOCSTR_MAX
} ASSOCSTR;
My guess is that you want ASSOCSTR_FRIENDLYAPPNAME.
DWORD dwSize = 255;
TCHAR sBuffer[MAX_PATH] = {0};
HRESULT hr = AssocQueryString(0, ASSOCSTR_EXECUTABLE, _T(".htm"), _T("Open"), sBuffer, &dwSize);
CString csExt;
csExt.Format(_T("%s"), sBuffer);
AfxMessageBox(csExt);
Sorry, no code, but some useful information. See this related question: how-does-vista-generate-the-icon-for-documents-associated-to-my-application
It asked about icons, but it turns out the program associated to an extension is stored in the same place in the registry as the icon for that extension.
It's a Win32 FAQ since 1995 (Shell, see Google Groups, Win32)

Resources