sp0987

We have introduced a new variable to the interface part and a function to the implementation portion of the Delphi 11 System.Sysutils.pas, in accordance with project requirements. The freshly generated variable is not accessible to me, and when I try to access it, I get the "Undefined Identifier" error. In Delphi 7, the same procedure was effective.

I didn't fully go through their WiKi and examples before, but the "Hooking WinAPI function" example is exactly what I need. I've got the idea how it works now. Thank you ALL for helping out pointing me the right direction!

I was planning to use the suggested DDetours library and since I didn't have it nor D11 in front of me I called it createNewDetour(). This is the actual function: function InterceptCreate(const TargetProc, InterceptProc: Pointer; const Param: Pointer = nil; const Options: TInterceptOptions = DefaultInterceptOptions): Pointer; overload; Calling reference of the original function will not work then. Thank you for the explanation of the internal DDetours implementation. If there is no other way than I'll look into modifying the PE imports table. That is something I never had to do. Hopefully it is easy.

Great idea, thank you. I will save the original reference before the detour and use that from within. FYI, I'm going to rewrite the existing D7 implementation using the mentioned DDetour library and use same or built in D11 as well.

before I start, how do I ensure that calling the original Windows.GetLocalTime from within my detoured function does not get also detoured causing circular reference errors? Or that will no longer possible? Example: procedure myNewLocalTime(var st: TSystemTime); begin st := Windows.GetLocalTime(st); // now further modify st end; createNewDetour(@Window.GetLocalTime, @myNewLocalTime, ...);

Because our software needs to operate/tested through time from past to the future in cycles and we can't change the OS time as we did in past.

Thanks for this suggestion too. GetLocalTime is just reference into external Windows DLL in Windows unit I think. I'll need to create a wrapper with same name around it with additional logic somewhere within my project which can be reached by the original GetLocalTime in sysUtils? Correction: it doesn't need to have same name. I could do something like: // excuse wrong code as I do not have D11 in front of me createNewDetour(@Window.GetLocalTime, @myNewLocalTime, ...); yes?

If detours take care of this than that would be exactly what I need! I will attach detours in main's object constructor and test even 3rd party code goes through them. Thank you all for this suggestion!

Hi, I looked into the detours, its definitely a cool feature but I'm not sure it will solve our dilemma. With some (coding) effort detours may intercept the few system's DateTime functions within our project units, but what about 3rd party units, code and components? They will probably be still using the core sysUtils with original functionality. This may introduce bugs as the app will use 2 different times (ours, and OS). Is there a way (place in Delphi) we could easily (without recompiling RTL/VCL) override the few sysUtils's functions? Or this exactly can be accomplished with proper implementation of detours?

If it's really about the interface section, then i have tested the same without modifying interface section. I just created a new function in implementation section and tried to call the newly added function in our sample app. It also gives me the same error.

The utility was a good suggestion. Thanks for that. But, in our case we would like to handle it in our code as we sync the changes with DB and other's.

related to datetime or datetime conversions?

In Delphi 7 we easily intercepted/modified result of all DateTime core functions as Now, Date, Time etc. to use our DateTime (not the real OS DateTime) for testing purposes without the need to change the machine's OS time. D7 easily allowed us to do that introducing an optional event. Here is a small example how we successfully handled it in D7: type TGetTbtTime = procedure(var st: TSystemTime) of object; var gGetTbtTime: TGetTbtTime; procedure tbtLocalTime(var st: TSystemTime); begin if Assigned(gGetTbtTime) then gGetTbtTime(st) // HERE WE PROVIDE BACK OUR OWN DATETIME else Window.GetLocalTime(st); end; // NATIVE DELPHI FUNCTION function Date: TDateTime; var SystemTime: TSystemTime; begin tbtLocalTime(SystemTime); with SystemTime do Result := EncodeDate(wYear, wMonth, wDay); end; D11 is giving us a hard time to do the same.

We need to modify all sysutils date time functions

As per the suggestion , it looks like this ,and the chain goes till all the folders are included. Was i right?

If this is to us, i have tested the same with sample application with only one unit in it.

It means the path which contains all System.XXX.Pas files (C:\Delphi11\source)?

Please find the .dproj . SampleApp.dproj

I've heard on a few blogs that it's best to leave the sysutils.pas file interface alone. However, the issue is creating a new variable that needs to be utilized in several sysutils.pas routines.

It didn't work. I have placed the folder path as first option in project search path. Is there any other areas i have to change i.e., library path in Delphi IDE-> Tools-> Options.

Scenario 1: I moved the sysutils.pas file to a different location (I'm assuming it's a project folder), and I included the project's folder in the project search path. Then, during compilation, I received "[dcc32 Fatal Error] System.SysUtils.pas(35475): F2051 Unit System.Classes was compiled with a different version of System.SysUtils.FreeAndNil". Scenario 2: I placed the sysutils.pas in the base folder i.e., (C:\Delphi11\source\rtl\sys). Then, during compilation, I received a "Undeclared Identifier"

The Path was right. The discussion was not about our project. It's about the working of sysutils.pas from Delphi 7 to Delphi 11.

HTTPServer : Tidhttpserver with httpserver do begin HTTPServer.DefaultPort := 8080; HTTPServer.Bindings.Clear; HTTPServer.Bindings.Add.port := 8080; if active then stop else active. end procedure HTTPServerCommandGet(AContext: TIdContext; req: TIdHTTPRequestInfo; res: TIdHTTPResponseInfo); begin try res.SERVER := servername; res.ContentType := 'text/html;charset="UTF-8"'; res.ResponseNo := 200; log(req.httpcommand); --// If i remove this then am getting EInvalidPointer : Invalid pointer operation 17:01:23.675 - /images/RuleCOMPILEDSCRIPT.png : /images/RuleCOMPILEDSCRIPT.png for all types of files // if the req.documet is other than .png/.jpg Data := LoadDataFromFile(doc); res.ContentType := fMIMEMap.GetFileMIMEType(doc); res.ContentStream := TStringStream.Create(Data); // if the req.documet is .png/.jpg res.ContentType := fMIMEMap.GetFileMIMEType(doc); res.ContentStream := TFileStream.Create(doc, fmOpenRead or fmShareCompat); except on E: Exception do begin Log(req.URI + ' : ' + req.Document + sLineBreak + E.ClassName + ' : ' + E.Message); end; end; end Am getting EInvalidPointer : Invalid pointer operation while processing one get request to another get request. If the log(req.httpcommand) is used then am not getting any invalid pointer operation exception. Attached sample log file log - Copy.txt

Hi, For Delphi11, we have been utilizing the ICS component suite. With the "TSslHttpServer" component, we recently discovered new behavior. The "KeepAliveTimeSec & KeepAliveTimeXferSec" parameters are intended to shut the connections after an idle time, but when we set the property value to larger than "0," the entire webserver halted.

The problem was fixed. Objects that are created without initializing to Nil are the source of the issue. It provided AV in the most recent Delphi version, but it functioned in earlier versions. Thank you for your kind support.