Is there any msscript control in 64 bit?
I google a bit and all say no 64-bit yet
The reason that I need 64bit msscript.ocx is that I want to compile delphi projects in 64-bit using XE3.
It compiles OK in XE3 and I have obtained a 64-bit exe but when it executes to the following line,
script := TScriptControl.Create(nil);
It gives me a 'Class Not Registered' error. I only found msscript.ocx under C:\windows\SysWOW64 but there is no such file under System32 folder.
I really want this to work so any quick replacement for this?
This is an old post. but I just found a very good alternative to 64-bit MSScript Control (Microsoft does not have 64-bit msscript.ocx)
http://www.eonet.ne.jp/~gakana/tablacus/scriptcontrol_en.html
and I have changed only a few lines of code in my application and it works in 64-bit based on this ScriptControl64.
The msscript component was not ported to 64 bit. It's a legacy component and MS chose not to put the effort into migrating it to 64 bit. You'll simply need to find another way to do whatever it is you do with that component.
I faced the same issue porting an c++ application from 32 to 64 Bit.
I know that this question was raised on Delphi but I hope someone can make use of this information or transfer it to other languages.
We where initiating the "ScriptControl" (MSScriptControl.ScriptControl.1) via CreateDispatch.
The control info is located in Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ScriptControl
and we executed VBS or JScript with this MS control in 32 Bit:
COleDispatchDriver* m_dispScriptControl = new COleDispatchDriver();
if (m_dispScriptControl)
{
if (m_dispScriptControl->CreateDispatch(_T("ScriptControl")))
{
...
.... setting language to be used and other proteries .. then execute script code:
_variant_t varResult;
VariantClear(&varResult);
EXCEPINFO excepinfo;
VARIANT parameters;
parameters.vt = VT_BSTR;
parameters.bstrVal = strScriptCodeWCHAR;
DISPPARAMS dispparams;
dispparams.rgdispidNamedArgs = NULL;
dispparams.cNamedArgs = 0;
dispparams.cArgs = 1;
dispparams.rgvarg = ¶meters;
unsigned int uArgErr = 0;
if (S_OK != m_dispScriptControl->m_lpDispatch->Invoke(0x7d2, IID_NULL, LOCALE_SYSTEM_DEFAULT, DISPATCH_METHOD, &dispparams, &varResult, &excepinfo, &uArgErr))
...
}
After some research it seems not to be possible to create the
ScriptControl in 64 bit application as of a MSDN query:
Question was: I have window forms application currently working fine
on 32 Bit Application and i am investigation so we can install it on a
64 bit computer but getting on lauching the application as below.
Class not registered (Exception from HRESULT: 0x80040154
(REGDB_E_CLASSNOTREG))
The error is located on AxInterop.MSScriptControl.dll
Awnser is: If it ONLY lives in C:\Windows\SysWOW64, then your .Net
application cannot run in 64-bit mode. Make sure you compile it for
x86 instead of Any CPU. Then you'll be able to use it in 64-bit
Windows, but it will be a 32-bit process.
https://social.msdn.microsoft.com/Forums/windows/en-US/1e9ddfe4-3408-4a34-ba43-a1a0931daebd/64-bit-windows-7?forum=clr
With which we where not happy as we want to run as 64-bit process
Our solution was to use the Microsoft IActiveScript Interface. And implemented the same on our main window:
BEGIN_INTERFACE_PART(ActiveScriptSite, IActiveScriptSite)
STDMETHOD(GetLCID)(LCID*);
STDMETHOD(GetItemInfo)(LPCOLESTR, DWORD, LPUNKNOWN*, LPTYPEINFO*);
STDMETHOD(GetDocVersionString)(BSTR*);
STDMETHOD(OnScriptTerminate)(const VARIANT*, const EXCEPINFO*);
STDMETHOD(OnStateChange)(SCRIPTSTATE);
STDMETHOD(OnScriptError)(IActiveScriptError*);
STDMETHOD(OnEnterScript)();
STDMETHOD(OnLeaveScript)();
END_INTERFACE_PART(ActiveScriptSite)
Now when we have to execute script code we do the following, which works fine in 64 and 32 BIT versions of our built:
CString strLanguage;
if (nLanguage == 1)
{
strLanguage = _T("VBScript");
}
else
{
strLanguage = _T("JScript");
}
CComPtr<IActiveScript> m_pAxsScript;
HRESULT hr = m_pAxsScript.CoCreateInstance(CT2W(strLanguage), NULL, CLSCTX_INPROC_SERVER | CLSCTX_INPROC_HANDLER);
m_pAxsScript->SetScriptSite(&m_xActiveScriptSite); //m_xActiveScriptSite is a member of the interface
CComQIPtr<IActiveScriptParse> m_pAxsScriptParse = m_pAxsScript;
m_pAxsScriptParse->InitNew();
EXCEPINFO pException = { 0 };
hr = m_pAxsScriptParse->ParseScriptText(_bstr_t(strCode), 0, NULL, NULL, dw, 0, 0, NULL, &pException);
//execute script
m_pAxsScript->SetScriptState(SCRIPTSTATE_CONNECTED);
m_pAxsScriptParse.Release();
m_pAxsScriptParse = nullptr;
hr = m_pAxsScript->SetScriptState(SCRIPTSTATE_DISCONNECTED);
ASSERT(hr == S_OK);
m_pAxsScript->Close();
m_pAxsScript.Release();
Related
I have an application which is build using several DLL files.
I'm trying to perform PCL's statistical outliers removal using the following code:
PointCloudWithRGBNormalsPtr pclCloud(new PointCloudWithRGBNormals());
ConvertPointCloudToPCL(in_out_cloud /*my own structure which includes xyz, rgb, nx ny nz*/, *pclCloud);
pcl::StatisticalOutlierRemoval<PointXYZRGBNormal> sor;
sor.setInputCloud(pclCloud);
sor.setMeanK(10);
sor.setStddevMulThresh(1.0);
sor.filter(*pclCloud);
ConvertPointCloudToPCL:
static void ConvertPointCloudToPCL(const std::vector<Cloud3DrgbN> &in, PointCloudWithRGBNormals &output)
{
for (auto it = in.begin(); it != in.end(); it++)
{
const Cloud3DrgbN &p3d = *it;;
PointXYZRGBNormal p;
p.x = p3d.x;
p.y = p3d.y;
p.z = p3d.z;
p.normal_x = p3d.nX;
p.normal_y = p3d.nY;
p.normal_z = p3d.nZ;
p.r = p3d.r;
p.g = p3d.g;
p.b = p3d.b;
output.push_back(p);
}
}
For some reason, if I call this function from 1 of my dlls it works as it should. However, there's 1 dll that if I call it from it, when pclCloud goes out of scope, I'm getting an exception from Eigen's Memory.h file at the handmade_aligned_free function
I'm using Windows 10 64-bit, pcl 1.8.1 and Eigen 3.3 (tried 3.3.4, same thing)
Update:
After further digging, I've found that EIGEN_MALLOC_ALREADY_ALIGNED was set to 0 because I'm using AVX2 in my "problematic" DLL. I'm still not sure though why using Eigen's "handmade" aligned malloc/free causes this crash.
There seems to be a known issue (see this) with Eigen, PCL & AVX
Well I found the problem and how to solve it.
It seems that the DLLs that comes with the "All in 1 installer" for windows weren't compiled with AVX/AVX2 support.
When linking these libraries with my own DLLs, the ones that compiled using the AVX, this mismatch caused Eigen to use the different types of allocations and freeing of memory causing the crash.
I compiled PCL from source using AVX2 and linked these library and everything works.
It's worth mentioning that the DLL that worked before now has issues since it doesn't have AVX and PCL now do.
I am porting my code to 64-bit platform.but I get a problem with DialogBoxParam.it work fine with 32-bit platform but not 64-bit.I used it like below
DialogBoxParam(Hinstance,MAKEINTRESOURCE(DLG_INPUTBOX),owner,#DialogProc,NativeInt(#info))
DLG_INPUTBOX come from the resource file
unit resource_gui;
interface
CONST
DLG_INPUTBOX = 8810;
DLG_PROGRESS = 8800;
DLG_AREYOUSURE = 8809;
BITMPAT_UNCHECKED = 8804;
BITMPAT_CHECKED = 8805;
{$R DLGRES.res}
here is the dialogpro
function DialogProc(hwndDlg:HWND;uMsg:UINT ;wParam:WPARAM ;lParam:LPARAM ):NativeInt;stdcall;
var
info:Pinfo;
OldEditValue:String;
CanClose:boolean;
begin
Result := EIINT(0);
case uMsg of
WM_INITDIALOG:begin
setWindowLong(hwndDlg,GWL_USERDATA,lParam);
end;
WM_SHOWWINDOW:begin
.......
I set a breakpoint in the WM_INITDIALOG code block but it didn't come in
See if this helps:
DialogBoxParam - works in win32, but doesn
I've been changing my code to 64 bit and came across my DialogBox Procedures. The call I made to DialogBoxParam to initialize the dialog box would no longer compile in 64 bit, so I changed my procedures from returning BOOL to returning INT_PTR.
Now when I run my code, my dialog box never shows up.
I put a break point in the DialogBox Procedure and it get:
WM_SETFONT
WM_DESTROY
WM_NCDESTROY
messages in that order. I never receive a WM_INITDIALOG message at all anymore!
My call to DialogBoxParam returns -1 and GetLastError returns 0
I had the exact same problem today. I found that my manifest file had the wrong processor architecture associated with it.
processorArchitecture="x86"
instead of
processorArchitecture="amd64"
Once I fixed that, the dialogbox popped up as expected.
I'm trying to install GLScene into RAD Studio 2010, with the aim of using it from a mostly C++ project. I downloaded the latest snapshot (5991, November 2011) and have been trying to compile and install the two main packages: GLScene_DesignTime and GLScene_RunTime. I haven't even tried some of the other libraries (CUDA, etc), I just want to get the base packages running.
I've encountered a number of problems, one of which I can't solve, and I'm seeking the help of anyone on SO who has successfully installed GLScene, or might know how to solve these Delphi compiler errors.
First problem (solved?)
When compiling, a number of files gave the following error:
[DCC Warning] GLSelection.pas(297): W1025 Unsupported language feature: 'abstract class method'
This is caused by a method declaration something like:
TGLBaseSelectTechnique = class
public
class function IsSupported: Boolean; virtual; abstract;
It seems that a virtual abstract class method is not supported in Delphi 2010, and I have solved it by removing 'abstract' and providing a dummy implementation, e.g. just returning false.
The second problem (not solved) - Delphi compiler fatal errors
I am now encountering two more serious errors. When compiling, the compiler fails like so:
[DCC Fatal Error] Exception EAccessViolation: Access violation at address 05AE8ED9 in module 'dcc140.dll'. Read of address 00000003
[DCC Error] Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED))
It doesn't say what file caused this, but I think it's caused by Spline.pas. Occasionally and not as often, I get this:
[DCC Fatal Error] Spline.pas(1): F2084 Internal Error: AV062D8ED9-R00000003-0
This indicates Spline.pas, and I think the first error is probably related to the file too, because after getting the first one if I then clean the project, cleaning will fail saying it could not delete Spline.hpp. (I have to close and reopen the IDE.) Spline.hpp just contains the following:
// CodeGear C++Builder
// Copyright (c) 1995, 2009 by Embarcadero Technologies, Inc.
// All rights reserved
// (DO NOT EDIT: machine generated header) 'Spline.pas' rev: 21.00
#ifndef SplineHPP
#define SplineHPP
#pragma delphiheader begin
#pragma option push
#pragma option -w- // All warnings off
#pragma option -Vx // Zero-length empty class member functions
#pragma pack(push,8)
#include <System.hpp> // Pascal unit
#include <Sysinit.hpp> // Pascal unit
and there it stops. It looks to me like it failed when trying to generate the HPP file.
I always get one of these two failures. The second is the only one I can tie to a specific file; the first fails halfway through the project, but I can't see where it got up to when it failed. I am compiling from inside the IDE.
I've looked in Spline.pas, and it seems pretty basic code - I can't see anything unusual at all. You can find it here, and apparently the file hasn't been touched for seven years... so I think it should compile :)
If I change the project settings so it does not generate headers, it compiles fine. (Generating just obj files, and any other of the settings that does not include "headers", all work fine.) But this isn't a good workaround for me - after all, I need to use it from C++ Builder, so my normal setting would be "Generate all C++ Builder files". At a bare minimum, I need HPP and OBJ files.
Has anyone here used GLScene in a recent version of C++ Builder? Have you encountered similar problems? Any idea how to solve this one?
I am using:
RAD Studio 2010 (fully patched and up to date; DDevExtensions and IDEFixPack installed.)
The November 2011 snapshot; I tried the March 2011 snapshot too, and got the same problems. Link to snapshots here.
The Delphi 2010 packages modified only by changing the linker output to generate C++ Builder files; and also the BCB 6 packages. Both give the same errors.
Edit: GLScene now has compatibility with RAD Studio XE3 (including C++ Builder.)
Now there is full compatibility of GLScene with Embarcadero RAD Studio
C++Builder XE3 as in design and runtime mode.
You can download it from http://yadi.sk/d/o1QGI2KA10MK1 (95Mb)
-- from Pal Wassail's post on the Embarcadero forum thread.
{quote:title=David M wrote:}{quote}
Hi,
I'm trying to install GLScene into RAD Studio...
David
And here is more simple Test for EMB developers of Delphi XE3 header generator -
1.Create a VCL Form Application
2.Add in Unit1.pas interface section
type
TVector3f = array[0..2] of single;
TVector4f = array[0..3] of single;
function VectorAdd(const v : TVector3f; const f : Single) : TVector3f; overload;
function VectorAdd(const v : TVector4f; const f : Single) : TVector4f; overload;
3.Add in implementation section
function VectorAdd(const v : TVector3f; const f : Single) : TVector3f;
begin
Result[0]:=v[0]+f;
Result[1]:=v[1]+f;
Result[2]:=v[2]+f;
end;
function VectorAdd(const v : TVector4f; const f : Single) : TVector4f;
begin
Result[0]:=v[0]+f;
Result[1]:=v[1]+f;
Result[2]:=v[2]+f;
Result[3]:=v[3]+f;
end;
Set Delphi Compiler option “Generate C++ .objs, headers, namespaces, export”
Build the project
Then Delphi XE3 compiler generates wrong header file Unit1.hpp with lines:
extern PACKAGE TVector3f __fastcall VectorAdd
(float const v, const float f)/ overload */;
extern PACKAGE TVector4f __fastcall VectorAdd
(float const v, const float f)/ overload */;
If now you are trying to use this header file Unit1.hpp in my.cbproj you get fatal error:
“E2238 Multiple declarations in …”
Yes, if you change vector array types to records:
TVector3f = record
case boolean of
true : (Coord: array[0..2] of single);
false : (X,Y,Z: single);
end;
then the problem could be solved, because in this case Delphi compiler generates
extern PACKAGE Vectortypes::TVector3f __fastcall VectorAdd
(const Vectortypes::TVector3f &v, const float f)/* overload */;
extern PACKAGE Vectortypes::TVector4f __fastcall VectorAdd
(const Vectortypes::TVector4f &v, const float f)/* overload */;
and you could build your C++Builder VCL application without "Multiple declaration " error. It was done for old GLScene version in 2007, but now you need to rewrite some part of code in new library, starting from VectorGeometry.pas module.
There are second way to fix such automatic header's errors - improvement of Delphi compiler in Generating C/C++ headers, namespaces and packages option. But it's in hands of EMB developers.
Here's how I do it:
Download and extract this ZIP file (directly into the root folder of GLScene, allowing it to overwrite as necessary)
Load up the appropriate RAD Studio version (2007 to XE2) and open the file *GLScene_Group.groupproj* (where = your RAD Studio version)
Build/Install each Package in group order
I have carefully assembled these fixed packages to ensure they all install and function properly from 2007 to XE2. Some packages (at the bottom of each group) require additional dependencies to function (such as the Python package) so be mindful of these.
I have tested and confirmed that these work on RAD Studio 2007 to XE2 only.
Don't forget to add the \Source folder (and all subfolders) to the Search Paths (either for the IDE itself or an individual Project, as you desire) otherwise the projects using GLScene components will fail to compile complaining of missing units.
Enjoy!
Not for RAD Studio 2009 but for old GLScene installation in BCB6 she was running well. But current version after installation in RAD Studio XE/XE2/XE3 does not work at all. It seems that the main problem is hidden in overload mechanism of procedures in Vectorgeometry.pas, so Delphi compiler (with using an option for Output of all C++ files and packages) creates coincident strings in Vectorgeometry.hpp and others. Thus you have visual components in C++Builder panel, but your application fails with errors during building. It must be repaired in .pas files by GLScene developers.
When you trying to build an application with GLScene under C++Builder XE3 you will get over 50 BCC32 errors in glcrossplatform.hpp, vectorgeometry.hpp and so on. There is a way to repair the library on your own discretion. Make a new copy of GLScene directory. In GLCrossPlatform.pas rename the procedure RGB to GLRGB (it's work!). Then in VectorGeometry.pas and in many others files of source codes change all overload procedures with slightly different parameter names, so you should't encounter coincident procedures in .hpp files after Delphi option output C++ (last option that includes packages). Then rebuild all GLScene packages. At the end of the process I hope it should work for C++Builder XE3.
I have exact he same errors.
#The second problem
Go to "spline.pas" and change
TCubicSplineMatrix = array of array[0..3] of Single;
to
TCubicSplineMatrixEx = array[0..3] of Single;
TCubicSplineMatrix = array of TCubicSplineMatrixEx;
Now "Rad Studio 2009" can compile and install GLScene for C++Builder. I can start a new C++Builder VCL Application and select GLScene components from the toolbox and drop in my VCL form.
I think, this is the solution for your basic problem, but unfortunately I can not compile my VCL project successful. I get over 50 BCC32 errors in glcrossplatform.hpp and vectorgeometry.hpp. If anyone can help here, that would be great.
#Your First problem
I get this warnings too, but I have nothing changed for it. Just ignore it?!
I am developing an ADO application (32 bit) on Windows 7 64 bit SP1 (all updates installed): The app must run on Win XP. According to http://support.microsoft.com/kb/2517589/en-us I am using msado60_backcompat. That worked well until lately, but now it crashes.
My code (snippets):
_CommandPtr cmd(__uuidof(Command));
cmd->ActiveConnection = dbconn;
cmd->CommandText = _T("SELECT [si] FROM [TTable] WHERE [TTable].[ti1]=?");
cmd->Parameters->Append(cmd->CreateParameter(L"#ti1", adTinyInt, adParamInput, 1, 7));
CreateParameter is implemented in msado60_backcompat:
inline _ParameterPtr Command15::CreateParameter ( _bstr_t Name, enum DataTypeEnum Type, enum ParameterDirectionEnum Direction, ADO_LONGPTR Size, const _variant_t & Value )
{
struct _Parameter * _result = 0;
HRESULT _hr = raw_CreateParameter(Name, Type, Direction, Size, Value, &_result);
if (FAILED(_hr)) _com_issue_errorex(_hr, this, __uuidof(this));
return _ParameterPtr(_result, false);
}
raw_CreateParameter() calls into msado15.dll into CCommand::CreateParameter. There a crash occurs at offset 0x34f (offset inside the function):
First-chance exception at 0x655ed5a6 (msado15.dll) in adosqlbugcheck.exe: 0xC0000005: Access violation writing location 0xcccccccc.
Unhandled exception at 0x655ed5a6 (msado15.dll) in adosqlbugcheck.exe: 0xC0000005: Access violation writing location 0xcccccccc.
Msado60_Backcompat.tlb: 73728 bytes, 29.4.2011
msado15.dll: 6.1.7601.17514, 1019904 bytes, 21.11.2010
The error does not occur if I use msado15.dll.
Can someone reproduce the error? Is there a solution?
The issue is solved. I was #import-ing the msado60_backcompat.tlb from "C:\Program Files\Common Files". If I import the version from "C:\Program Files (x86)\Common Files" it works. The compiler generates tlh files from both tlb files with exactly the same UUIDs and everything else, they only differ in that the one contains
typedef __int64 ADO_LONGPTR;
typedef ADO_LONGPTR PositionEnum_Param;
While the other contains
typedef long ADO_LONGPTR;
typedef enum PositionEnum PositionEnum_Param;
From my understanding of COM interfaces this should not happen. But since MS commits they really made a mistake it seems to just be the way it is.
Just for information, MS has a new solution coming up: http://blogs.msdn.com/b/psssql/archive/2011/10/03/yes-we-made-a-mistake-and-are-finally-going-to-fix-it.aspx.
What do we do wrong?
Inf file:
; Adapted from the example INF in the Microsoft document "How to Use WinUSB to Communicate with a USB Device"
[Version]
Signature = "$Windows NT$"
Class = NTMR
ClassGUID={6E76E110-A9AC-46fb-AD33-1F0444672821}
Provider = %ProviderName%
DriverVer=05/20/2009,1.0.0
CatalogFile=ti_0451_9001_ia64.cat
; ================== Class section ==================
[ClassInstall32]
Addreg=UsbReg
[UsbReg]
HKR,,,0,%ClassName%
HKR,,Icon,,-1
; ========== Manufacturer/Models sections ===========
[Manufacturer]
%ProviderName% = MyDevice_WinUSB,NTx86,NTamd64,NTia64
[MyDevice_WinUSB.NTx86]
%USB\MyDevice.DeviceDesc% =USB_Install, USB\VID_0451&PID_9001
[MyDevice_WinUSB.NTamd64]
%USB\MyDevice.DeviceDesc% =USB_Install, USB\VID_0451&PID_9001
[MyDevice_WinUSB.NTia64]
%USB\MyDevice.DeviceDesc% =USB_Install, USB\VID_0451&PID_9001
; =================== Installation ===================
[USB_Install]
;Include=winusb.inf
Needs=WINUSB.NT
[USB_Install.Services]
;Include=winusb.inf
AddService=WinUSB,0x00000002,WinUSB_ServiceInstall
[WinUSB_ServiceInstall]
DisplayName = %WinUSB_SvcDesc%
ServiceType = 1
StartType = 3
ErrorControl = 1
ServiceBinary = %12%\WinUSB.sys
[USB_Install.Wdf]
KmdfService=WINUSB, WinUsb_Install
UmdfServiceOrder=WINUSB
[WinUSB_Install]
KmdfLibraryVersion=1.7
[USB_Install.HW]
AddReg=Dev_AddReg
[Dev_AddReg]
HKR,,DeviceInterfaceGUIDs,0x10000,"{ca4f3183-4521-4a24-81aa-46dfcb2cb017}"
[USB_Install.CoInstallers]
AddReg=CoInstallers_AddReg
CopyFiles=CoInstallers_CopyFiles
[CoInstallers_AddReg]
HKR,,CoInstallers32,0x00010000,"WinUSBCoInstaller.dll","WUDFUpdate_01007.dll","WdfCoInstaller01007.dll,WdfCoInstaller"
[CoInstallers_CopyFiles]
WinUSBCoInstaller.dll
WdfCoInstaller01007.dll
WUDFUpdate_01007.dll
[DestinationDirs]
CoInstallers_CopyFiles=11
; ================= Source Media Section =====================
[SourceDisksNames]
1 = %DISK_NAME%,,,\i386
2 = %DISK_NAME%,,,\amd64
3 = %DISK_NAME%,,,\ia64
[SourceDisksFiles.x86]
WinUSBCoInstaller.dll=1
WdfCoInstaller01007.dll=1
WUDFUpdate_01007.dll=1
[SourceDisksFiles.amd64]
WinUSBCoInstaller.dll=2
WdfCoInstaller01007.dll=2
WUDFUpdate_01007.dll=2
[SourceDisksFiles.ia64]
WinUSBCoInstaller.dll=3
WdfCoInstaller01007.dll=3
WUDFUpdate_01007.dll=3
; =================== Strings ===================
[Strings]
ProviderName="NTMR"
USB\MyDevice.DeviceDesc="TMS320VC5509A WinUSB driver"
WinUSB_SvcDesc="TMS320VC5509A board"
DISK_NAME="TI_WINUSB Install Disk"
ClassName="NTMR"
The only differences I can see between my version and yours is the following:
Newer version of WinUSB - (WdfCoInstaller01009.dll, WinUSBCoInstaller2.dll)
I have not commented out "Include=winusb.inf" under both USB_Install and USB_Install.Services.
My KmdfLibraryVersion is 1.5 (not 1.7). Which seems strange to me, since it would appear that I have a newer version of the WinUSB driver. Also, my DriverVer is set to 2010, but I'm not sure if that would cause a problem.
I do not have "UmdfServiceOrder" under my USB_Install.Wdf.
Unfortunately I cannot see anything blatantly wrong with your inf file. Give these a try? My inf file works fine for Win7 x64. You could also try removing the .cat file for testing purposes, since it isn't needed for installation under Win7.
Well, you are aware of the distinction between ia64 and x64, right? The .cat file, by name, suggests that the driver is for Itanium. Personally I'm not even aware of an Itanium build for Windows 7, but I could be wrong.
Either way, x64 and ia64 are not the same and a driver compiled for one would not work on the other.