I try to get the path to the ProgramFiles environmental variable, that is supposed to expand to C:\Program Files (x86) on a x64 machine and to C:\Program Files on a x86 machine.
The problems is that in the nmake file if I do:
all:
echo $(PROGRAMFILES)
This will expand to C:\Program Files everytime and this is wrong.
Environment details from a x64 machine:
ProgramFiles(x86)=C:\Program Files (x86)
ProgramW6432=C:\Program Files
:: this one is special, if will return different results based on current process x86/x64
ProgramFiles=C:\Program Files (x86) or C:\Program Files
PROCESSOR_ARCHITECTURE=x86 or x64
Now the updated question is how to get the location of x86 program files inside nmake, in a way this will work on both x86 and x64 machines?
This expression seems to work on 64-bit Windows 7, with nmake running in both 32-bit and 64-bit:
%%PROGRAMFILES(x86)%%
e.g.
LC = %%PROGRAMFILES(x86)%%\Microsoft SDKs\Windows\v7.0A\bin\lc.exe
If you're on an x64 machine it is totally legal that %ProgramFiles% points to C:\Program Files - from within a 64-bit program's environment.
The variable you have to use to get the x86 counterpart is %ProgramFiles(x86)%.
Which one to use can be determined by evaluating the current OS's architecture that is set in the PROCESSOR_ARCHITECTURE environment variable (which is e.g. set to AMD64). Or simply try to get %ProgramFiles(x86)% and if it is empty get the content of %ProgramFiles%.
Another approach would be to start a 32-bit cmd.exe and run your make there. It is located in C:\Windows\SysWOW64.
Related
As explained in MSDN's WOW64 Implementation Details, the variable %PROGRAMFILES%,
in a 32-bit-process on a 64-bit-Windows OS, resolves to C:\Program Files (x86)
in a 64-bit-process on a 64-bit-Windows OS, resolves to C:\Program Files
You can verify this e.g. with a Delphi 10.1 program, compiled both with the 32-bit Windows Target Platform and with the 64-bit Windows Target Platform:
MyShellExecute('%PROGRAMFILES%');
So, from a 32-bit Delphi Application executed in a Windows-64bit-OS, how can I get BOTH:
the ProgramFiles directory for 32-bit-Programs (C:\Program Files (x86))
the ProgramFiles directory for 64-bit-Programs (C:\Program Files)
Use the following environment variables:
ProgramW6432 to obtain the 64 bit program files directory.
ProgramFiles(x86) to obtain the 32 bit program files directory.
These return the same values in both 32 and 64 bit processes.
Of course, relying on environment variables is always a little brittle. It's always possible for your parent process to have modified these variables before creating your process.
To make your program more robust you should use known folder IDs instead. Use FOLDERID_ProgramFilesX64 and FOLDERID_ProgramFilesX86.
Because I was having problems, I opened a command window and changed to the very bin directory where ant was installed. Then I entered 'ant -version'. It returned:
Files\Java\jdk1.8.0_72"" was unexpected at this time.
Entering 'ant' alone gives the same message. The JAVA_HOME is set to the jdk folder (jsk1.8.0_72), and the PATH adds \bin to it. Nothing else appears broken.
Any ideas gratefully received. Thank you.
Since writing the above, I tried shifting to 32-bit jdk7 from 64-bit jdk8. Output from "ant --version" changed a bit to: Files was unexpected at this time.
Changing the Symlinks in C:\ProgramData\Oracle\Java\javapath did nothing good.
Output of "set | findstr /b /i //"java_home=//"" is:
JAVA_HOME="C:\Program Files (x86)\Java\jdk1.7.0_79"
For PATH=, the output is too long and characters could be missed, so instead I ran: echo %PATH% > d.txt. Here is the result:
C:\Program Files\Everything;C:\Program Files\gradle-2.8\bin;"C:\Program Files (x86)\Launch4j";C:\Program Files (x86)\Apache\apache-ant-1.9.6\bin;"C:\Program Files (x86)\Java\jdk1.7.0_79"/bin;C:\cygwin64;C:\cygwin64\bin;C:\ProgramData\Oracle\Java\javapath;C:\Program Files (x86)\Windows Resource Kits\Tools\;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\curl;C:\Devkit\bin;C:\Ruby21-x64;C:\Ruby21-x64\bin;C:\Perl64\site\bin;C:\Perl64\bin;C:\Program Files (x86)\Apache\apache-ant-1.9.0\bin;"C:\Program Files (x86)\Java\jdk1.7.0_79"\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Common Files\Acronis\SnapAPI\;C:\Program Files (x86)\GNU\GnuPG\pub;C:\Program Files (x86)\WinMerge;C:\Program Files (x86)\Bazaar;C:\Program Files\jEdit;C:\Program Files (x86)\Groovy\Groovy-2.1.7\bin;C:\Program Files\MySQL\MySQL Server 5.1\bin;C:\Program Files (x86)\Calibre2\;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;C:\Program Files (x86)\CMake\bin;C:\Program Files (x86)\mingw-w64\i686-4.9.2-posix-dwarf-rt_v4-rev2\mingw32\bin;C:\Program Files (x86)\Scite\scite\bin;C:\Program Files (x86)\nodejs\;C:\Program Files (x86)\Git\cmd;C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0\;C:\Program Files\Microsoft SQL Server\120\Tools\Binn\;C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\;C:\Program Files (x86)\QuickTime\QTSystem\;C:\Tcl\bin;C:\Program Files (x86)\Arduino\hardware\tools\avr\bin;C:\Program Files\dbd\Beard;C:\Program Files\dbd\dd;C:\Users\dbd\AppData\Roaming\npm
Please note that all the Java Demos run OK, suggesting that the basic java installation is OK.. Have not yet looked at the Registry. All of this is mysterious and upsetting.
Thanks to Stefan De Laet and Chad Nouis. More to be done.
This entry in your PATH doesn't look quite right:
"C:\Program Files (x86)\Java\jdk1.7.0_79"/bin
Those quotation marks shouldn't be there. Also, the forward slash before bin should be replaced with a backslash:
C:\Program Files (x86)\Java\jdk1.7.0_79\bin
Next, the JDK directories appear twice in your PATH:
...;"C:\Program Files (x86)\Java\jdk1.7.0_79"/bin;...;"C:\Program Files (x86)\Java\jdk1.7.0_79"\bin;...
Only one JDK directory is necessary. I recommend deleting the second entry.
Further, your JAVA_HOME also shouldn't have quotation marks. The following...
JAVA_HOME="C:\Program Files (x86)\Java\jdk1.7.0_79"
...should be...
JAVA_HOME=C:\Program Files (x86)\Java\jdk1.7.0_79
At long last and finally, 'ant -version' gets the correct response: "Apache Ant(TM) version 1.9.6 compiled on June 29 2015". I beiieve several things contributed to the success:
Switching from 64-bit to 32-bit java. Since Ant comes as a zip file, I could not discover whether it is really 64-bit or 32-bit. I did find it in my 32-bit folder, but that could be a holdover from earlier times. But maybe not.
fixing the PATH. The PATH which I sent was an end-result after substitution composed of a replacement for the following: "...%JAVA_HOME%/bin...". Normally, I would have spotted it, but because of the %, I did not. Thank you Chad Nouis! When I switched to 32-bit, I did not touch the PATH entry, but merely changed JAVA_HOME. This may have been in the system for some time.
Oh Well! Have a good day everyone and thanks again!
Under Windows 7 64bit, the *32.dll from System32 are 64bit libraries (according to Dependency Walker - depends.exe x64). A strange issue I noticed is that doing - for example - cp /c/System32/ws2_32.dll /c/mingw64/some/lib/libws2_32.dll in the MSYS Shell is breaking/converting the DLL to 32bit file (still according to Dependency Walker)... While copying/renaming it through Windows Explorer keep it unchanged... Still weird. If anyone has an explanation...
Or did I miss something about cp command usage...
Note: I already tried options like --preserve=all or --symbolic-link.
Thanks.
cp is somehow (either directly or due to the parent process that you're running it from) running as a 32-bit process. File System redirection is kicking in and you're actually copying ws2_32.dll from the C:\Windows\SysWOW64 directory instead - where it already exists as a 32-bit DLL.
32-bit applications can access the native system directory by substituting %windir%\Sysnative for %windir%\System32. WOW64 recognizes Sysnative as a special alias used to indicate that the file system should not redirect the access.
I have both jdk and jre installed on my windows 7.
I have set the JAVA_HOME to
C:\Program Files\Java\jdk1.6.0_23
I have add
C:\Program Files\Java\jdk1.6.0_23\bin
to PATH.
but the java.exe still pointing to my jre dir, which is
C:\Program Files\Java\jre6\bin
since when I run
java.exe -server
it complains
Error: no `server' JVM at `C:\Program Files\Java\jre6\bin\server\jvm.dll'.
can anyone tell me what else do I need to set?
since you are on windows, java doesn't work like that.
there is a java.exe in some windows directory (%windir% system32 for you)
This java.exe actually looks in the registry HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment
PATH won't help ya! Since I tend to get lazy I delete the JRE and create a junction to the JDK instead.
Just remove java.exe from %windir%\system32
If you have a 64bit operating system, it will try to use the 64bit jre that is preinstalled on windows 7. You can try using add/remove programs to remove the 64bit jre. I've had this problem several times and I've always fixed it by removing the 64bit jre.
Right click MY Computer> properties > Advanced System Settings > Environment Variables >
Search for Path..
Remove the exisiting path and then add yours..
take care of the semi colon
make sure that your JRE/bin directory is not included in your path. the first instance of java.exe found while searching your path will be the one that is executed. if you've added your JDK to the path after the JRE then the JRE will always be picked.
you can also explicitly specify the full path to java.exe when invoking java. this will ensure that you always know what java jre/jdk you are invoking.
i truly don't get it.
trying to recompile the qr5 packages, and is impossible with this Delphi.
build the QR5Run_Rad6.bpl, everything is fine.
when i install QR5Design_RAD6.bpl an error message appears
"its not possible to run the program since qr5run_rad.bpl is missing in your computer. try again installing your program to solve this problem."
just did!
clean build compile doesn't work in any order. closed the ide and reopened , still doesn't work.
what else is left?
clean all related dcp and bpl
QR5Design_RAD6.bpl <> qr5run_rad.bpl
And more importantly, the qr5run_rad.bpl needs to be found on the systempath in order for the IDE to find it so it can be used by the design time package.
In other words: you need to build the qr5run_rad.bpl as well as the QR5Design_RAD6.bpl. And you need to make sure that the qr5run_rad.bpl ends up in a folder that is on your system path, not just any old folder where you have the sources and/or dcu's.
In addition to what Marjan wrote:
Windows uses these places when looking for a DLL (or BPL, which is a DLL):
The directory from which the application loaded.
The system directory. Use the GetSystemDirectory function to get the path of this directory.
The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
The current directory.
The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.
Delphi puts BPL files in a directory like C:\Documents and Settings\All Users\Documents\RAD Studio\8.0\Bpl which it adds to your PATH when Delphi is installed. For Delphi 2009, that Path would probably be C:\Documents and Settings\All Users\Documents\RAD Studio\6.0\Bpl on a Windows XP machine.
--jeroen