I try to run a program in MATLAB (R2011a, 64 bits), the program contains ActiveX, but I get an error:
In put PROGID does not represent an Activex control. if this PROGID
used to work before, please check vendor's documentation for
equivalent activex control progid
this program is fully launched in MATLAB (R2009, 32 bits)
I have instaled VB6.
Any help?
You are running 64 bit Matlab and your ActiveX control is 32 bit.
Check out this link. It deals with the bitness needing to match between the Matlab version and the Ax control. If you are running 64 bit Matlab, then the ActiveX control should also be 64 bit.
You could alternatively install 32 bit Matlab.
Related
Win7 Service Pack 1
Matlab 2013b
Hello
I am trying to include a libfaad2.dll lib (which I got ready compiled) to Matlab so I can use the functions. I try this with the loadlibrary command.
But I get the error message
libfaad.dll is not a valid win32 application!
from matlab.
A short examination of libfaad2.dll with DependencyWalker (x64 Version) showed that it needs c:\windows\system32\Kernel32.dll. But there is also shown that 2 functions are not available in kernel32.dll
---> So I guess this is not a Matlab Problem
BUT the c:\windows\sysWow64\kernel32.dll includes the desired functions!
How can I tell matlab, or generally, that the libfaad2.dll file should use the sysWow64\kernel32.dll ?
Found a solution: Installing 32 bit version of Matlab and try with this. Worked at first try!
More detailed: Win7 has 2 different folders for system .dlls
C:\windows\system32: Here are all the .dlls for 64-bit software and not for 32!
C:\windows\SysWoW64: WoW64 stands for "Windows on 64-bit Windows", and it contains all the 32-bit binary files required for compatibility, which run on top of the 64 bit Windows.
Using 32-bit version, Matlab will use the SysWoW64 files. And that is the rigth kernel32.dll which contains all the functions needed!
I'm trying to run the basic Matlab enginedemo.cpp in VS2010 on Windows 7 and no matter what I do the code:
`if (!(ep = engOpen(""))) {
fprintf(stderr, "\nCan't start MATLAB engine\n");
return EXIT_FAILURE;
}`
Always errors.
I had both MatlabR2012b and MatlabR2012a installed on my computer but I uninstalled MatlabR2012a and then removed all references to it from my path variable.
I am running x64 MatlabR2012b and I set my VisualC++ Win 32 Console Application.
I also already set the Debugging Environment to: {MatlabRoot}\R2012b\extern\lib\win64\microsoft
C/C++->Additional Include Directories: {MatlabRoot}\R2012b\extern\include
Linker->General->Additional Library Directories: {MatlabRoot}\R2012b\extern\lib\win64\microsoft
Linker->Input->Additional Dependencies: libmx.lib;libmat.lib;libeng.lib
My Matlab version is also registered so that shouldn't be causing the error.
I searched through some of the other stackoverflow questions concerning this and most of them seemed to fix their problems by removing older versions of matlab from the path variable but it hasn't worked for me.
You cannot load 64 bit DLL in 32 bit application. You must make 64 bit console application if you want to work with 64 bit matlab.
You should have {MatlabRoot}\bin\win64 in your PATH (there are libeng.dll and other matlab engine libraries) so your application can find matlab engine libraries during runtime.
execute "matlab /regserver" from command prompt. (to re-register COM components from Matlab 2012a - might not be required, but to be sure)
Hope this helps.
I just got my first 64-bit Windows notebook. Now I'm looking for information when and why to use the 32 or the 64-bit versions of PowerShell or ISE.
My first impression is that I better stay with 32 bit, until I understand things better.
What I miss or didn't find are basic tutorials and practical experiences and links to this questions.
I'am working on a Seven 64Bits and W2K8 R2 for one year now, and, on the command line, I'am always using 64 bits Powershell without any troubles.
For me the problem is not to choose 32 or 64 Bit PowerShell.exe, but to know that the two exists, and that a 32 bits process will use the 32 bits PowerShell. For example if you use PowerShell as post build execution script in Visual Studio 2010, it will use 32 bits PoweShell because Visual Studio 2010 is 32 bits process.
The two versions see two differents places in the registry so you have to Set-ExecutionPolicy for both.
As scripting is concerned I do not use ISE, but PowerGUI script Editor. You can use
[intPtr]::size
in a script to know if you are runing 32 or 64 bits PowerShell.exe.
You would use the 64 bit versions of PowerShell or PowerShell ISE where the problem you are trying to solve is uniquely 64 bit. For example:
You need your PowerShell script to be able to consume more memory than a 32 bit application will allow
You are consuming libraries that are 64 bit only or need to run in a 64 bit environment. For example on Windows 2008R2/IIS7.5 if you are using the Microsoft.Web.Management managed wrapper, if you need to modify administration.config via this library then your application or script needs to run in a 64 bit process.
I typically stick with 64-bit PowerShell unless I have a good reason to not use it. One issue with 32-bit PowerShell is that you may accidentally find yourself in HKLM:\SOFTWARE\Wow6432Node location of the registry instead of where you think you are.
The example I've most-often come across for an explicit need for 32-bit is when using certain COM objects. For example, if you have a 64-bit OS, but 32-bit Office... If you want to instantiate a Word, Excel, or Access object, you're going to need to be in 32-bit PowerShell or else it's going to act as if you don't have Office installed at all.
When running SharePoint 2013, it's important to run the 64-bit versions when attempting to user the Windows.SharePoint.PowerShell snapin. I spent too much time not realizing I had open the 32-bit ISE not being able to load SharePoint Commands.
I think you don't really need to take care about that. As for my 64bit system, there is only a 32bit PowerShell preinstalled (in \system32) and it works without any issues. So just use it ;) And well, besides that, it's most likely the same case as with any other application: if you rely on functions/properties that are only available under 64bit you are better of to use the 64bit version of that application.
I have access to a library with pre-compiled 32 bit mex files (Windows: .mexw32, Linux: .mexa32). I am having a hard time compiling the library myself for a 64 bit machine, so I was wondering if there is a way to make MATLAB 64 bit work with 32 bit mex files.
In general accessing 32bit code from a 64bit executable is nontrivial. Therefore I doubt they have implemented this in MATLAB natively...
No a 64-bit program cannot use 32-bit shared libraries. One option is to install the 32-bit version of MATLAB on your machine as well.
I'm trying to debug a .NET 3.5, 32 bit application running on Windows 7/64 bit with WinDbg. I'd like to use psscor2, but I can't load it. I can't load sos, either.
When I try to load psscor2, I get this error:
> .load psscor2
The call to LoadLibrary(psscor2) failed, Win32 error 0n193
"%1 ist keine zulässige Win32-Anwendung."
Please check your debugger configuration and/or network access.
When I try to load sos, I get this error:
> .loadby sos mscorwks
Unable to find module 'mscorwks'
My guess is that the 64bit version of WinDbg can't load 32 bit extension dlls like psscor2 and sos. But I couldn't find a download for the 32 bit version of WinDbg, or a 64 bit version of psscor2.
PS: I have (sort of) solved the problem: I installed the Windows 7 SDK in a 32 bit virtual machine, and copyed the 32 bit version of WinDbg from there to my development PC. But there has to be a easier way to do this!
If you want to debug a 32 bit application, you should use the 32 bit version of WinDbg and load the 32 bit version of SOS/PSSCOR2 even if you're on 64 bit Windows.
If you use the 64 bit version, you'll end up debugging the Wow64 process, which means you must go through some additional loops to be able to debug the application as a 32 bit process. If you must do this for some reason, you need to load the wow64exts extension as well and switch to 32 bit mode using the !sw command. Even if you do this there are some issues with using the 64 bit version with a 32 bit application, so I recommend that you use the 32 bit version of WinDbg.