I have to make an installer for motionbuilder 2011 for 32 bit and 64 bit.
The installer should detect and deploy the corresponding plug-ins.
One of the 64 bit machines has both versions installed on it but the registry shows only one of them at a time.
Is there any way to detect both the installed versions and deploy the corresponding plug-ins in their install directories?
Thanks
you have to query HKEY_LOCAL_MACHINE64 to get MoBu 64-bit path. For example, using Inno Setup script:
32-bit path
RegQueryStringValue(HKEY_LOCAL_MACHINE, Software\Autodesk\MotionBuilder\2011, 'InstallPath', path)
64-bit path
RegQueryStringValue(HKLM64, Software\Autodesk\MotionBuilder\2011, 'InstallPath', path)
Hope that helps!
Related
I'm currently trying to learn Assembly for x64 Windows. I tried the example code from this Intel website,
but whenever I try to compile it with the command given in the document:
ml64 hello.asm /link /subsystem:windows /defaultlib:kernel32.lib /defaultlib:user32.lib /entry:Start
I always get an
LNK1104 error
I know that it means the compiler can't find the library file, I googled the problem and quickly found that I need Visual Studio with Windows SDK, which I downloaded and installed. But still can't find a kernel32.lib or user32.lib in any files other than the Windows system files.
I tried everything and I simply can't fix it. I hope someone could help figure this out.
There is a well-known MASM32 SDK available created by hutch--. This package contains the requested libraries in a (legacy) 32-bit version.
But there is also a 64-bit update of that famous package by hutch--:
Current build of the 64 bit MASM SDK.
It should contain the .inc and .lib files you need and more...
This is the current build of the 64 bit MASM SDK. This one is a lot closer to complete and with the correct Microsoft binaries added to it, it is capable of building a wide array of application types. It can be use in 2 different ways, it should be unzipped from the root directory of the partition that it is being installed on. You can either manually add it to an installation of the MASM32 SDK OR you can install it on a partition that does not have MASM32 on it and simply rename the buildx64 directory to MASM32. Installing it on another partition is the preferred technique as QE has its menus and accessories set up for building 64 bit code.
You still need to add the Microsoft binaries which would typically be from an installation of vs2017 or from an earlier version for Win7 64. In the bin64 directory there is a file called "Microsoft_File_List.txt" which shows the files you need. The list is from the current version of Visual Studio 2017 version and if this is the version you have, use the ML64 from the "x86_amd64" directory that is 402,584 bytes in size.
In the "buildx64" directory is a batch file called "makeall.bat". This must be run to build all of the libraries and include files.
They are the gold standard of Windows assembly developing.
Have installed 11g in Windows 7 (64 bit machine). Since the SQL developer wont work with 64 bit jdk.
Installed the 32 bit jdk1.7.0
and changed the ORACLE_HOME\sqldeveloper\sqldeveloper\bin\sqldeveloper.conf file SetJavaHome point to 32 bit jdk1.7.0.
Again started the SQL developer, but it throws msvcr100.dll missing. Find that the SQL Developer3.x supports at max jdk1.6.X.
Even tho the question is answered I would like to point out that downloading random DLLs from untrusted sources should be avoided.
If you are missing MSVCR100.DLL just install the correct redist for your platform.
32Bit: Microsoft Visual C++ 2010 SP1 Redistributable Package (x86)
http://www.microsoft.com/de-de/download/details.aspx?id=8328
64Bit: Microsoft Visual C++ 2010 SP1 Redistributable Package (x64)
http://www.microsoft.com/en-us/download/details.aspx?id=13523
Cheers,
Antonio Huete
These information is specified in ORACLE_HOME\sqldeveloper\releasenotes . So install the jdk1.6 and make the sqldeveloper.conf SetJavaHome point to this.
other workaround is go to jdk1.7.0 installed path jdk1.7.0\jre\bin copy msvcr100.dll and paste it into ORACLE_HOME\sqldeveloper\sqldeveloper\bin and again try start SQL Developer. It will start.
And The file is from
This file was downloaded from: http://www.dll-files.com
If you downloaded it from somewhere else, please let us know: http://www.dll-files.com/contact.php
Installation instructions:
Extract the .dll file from .zip file. We recommend that you extract the .dll to the installation directory of the program that is requesting the .dll.
If that doesn't work, you will have to extract the .dll to your system directory. By default, this is:
C:\Windows\System (Windows 95/98/Me)
C:\WINNT\System32 (Windows NT/2000)
C:\Windows\System32 (Windows XP, Vista, 7, win 8)
If you use a 64-bit version of Windows, you should also place the .dll in C:\Windows\SysWOW64\
Make sure to overwrite any existing files (but make a backup copy of the original file for safety).
Reboot your computer.
If the problem still occurs, try the following:
Open Windows Start menu and select "Run...".
Type CMD and press Enter (or if you use Windows ME, type COMMAND)).
Type regsvr32 .dll and press Enter.
If you have any other problems, see our HELP-section at www.dll-files.com/support/
I have just downloaded latest 4.1.3 version with jdk included - Windows 64-bit with JDK 8 included to my Windows Server 2008 R2 64-bit and faced the same problem. Could not start sqldeveloper.exe, because "msvcr100.dll is missing from your computer".
I did not want to install any additional bloatware, so what I did:
take msvcr100.dll from original download SQLDeveloper folder sqldeveloper\jdk\jre\bin
and copy it to Your's oracle installation bin folder, in my case - C:\oraclexe\app\oracle\product\11.2.0\server\bin
SQL developer started!
Edit (path)\sqldeveloper.sqldeveloper\bin\sqldeveloper.conf with Notepad++ or some other advanced text editor. Don't use Windows Notepad for this.
Locate the SetJavaHome variable. Replace "../../jdk" with your regular PC Java source. On mine it was "C:\Program Files\Java\jdk1.8.0_73".
The line looks like this when you're done:
SetJavaHome C:\Program Files\Java\jdk1.8.0_73
Save and exit.
I got this error while running Oracle JDeveloper.
I have copied the msvcr100.dll file from C:\Windows\System32 to C:\Program Files\Java\jdk1.8.0_261\jre\bin.
It worked for me. Also check the enviromental varibles settings.
The JDK needs msvcr100.dll to either be located in the same directory as sqldeveloper.exe OR already be installed on a Windows machine in a location defined in environment path variable. In testing SQL Developer install on various Windows 7 machines where I have other software installed (not a clean machine), the msvcr100.dll is installed on C: \Windows\system32\msvcr100.dll.
you may get it from sqldeveloper\jdk\jre\bin\msvcr100.dll(refer your installation dir)
I was facing the same issue and it worked for me.
For me the solution was to simply upgrade SQL Developer. When work changed over my laptop I copied SQL Developer between machines and I got the above error except for msvcr120.dll. I copied that dll from my old machine but then it needed another and then another. So I downloaded the latest version of SQL developer and the errors went away. It might not solve the issues for everything but I think updating to the latest version should be done before trying any of the other solutions.
Under Windows 7 x64, when I try to profile an x86 executable with the latest version of Dependency Walker (2.2.6000) the profiling process always hangs at a certain point. Most of the time the last DLL that is loaded is c:\windows\syswow64\URLMON.DLL, so it seems that something inside that DLL is causing a problem. Profiling the same executable on Windows 7 x86 works flawlessly.
I have googled quite extensively, but couldn't come up with a solution to the problem. One suggestion that I found was to uninstall IE 8 or IE 9 and replace it with IE 7, but this doesn't really help. The only effect that I can observe is that with IE 7 the profiling process hangs at a different DLL (iertutil.dll, if I remember correctly, also from the system's syswow64 folder).
So my question is: How can I get Dependency Walker to profile x86 applications on x64 Windows 7? Of course, it would also be nice to know why the problem exists in the first place :-)
Some final notes:
I am using the x86 version of Dependency Walker because I want to profile an x86 executable
Running Dependency Walker as administrator does not help
All profiling options marked as "may fail on WOW64" are disabled
The executable I am currently using as a test case to reproduce the problem is the Sumatra PDF viewer (download link) because it is a simple .exe that does not need installation
Updated instruction based on #Stone Free's comments
The download link you need has changed to:
https://www.microsoft.com/en-us/download/details.aspx?id=42273
Go down to the 2. Install WDK 10 section and select the download:
Locate and run the Wdk setup (wdksetup.exe) from stage 2, then choose the download option rather than install.
Once completed locate and run DownloadLocation\Windows Kits\10\WDK\Installers>"Windows Driver Kit-x86_en-us.msi"
Then you will find Dependency Walker at:
C:\Program Files (x86)\Windows Kits\10\Tools\x64\depends.exe for the 64 bit version
C:\Program Files (x86)\Windows Kits\10\Tools\x86\depends.exe for the 32 bit version
Which is Dependency Walker version 2.2.10011 built 2015-10-29
A handy tool is to use https://github.com/juntalis/depends-launcher which is a simple launcher for Dependency Walker that determines the platform (x86|x64|ia64) of an windows image (dll, exe, etc) and launches the appropriate version of depends.exe to view its dependencies. It's main purpose is for use in a context menu entry to easily view an image's dependencies.
The latest currently known version of Dependency Walker seems to be the 2.2.10011 from 2015-10-29 (links below).
It was deployed with some Windows Development Kit for Windows 10 but the version that it contained is not available anymore from the Microsoft Pages and all the newer Versions does not contain it anymore for unknown reason.
Maybe because also the latest versions have some Problems with the Dynamic-Link Library Redirection or other performance issues. (Using dependency walker under windows 10 seems to be a lot more slow and cumbersome than at previous windows versions - but still great tool for the job)
Following Versions are available:
2.2.10011 (2015-10-29)
unofficial available from this development blog - download at own risk
https://zzz.buzz/2017/05/18/download-dependency-walker/
2.2.9600 (2013-08-22)
available through the WDK 8.1
https://www.microsoft.com/en-us/download/details.aspx?id=42273
after installation present in C:\Program Files (x86)\Windows Kits\10\Tools\[Arch]\depends.exe
2.2.6000 (2006-10-28)
available from official authors website
http://www.dependencywalker.com/
Potential replacement:
For simple tasks the Github project lucasg/Dependencies may be worth to be checked out. But it currently does not support profiling a running app to debug broken runtime dependencies as depends.exe can do.
I've had to switch to using a GitHub project: Dependencies.
As of Windows 10 1809 (10.0.17763) I'm unable to run even depends.exe version 2.2.10011 included in 10.0.10586.0 WDK.
I ran into the same problem and I discovered it is fixed in the latest version of Dependency Walker. I compared 2.2.6000 versus 2.2.8288 and the problem exists in the former but not the latter. However, you will probably have to wait for the Windows 8 WDK to be released to the public in order to get the latest version.
I am trying to run an application called vdbench on my windows2008R2 which is a VM. However, the application does not have 64 bit support and can be only run with 32 bit version of Java. I am trying to understand if I can install the 32 bit JRE and run the application on the windows2008R2 64 bit server? I tried it but the application is not able to run saying 'java' is not recognized as a program. I am wondering if I need to map my windows2008R2 to run the specific 32bit version of JRE?
You need to do nothing except install the 32-bit JRE / JDK whatever your requirement.
I do this all the time. The only real reason to use the 64-bit version is if you application needs to be able to access more than 4GB of RAM (or some programmatic lib dependency)
Make sure you install the 32-bit version and point the JAVA_HOME environment variable to the install dir so if you install JRE 1.6 it JAVA_HOME should be something like
C:\Program Files (x86)\Java\jre1.6.0_XX
Also, in your Path environment variable add %JAVA_HOME%\bin to its end, this will make all the java executable's available at the command line.
In the case of a JRE you can use an environment variable called JRE_HOME if you want instead of JAVA_HOME.
You can also add -d32 to the JVM options, which should tell the JVM to run in 32-bit mode.
You must install a 32-bit JDK or JRE. Then, add a new system environment variable named EXE4J_JAVA_HOME pointing to the new install dir (there's no need to overwrite the JAVA_HOME env. var.).
I am trying to use a 32 bit wix installer to install to the powershell directory c:\windows\????\windowspowershell\v1.0
i have hard coded the 32bit directory
and i am trying to read the registry to return the 64 bit location.
all works fine on a 32bit machine, the registry gets read with the correct value and the file is installed to the correct place.
however when running on a 64bit machine (server 2008 R2) the registry picks up the correct 64 bit location but my hard coded 32 bit location is overwritten with the 64 bit registry value.
what is going on?
is there a better way of doing this?
what i have is a single ps1 script that needs to be installed to the powershell directory, if there is a 64 bit and 32 bit directory the same file should be copied to both locations
thanks
James
Windows Installer was designed to be platform specific. X86 packages can only write to X86 locations and X64 packages can only write to X64 locations. There are some hacks that allow you to get around this but they aren't supported. The official Microsoft solution is to create multiple MSI's and use a bootstrapper to chain them together ( ugly ) but you can also use a custom action to copy the file to the secondary location.
Sorry, no good solutions on this one IMO.