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!
Related
I have developed a custom snmp extension agent to work in conjunction with Windows Snmp service. I have implemented in C++ using the interface provided by snmp.h from Microsoft and I am creating a 64 bit dll to be used as extension agent.
To install this dll as extension agent I have added a registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SNMP\Parameters\ExtensionAgents as:
MyAgent REG_SZ SOFTWARE\MyAgent\CurrentVersion
And under HKEY_LOCAL_MACHINE\SOFTWARE\MyAgent\CurrentVersion, I have created another registry specifying the path of the dll as:
Pathname REG_EXPAND_SZ C:\Program Files\testing\MyAgent.dll
When I did this in the system event logs I keep getting that the The SNMP Service is ignoring extension agent dll C:\Program Files\testing\MyAgent.dll because it is missing or misconfigured.
The agent is a trapless agent. It exposes the SnmpExtensionInit and the SnmpExtensionQuery function from snmp.h. I don't know what is messed up. Do I need a 32 bit dll? All of the sources on internet are very old and refer to Windows NT. I need to configure it on newer operating systems like Windows 10 and Windows server 2016. Any suggestions would help.
Also there are similar questions on SO for same error but all of them are related to migration of a 32 bit dll. I am starting with 64 bit.
because the SNMP process is still 32-bit the key needs to be
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6232Node\MyAgent\CurrentVersion
but I am finding the SnmpExtensionInit is not called
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
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.
I am trying to create a single-sign on connection to a System i server using the example published in IBM's iSeries Telnet Enhancements RFC 4777 within a client telnet app written in C++.
The code sample given calls AcquireCredentialsHandle and then a call to InitializeSecurityContext. The call to InitializeSecurityContext returns an error of SEC_E_TARGET_UNKNOWN, presumably because it does not understand the target name I am passing.
The RFC 4777 says this target name should be a string with kbsrv400 then my server name fully qualified in lower case. I interpretted this as "krbsrv400/iseries.domain.com". I've tried a variety of combinations here but can't get anything to work and not yet found any other code samples that use the MS SSPI API to connect to IBM System i.
I know the Kerberos setup on the System i and domain is working OK as IBM's own iSeries Access is able to login OK and perform a telnet 5250 signon using kerberos.
I am running on Windows 7 signed into a domain. The domain is setup under Active Directory in Windows 2008. I'm using MS Visual Studio 2005 to build my telnet app. The System i server OS is V6R1.
Has anyone got this sample code working?
Any advice on what the format of the target name should be when using it to talk to System i?
Thanks!
Additional info: 9/8/2011
Have got this working OK under Windows XP client with a Windows 2003 managed Domain.
There were two errors in the RFC:
1) It said to use a name of "krbsrv400/spi name" but looking at the ticket in kerbtray that was generated when I logged in using iSeries Access, I saw the actual format was "krbsvr400/spi name".
2) The RFC said to pad the ticket length sent to the system i but when I used Wireshark to look at the IBM iSeries access telnet, I found they did not pad it.
Changing the above got single-signon working OK in my app on Windows XP. I am still experiencing problems on Windows 7.
This is a different domain (managed by the company, and on Windows 2008 and Windows 2003 servers across the world) and with a different iSeries.
Strangely, I can use Kerberos login in System i Access OK, but when I look in kerbtray I do not see a kerbsvr400/... ticket for the system i machine like I do on Windows XP. My app does not work and fails with a SEC_E_TARGET_UNKNOWN error.
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