I have a Matlab script that requires a function in a DLL, and calls addpath to put it's location on the path. This works fine, but when I try to invoke the same script on the command line with matlab -r "scriptname" it errors out saying that method is undefined. Is there something different happening when I'm starting from the command line vs loading up the GUI normally?
turns out both 64-bit and 32-bit versions of matlab were installed, and the first one in the path was the 64-bit, whereas I needed the 32-bit for things to work.
Related
I've tried to convert a tcl file to a exe file by using FREEWRAP.EXE .
It works on most of the files, but there is one file which includes a line of code "load TLTcl.dll " which will always fail.
When I run the tcl file with activetcl, it was fine.
Since I convert the tcl file to a exe file and put TLTcl.dll on the same folder with it, the exe always crash while executing.
I wonder how to load a dll file in the tcl file when I turn a tcl to a exe.
Thanks a lot !
puts "Starting FLASH script"
puts "FLASH write will be performed now, make sure you have an extra flash... "
#load 10 lira tcl DLL
load TLTcl.dll
It sounds like TLTcl.dll was not built with stubs support, which means that it links against a real tcl.dll (possibly with a version number in the name) and freewrap doesn't use that; it uses a statically-linked build so that the whole system can be a simply-redistributable file.
You'll need to rebuild TLTcl.dll with stubs support enabled (assuming it is a DLL that implements a Tcl extension). That's not usually too difficult, as it is a matter of defining the USE_TCL_STUBS preprocessor symbol when compiling all the files, and linking against the tclstub static library; it probably has the version number embedded in the filename (and the version of the Tcl headers you compile with and the stub library you link with must match). Note that it is a property of Tcl's API that if you build against the Tcl 8.5 stubbed API, you can be loaded into a Tcl 8.6 interpreter. (Indeed, that level of forward compatibility is there from about 8.0.6† through to 8.7, which is still in active development so you won't be using it yet.)
†This was a version that was only released to a few commercial partners. Everyone else used newer supported versions.
I have compiled Lua 5.3 as a 32 bit c++ DLL and exe. The DLL contains all the lua code except for lua.cpp and luac.cpp. The exe compiles lua.cpp and uses the DLL to run the lua interpreter. This works fine when running on its own from the command line. I wish to be able to run from the IDE using this DLL and exe.
If I replace /ZeroBraneStudio/bin/lua53.dll and lua53.exe with my own versions, I can run scripts (clicking the two green arrows). However, debugging does not work, giving the following error:
The procedure entry point luaL_addlstring could not be located in the dynamic link library lua53.dll.
I can see that this is happening because the debugger is making use of luasocket. \ZeroBraneStudio\bin\clibs53\socket\core.dll is dependent on lua53.dll, and is expecting it to contain lua compiled as c.
So, what is the correct solution to this - is it to compile luasocket as c++ as well?
(And, if so, does anybody have instructions/guidance for doing so? I have been unable to find anything on this.)
Thanks.
I'm not sure how exactly the DLL was compiled, but the error message likely indicates that the luaL_addlstring and other functions are not exported by it. If the symbols are exported correctly, you should be able to load luasocket and get the debugging working. See this thread for the related discussion.
Also, you don't need to replace lua53 library and executable, as you can configure the IDE to use your own copy of it using path.lua53 configuration setting as described in the documentation.
Okay, I was able to get it working. The solution was to compile luasocket as c++. I won't give full instructions on how to do this here, but some points to hopefully help anybody else with the same issue:
Got luasocket from here: https://github.com/diegonehab/luasocket
Renamed all *.c files to *.cpp
Renamed Lua52.props to Lua.props (I am using lua 5.3 but seems like it is compatible?)
Placed lua headers and lib in appropriate folders
Opened solution in Visual Studio 2012
Fixed up minor issues with project files, like the renaming of the files.
Added 'extern "C"' to declaration of luaopen_socket_core and luaopen_mime_core functions (necessary for lua to be able to load libraries).
Built solution
Copied new dlls into clibs53/socket and clibs53/mime folders.
I used Dependency Walker to help with this. If anybody wants further details in the future please leave a comment.
I have a very simple jar file and I'm trying to convert it to a mono dll using ikvmc, but I'm getting the message "Error: unable to load runtime assembly".
My command line is:
ikvmc -target:library test.jar
My jar contains only one class, that simply has a method returning a String.
I'm just trying to experiment with ikvmc at this point before starting to develop some more complicated things.
I'm using:
Open Suse 11.3, 32 bits
kernel 3.11.6-4-desktop
ikvmc version 0.44.0.5
mono 3.0.6
Any hints?
Ok, I've got it working...
I've copied all files on folder "/usr/lib/mono/ikvm" to folder "/usr/lib/ikvm".
Apparently, ikvmc searches for runtime assemblies on the same folder where ikvmc executable are located.
If someone knows a workaround or a unkown (for me, at least) setting that avoids such copy, I really would like to know.
I have seen many solutions for automating my InstallShield build, but I am having issues with each one. I am using InstallShield Professional 2013. Sorry for the lengthy question, but I am clueless on which direction to go to solve my issues.
1) IsCmdBld.exe - I have a script that runs and will build my installer. BUT, when the installer runs, I get an error message that says "The System Administrator has set policies to prevent this installation". I am not sure why this is happening, but I do not get the same error message if I build the installer through the designer. EDIT: Here is my command (%guid% is a Guid I generate to set the Product Code):
for /f %%i in ('"C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\uuidgen.exe"') do set guid=%%i
"C:\Program Files (x86)\InstallShield\2013 SP1 SAB\System\ISCmdBld.exe" -p "MyInstaller.ism" -r SingleImage -y "1.0.0.13" -z ProductCode=%guid%
2) InstallShield Automation Interface - I have followed numerous examples and tutorials on this, but all end in the same result. When I call the following code:
var project = new ISWiAuto20.ISWiProject();
I get this error:
Unable to cast COM object of type 'System.__ComObject' to interface type
'ISWiAuto20.ISWiProject'. This operation failed because the QueryInterface call
on the COM component for the interface with IID '{872D23A7-C18D-468C-895D-1CF027E4FBB1}'
failed due to the following error: Library not registered.
(Exception from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED)).
3) MsBuild.exe - Running MsBuild on my InstallShield project file yields this error:
error NSB4025: The project file could not be loaded. Invalid character in the
given encoding. Line 1, position 1
The choice between these approaches (when they all work) largely depends on the build system you are trying to integrate with. If you're using a batch or makefile approach, IsCmdBld.exe is probably the easiest starting point. If you're using Visual Studio and TFS or MSBuild, you'll probably have more luck there, as it will report errors in a way the build system can understand. (Other than that, they're fundamentally similar.) If you need to make tweaks to the project before you build it, the automation layer can either augment or replace the other approaches.
But in your case you say they all don't work. What have you done to diagnose why? Here are the first steps I'd take for each of those symptoms:
IsCmdBuild built setups yielding an error that the IDE-build ones do not. First identify what the problem really is. Look in a verbose log for more information. Build both ways with the .msi available and compare the results with MsiDiff. Make sure you've tested elevated. Depending on what you find, it may be something to address in the project, the build process, or a bug in InstallShield.
Automation Interface yields TYPE_E_LIBNOTREGISTERED. First off, if this is the IDE machine, consider repairing the installation. If it's a standalone-build machine, ditto. If it's a standalone-build machine that didn't use the installation, you should, or at least you should ensure the dependencies are present and that the automation interface is registered. Secondly, as Christopher Painter noted, InstallShield is a 32-bit product so it must be invoked from a 32-bit context. If you're calling, say, CScript to run a .vbs file, make sure you're using C:\Windows\SysWow64\CScript.exe.
MSBuild NSB4025. The comment from stijn is largely correct - you can't call MSBuild on the .ism file (while it can be xml instead of binary, it's not MSBuild-compatible). However you can create a .isproj file that can work correctly. Save the project in Visual Studio, or copy <InstallShield>\Support\0409\MSBuild.xml to (ProjectName).isproj and tweak its contents; call MSBuild on the resulting .isproj file. Odds are strong this will have approximately the same results as IsCmdBuild, as the build portion is largely shared.
Using MSBuild doesn't follow the exact order of the Project files specified in the solution .sln file.
The best option is to use devenv.exe
And sometimes, devenv doesn't return exact return status, so I kept an exe to scan the log file for the success code.
https://devopsdiaryblog.wordpress.com/2017/12/20/devenv-return-code-issue/
And for iscmdbuild.exe, better to use commandline as it is the suggested one from flexera.
I have tried to use the following code:
cd c:\windows\system32
regsvr32.exe dllname.ax
But this is not working for me. How can I register a DLL file on Windows 7 with a 64-bit processor?
Well, you don't specify if it's a 32 or 64 bit dll and you don't include the error message, but I'll guess that it's the same issue as described in this KB article: Error Message When You Run Regsvr32.exe on 64-Bit Windows
Quote from that article:
This behavior occurs because the Regsvr32.exe file in the System32
folder is a 64-bit version. When you run Regsvr32 to register a DLL,
you are using the 64-bit version by default.
Solution from that article:
To resolve this issue, run Regsvr32.exe from the %SystemRoot%\Syswow64
folder. For example, type the following commands to register the DLL:
cd \windows\syswow64 regsvr32 c:\filename.dll
If the DLL is 32 bit:
Copy the DLL to C:\Windows\SysWoW64\
In an elevated command prompt: %windir%\SysWoW64\regsvr32.exe %windir%\SysWoW64\namedll.dll
if the DLL is 64 bit:
Copy the DLL to C:\Windows\System32\
In an elevated command prompt: %windir%\System32\regsvr32.exe %windir%\System32\namedll.dll
I know it seems the wrong way round, but that's the way it works. See:
http://support.microsoft.com/kb/249873
Quote: "Note On a 64-bit version of a Windows operating system, there are two versions of the Regsv32.exe file:
The 64-bit version is %systemroot%\System32\regsvr32.exe.
The 32-bit version is %systemroot%\SysWoW64\regsvr32.exe.
"
Type regsvr32 name.dll into the Command Prompt (executed in elevated mode!) and press "Enter." Note that name.dll should be replaced with the name of the DLL that you want to register. For example, if you want to register the iexplore.dll, type regsvr32 iexplore.dll.
On a x64 system, system32 is for 64 bit and syswow64 is for 32 bit (not the other way around as stated in another answer). WOW (Windows on Windows) is the 32 bit subsystem that runs under the 64 bit subsystem).
It's a mess in naming terms, and serves only to confuse, but that's the way it is.
Again ...
syswow64 is 32 bit, NOT 64 bit.
system32 is 64 bit, NOT 32 bit.
There is a regsrv32 in each of these directories. One is 64 bit, and the other is 32 bit.
It is the same deal with odbcad32 and et al. (If you want to see 32-bit ODBC drivers which won't show up with the default odbcad32 in system32 which is 64-bit.)
Open the start menu and type cmd into the search box Hold Ctrl + Shift and press Enter
This runs the Command Prompt in Administrator mode.
Now type: regsvr32 MyComobject.dll
If the DLL is 32 bit:
Copy the DLL to C:\Windows\SysWoW64\
In elevated cmd: %windir%\SysWoW64\regsvr32.exe %windir%\SysWoW64\namedll.dll
if the DLL is 64 bit:
Copy the DLL to C:\Windows\System32\
In elevated cmd: %windir%\System32\regsvr32.exe %windir%\System32\namedll.dll
Finally I found the solution just run CMD as administrator then write
cd \windows\syswow64
then write this
regsvr32 c:\filename.dll
I hope that answer will help you
Everything here was failing as wrong path. Then I remembered a trick from the old Win95 days. Open the program folder where the .dll resides, open C:/Windows/System32 scroll down to regsvr32 and drag and drop the dll from the program folder onto rgsrver32. Boom,done.
And while doing this, if you get error code 0x80040201, try the solution in DllRegisterServer failed with the error code 0x80040201, but make sure, you open command prompt as Run as Administrator.
Knowing the error message would be rather valuable. It is meant to provide info, even though it doesn't make any sense to you it does to us. Being forced to guess, I'd say that the DLL is a 32-bit DirectX filter. In which case this should be the proper course of action:
cd c:\windows\syswow64
move ..\system32\dllname.ax .
regsvr32.exe dllname.ax
This must be run at an elevated command prompt so that UAC cannot stop the registry access that's required. Ask more questions about this at superuser.com
I just tested this extremely simple method and it works perfectly--but I use the built-in Administrator account, so I don't have to jump through hoops for elevated privileges.
The following batch file relieves the user of the need to move files in/out of system folders. It also leaves it up to Windows to apply the proper version of Regsvr32.
INSTRUCTIONS:
In the folder that contains the library (-.dll or -.ax) file you wish to register, open a new text file and paste in ONE of the routines below :
echo BEGIN DRAG-AND-DROP %n1 REGISTRAR FOR 64-BIT SYSTEMS
copy %1 C:\Windows\System32
regsvr32 "%nx1"
echo END BATCH FILE
pause
echo BEGIN DRAG-AND-DROP %n1 REGISTRAR FOR 32-BIT SYSTEMS
copy %1 C:\Windows\SysWOW64
regsvr32 "%nx1"
echo END BATCH FILE
pause
Save your new text file as a batch (-.bat) file; then simply drag-and-drop your -.dll or -.ax file on top of the batch file.
If UAC doesn't give you the opportunity to run the batch file as an Administrator, you may need to manually elevate privileges (instructions are for Windows 7):
Right-click on the batch file;
Select Create shortcut;
Right-click on the shortcut;
Select Properties;
Click the Compatibility tab;
Check the box labeled Run this program as administrator;
Drag-and-drop your -.dll or -.ax file on top of the new shortcut instead of the batch file.
That's it. I chose COPY instead of MOVE to prevent the failure of any UAC-related follow-up attempt(s). Successful registration should be followed by deletion of the original library (-.dll or -.ax) file.
Don't worry about copies made to the system folder (C:\Windows\System32 or C:\Windows\SysWOW64) by previous passes--they will be overwritten every time you run the batch file.
Unless you ran the wrong batch file, in which case you will probably want to delete the copy made to the wrong system folder (C:\Windows\System32 or C:\Windows\SysWOW64) before running the proper batch file, ...or...
Help Windows choose the right library file to register by fully-qualifying its directory location.
From the right batch file copy the system folder path
If 64-bit: C:\Windows\System32
If 32-bit: C:\Windows\SysWOW64
Paste it on the next line so that it precedes %nx1
If 64-bit: regsvr32 "C:\Windows\System32\%nx1"
If 32-bit: regsvr32 "C:\Windows\SysWOW64\%nx1"
Paste path inside quotation marks
Insert backslash to separate %nx1 from system folder path
or ...
Run this shotgun batch file, which will (in order):
Perform cleanup of aborted registration processes
Reverse any registration process completed by your library file;
Delete any copies of your library file that have been saved to either system folder;
Pause to allow you to terminate the batch file at this point (and run another if you would like).
Attempt 64-Bit Installation on your library file
Copy your library file to C:\Windows\System32;
Register your library file as a 64-bit process;
Pause to allow you to terminate the batch file at this point.
Undo 64-Bit Installation
Reverse any registration of your library file as a 64-bit process;
Delete your library file from C:\Windows\System32;
Pause to allow you to terminate the batch file at this point (and run another if you would like).
Attempt 32-Bit Installation on your library file
Copy your library file to C:\Windows\SystemWOW64
Register your library file as a 32-bit process;
Pause to allow you to terminate the batch file at this point.
Delete original, unregistered copy of library file
There is a difference in Windows 7. Logging on as Administrator does not give the same rights as when running a program as Administrator.
Go to Start - All Programs - Accesories.
Right click on the Command window and select "Run as administrator"
Now register the dll normally via : regsrvr32 xxx.dll
You need run the cmd.exe in c:\windows\system32\ by administrator
Commands:
For unregistration *.dll files
regsvr32.exe /u C:\folder\folder\name.dll
For registration *.dll files
regsvr32.exe C:\folder\folder\name.dll
Part of the confusion regarding regsvr32 is that on 64-bit windows the name and path have not changed, but it now registers 64-bit DLLs. The 32-bit regsvr32 exists in SysWOW64, a name that appears to represent 64-bit applications. However the WOW64 in the name refers to Windows on Windows 64, or more explicity Windows 32-bit on Windows 64-bit. When you think of it this way the name makes sense even though it is confusing in this context.
I cannot find my original source on an MSDN blog but it is referenced in this Wikipedia article http://en.wikipedia.org/wiki/WoW64
Here is how I fixed this issue on a Win7 x64 machine:
1 - error message:
"CoCreateInstance() failed
Plkease check your registry entries
CLSID{F088EA74-2E87-11D3-B1F3-00C0F03C37D3} and make sure you are logged in as an administrator"
2 - fix procedure:
Start/type cmd/RightMouseClick on cmd.exe and choose to "Run as Administrator"
typed:
regsvr32 /s C:\Program Files\Autodesk\3ds Max Design 2015\atl.dll
regsvr32 /s C:\Program Files\Autodesk\3ds Max Design 2015\MAXComponents.dll
restart Win 7 and back in business again !
Hope this helps !