Is there a way to tell a Delphi project that builds a DLL to use as a host application an executable in the same directory as the output directory of the DLL being built?
something like this:
One thing is, I'm using option sets with Delphi XE2, so in the dproj for the DLL I'm building I don't even have a DCC_ExeOutput directory, not sure if that matters.
Allowing this would seriously decomplicate some issues we've ran into trying to migrate from VSS to SVN.
Also, what do you call the $(thing)'s?
The $(name) things are environment variables. I tried setting the host application to .\$(Platform)\$(Config)\Test.exe and received this error message:
Could not find program, '.\%Platform%\%Config%\Test.exe'.
Note how the $(...) was turned into environment variable syntax.
I also tried with $(systemdrive)\Test.exe and received this error message:
Could not find program, 'C:\Test.exe'.
So clearly environment variables will be substituted with their values, if they do exist. I think it is reasonable to conclude that the environment used to start a host application clearly does not define the special Delphi specific environment variables.
So I think the answer to your question is that you cannot use indirection like this for the host application setting.
On the other hand, environment variables are substituted so perhaps you could use that to make things easier. In other words you could define some environment variables of your own. I've no idea whether that may be of help to you since I don't know the precise details of your problem.
Related
I am the beginner for visual studio IDE. While I was assigned the project in the Visual studio IDE. I was asked to create system environment variable as ACE for ACE Lib files. Could any one please tell me why we configuring the system environment variable. What they actually mean ?
My doubt is what is environment variable ?
How it communicate with the IDE ? Why it is so important to setup environment variable ?
(Please correct me If I got anything wrong here)
Do you need to change the path stored in EnvironmentVariable, some thing like this,
http://www.computerhope.com/issues/ch000549.htm
or else you need to Create, modifie, or delete an environment variable stored in the current process,
https://msdn.microsoft.com/en-us/library/z46c489x(v=vs.110).aspx
Adding more details in your question might be helpful.
We have a Delphi program whose task is like a service program. It watches a particular folder for a certain period, and it works great on Windows XP and 2003, but on Windows 2008r2 64bit, when it wants to create an automatic folder, it will show this message:
The ... folder does not exist. The file may have been moved or deleted.
This message causes the program to halt, which is not good; it should not be interrupted.
What can I do about this?
P.S.: I really don't have any idea whether to post my problem in Stack Overflow or Server Fault, so I've guessed it should be here.
It's likely the VirtualStore, if you're trying to store beneath Program Files (either one). See my writeup:
http://www.clipboardextender.com/off-topic/vista-program-files-hide-and-seek
You've left out the ... folder name. While that's understandable, it wouldn't happen to have anything to do with program files (which on x64 will be split in 2 directories) would it?
Windows Server 2008 is able to use 'virtual' file pathes. That means: 'what you see is not what you get'. The Windows Explorer just shows you the 'display' name. Check the file path with cmd.exe, if the path you are trying to use does realy exist.
The reason is of cause the File Virtualization (see for example http://msdn.microsoft.com/en-us/library/bb756960.aspx and http://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx).
Because we on stackoverflow.com and not on serverfault.com I want add to all other answers that you can use Wow64DisableWow64FsRedirection, Wow64RevertWow64FsRedirection and Wow64EnableWow64FsRedirection functions (see http://msdn.microsoft.com/en-us/library/aa365743.aspx) to control the File Virtualization in your program. An example of the usage of this functions in C# you can find here http://www.pinvoke.net/default.aspx/kernel32.wow64disablewow64fsredirection.
You'll need to tell us the exact path and how do you go about constructing it. It can be as simple as the app not using env variable expansion but assuming that user's folders are where they were before.
Path virtualization (there are 2 kids actually) that people mentioned will hit you only if your app is trying to mess with system folders.
More puzzling problem will hit you if you are not expanding env vars like APPDATA, LOCALAPPDATA etc. and not expecting that there's more of them on Win7 and 2k8. Not only that default paths of user's files changed but some of them can also be on network shares - for the same user. So if you were running based on expectation that all user's stuff will be at definite paths under say %USERPROFILE% you can get hit by several surprises. Also notice %ProgramData% .
Fastest way to find out - open cmd.exe, run set and if you see some paths that you are constructing in alternative ways, take notice that you need to start expanding env vars for them. Then open cmd.exe as a 32-bit app and check set again. You can also pick them up via Process Explorer from some running 32-bit or 64-bit app.
Switching your app to 64-bit build will resolve most of virtualization issues but not the env var expansion. Also if your app is touching system folders you need to request elevated run from the code or even better make the manifest and declare it there. Then OS will yell at user up front if his UAC is on and your app will avoid that 2nd virtualization. BTW, virtualization is controllable via group policies so it might be present on some boxes and missing on others.
I'm using a Java application which allows you to import custom files. On import, these files are loaded into memory.
The problem is that the files I want to import are very big, this causes an OutOfMemory exception. The crash log also informs me that the VM was started with the java parameter "-Xmx512m", I want to alter this to "-Xmx1024m" so that I got double the memory available.
The problem is that this application is using it's own JRE folder and that there's a launcher written in C which is calling the jvm.dll file. In any way, java.exe or javaw.exe are never called and thus I cannot set these parameters myself (if I delete these executables it doesn't matter, can still run the application - this is not the case with the dll).
So, my question is, can I set this VM parameter in an other way? I'm even willing to alter the JRE files if there is no other way.
Update: Found some extra info:
jvm_args: -Djava.system.class.loader=com.company.loader.NativeClassLoader -Xmx160m -Xms160m -Xincgc
java_command: unknown
Launcher Type: generic
You would probably be better off attempting to eliminate the launcher use a standard JVM. See if you can figure out what parameters Java is being launched with--it might help to dump the launcher and any associated configuration files.
Then you just call java yourself.
This may not work at all depending on what else the launcher is doing.
edit:
try:
java -Djava.system.class.loader=com.company.loader.NativeClassLoader -Xmx160m -Xms160m -Xincgc
from the command line against a real JVM. There is a good chance it will fail because of the NativeClassLoader or other stuff set up by the java loader.
Also you may be missing the actual java class it is trying to start (I don't know if that "NativeClassLoader" needs the actual main class or not).
Without knowing more about the C class loader, I don't know if anyone can help you much. Perhaps you could contact the vendor? You might dump the .exe file and see if there is any identifying text--if you could figure out where it came from, you might be able to find docs on it telling you how to forward parameters to the JVM
I'm trying to build a simple release build batch for our app. I'd like to use environment variables inside the <AppName>.cfg file. However these seem not to get expanded. Neither
-U"$(DELPHIKOMP)\VclZip;..."
nor
-U"%DELPHIKOMP%\VclZip;..."
work. However
-U"C:\DelphiKomp\VclZip;..."
does. Any idea what I'm doing wrong?
Please note: We're using BDS2006, so MSBuild is no option for now.
Update: As gabr suggested I wrote a little tool that expands the environment variables in my cfg and calls dcc32 for me. Thanks to all for their answers!
DCC32 doesn't support expansion of environment variables.
I'm pretty sure there exists a utility on the Internet which expands all variables in the cfg file, calls dcc32.exe and restores original cfg file, but I can't locate it anymore.
You can write such program pretty easily by yourself, though.
Why not pass them as command line parameters to dcc32 - in that case the shell will expand them.
FWIW, using Delphi 2006 does not preclude MSBuild, or make, or another build tool; just shell out to dcc32 as necessary.
We need to get data out of an older accounting system. We have received a dll that gives us access to the data we need. It includes a type library that we have imported.
If we run our test application from the same directory as the accounting system, everything works fine. If we try to run our application from a different directory, we get the following error:
Dynamically Bound RTS
Runtime DLL 'OOPS', version 3.1, entry point oops
not recorded in registry, not found or incompatible with requirements
of dynamically bound COBOL program. Dynamic binding of RTS requires:
Runtime DLL 'OOLSM', at least Version 3.1
Can anybody provide some helpful information on this?
Are we supposed to have some kind of cobol runtime in our directory? Or in the path? Or registered in the registry?
Thanks,
-Vegar
Updates:
Setting the system %path% to include the path to the accounting system seems to do the trick. Including it as a user variable did not have the same effect for some reason.
What Cobol are you using?
I had done this for year with Microfocus NetExpress 3.1, and all works just fine.
I write COBOL DLL to access COBOL data files, and also write Delphi DLL to add new features to old COBOL systens.
And yes, I use to set the runtime path, that is environment variable called COBDIR, there are others,but usually %PATH% and %COBDIR%is enough.
If you give more detais about what COBOL compiler are you using, and how is the dll interface that you are calling, will me ore easy to help you.
And maybe "Dependence Walker" can help you to identify what run time files are missing, if it is.
http://www.dependencywalker.com/
If it works from the accounting app's directory, but not a different one, the first thing I'd try is adding that directory to your path.
Unless it is already loaded into memory, Windows looks for DLL's that a program is requesting in every location listed in its PATH environment variable, and also in the directory the application is located within.