Tommi Prami

So far my tests with this has been very good. Solves some issues I need to tackle. Don't have code for Removing service, but not sure how much that is even needed. Sure there is use for removing also, but at least not important for me. -Tee-

Seems to be active on our App:

Voted...

There are some limitations which Windows versions ASLR supported and which variant. High entropy one needed quite new version (Win10 if I recall)

We use madExcept, but that is not the point. Point is will it effect to the AV-address or not?

Did not get from that will it affect into the the Delphi Image base setting or not: Maybe I did not ask clearly enough. What I am actually asking is: I get (from bugreport above) that if ASLR is on, the address in Access Violation can't be checked from MAP file as is. Because there is not enough info to do that. So that if there is Access violation at Customer, they send the Address/Screenshot, that I could not get the actual error location from map-file, because it could not know the where ASLR has actually located the code, so I would need the ASLR offset or something like that also? And reading those ASLR articles did not help much, so I could be sure is my impression wrong or not. I googled how ASLR works and there was lot of low level descriptions, but not sure will it affect to AV and/or map-file investigation. -Tee-

Voted If possible edit the code parts (I think there is way to have prettied code in Jira) so the bug report would be essier to read.

Innosetup has LZMA and LZMA2 code, might be that it is using it "in own way", did not check that closely. But there are .obj files for 32 & 64bit build and so on. Don't know is the headers translated fully. Ah did not see that this was Cross platform, and those might not be portable, but anyhow, maybe someone else can use the info,..,. -Tee-

Download link gives 404

I could not find simple summary on features what are available. Would help. -Tee-

Yo, As windows does the similar thing when doing file operations in explorer, if it start to take time, then it bring s dialog up, and do not flash it if operation is fast (At least sometimes it seems this way). I've been pondering this kind of pattern for a long time. Never tried to code this, but as concept it might be nice, but I have feeling that this is easy to mess up, and for sure easy to kiss some corner cases to have super weird issues, I think. My idea would be something like LLazyProgress := LAzyProgressFactory(ParentFormEtc, lpMarquee, 300); try ... Work finally LLazyProgress.Free; end; If this would be network or file operation, sometimes it might be fast and sometimes very very slow,. And you kind of can't know for sure., My idea was that there would be some, like 300ms delay, if process takes more time than that, progress dialog would show, It could be marquee style, or if progress is more defined and known, could pass some callback for the actual progress and show it, Any thoughts/ideas on this. Mainly if problem with fluctuation of time process takes, sometimes there would be fast flash of dialog for user, and they never could see what was it. Completely different discussion should there be some kind of UI element to show user that progress has finished. -Tee-

Relocating actual work to thread, is what I would like to avoid, as it adds quite log extra complexity, like needs new connection to database etc. This why I asked because there might not be good solution without having actual work in a separate thread/task (= thread). For sure having the actual work in separate thread would have its own benefits, like they would crash if they mess around with GUI, but most likely work in legacy app has some GUI updates, that's why it would make it much easier to just keep the work in main thread. So far what I've been pondering that it would need thread, but been thinking that maybe the Lazy progress bar showing logic would be in thread. I thought something like this could work: 1. Have and initialize background thread which waits for progress bar dialog requests. 2. Also create initialize progress bar dialog 3. Request progress bar 3a If progress bar request is still alive and time period is over, show dialog 4. when work is done, ask thread to hide the dialog, if visible at all 5. free the request Needs some thread safety and TEvents or something for signaling and so on. Also Progress bar dialog would naturally be modal, and process messages in a way or other.

I most likely would have more than less both, but slightly off topic...

I tried to read the articles linked, and it was not very clear will this affect we signing our apps, or is this just when it is done in Azure or so. And where actually requirement is coming from, what actually will enforce this for us, if will. MEaning how resulted signed app will differ from what we have now? Articles , to me, are written in way that you need lot of background information to actually understand what this all means. -Tee-

https://quality.embarcadero.com/browse/RSP-39546?filter=18027 Vote and/or collaborate if feels serious to you... -Tee-

Even tough this is very weird example, but seems like something that with some bad luck one could get hit by that. -Tee-

Please report to the Bug Report that you could reproduce it...

RTL has Buffered file stream now, but I think there is no buffered Memory stream, I think. is there fast implementation available? I made long long time ago one, but that was not super good implementation and don't have code anymore. At least then it made some code way faster, and Stringbuilder I believe is not super fast, and and can't handle binary data 🙂 -Tee-

Not problem for me, but "interesting" choice to implement those features with helper, they kind of can modify existing classes quite freely if they want 🙂 -Tee-

To me quite the opposite, just the release we needed. Quality updates should come more frequently IMHO. -Tee-

Fellow forum members educated me of feature I did not know existed, or I knew, but I never used it this way. I've attached pdf-file for the info. Thanks all helping to get the call count, this is pretty cool. Get call count with Delphi Debugger.pdf

Now that went through TMemoryStream code, it is buffered... I must confuse it into some other stream class, sorry about that. But really interested how to get call count of the non breaking breakpoint tough...

That would be good to investigate, how I can see the count like that, never knew you could setup a breakpoint like that, so how to do that?? Non braking breakpoint yes, but how to see how many times it is called... Also should run as release build with optimizations on, to see how it runs then. (This was pretty much similar, little bit slower, but OK)

I do fast and crude test. Good that I did, speed gain is nice, prosentually, but it is much faster that I though: procedure TForm3.Button1Click(Sender: TObject); const LOOP_MAX: Integer = 90000000; DATA: RawByteString = '0123456789'; var LStopWatch: TStopWatch; I: Integer; LStream: TMemoryStream; LDataLength: Integer; begin LDataLength := Length(DATA); LStream := TMemoryStream.Create; LStopWatch := TStopWatch.StartNew; try LStopWatch := TStopWatch.StartNew; for I := 1 to LOOP_MAX do LStream.Write(DATA[1], LDataLength); LStopWatch.Stop; finally LStream.Free; end; Memo1.Lines.Add('No preallocation: ' + FormatFloat('0.000s', LStopWatch.Elapsed.TotalSeconds)); LStream := TMemoryStream.Create; LStream.Size := (LOOP_MAX * LDataLength) + 1000; LStopWatch := TStopWatch.StartNew; try LStopWatch := TStopWatch.StartNew; for I := 1 to LOOP_MAX do LStream.Write(DATA[1], LDataLength); LStopWatch.Stop; finally LStream.Free; end; Memo1.Lines.Add('Preallocation: ' + FormatFloat('0.000s', LStopWatch.Elapsed.TotalSeconds)); end; No preallocation: 1,150s Preallocation: 0,647s Nice speedup, prosentually, but time saved in real world situation is very small. So no point of optimizing this, in my current case. This way. Maybe my mary failed me, and my original optimizations where pre FastMM times. or I just looked how many percent faster it was 😉 Or both.... -Tee-

For sure. My experience is that if you write lot of stuff to to stream, and if there is lot of reallocation, it'll be quite slow. Need to measure this for sure, before commit into anything. All I know i've used buffered stream to speed up very close to same situation now. I just remember that some parts of the code got way faster, and overall saw significant speedup. I think this comes down to how much data is written and how small pieces and so on, in other words, how many reallocations will happen in real world. I think I logged the final stream sizes for a day (it was an server which made Xml files) and used Stetson-Harris method to pic some nice size for initial allocation size, and adjusted growth strategy to get some kind of balance and not to allocate way too large buffers. Concatenating strings on FastMM is fast, but still I managed to make nice speedup back then. It is quite easy to make Buffered stream, but testing and handling all possible corner cases you first miss... That is why I am asking if there is good implementation that I could test, does it make sense or not (in this case) 🙂 -Tee-