I have a client who is requesting that we give them an MSI file instead of our normal EXE file for installation of our software. The client has users on multiple Windows operating systems (2K, XP, Vista). As stated in the title of the question, do I need to create a MSI specific to each OS or are MSIs generic enough to work on all of these operating systems.
.MSI files can work successfully on multiple OSes.
One caveat is 32-bit vs. 64-bit: you'll have to make the choice of do you want to natively support 64-bit Windows. Your options are:
1) One .MSI file for both 32-bit and 64-bit. You would mark the package as 32-bit in the Summary Information Stream. Files would get installed to the 32-bit equivalent targets in 64-bit Windows. (e.g. Program Files (x86), 32-bit HKLM/Software/WOW64, etc.)
2) Two .MSI files, one each for 32-bit and 64-bit. Different Summary Information Stream for each package. This way the 64-bit targets would be the native 64-bit targets in 64-bit Windows. (e.g. Program Files, HKLM/Software, etc.)
More reference: Using 64-Bit Windows Installer Packages
You might want to have an MSI for X86 and X64 but I do not think you should have one for each OS.
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!
This isn't my area of expertise so I'm asking hopefully the right question.
We have a server that is lease rolling. The old server is a 32-bit windows server and the new server is 64-bit windows 2008 R2 SP1.
One of the web applications uses Perl to run some scripts.
We can run the same 32bit version on the new 64-bit machine? (e.g. if there is a same version but one is 32-bit and one is 64-bit, are they essentially the same?)
If a script is working on a 32-bit version, should it still work under the 64-bit version of Perl?
If the questions need clarifying, please let me know and I'll see about asking the appropriate person on our team.
I think the answers to both your questions are yes. The 32-bit applications should run fine on your 64-bit Windows, but will not be able to utilize any of the 64-bit features (where a larger usable address space may very well be the most important if you ever want to parse big XML using XML::Twig ;-).
The script running under 32-bit perl will work on a 64-bit perl, provided you get all the modules for the 64-bit perl in order, since they typically run from different directories. Also, be aware that for 64-bit perl on Windows you probably need Strawberry perl, ActiveState perl or similar. Cygwin is only 32-bit as far as I know.
Yes, you can, as long as you redeploy properly, including the build steps for dependencies. Just copying files over will only work if the whole application stack is pure-Perl, which is not likely. — Yes, they are essentially the same, but binary incompatible.
Likely yes. Problems can arise with the dependencies, however the number of modules that fail due to 32-bit/64-bit differences are miniscule.
If you're concerned about compatibility, you should be able to run the 32-bit version of perl on the 64-bit machine (assuming both are x86). But the 64-bit version should work more or less the same as the 32-bit one, with a couple of exceptions that should not affect scripts. (They have to do with C/XS code in modules, mostly. Binary-compatibility stuff. Meaning modules will have to be built for 64-bit. Fortunately, any Perl interpreter that doesn't suck will do the build stuff for you in the case of *nix, or provide a package manager that has pre-built modules like ActiveState does.)
If I have a process dump file, is there anyway of knowing if the dump was generated on a x64 machine or x86 machines?
You can use the .effmach command to know the architecture that the dump was created on. Note that there is the WOW64 scenario where the dump arch is x64 but you should actually debug it with a x86 approach (see !wow64exts.sw command).
0:000> .effmach
Effective machine: x64 (AMD64)
You can look at the environment variables. Output of command !peb, among other things, contains list of environment variables. If you see variables PROCESSOR_ARCHITEW6432 or ProgramW6432 defined, the OS is 64 bit. Otherwise, it is 32 bit.
Unfortunately, above answers don't work in most cases.
Dupmchk.exe will say "x86 compatible" for both x86 and x64 OS if the target process was built as x86 binary. And !peb command also gives you useless "PEB NULL..." for minidumps which we use most of the time.
You would better check the full path of "Kernel32.dll" since x64 OS will load "C:\Windows\Syswow64\Kernel32.dll" instead while x86 OS will load the plain "C:\Windows\System32\Kernel32.dll" for x86 executables. Loaded modules and their paths are recoreded in minidump and easily checked by dumpchk.exe, windbg and Visual Studio.
You can use the dumpchk.exe utility that ships with Debugging tools for Windows. Simply pass the dump file as the argument.
In the generated report, you'll have the OS version and the CPU flavor, for example :
Windows 7 Version 7601 (Service Pack 1) UP Free x64
Product: WinNt, suite: SingleUserTS
I'm trying to deploy an application on Windows Server 2008 (SP2 x64) and Windows 7 (x64), using VS2005 Installer Project. The MSI version (I think) it the 2.0.
Everything works fine, except that some registry keys and some files are not copied on the install machine. The MSI system doesn't notify about nothing (and I don't know whether MSI logs its operations).
Are there incompatibilities between my MSI installer project and these new OSes? It seems to me that the OS protect itself for being modified in some part.
For example, I'm trying to set the registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\WinLogon\SpecialAccounts\UserList\User
but it is not created. In the same installer there are many other keys, which are created like expected (as they always did before on Windows XP and Windows Server 2003).
To provide another example, I'm trying to install the file
%SystemFolder%\oobe\info\backgrounds\backgroundDefault.jpg
(where %SystemFolder% is typically "C:\Windows\System32"), but the file is not copied at all!!!
What's going on?
I've found the backgroundDefault.jpg file is located in another directory: %SystemRoot%\SysWOW64\oobe\info.
But I've not specified nothing about a System (64 bit) folder. How can I copy the file in the right place?
First, regarding logging, you can request MSI to create a log file of its operations like this:
msiexec.exe -i my_msi_file.msi -l*vx logfile.txt
This will create a log file called logfile.txt.
Second, it sounds like you're creating a 32-bit MSI and running it in 64-bit Windows. There is nothing wrong with this, but be aware that Windows is using file system redirection. Windows has a separate SystemFolder and HKLM/SOFTWARE keys to host 32-bit applications. If you look in the Registry at HKLM/SOFTWARE you'll probably see a sub-key called Wow6432Node -- this is where 32-bit apps write their Registry data.
When downloading the tar file from AdaCore for the GNAT compiler (the libre version), I noticed that there are two exe files for installation purposes:
win32ada-gpl-2010.exe of size 2.67 MB
and
gnat-gpl-2010-i686-pc-mingw32-bin.exe of size 70.2 MB
In the folder containing the second one, there are instructions for the installation and it installs the GPS editor as well.
I have Win XP and chose to install the second exe file. Now I'm thinking that the second one is for a MINGW installation whereas the first exe file is for a native Windows installation. But I can't find information for this. Which of the two exe files is for a normal Windows installation?
Thanks a lot...
Win32Ada I believe is just a set of Win32 bindings for Ada. That's why it is so much smaller.
You might download that if you want to do a lot of Win32 systems programming or GUI work, and don't have a set of higher-level bindings (eg: GTKAda)