I am exploring a Citrix environment and noted that there is are two System32 folders one in the usual location and another under a Citrix folder. What is the difference. When is one used and when is the other used. If I have application specific dll's that I normally put in the System32 folder, should they be in the Citrix\System32 folder instead?
Thank you,
Elliott
Do not put anything in System32 folders! Neither in the regular Windows ones (32 bit and 64 bit), nor in the Citrix one. Use your application's installation directory.
The Citrix\System32 folder is used by Citrix only. Don't mess with it.
Related
Why does Test-Path -Path $folder -PathType Container return true, but folder does not exist?
The Path is:
C:\Windows\system32\WindowsPowerShell\v1.0\Modules\MyCompany\Modules
Same code in ISE x86 and ISE, but different results
The answer is here
Excerpt:
The 'System32' folder is for 64-bit files and the 'SysWOW64' folder is for 32-bit files
This can be somewhat confusing, but the System32 folder is intended
for 64-bit files and the SysWOW64 folder is intended for 32-bit files.
This may seem a bit illogical if you look at the folder names, but
there is an explanation to this. It has to do with compatibility. Many
developers have hard coded the path to the system folder in their
applications source code. They have included "System32" in the folder
path. And to preserve compatibility, if the application is converted
to 64-bit code, the 64-bit system folder is still named System32.
But what about 32-bit applications that have the system path hard
coded and is running in a 64-bit Windows? How can they find the new
SysWOW64 folder without changes in the program code, you might think.
The answer is that the emulator redirects calls to System32 folder to
the SysWOW64 folder transparently so even if the folder is hard coded
to the System32 folder (like C:\Windows\System32), the emulator will
make sure that the SysWOW64 folder is used instead. So same source
code, that contains a path with the System32 folder included, can be
compiled to both 32-bit and 64-bit program code without any changes.
So remember: • the SysWOW64 folder is intended for 32-bit files only
• the System32 folder is intended for 64-bit files only It is very
important that a binary file compiled to a specific bitness (32 or 64)
is installed to the correct system folder. Otherwise the program that
needs the file will not be able to load the file and will probably not
work as expected.
That's why ISE x86 output is in SysWow64 folder and the call to:
C:\Windows\system32\WindowsPowerShell\v1.0\Modules\MyCompany\Modules
is redirected to the SysWow64 folder.
The ISE console is running as x64 and therefore will look in System 32 and will not find this folder, but the folder was created in ISE x86 console, which saves the folder under SysWOW64.
I am trying to make Eclipse run entirely on my flash drive so I could program anywhere on any computer, if it is Windows, really.
To accomplish this, I need some way to make the ".eclipse", ".p2", ".gitignore", and ".tooling" be on the flash drive and not in the C:\Users(user)\ directory.
Any solutions?
You can use portable eclipse.. download from: https://sourceforge.net/projects/eclipseportable/
Remember you have to have JDK installed on the computers that you want to work on.
I am creating a Chocolatey package for internal team usage. (In this case, the package is for Microsoft's windows debuggers.)
Windows Debuggers contains two folders, one for 32-bit x86 executables and an x64 folder for 64-bit executables.
The executable names are identical.
x86\adplus.exe
x64\adplus.exe
After installation it looks like the shim created by Chocolatey is indeed starting one of the adplus instances successfully. But sometimes I need the 32-bit version and sometimes I need the 64-bit version.
So here is the question: When there are two identically named executables in different directories, how do I tell Chocolately to create different shims for the executables in each directory?
The short answer is that you can't have two identically named shims in the Chocolatey shim folder ($env:ChocolateyInstall\bin).
A limitation of Windows for a directory is that each file/folder must be a unique name. This is what you are running into. Shims get dropped into the $env:ChocolateyInstall\bin folder, which puts them on the PATH automatically because $env:ChocolateyInstall\bin is on the PATH (it allows folks to install all kinds of things without overloading the PATH environment variables).
You can create an empty file ending in .ignore (e.g x86\adplus.exe.ignore) file next to the one you don't want to be shimmed. This is documented on the wiki. You can even do it programmatically during install based on something like OS architecture.
It sounds like you have a need for one of them sometimes and the other at other times on the SAME machine. I would suggest .ignore files for both files, and likely using Get-BinRoot to push the files to a tools folder (you get to define where the location of this is). Then you can set the process PATH temporarily for whichever one you need and it doesn't persist to the actual path. You can even set one on the path and then override it when you want the other.
Since the automation scripts are just PowerShell, you have all kinds of options here.
I calculated MD5 and SHA256 hash values of notepad.exe and mspaint.exe through online hash generators md5FileCalculator Onlinemd5.
What i noticed is that if i calculate when both exe's are present in their actual postion in system32 the value coming is different than when placed somewhere out of system32 folder.
What is the reason behind that ? Which is the correct hash value ?
I am using Software Restriction policy to block the applications, I created a hash rule for notepad.exe(present in SYSTE32 folder) file and blocked it. When I check the hash value in registry it is different from the hash value of notepad.exe (from SYSTEM32 folder) calculated through other methods like online md5 calculators or through Windows API. But when I copy the notepad.exe file into some other folder say on desktop and calculate the hash value, it is coming same as it is in registry for which I created the rule.So the correct value is I think the one which I get when file is out of system32 folder. But I am not getting why it is happening ? Does it have something to do with permissions ?
It's because of 32-bit applications running on 64-bit Windows, and how Windows handles the System32 folder for those programs.
This was also driving me nuts for a while because I couldn't for the life of me figure out why certain files in System32 (namely .dlls and .exes) were returning different hashes depending on what I checked them with.
Using HxD and Firefox to upload a file to check its hash, I got different results compared to using QTTabBar's hash checker, which runs inside explorer.exe.
But if I copied one of these files to another location, I would then get identical results across all programs.
Meanwhile, HxD showed different file lengths for the copied file vs the one in System32, and while both showed similar byte distribution, there were also significant differences.
But then I thought to try the same thing on another folder, and finally cracked it, with a little help from Wikipedia:
The operating system uses the %SystemRoot%\System32 directory for its
64-bit library and executable files. This is done for backward
compatibility reasons, as many legacy applications are hardcoded to
use that path. When executing 32-bit applications, WoW64 transparently
redirects 32-bit DLLs to %SystemRoot%\SysWOW64, which contains 32-bit
libraries and executables.
32-bit applications are generally not aware
that they are running on a 64-bit operating system. 32-bit
applications can access %SystemRoot%\System32 through the pseudo
directory %SystemRoot%\Sysnative.
Because HxD and Firefox (and most other browsers) are all 32-bit applications, when you load a file into them, Windows is actually transparently redirecting them to the file of the same name in the SysWOW64 folder (presumably if you ran a 64-bit browser, you would not encounter this problem).
Similarly, when you copy a file out of System32 to another location, explorer.exe, being a 64-bit process, copies the original System32 file, and not the (confusingly named) SysWOW64 equivalent.
So as the wiki states, if you enter %SystemRoot%\Sysnative
into the path of the open file dialogue in your 32-bit application, it should load the file from the real System32 folder, and give you the correct result.
And if you check the files in the SysWOW64 directory, all files should return the same respective hashes regardless of what you open them with.
Further reading:
SysWOW64
Sysnative
Are you sure you're checking the exact same file yet on diferent paths? I think you're checking two diferent notepad.exe. Check the size of the file... it must be exacly the same on bytes.
I've just checked my notepad.exe on two distinct paths C:\Windows\System32 and C:\Windows and they are diferent.
I have always wondered about this. So many application setups have a zip file that you unzip, and in it are a bunch of files, among other things an exe and an msi. What is the difference? They are often even about the same size. I am never really sure which one to execute, sometimes I do the exe and sometimes the msi, and it usually works with either one. But does one of them do anything that the other doesn't do? And if not, isn't it kind of a waste having two files that does the same thing? Especially when thinking about download size, etc...
Not sure if this should be here or on ServerFault, or maybe neither, but I figured since developers usually are the ones creating setup files, then developers might know why this is like it is =)
In the case where you have both exe and the msi the exe is just a loader for the msi. If you have an installation supporting multiple languages then the exe applies a language transform (mst) on the msi before installing.
You can consider the exe as a wrapper around the msi. The msi file may or may not be given separately. The reason why people give the msi file too is to facilitate a group policy installation (in a Windows Active Directory infrastructure) as you can only push down installations of msi files and not exes.
The setup.exe is a wrapper for the MSI, but it is not only a wrapper.
The setup.exe can rely on a setup.ini to define parameters
The setup.exe checks for the Windows Installer (a MSI cannot be installed otherwise)
The setup.exe can check for frameworks, like the .NET framework. The developer can pick one of those defined in C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages (for Visual Studio 2008). If it is lacking, it will try to download it from http://www.microsoft.com/
The setup.exe can be reconfigured with msistuff.exe
The actual installation is done in the MSI. As Prashast said, the exe is just a wrapper, but the reason for having the exe, is that an exe is allways possible to run. If the user do not have MS Installer installed on the computer, or his version of MS Installer is older than the version required by your installation, then the MSI file is not possible to run.
The exe provides automatic installation of MS Installer (including some question to the user if he/she wants to do this) before running the MSI file. In most cases, the install packages needed for Microsoft Installer is included inside the setup.exe, or sometimes it is just the prerequisites check with a link to download the installation from Microsoft.
In very basic words,
you can deliver just the .msi file and it will install. but .exe will not work without the .msi