Is there a way to get the Microsoft Cryptography API: Next Generation to work on Windows XP?
I'm afraid not. CNG is available on Windows Vista+ only. KSP is not the only dependency that CNG has. There are several other functionalities for which it requires the underlying OS to be Vista+.
As you certainly already know, CNG rely on a windows vista/seven/8 CNG keyisolation service (keyiso) it's provided by the operating system and not available in XP. You can rely on cryptoAPI which is availaible in XP. It will certainly be cheaper to provide win 7/8 licence than to try to redevelop the service and to port the SDK for XP which was a nice OS but not the future.
Related
I've just come to use WTSGetActiveConsoleSessionId to get the active console session ID.
I need this to work on XP / Server 2003. I'm 99% sure I've used this before successfully on those OS's. I've just checked (with depends.exe) and kernel32.dll exports WTSGetActiveConsoleSessionId on those OS's.
However, the MSDN page says:
Minimum supported client Windows Vista
Minimum supported server Windows Server 2008
What's up with that? Am I missing something? Is it safe to use it on XP / Server 2003?
Windows XP and Windows Server 2003 are no longer supported, so the minimum supported client/server is Windows Vista and Windows Server 2008, respectively. A common mistake is, that developers read the information to mean "introduced in". This is not the case.
Is it safe to use it on XP / Server 2003?
No. Neither Windows XP nor Windows Server 2003 receive bug fixes, or security and feature updates. The documented contract in the MSDN may or may not apply to systems that are no longer supported.
WTSGetActiveConsoleSessionId is available on Windows XP and Windows Server 2003, and if you have established that it is good enough for you, you can use it. It's just not safe to do so. You should ask your customers to upgrade to one of the supported client/server OSs.
I think it worked for me too in XP SP3 more info
I'd like to use both Google's Native-client API and BlueZ for a senior design project but, I can't figure out if BlueZ is compatible the Native Client SDK. Does the full set of white-listed APIs include this library?
I'm uncertain if bluetooth APIs in general are white-listed for Android Native Client apps, but even if they are, there are not going to be native BlueZ APIs available on all devices or versions.
As indicated by Google (https://source.android.com/devices/bluetooth.html) as of JB 4.2 the native bluetooth stack is BlueDroid, which is based on Broadcom's stack. Before that time BlueZ was the default stack, but was replaced by some vendors with their own.
It may still be possible to install BlueZ on your newer OS device if it is rooted, but you cannot at all be certain the underlying stack on any random device will be BlueZ or BlueDroid, so if developing an app for distribution you would need to limit yourself to official APIs that Android provides (http://developer.android.com/guide/topics/connectivity/bluetooth.html), or maybe implement on each stack and detect at runtime what stack to use, assuming what you want to do is even possible with BlueDroid.
I know that VB offers many things to control it : SDK, API, COM, web server etc
What I'd like to do is have a GUI to simply create VM connected through networks but I have to know: what is the best solution use Frontends [1], webserver, COM* or API ? elsewhere libvirt ?
A an example a use case could be : I put 3 VMs on my GUI, choose their respective OS , create 1 or more network connection(s) for each and connect these VM to create network(s).
Python, C++, etc, implementation language doesn't matter.
[1] http://www.virtualbox.org/manual/ch01.html#frontends
My qualifications for answering this being that I created and have maintained Vagrant since early 2010. Here are my general opinions of each of the available frontends for scripting VirtualBox:
vboxwebsrv is the VirtualBox web service which provides an API to control VirtualBox. The pro of this is that web services are easy to program for nowadays. The main con is that you must handle startting and stopping this web service manually (or check to make sure it is already running). Historically, the web service has not been fully up-to-date with the latest APIs available in each version of VirtualBox, but I'm not sure what the status of that is today.
COM or C API. VirtualBox provides an XPCOM based API on non-Windows platforms and an MSCOM based API on Windows. If you can't use C++, you can also use the C API on Linux (but it is not available/exported on Windows). I used this API for over a year. Pros: Fast and complete. Since it is a C API it is very fast, communicating with the VirtualBox process directly. It is also complete, since this is the same API that VirtualBox GUI is using as well as using internally. The main con is that XPCOM is not easy, and the C API is not available on Windows, meaning you either have to pain through XPCOM, or you need to handle both C and MSCOM. I chose the latter and it turned out to be a nightmare of compatibility. Almost every minor release of VirtualBox (3.1, 3.2, etc.) will change the API in a backwards incompatible way (slightly) and a major release and you can completely forget about (3.0, 4.0, etc.). This makes handling older versions of VirtualBox... tricky. This is definitely an advanced use case.
VBoxManage is the CLI based frontend for VirtualBox. Under the covers VBoxManage is of course just using the COM-based API, but provides a much more user-friendly cover on top of it. I've found that for 99% of use cases, VBoxManage can cover it. VBoxManage also handles all error handling, does proper exit status (0 for success, non-zero for everything else), etc. After 1.5 years of the C API I've switched back to VBoxManage because its simply easier to use and does what I need to do. The downside is you must use a subprocess to talk to VBoxManage. The upside is VBoxManage changes relatively infrequently, and as such it makes it very easy to support many versions of VirtualBox.
I hope this helps!
I'm trying to write an application that connects to my company's wireless network automatically on windows XP.
I've found the Wireless LAN API but it requires me to have some hotfix installed on the machine, and you need to have sp2 or higher(There are machines with SP1, and I'm required to support any XP machine).
I've tried to find some samples about Wireless Zero Configuration on MSDN but with no luck, only samples I've found are for WinCE, I think Microsoft stopped supporting it. In addition I couldn't find where to download the dll and header file for working with the WZC.
There must be a way to do it and work on any service pack because I've found Zwlancfg by ENGL
Point out that any change you'll have to introduce to these old XP machines will be similar in magnitude to the SP2 update, except that (1) you don't have the insight into the network stack that Microsoft has, (2) you don't have the experience in Windows development that Microsoft collectively has and (3) you don't have the testing resources (including beta testers) that Microsoft has. So your change will be more risky and less stable than the SP2 update.
Couldn't you just setup the wireless password and tell XP to auto-join when it sees the network?
Maybe I'm missing something but it happens automatically, so I don't see why you need to code an app to do this.
I would encourage you to advocate for upgrading those XP machines at least to Service Pack 2 as it was a major upgrade in terms of functionality and security. It's also been at least 5 years since it was rolled out so I can't imagine you'd have compatibility issues with 3rd party software.
That being said.
Wireless for XP was seriously reworked with Service Pack 2 and the Wireless Network Policy was created that allows you to push out policy to all machines on your network via the Group Policy MMC.
You should try native wifi api but it will work with XP SP2
There is one WLANCONNECT() methos try that one
with that you will be able to connect to network with your program
I'm porting a C++ 32 bit application to 64 bit on windows. The application is a client of IBM WebSphere MQ. It uses the MQ client API.
Now, as the port progresses, I'm trying to find a 64 bit client. So far, no luck.
Does anyone here happen to know if where I can find one or confirm that there isn't one?
Websphere MQ 7 for Windows supports x86 and x64, but not Itanium 64-bit. It only officially supports Visual C++ 2005 for development at the moment but IBM usually issues PTFs for toleration on a regular basis so it shouldn't be too long before C++ 2008 support is there.
The statements of support and requirements are hosted on IBM web pages at http://www-01.ibm.com/support/docview.wss?rs=171&uid=swg27011920 if you're interested in further details.
Since this is getting lots of views, let's provide the direct link to the WMQ V7 client download. Note that it DOES support 64-bit Windows clients in some versions of Windows.
The System Requirements page for WMQ v7.0.1 now lists Visual Studio 2008 as supported.
Note that some of the supporting code is 32 bit so the client installs to the Program Files (x86) directory.
The IA94 SupportPac referenced by another poster implements the JMS API over C++ and the supported environments for that SupportPac are a subset of those for the WMQ client. If you are not using the SupportPac, refer to the link above for System Requirements instead.
I found this page on IBM's site: IA94: IBM Message Service Client for C/C++. On it there is a link to a readme.txt file which, under "Supported environments" lists "Windows 2003 Server x64 edition - Microsoft Visual C++ .NET 2005 Service Pack1".
Hope that helps!