Two Delphi programs need to load foo.dll, which contains some code that injects a client-auth certificate into a SOAP request. foo.dll resides in c:\fooapp\foo.dll and is normally loaded by c:\fooapp\foo.exe. That works fine. The other program needs the same functionality, but it resides in c:\program files\unwantedstepchild\sadapp.exe. Both aps load the DLL with this code:
FOOLib := LoadLibrary('foo.dll');
...
If FOOLib <> 0 then
begin
FOOProc := GetProcAddress(FOOLib , 'xInjectCert');
FOOProc(myHttpRequest, Data, CertName);
end;
It works great for foo.exe, as the dll is right there. sadapp.exe fails to load the library, so FOOLib is 0, and the rest never gets called. The sadapp.exe program therefore silently fails to inject the cert, and when we test against production, it the cert is missing, do the connection fails. Obviously, we should have fully-qualified the path to the DLL. Without going into a lot of details, there were aspects of the testing that masked this problem until recently, and now it's basically too late to fix in code, as that would require a full regression test, and there isn't time for that.
Since we've painted ourselves into a corner, I need to know if there are any options that I've overlooked. While we can't change the code (for this release), we CAN tweak the installer. I've found that placing c:\fooapp into the path works. As does adding a second copy of foo.dll directly into c:\program files\unwantedstepchild.
c:\fooapp\foo.exe will always be running while sadapp.exe is running, so I was hoping that Windows would find it that way, but apparently not. Is there a way to tell Windows that I really want that same DLL? Maybe a manifest or something? This is the sort of "magic bullet" that I'm looking for.
I know I can:
Modify the windows path, probably in the installer. That's ugly.
Add a second copy of the DLL, directly into the unwantedstepchild folder. Also ugly
Delay the project while we code and test a proper fix. Unacceptable.
Other?
Thanks for any guidance, especially with "Other". I understand that this issue is not necessarily specific to Delphi. Thanks!
The MSDN documentation for LoadLibrary tells you exactly where Windows will search for the DLLs. You either have to hard-code the path to the DLL, put it in the same folder as your app, or put it in one of those default search locations from the LoadLibrary docs.
This is not exactly a solution for the question asked, but it would have helped me, when I stumpled upon this question:
You can extend the search path for LoadLibrary via SetDllDirectory.
From MSDN-Doku:
The search path can be altered using the SetDllDirectory function.
This solution is recommended instead of using SetCurrentDirectory or
hard-coding the full path to the DLL.
You would have needed to add one line before your LoadLibrary call(s):
SetDllDirectory(PChar('c:\fooapp'));
Or you can simply edit the environment variable "path" and place the path to the dll in there. In this case adding ;c:\fooapp to the path should be sufficient. Since the environment changes of a parent effects a child, you can also create a loader application which adjusts the its environment variable then spawns to your application.
Related
Found this this post ISAPI web application hanging if FastReport.PrepareReport is called
It helped solving my problem partially. As well I´ve turned Wisiyng property to False on frxRichView. Since I'm retunrnig a base 64 string I've also tryed switched loading from StrToStream/LoadFromStream to LoadFromFile. The problem persist with multiple acess, 2 out of 10 process can finish loading my Pdf file. All the others requests hangs until timeout. Does anyone have an idea what else can I do? is there anyother way to retunr rtf format into Fastreport report Thanks.
I could only get time-out error using Selenium to test multiples request from the client side.
Update: I've figured that just having a TfrxRichView component in the report causes the hanging, it doesn't even need to have a rtf text on it. Replacing it to a memo all request are answered.
UPDATE: Got a answer from fast report and I wold like your opinion.
ok,
I had similar problems, and it is not easy to find out the reason, but maybe you can find your solution in between my considerations..
1) Stack Size
When ran in IIS your ISAPI is only a DLL called by a process, you are not the main process so you have to pay attention to stack dimension.
Normally a Delphi application have a default stack size of 1Mb, in ISAPI DLL you will have only 256Kb of stack.
Maybe you are facing a stack overflow exception.. it can explain why it does not occurr always but only in some circumstances..
2) Trapped Exception
In general you get some error during the preparation of report (aka all the job of working with data, expressions, variables, formulas etc etc..) can bring to a trapped exception. You may be unable to see it from outside but code execution was broken somwhere and report preparation had not finished.
3) MessageBoxes and/or standard Exceptions
when running in ISAPI you should not output anything to user interface,
maybe a message dialog (or an exception) can bring to unexpected behaviour.
4) Global Var
You should avoid global var because in ISAPI they will be common across threads
So, if you have sources, debug the application.. at first exception you should understand where is your problem..
If you have not sources.. chek the above list.. I hope you can find some useful information.
You have two ways to solve this:
1- Try to recreate this behavior while debugging your ISAPI DLL. If you are lucky, you can identify the thread that is hanging your application. Sometimes this is hard or even impossible to recreate.
2- If you have access to the hung ISAPI application instance, use a tool like SysInternals Process Explorer to create a minidump file. Your application must be built using full debug symbols and you should have the corresponding map file. With one (or more - even better) dump files obtained from your hung application plus the map file, you can use another tool, WinDbg to analyze it and find the cause. (Sometimes) WinDbg can show exactly which thread is hanging the whole application and the line of code that causes it.
If you have never done that, I must warn you that this kind of analysis is almost a gamble... You have to use several different tools with little
or no documentation, read heaps of technical info in various places. In the end, sometimes it works wonderfully and sometimes it fails miserably.
Because debugging ISAPI is not obvious, but also because I wanted to be able to switch easily between more different hosting solutions — and wanted to update my website on the fly without a restart of the web-server/service — I created xxm. It has a singular interface to the HTTP context, your DLL gets loaded by either a IIS ISAPI handler, or a HTTP.SYS handler, or an Apache httpd module, or for debugging locally you can just set xxmHttp.exe as host application to get IIS out of the way.
I want to use ShellExecute iexplore.exe (with an html file name as a command line arg), even if iexplore isn't associated with html files.
Assuming the user hasn't uninstalled it, how safe is it to do so without supplying a path to the program. This works on my machine, i.e. the default Windows search path contains a path to iexplore.exe. Is it reasonable to expect this on all recent Windows (XP+) machines?
Is there a safer way to ShellExecute iexplore.exe?
(Delphi XE2)
(Although this question stands alone, I'll giving the user the option to run IE in the context of this SO question I asked at the same time: Detect Chrome as browser associated with html files in Windows)
'iexplore.exe' is not in the default search path. It's path is registered in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\IEXPLORE.EXE key. If this key, for any reason, is missing or pointing to a wrong location, your approach won't work. I would think the probability of this happening would be quite low.
As one alternative, you can use Internet Explorer object. With a broken registry or similar, this may also fail, but it sounds like a more official way to me.
ie := CreateOleObject('InternetExplorer.Application');
ie.Visible := True;
ie.Navigate('http://example.com');
IE Object reference here.
I build four different "types" of applications with my framework:
1) Windows Services
2) Normal Applications
3) Service Applications (a normal application with the functionality of a Windows Service but with a local GUI console and an ability to auto-upgrade)
4) Remote GUI Consoles
Now I can detect, through code, if the application is a Windows Service. But currently to detect between the others I use DEFINES that need to be added to the project file. I would like find an alternate way that does not rely on DEFINES if possible. My initial thoughts are to use the Comments field of the project's version info.
Any ideas?
Edit: I am after a general technique that works regardless of how I "type" my applications. At the moment I use DEFINES from the project configuration, which works, but makes the code slightly messier than using "if" code switches, and because it is stored in the .dproj file, can be hidden from view.
Solution: From David's suggestion I initially used the conditional defines (and any other information such as whether the application was running as a Windows Service) to map all applications to one of the 4 application types, stored in a globally accessible object. Unless linking files that made no sense to include with a particular application type, I replaced almost all of my conditional compilation flags with code, which significantly improved the readability of the code. There are a few other "tweaks" I implemented, but that was the basic implementation.
Depending how you are using the Application global variable you can detect if you application is a Service, a VCL or a console App checking the type of this global variable. for consoles app you can use the System.IsConsole variable.
function ApplicationIsService(Component:TComponent):Boolean;
begin
Result:=Component.ClassName='TServiceApplication';
end;
function ApplicationIsVcl(Component:TComponent):Boolean;
begin
Result:=Component.ClassName='TApplication';
end;
and you can use like this
if ApplicationIsVcl(Application) then
//do something
else
if ApplicationIsService(Application) then
//do something else
else
if IsConsole then
//do another thing
It sounds like each project has a single app type so it seems logical to differentiate in either the .dpr file or the .dproj files.
Call a function to set a private global variable from the .dpr file.
Or use a conditional defined in the .dproj as you do now.
If it was me I'd stick to a conditional but use the trick of converting it into a Delphi enum with a shared helper method to make it read better.
Is there any way to delete a file when its using by any program or other process in windows?
I searched and found this 2 ways:
1- using RunOnce key in Registry;
I'm not gonna use this because i dont want to wait for windows restart or anything else... prefer to do it ontime!
2- using the way declared in this page: http://www.delphipages.com/forum/showthread.php?t=201190
the problem here is its useful under NT windows, i need a way works on all Windowses!
Thank you.
the problem here is its useful under NT windows, i need a way works on all Windowses!
All modern desktop Windowses (XP, Vista, 7) are also NT. Do you really need to work with NT<4 or Win98? Or even Win CE/Mobile/Phone? Probably not.
If you need to delete an open file straight away, about the only thing you can do is attach to each process using debugger privileges, see if it has any handles open on the file, and if so close them underneath it. You can do this the manual way using eg Process Explorer. Many applications won't react well to having their files closed on them; expect them to exception out when they try to do something with the dead handle.
Unfortunately there is no option in Windows to have Unix-style files that can exist attached to a file handle independently of being stored under a filename on disc.
You cant delete a file when someone is using it. No matter how hard you try, windows will not let you. It can work with some files, but in general it does not work.
What you can try is postpone the deletion, when no one is using the file. You can:
1 - use RunOnce, but you dont want that.
2 - Wait in a loop, trying to delete the file. Pseudo code:
DeleteFile
Check if you was able to delete or if file still exists.
if you are able to delete, then exit loop.
That is the best you can do, and what i could remeber.
Try MoveFileEx with MOVEFILE_DELAY_UNTIL_REBOOT flag. Will postpone move or delete action until reboot.
Edit:
If you don't whant to restart the only option is to close those handles. ProcessExplorer does that and works all the time and I have not seen any process to crash. See more info about enumeration handles in a process at
http://www.codeguru.com/forum/archive/index.php/t-176997.html. But keep in mint that you should enumerate all processes in the system and behave different on Vista+ (you need to be elevated)
Your files are most likely locked because some process has a handle open to them. That is the most common reason for the Access denied result when deleting or moving a file.
A really blunt way is to close that handle.
Then Handles tool from SysInternals (you can download the sources too) can do that for you: I have been successfully using that.
Note 1: You need administrative privileges to use it.
Note 2: Closing a handle from another process is considered very rude, and can make that process unstable.
Is is possible to open a text file and read the contents while another application is updating the file, in such a way that it does not cause a lock conflict?
I need to monitor a log file from one application which is updated by another application each time an event occurs.
I do check if the file is in use before I try to read it, but that does not seem to work in all cases.
Thanks, Pieter
it depends on how the first app open that file.
i.e when calling CreateFile API to open a file, there is dwShareMode param which tells the api how to open it (if this was given 0, it can't be accessed from other applications IIRC).
otherwise there should be no problem with reading from that file.
if im not mistaken, to check if that file is being opened read only u can call
something like
CreateFile(pchar(fName), GENERIC_READ or GENERIC_WRITE, 0, nil, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0) ;
Download Process Monitor from Sysinternals.
Open the filter dialog and add a "path" filter for your log file.
Start the log-writing application (I'll call this "logwriter").
Look for and click on the event where logwriter does a CreateFile.
Under "Detail", it should have "Desired Access: Generic Write". And it should have "ShareMode: Read", which corresponds to FILE_SHARE_READ in the call to CreateFile. What it means is, "I, logwriter, permit others to read my file".
Now run your log-reading application ("logreader"), and do the same exercise.
The Detail should have "Desired Access: Generic Read". And it should have "ShareMode: Read, Write", which means, "I, logreader, permit others, including logwriter, to read and write to the log file".
Those are the most sensible values, I think, and they will prevent locking. Other combinations may be permissible. There is a table here.
Now, you haven't said what happens when it "does not seem to work in all cases". What to do next will really depend on the details. Hopefully the above will give you enough information to work out what is going wrong.
You won't get a lock conflict because the writing application is very unlikely to have locked the file. Doing what you suggest generally works without problems (it's what the UNIX tail -f command does) and those minor glitches that do occur can be ignored. I've written a couple of log monitoring apps in te past that worked like this, with no problems.
Try using FileSystemWatcher to get events when a file is updated.
A more delphi friendly link
Quite apart from getting the file sharing to work right which may be impossible depending on what the other program requests, some programs will close the file between accesses.
I have had success in the past with my program waiting for the file to become available, then quickly opening it, grabbing the needed data and closing it. At least in DOS an attempt to access a locked file caused a few retries, and I bumped up this setting, so that if the other program tried for the file while I had it they would simply be delayed and never see an error.
I was even able to update the file (I made sure NOT to close it in between!) without the other program ever knowing a thing.
Ugly as sin but we couldn't change the other program so it was the only way to get the job done. It was deployed in-house for years, I never heard a peep from the users of that system. It finally went away when the machinery the other program controlled was retired.
XpoLog will do the trick without changing your env or code, XpoLog log monitor
Avar is right - you are at the mercy of the writing program here. If they are locking the file, then there are a couple of things you can do:
1 - Check for a change in the "last modified" date time - if that changes, then you know something has happened.
2 - If the mod datetime did change, then (depending on the size of the file) it might be good enough to create a copy of the file and check that.
we use "Tail for win32",
i know its not delphi but it might be useful
http://tailforwin32.sourceforge.net/