aehimself

Nice article, it's always good to learn something new! What I meant is that - according to what you said - "No attack happens before a ping". I translated that as - if there's no reply, most hackers won't even bother with other ports as they will consider the target unreachable. Know about it but never got further than installing it. When I had some free time I really wanted to do a scan of my home network to see what can be improved from security perspective. Now we are talking! This looks absolutely terrific and terrifying at the same time. Just like human presence on the Internet. People can always know more about you than you want them to, especially if they know where to look! I am a bit afraid of these stuff. I mean, real hacks were performed with Metasploit, it just sounds too "dark web"-ish just to satisfy one's childish interest in the topic. Ethical hacking is still hacking and noone will know your purpose once you start collecting tools to fool around. I guess I'll have an other look on Kali Linux. That seems to be a more... ethical choice for someone like me 🙂 Anyway thank you for the resources. It's not only a hint on how to make our environment safer but what protection we can or should implement in the software we write! P.s.: it just hit me.... isn't metasploit a part of Kali...?

Indeed. From C#, the only things I'd like to have in Delphi are: - Changing code while debugging (I know, possible because of JIT in .NET, so not going to happen but still, it's really-really useful) - Faster and more precise error insight and code completion (although, I regularly have to use my script to delete .vs folders because it goes nuts...) - Linq - Ternary operators I can live without everything else.

No. Git bash is just an alternate shell to cmd with Linux-like commands. Yo can run git from your old and rusty cmd directly (ShellExecute / CreateProcess from Delphi) and it will work just as good as from Git Bash. I have a .cmd file to check all of my local git repositories and if there is an update upstream it pull-rebases all local branches, taking care of automatic stashing if necessary - it only stops for merge conflicts. Just double-click it and everything is as fresh as they are on their official repository.

Yep, that was exactly my idea when I made the shots about .Read and .Extract and I saw that they can output to TBytes directly... 🙂

I'm not ignoring it but I doubt I'll change my coding style because of this. It's all a matter of personal taste... and while nil-ing a local variable is indeed useless right before exiting a method... I already got used to it and the overhead is negligible.

Kind of a habit, I'm always using FreeAndNil. At least If Assigned(something) works properly 🙂

I'm using this helper method to unzip the first file from a Base64 encoded string: Function UnzipBase64(inEncodedString: String): TBytes; Var ms: TMemoryStream; tb: TBytes; zip: TZipFile; zipstream: TStream; header: TZipHeader; Begin ms := TMemoryStream.Create; Try tb := TNetEncoding.Base64.DecodeStringToBytes(inEncodedString); ms.Write(tb, Length(tb)); ms.Position := 0; zip := TZipFile.Create; Try zip.Open(ms, zmRead); If zip.FileCount = 0 Then Raise Exception.Create('ZIP file is valid, but it does not contain any files!'); zipstream := nil; zip.Read(0, zipstream, header); Try zip.Close; SetLength(Result, zipstream.Size); zipstream.Read(Result, zipstream.Size); Finally FreeAndNil(zipstream); End; Finally FreeAndNil(zip); End; Finally FreeAndNil(ms); End; End; Could be shortened as far as I see, but it shows what you want. Open a zip file from stream, and extract a file from it to an other stream.

Do you mean Zip64? "The original .ZIP format had a 4 GiB (232 bytes) limit on various things (uncompressed size of a file, compressed size of a file, and total size of the archive), as well as a limit of 65,535 (216) entries in a ZIP archive. In version 4.5 of the specification (which is not the same as v4.5 of any particular tool), PKWARE introduced the "ZIP64" format extensions to get around these limitations, increasing the limits to 16 EiB (264 bytes)."

I'd kill for those, they are truly a missing feature.

It does: However - as I mentioned - Delphi's TZIPFile still has it's limitations which ZipForge for example overcame already. This includes but (possibly) not limited to LZMA compression, proper Zip64 support and replacing one file inside the ZIP archive.

I'd choose SynEdit. Supports syntax highlighting, code folding and even completion. I made my own SQL syntax highlighter based on a TRichEdit component but it seriously started to lag when the script was around 3000 lines (full parsing and recoloring needed 300 ms, which is way too noticeable when it runs after each keypress...). Although I could have optimized the logic (move parsing to a BG thread, only recolor when a closer was entered, only parse changed lines, etc) I just pulled SynEdit from GitHub and I'm very happy with it ever since. I don't like having a full package installed in my IDE for one project only, but seeing how smooth and fluid that implementation is compared to mine... well, it will stay forever, I suppose 🙂

Yes, I phrased myself incorrectly. I am pretty damn sure it would cause havoc now, after these many years. What I meant in the beginning to fix it [...], thanks for pointing that out. All I know is I had an imagination on how things should work and an urgent bug to fix. Caused me a serious headache. I'm sorry if I offended anyone by calling Earl a bug 🙂

It makes no sense, especially if a compiler directive instructs otherwise. My guess is that there is some badly written structure behind the scenes and it would be too much effort to "fix" it now. This is typically when we start to name our bugs, celebrate their birthday, call them a feature and see where they evolve to 🙂

BRCC32? 🙂 Seriously, though. I have a batch script which crawls through a directory structure and creates a .RC file based on what it finds. As a final step it launches BRCC32 thisfile.rc and deletes the unnecessary .RC file. Works like a charm.

http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devcommon/expressions_xml.html "Note: If either operand involves a Variant, the compiler always performs complete evaluation (even in the {$B} state)." It's a feature.

I pushed Opens to a background thread and the UI froze at the first .RecordCount call. The solution was to add .Fetch after .Open in the worker, and the scrollbar still had only 3 positions. I manually had to handle the WM_SCROLL message and had a custom UpdateScrollBar which called SetScrollInfo. Some of this code might be obsolete already if DBGrid got an update since 10-10.1... never really checked.

Introduce a Variant in the check. I was hitting my head for days when I finally found out that Delphi always evaluates a boolean fully, if a variant comparison is present.

Sounds like a backdoor. If the code is already running on your system, it can do anything as most of us have UAC turned off I presume. This is one more thing very charming about Linux. To be honest, Delphi IDE and my VCL applications are the ones keeping me on Windows. No virtualbox, no home-devserver in my case would catch up with the speed I desire. I almost had Delphi 10.2 running with Wine. Basic "Memo1.Lines.Add" things worked, but anything more complicated made everything go boom 😞

Sligthly offtopic. Really? Never heard of this "pattern" so far. Also seems a bit strange. Most of the network devices block ICMP requests by default, aborting all malicious attempt. Or am I missing something? P.s.: This question lacks sarcasm, irony and whatsoever. I am genuinely interested in this topic but my knowledge is limited, unfortunately.

I decided to use Delphi's own TDBGrid for one of my projects; I personally don't like installing a full 3rd party suite for a single component if I can just fix the built-in up... Long story short, I did exactly what @Lars Fosdal advised - just added the very same Unicode character to the TField's displayname (I think that's the property...?). No complaints from users, they all like it. I don't use the standard grid, but as TDBGrid descends from it I suppose it's very, very, very limited too. The only reason I don't break out of my comfort zone and look for a cheap alternative is that I managed to fix most of the inconveniences already. If I'd go back in time I'd slap myself a couple of times not even to start with it. It was just waaaaay too much effort 😞 P.s.: my favorite "feature" is that the vertical progress bar had 3 positions: first record is active: topmost. Last record is active: downmost. Everything else inbetween - progress bar is at 50%. I seen no other component with this "design" yet.

Did TZipFile ever got a proper update? Although it's good to have something built in, https://github.com/ccy/delphi-zip adds LZMA and probably ZIP64 support. I myself forked that too to fix a memory leak and make it open some corrupted ZIP files too. I wonder if I can drop Zip2 in my projects and to use the built-in version again.

A long time ago I wrote an application where I was forced to push specific long-running operations into background threads to keep the UI responsive. Stupidly enough, each method wrapper kept the control away from the VCL thread and returned only when the background process finished. This was a quick and dirty solution so not much of the code had to be changed. For example: myclass := TMyClass.Create; // Setup myclass // Instead of myclass.DoWork, now it looks like this: WorkWithBackgroundThread(myclass); // Get the results out of myclass FreeAndNil(myclass); Where in WorkWithBackgroundThread lies the evil: workthread := TWorkThread.Create; // setup workthread workthread.Start; While Not workthread.Finished Do Begin Application.ProcessMessages; Sleep(10); End; This worked for a while, up until I updated a component the application is using and now it started to throw invalid pointer operations. Long story short, the execution pointer / counter jumps in-and-out of different methods called by window messages, corrupting some Strings in the process (in the debugger the value quickly changes to "inaccessible value") so yeah... I am thinking on re-writing the whole thing to be event driven, but unfortunately far too many logic already depend on not receiving the control back. Is there a way doing something like this in modern Delphi (10.2+) ? I noticed that now we have a System.Threading unit with some task implementations, but ITask.Wait also blocks the caller thread (and this unit does not have a high reputation as far as comments went). The other bad thing about these implementations is exceptions and freeing an object up: Var sl: TStringList; x: ITask; begin sl := TStringList.Create; Try Try x := TTask.Create(Procedure Begin Sleep(10000); sl.Add('eeeee'); End); task.Start; // task.Wait; // will cause the UI to hang up Except On E:Exception Do ShowMessage(E.Message); End; Finally FreeAndNil(sl); End; Which will throw a nice and cozy nullpointer exception and is not getting caught in the except block... see my issue I suppose. So my question is: is there an easier salvation for me rather than the full refactor? I'd prefer not to use any 3rd party libraries to keep external dependency as low as possible.

The UI is a simple tabbed interface. One tab can be "blocked" (by disabling all buttons and actions when a BG operation starts; re-enabled when ends) but the others (and with that - the whole UI) must stay unblocked. Furthermore, a nice spinning loading indicator with a "Cancel" button looks and feels more "professional" than a frozen, whitened form what you only can close with the task manager. Edit: As I already took a shortcut with the While xx Do Application.ProcessMessages method and seeing where it lead to - I am already in the process of rewriting the whole "action" logic to pure event based. It's a nightmare. To any future reader: don't be like me. Write your code clean, so you have to write it only once 🙂

I can double on both. I started to learn Git on the very same tutorials and they are indeed very informative and easy to understand. And yeah, those tools... 🙂

I'm completely new to System.Threading (I was told it exists today by one of my colleagues) and always used TThread descendants until now. I'll see what exactly this method does; thank you for the suggestion! The main purpose of this change is to get rid of the Application.ProcessMessages call in a loop, so this is not an option unfortunately.