We have an installation program that runs in Perl 32-bit. This program needs to get information on cluster resources, so it runs cluster.exe (using backticks) and parse its output.
On Windows Server 2003 this went well, as a 32-bit version of cluster.exe existed under syswow64. However, such a 32-bit version does not exist on Windows Server 2008, so the backticks run of cluster.exe says it can't find such an executable, as 32-bit process look for it under syswow64.
Can someone think of a way we can bypass this problem and get the cluster resource information?
One manual way is to copy the 64-bit version of cmd.exe from system32, and then run it with "/c cluster.exe" which will start the 64-bit cluster.exe under system32. (Copying the cluster.exe won't work well, as it can't find the cluster cache.) However, this is only good as a manual workaround, and not as a solution to all users.
Is there another way to cause windows to start the 64-bit cluster.exe?
Thanks,splintor
PS
A similar question was asked on technet a month ago, but didn't get a real answer.
I found two possible solutions:
One is to write a small 64-bit application named cluster.exe that simply calls %SystemRoot%\System32\cluster.exe (using system()), and put it under %SystemRoot%\syswow64. Since it is a 64-bit application, the correct 64-bit cluster.exe application will be called.
Another solution is to use the sysnative redirection (as explained here), so now we check - if %SystemRoot%\System32\cluster.exe exists, we use it, else if %SystemRoot%\Sysnative\cluster.exe exists we use it, else we use plain cluster.exe.
Note: this is very similar to this telnet.exe problem that just got answered.
Related
I seem to be able to access the functions in C:\WINDOWS\system32\opengl32.dll (and likewise C:\WINDOWS\system32\glu32.dll) from either a 32-bit or a 64-bit application (for what it's worth, I'm doing this from separate 32-bit and 64-bit Python 2.7 interpreters, via the ctypes module).
With glut32.dll, things are different. It only happens to be on my Path as part of a 32-bit installation of GraphViz. From 32-bit Python, I can link dynamically to it, but from 64-bit Python I get [Error 193] %1 is not a valid Win32 application.
Now, this error does not surprise me, because I had always thought DLLs were obliged to commit to one architecture or another on Windows (in particular, this recent question and its answers seem to say so). What surprises me is the lack of an error in the first case... How does opengl32.dll do it, and how can I replicate this behaviour when building my own DLLs?
On 64 bit system only 64 bit processes use c:\Windows\System32\opengl32.dll. For 32 bit processes system redirects c:\Windows\System32\opengl32.dll to c:\Windows\SysWOW64\opengl32.dll.
File System Redirector
In most cases, whenever a 32-bit application attempts to access %windir%\System32, the access is redirected to %windir%\SysWOW64. Access to %windir%\lastgood\system32 is redirected to %windir%\lastgood\SysWOW64. Access to %windir%\regedit.exe is redirected to %windir%\SysWOW64\regedit.exe.
Just out of curiosity, if I am creating a program installer, how should I decide in which "Program Files" directory to install to? On 32-bit systems, the environmental variable "%programfiles%" is good enough. However, on 64-bit systems, 32-bit programs should not install to that folder and instead to "%programfiles(x86)%", which as I understand points to "C:\Program Files (x86)". My question is: How should the installer decide which environment variable to use? Will the value of "%programfiles%" change for a 32-bit application, or should I always check first whether "%programfiles(x86)%" exists before using "%programfiles%", or should I do something entirely different?
Thanks! This is just out of my own curiosity, as I try to get used to 64-bit operating systems.
When the 32-bit program (installer in your case) asks the system to resolve the ProgramFilePath constant (check the exact name in MSDN), the system does not return C:\Program files, but C:\Program files(x86). So it's the system that decides, not the application.
I'm pretty certain that I read somewhere that Windows did this for you automagically. In other words, if your installer was 32-bits, it would be routed to the x86 directory variant even though you were trying to install into Program Files.
I'm sure I read this on The Old New Thing but here's a link that supports the contention until I can find that one.
Ah, yes, here it is, from the ever useful Raymond Chen.
Commenter Koro is writing an installer in the form of a 32-bit program that detects that it's running on a 64-bit system and wants to copy files (and presumably set registry entries and do other installery things) into the 64-bit directories, but the emulation layer redirects the operations into the 32-bit locations. The question is "What is the way of finding the x64 Program Files directory from a 32-bit application?"
The answer is "It is better to work with the system than against it." If you're a 32-bit program, then you're going to be fighting against the emulator each time you try to interact with the outside world. Instead, just recompile your installer as a 64-bit program. Have the 32-bit installer detect that it's running on a 64-bit system and launch the 64-bit installer instead. The 64-bit installer will not run in the 32-bit emulation layer, so when it tries to copy a file or update a registry key, it will see the real 64-bit file system and the real 64-bit registry.
all dos base application experts here is one thread i am creating.
i would like your opinion for this issues
i found one problem in windows xp or any windows system higher to windows 98
i have a dos base application which runs perfect on windows 98 but when i am running it on windows xp or other system it is showing me following error message
16 bit Ms-Dos Subsystem
An application has attemped to directly access the hard disk, which cannot
be supported. This may cause the application to function incorrectly.
Choose close to terminate the application
as i can run it by pressing ignore but want to remove this error message
second thing i found is dos base printing
printing is not working properly
as it prints some part then it pause for some time and then resume printing
so how to solve these problems.
An application has attemped to directly access the hard disk, which cannot be supported.
This error means exactly what it says. Older versions of Windows including 95/98/Me gave DOS programs full control over the system, meaning they could access hardware as they wished -- while this maintained compatibility with older programs, it could also cause the entire OS to crash if this one program did something wrong.
The Windows NT family (including XP and all newer versions) runs DOS programs in an NTVDM (NT virtual DOS machine) which does not have direct access to hardware, and any attempt by programs to access such things will cause the program to be terminated. Of course, you can ignore the error, but your program will likely not work correctly.
I am having a problem with windows system function “EnumProcessModules()” that is defined in psapi.dll. In our component we use this function to retrieve modules in a specified process. This function is working well as long as we run the program on a 32-bit OS. However, this function fails when we run the program on a 64-bit OS (e.g. W2K8 R2). As you all know we are targeting Clay and Brick on W2K8 R2s. This is a known problem as per the following discussion in MSDN. One work around that was suggested in that thread is to compile the code as 64-bit. To us that is not an option, at least not yet. Do you have any suggestions? Any pointers/suggestions/ideas will be appreciated.
http://social.msdn.microsoft.com/forums/en-US/winserver2008appcompatabilityandcertification/thread/c7d7e3fe-f8e5-49c3-a16f-8e3dec5e8cf8/
If your existing code must continue being compiled as 32-bit, one possibility would be to create a small 64-bit executable that enumerates the processes via EnumProcessModulesEx. The 32-bit process could spawn the 64-bit process when necessary to do that work. Then use some kind of IPC to transfer the information back to the 32-bit process. Depending on what is needed, that part could be as low tech as writing a file to disk and reading it from the first process (or pipes, shared memory, sockets, etc.).
Is there a way from a 32bit application running on a 64bit system to have access to the default folders for 64bit applications?
For example, using SHGetSpecialFolderPath with CSIDL_PROGRAM_FILES from a 32bit application returns "C:\Program Files (x86)' If the same call was used from a 64bit application, I would get "C:\Program Files". Is there a way of getting that "C:\Program Files" from a 32bit application?
A related question here does not help SHGetFolderPath() 32 bit vs 64 bit nor does supressing the wow64 filesystem redirection before calling SHGetSpecialFolderPath
Answering my own question, it seems it is not possible with SHGetSpecialFolderPath. In Vista and later, using the replacement function SHGetKnownFolderPath allows it with FOLDERID_ProgramFilesX64
I believe the whole reason for having separate folders was to prevent 32 and 64 bit applications from mixing. Therefore, you shouldn't need to see a folder belonging to a different bitness from your application.
You may have a very good reason, but I don't see one in your question as posted.