Is it possible to cull the graphics card name and graphics driver version from the registry using the Win32 API? Language is C# and environment is VS2010.
Related
I want to controll a robot arm with a raspberry pi running windows 10 iot. There is a dll to controll the arm. In the documentation of the dll it says that a .NET 2.0 framework is required. Is it possible to use the dll in my application for the windows core iot?
For Windows 10 IoT Core you create apps to do such things using the Universal Windows Platform (UWP) framework. This uses .Net Core. Not the full framework.
Check the latest version of the assemblies you require.
https://www.microsoft.com/net/core
I am not able to identify UI controls of Windows Store apps using AutoIt Window Information Tool. The standard app Calculator for example (Windows 10):
As you can see, it doesn't show information for button 8. I tried both x86 and x64 versions.
How to interact with Windows Store apps? For traditional desktop apps AutoIt works as expected.
It's impossible, AutoIt developers have no plans to support UI Automation API. You can find Inspect.exe in your Windows SDK and run it in UIA mode to compare with AutoIt Info tool.
There are some other tools supporting UIA (TestStack.White (C#), Winium.Desktop (C#) and some direct UIA wrappers on other languages like pyuiautomation on Python). pywinauto 0.6.0 added MS UI Automation support.
UIA support for AutoIt; 24 Apr 2009 AutoIt forum thread. Plans may have changed, but it's the top result for a "AutoIt WPF support" Google search.
In order to use Autoit Window info tool in Win10 you should use 64bit version exe.
Au3Info_x64.exe
Common location is C:\Program Files (x86)\AutoIt3\Au3Info_x64.exe
In almost every text about the new WinRT API I came to statements like "WinRT is the new API for Windows and replaces the old Win32 API". Since WinRT aims the development Windows Store apps, this statement to me does not seem to hold true.
There are lots of applications I just can not imagine to be done with WinRT (e.g. Microsoft Office, Adobe Products, 3D Designer Programs and even Visual Studio). These applications still need the functionality of the Windows API (aka Win32).
So why is it so often said, that the WinRT API replaces the Windows API?
This has kind of changed, recently due to a couple reasons, but here's the rundown of why you want to use WinRT over Win32 in current Windows application development (circa 2017):
WinRT is leveraged by UWP apps
Win32 apps can be converted into UWP apps using the Desktop Bridge
Windows 10 S requires all apps to go through the Windows Store
Ergo, using WinRT will invoke less time spent converting projects and code for the new Windows 10 S Store-only application paradigm.
In regards to WinRT vs. Win32API vs. .NET, both .NET and WinRT are partially built with Win32; IIRC, they use subsets of it. At least that's what was communicated back in 2012 from ArsTechnica in Peter Bright's article, "Turning to the past to power Windows’ future: An in-depth look at WinRT". That's where this stack chart comes from, or at least it was used there:
I'm not sure if it's often said that the Windows Runtime (WinRT) API replaces the Win32 API. It's not something Microsoft is saying. In many ways WinRT tries to learn from the failure of the .NET Framework to replace the Win32 API. That includes Microsoft not trying to push WinRT as a replacement, but merely a new way of doing things.
There isn't actually much of a reason why the applications you mentioned couldn't be be implemented using the WinRT API. The new API includes a lot of the functionality of the old. You can write WinRT applications in C++ and the resulting applications are native executables, not managed ones. It's even possible to use a subset of the Win32 APIs.
While Adobe has little to gain by porting its applications to WinRT, expect Microsoft to do so. They rewrote most of Visual Studio to use the .NET framework. If anything the WinRT API makes it practical to implement much more of it the new environment.
I have a code base of native C++. Recently I incorporated a Windows 8 tablet into the system that we deploy to.
I have a .NET managed DLL that accesses the Tablet orientation sensor. This managed code is wrapped by an unmanaged class that I can access from the native C++.
The problem is that I cannot run and debug the code on my Windows 7/VS2010 box without getting an Access Violation at the outset. No breakpoints are even hit before the exception.
Is there a way to ignore the managed DLL while debugging on the Windows 7/VS2010 box?
Delay loading is your friend. Read the MSDN documentation, starting with Linker Support for Delay-Loaded DLLs.
Is the DirectXMath library cross platform? Is it possible to use it with OpenGL and/or on OSX and Linux?
DirectXMath primarily relies on the Visual Studio compiler intrinsics support. As a header in the Windows 8.x SDK, it officially only supports Visual Studio 2010 - Visual Studio 2013, and Windows Vista or later. It only has a single Win32 API dependency (IsProcessorFeaturePresent), even that is optional.
It is technically possible to use it for Windows XP, but there's no official SDK configuration that would provide it in the headers that are supported on Windows XP.
There's no official support for other compilers, but it would probably work with the Intel compiler.
Otherwise DirectXMath is not actually tied to Direct3D in particular, so you could use it with OpenGL or whatever.
The main issue is going to be that the DirectXMath library is available in the Windows 8.x SDK, the Windows Phone 8.x SDK, the Xbox One XDK, and Xbox One ADK. You'd have to look at those EULAs--I'm not a lawyer and I cannot provide legal advice.