Programmatically installing printer drivers from Windows Update - c++

I'd like to be able to programmatically install a selected printer driver from Windows Update. I've tried doing so with something like the following code, but the only search results returned were the collection of Windows Language Packs that I haven't installed.
IUpdateSearcher *pUpdateSearcher = NULL;
// Snip instantiation code
pUpdateSearcher->put_ServerSelection(ssWindowsUpdate);
pUpdateSearcher->put_CanAutomaticallyUpgradeService(VARIANT_TRUE);
pUpdateSearcher->put_IncludePotentiallySupersededUpdates(VARIANT_TRUE);
pUpdateSearcher->put_Online(VARIANT_TRUE);
hr = pUpdateSearcher->Search(
BSTR(TEXT("Type='Driver' AND IsInstalled=0 AND IsHidden=0")),
&pSearchResult
);
Is there a way I could programmatically search Windows Update for printer drivers in a way similar to how you can search Windows Update when manually installing a printer?

Related

Connecting Redland to Virtuoso through Virtuoso's ODBC/iODBC on MacOS X Environment

In order to install Virtuoso on my MacOS X environment, i used the brew port, that is:
brew install virtuoso
By doing so, it automatically installed some ODBC/iODBC drivers, that could not be overwritte by any other unixodbc setup. In particular if I try to link such library:
$ brew link unixodbc
Linking /usr/local/Cellar/unixodbc/2.3.4...
Error: Could not symlink bin/isql
Target /usr/local/bin/isql
is a symlink belonging to virtuoso. You can unlink it:
brew unlink virtuoso
To force the link and overwrite all conflicting files:
brew link --overwrite unixodbc
To list all files that would be deleted:
brew link --overwrite --dry-run unixodbc
By the way, I do not want to unlink this version. So I tried to compile Redland from scratch and download it from GitHub. In particular, I used two possible configurations:
env PKG_CONFIG_PATH=/usr/local/lib/pkgconfig ./configure --with-virtuoso --with-odbc=/usr/local/Cellar/virtuoso/7.2.4.2
env PKG_CONFIG_PATH=/usr/local/lib/pkgconfig ./configure --with-virtuoso --with-iodbc=/usr/local/Cellar/virtuoso/7.2.4.2
After adding rdf_hash_internal.h and rdf_heuristics.h in my project manually, everything just goes smoothly and everything gets both compiled and linked. In my C++ app, I'm trying to access the database with the following code:
world = librdf_new_world();
librdf_world_open(world);
storage = librdf_new_storage(world,"virtuoso",graphName.c_str(),"dsn='Local Virtuoso',user='dba',password='dba'");
model = librdf_new_model(world,storage,NULL);
context_node = librdf_new_node_from_uri_string(world,(const unsigned char*)defaultContext.c_str());
/* librdf_model_transaction_commit(this->super->model) */
librdf_model_size(super->model)
If either I disable the transaction or not, anyway I got the following error at line 941 of "rdf_storage_virtuoso.c":
rc = SQLDriverConnect(connection->hdbc, 0,(UCHAR *) context->conn_str,
SQL_NTS, context->outdsn,
LIBRDF_VIRTUOSO_CONTEXT_DSN_SIZE,
&buflen, SQL_DRIVER_COMPLETE);
Hence, I suppose there is a connection error at the ODBC/iODBC level. By the way, I could connect to virtuoso with the following command:
$ isql localhost:1111 dba dba
Connected to OpenLink Virtuoso
Driver: 07.20.3217 OpenLink Virtuoso ODBC Driver
OpenLink Interactive SQL (Virtuoso), version 0.9849b.
Type HELP; for help and EXIT; to exit.
SQL>
Is there any way to connect the Redland library with ODBC library by Virtuoso? Thanks in advance.
All those troubles were due to a configuration issue that AFIK was described in no guide (Correct me if I'm wrong, I'd like to find more details on both Virtuoso and Redland/librdf). Hereby, as I told in the comments, the problem was in ODBC, but the reason was that there is no mention in no Virtuoso guide how to configure their driver. This is the way to go:
/Library/ODBC/odbc.ini
[ODBC Data Sources]
VOS = virtuoso-odbc
[VOS]
Driver = /usr/local/Cellar/virtuoso/7.2.4.2/lib/virtodbc.so
Description = Virtuoso Open-Source Edition
Address = localhost:1111
UserName = dba
User = dba
/Library/ODBC/odbcinst.ini
[ODBC Drivers]
virtuoso-odbc = Installed
[virtuoso-odbc]
Driver = /usr/local/Cellar/virtuoso/7.2.4.2/lib/virtodbc.so
Consequently, even the configuration parameters required to access through Redland has to change.
storage=librdf_new_storage(world, "virtuoso","db1","dsn='VOS',user='dba',password='dba'");
Where VOS is the configuration definition within ODBC.
Moreover, the specific ContextNode specifies which is the Named Graph to be used.
I don't know much about brew, but is it possible to modify its package-definition so that it renames our isql binary, e.g. to isql-vt instead?
We already do this in our Debian/Ubuntu packaging by calling
./configure --program-transform-name='s/isql$$/isql-vt/;s/isqlw/isqlw-vt/'
See https://github.com/openlink/virtuoso-opensource/blob/develop/7/debian/rules#L31
I don't see the error you get from line 941, but two things concerning ODBC connections:
1) your --with-iodbc= must point to a copy of iodbc, not to virtuoso (you can get it from http://iodbc.org/ or your distribution probably has a package e.g. libiodbc2-dev on debian/ubuntu)
2) Virtuoso's isql tests a direct connection to virtuoso; to check that the driver manager is configured properly, use iodbctest (or unixODBC's isql that caused the conflict above in the first place).
First thing, iODBC is the ODBC driver manager Apple builds into OS X, and users are usually better off sticking with it -- though we (OpenLink Software, maintainers of iODBC) do recommend updating to the curent version, as Apple is typically many updates behind.
Related to that, Apple doesn't bundle the full iODBC SDK. They leave out the Frameworks, among other things.
Generally speaking, UnixODBC doesn't fully integrate with GUI-space OS X apps nor drivers, and there are various other issues that surface over time. Current iODBC doesn't care whether you're working in GUI or command-line, Carbon or Cocoa, 32-bit or 64-bit... It all just works (and if it doesn't work, we want to know, so we can fix it).
MacPorts and other packagers I've used have had ways to switch between UnixODBC and iODBC (e.g., variants); I can't quickly find such for Homebrew, but maybe you can?

Create a Direct3D12 Device fails with E_NoInterface

I'm trying to create a D3D12 device as specified in
https://msdn.microsoft.com/en-us/library/dn899120%28v=vs.85%29.aspx
I have a NVidia 670 gtx, Windows 10 preview build 9926, and last 10041 windows sdk.
I also have latest NVidia beta driver, system information for GeForce reports a DirectX12 runtime.
Calling
ID3D12Device* device;
HRESULT hr = D3D12CreateDevice(NULL, D3D_DRIVER_TYPE::D3D_DRIVER_TYPE_HARDWARE,
D3D12_CREATE_DEVICE_FLAG::D3D12_CREATE_DEVICE_NONE,
D3D_FEATURE_LEVEL::D3D_FEATURE_LEVEL_11_0, D3D12_SDK_VERSION, __uuidof(ID3D12Device), (void**)&device);
Returns me a HRESULT with NOINTERFACE error code
Strangely calling:
ID3D12Object* device;
HRESULT hr = D3D12CreateDevice(NULL, D3D_DRIVER_TYPE::D3D_DRIVER_TYPE_HARDWARE,
D3D12_CREATE_DEVICE_FLAG::D3D12_CREATE_DEVICE_NONE,
D3D_FEATURE_LEVEL::D3D_FEATURE_LEVEL_11_0, D3D12_SDK_VERSION, __uuidof(ID3D12Object), (void**)&device);
returns me a valid object, but I'm not able to use QueryInterface to get a valid device object afterwards.
Please note I already tried using LoadLibrary/GetProcAddress instead of using d3d12 headers, which returns same error code.
You should always use the same OS and SDK Build, because APIs can change betweens builds. Because you use SDK for Build 10041, you should also update Windows 10 to the Build 10041. Open the Settings App, and search for a new Windows 10 Build and install it.

EDSDK cpp error: 10 EDS_ERR_MISSING_SUBCOMPONENT

I am trying to get started with EDSDK to control my Canon 500D. I'm new to cpp, and windows XP apps and I'm using visual studio. After a great deal of blind trial and error I have finally managed to get the app to compile the basic sample code from the documentation. To do this I have the EDSDK.h, EDSDKTypes.h and EDSDKErrors.h headers in the right places and the EDSDK.dll and EDSDK.lib in the same folder as the code. It seems to be picking these up. I have got the 500D to be recognised by the PC so I believe the USB drivers are there.
The code is just trying to pick up the camera:
EdsError err=EDS_ERR_OK;
EdsCameraListRef cameraList=NULL;
err = EdsGetCameraList(&cameraList);
if(err == EDS_ERR_OK)
{...}
However, when I run this console app the error is picked up as 10 - which suggests, according to the document, that there is a missing subcomponent. This happens both if the camera is connected or not, so I'm thinking this is something missing from the compile. But I am getting nowhere with the documentation.
I have installed the edsdk 2.4 Windows version from a download not the official route, so this may be an issue.
Can anyone help? Specifically how can I find out what the missing subcomponent might be so I might include it. Is this a subcmponent of the build like a header file or something like a driver?
I know, old question but still it might help someone with the same problem.
From the documentation:
All DLLs are required in order to execute an EDSDK client application.
All of the modules in the DLL folder must be copied into the same folder where the EDSDK client application is in.
This means you'll have to have all DLLs beside your *.exe. Namely these DLLs:
DPPDLL.dll
DPPLibCom.dll
DPPRSC.dll
EDSDK.dll
EdsImage.dll
Mlib.dll
Ucs32P.dll

Insert item to desktop right-click menufrom shell extension

I've written a windows explorer shell extension using VS2010 and ATL, registered under HKLM\Directory\Background\shellex\ContextMenuHandlers to add my commands under context menu.
All is working as expected, but I want to add a context-menu entry which shows up if and only if user has right-clicked on desktop, like windows 7 defaults "gadgets, personalize, etc".
I've tried this, but does not work (does not match):
if (GetForegroundWindow () == GetDesktopWindow ()) {
// code here
}
Any toughts on how this can be done ?
I've also tried using SHGetFolderPath() with CSIDL_DESKTOPDIRECTORY and do a _tcsicmp(), this works, but does show up even if desktop directory is opened in a normal windows explorer window, which I don't want.
Register it under HKCR\DesktopBackground\shellex\ContextMenuHandlers

How to create a Linux desktop icon cross desktop (KDE, GNOME) with xdg-desktop-icon?

I'd like to use the xdg-desktop-icon tool because it can be scripted and works cross desktop (at least on Linux with Gnome and KDE). At least it is supposed to do so according to freedesktop.org. 1
Made a minimal file: test.desktop
[Desktop Entry]
Encoding=UTF-8
Type=Application
Exec=test
Icon=test
Name=test
Used xdg-desktop-icon...
xdg-desktop-icon install --novendor test.desktop
Exit code is 0. (Success.) But... I do not see any new icons on my desktop. Also not after reboot. This failed on Ubuntu Precise 12.04 with KDE and on Debian Wheezy with KDE.
How to use the xdg-desktop-icon tool correctly?
The problem on KDE has something to do with the desktop settings. Folder view, Newspaper view and so on.
xdg-desktop-icon relies on xdg-user-dir to determine the user desktop directory. You can check either against that command and the settings of your file manager (or program handling the desktop).
Assuming by default it would be /home/user/Desktop, then you have to check the file name there. If the file is there, then xdg-desktop-icon is working as expected.
You have to consider that the icon (test in your case) has to be installed separately using xdg-icon-resource. That is, if you are not using a stock icon or custom icon already installed or you are not using an absolute path for the icon.
Do not forget that xdg-desktop-icon only copies the .desktop file in a specific directory. No more no less.
If I am working on ~/myapp directory, I would check by doing:
$ xdg-user-dir
/home/user/Desktop
$ ls `xdg-user-dir`/test.desktop
ls: cannot access /home/user/Desktop/test.desktop: No such file or directory
$ xdg-desktop-icon install --novendor test.desktop
$ ls `xdg-user-dir`/test.desktop
/home/user/Desktop/test.desktop
Eventually, you can run with any xdg- script with:
$ XDG_DEBUG_LEVEL=1 xdg-desktop-icon ...
Which will give you an extra line telling you where the desktop file was installed. At this point, if the icon has not been installed, it might appear an ugly default icon.