aehimself

Actually no, compression is not performed in the project in which this class was used. Data packet is a JSON object which gets serialized and encrypted... size is usually between 80-140 bytes, which only increases after compression. The reason I didn't include a version in the header is the packet itself: if a new version adds a new field this easily can be detected during deserialization. I know the code is not completely universal. I kept it as simple as possible to do it's job in this context and nothing more - keeping the logic easy to read and understand. If your packets are usually larger than 64k, it's enough to change TPacketLength = UInt64; for example, the rest of the code should take care about this automatically. P.s.: I just read your first answer again and realized that I'm indeed copying an Integer in a TPacketLength which is definitely not right! I'll fix this and move the size check from my program to this class so I can reupload. I should also mention the size limit in the "Keep in mind" section I assume 🙂 P.s.p.s.: There was a network loss between just the other day and about 90k of buffer was received by the server upon reestablishment containing a number of ~140 byte packets. The code worked flawlessly, separated and processed each of these without errors. So yeah, I'm happy 🙂

Appending the length is included in the class method TBinaryPacket.AppendSize(Var inData: TBytes); As for the size limit I do have a check but it's in the sending method of my client application. You are absolutely right, it makes more sense here though! // If the buffer exceeds the maximum length allowed, raise an error as it can not be sent! If Length(buf) > TPacketLength.MaxValue Then Raise ETCPPortError.Create('Buffer overflow, cannot send ' + Length(buf).ToString + ' bytes!'); I personally have no experience with different byte order systems... You mean some systems (OSes..?) store a word like LLHH and an other like HHLL? I always thought that it's language dependent. In this case yes, the code is not ready for it yet. It can be achieved by adding one more byte to the beginning... 0 if sender is a LLHH system, 1 if sender is a HHLL system. The receiving part then can decide if we need to switch the order upon reading a packet out. Thank you for this input! Although I used this code to send and receive data from Windows to Windows it's always good to know that there are cases which I have to consider before using it in a future cross-platform project.

MemoryStream, BytesStream, you can even use a FileStream if you feel like it. For exotic coders even a 1024*768 bitmap would do. All I meant is that it is a choke point for consideration. In my case this was more than sufficient.

Is there a chance to see an (un)official Git repository? Would make updating the component much more easy

Be careful, the above code is NOT thread safe. If you have multiple threads using the same logger you'll end up crashing said thread due to unhandled exception in the exception handler or simply corrupting your log file. It's good for single threaded applications, though. Edit: Having a second look I'd vote against this method in general. If you know you will dump everything in a file no matter what it's better to write to that file and read it back all up if you want to display it in the UI. This way you are simply wasting resources, especially if your log file grows large. Also, appending to a memo has it's performance penalty which is extremely painful if items are arriving rapidly.

Got the same result as @Kas Ob. when building a JSON object and using my custom hasher: procedure TForm1.FormCreate(Sender: TObject); Var s256: TAESHA256Hasher; tb: TBytes; json: TJSONObject; begin s256 := TAESHA256Hasher.Create; Try json := TJSONObject(TJSONObject.ParseJSONValue(Memo1.Text)); SetLength(tb, json.EstimatedByteSize); SetLength(tb, json.ToBytes(tb, 0)); tb := s256.HashOf(tb); ShowMessage(TNetEncoding.Base64.EncodeBytesToString(tb)); Finally FreeAndNil(s256); End; end; Ps: I know I'm leaking json. So either the example is wrong or they are not parsing the document as we think (I also tried removing the opening and closing braces so only the body is processed - no luck).

While digging in the depths of a legacy application I was shocked to see that a binary data received through the network is stored and handled as a String. And it works. Imagine the following code: procedure TForm1.Button1Click(Sender: TObject); Var tb: TBytes; s: String; begin tb := TFile.ReadAllBytes('C:\temp\Project1.exe'); SetLength(s, Length(tb)); Move(tb[0], s[1], Length(tb)); // If CompareMem(@tb[0], @s[1], Length(tb)) Then ShowMessage('Contents are the same'); TFile.WriteAllText('C:\temp\project2.exe', s, TEncoding.Default); end; Fails. Produces the same amount of bytes, but it doesn't work. However, just by introducing a string casting: procedure TForm1.Button1Click(Sender: TObject); Var tb: TBytes; s: String; ans: AnsiString; begin tb := TFile.ReadAllBytes('C:\temp\Project1.exe'); SetLength(ans, Length(tb)); Move(tb[0], ans[1], Length(tb)); s := String(ans); TFile.WriteAllText('C:\temp\Project2.exe', s, TEncoding.Default); end; output executable is... well, executable. My bet is on some pointer magic Delphi is doing in the background, but can someone please explain WHY this works?!

I just want to make sure my logic is correct here. I built a really simple test, see .dpr and the generated .map file attached. I used this method to extract method addresses. Stack trace was as following: $0000000000429A84 $0000000000425327 $0000000000425C1B $000000000040A5C6 $000000000040A601 $0000000000429BE5 $0000000000429C0D $0000000000429C2D $0000000000429C82 $00007FFD09E97034 $00007FFD0A7A2651 Now, from each address I substracted image base ($400000) and $1000, which resulted the following relative addresses: $28A84 $24327 $24C1B $95C6 $9601 $28BE5 $28C0D $28C2D $28C82 $7FFD09A96034 $7FFD0A3A1651 In the map file "Address - Publics by name" section I looked for the address which is the closest but below each relative address. This gives me the method names. In the map file "Line numbers for xxx" section I searched for the exact relative address. This gives me the line numbers, if any. Based on the above approach my reconstructed stack trace is the following: StackTrace.GetExceptionStackInfo ( StackTrace:44 ) System.SysUtils.Exception.RaisingException ( ??? ) System.SysUtils.ExceptHandler ( System.SysUtils:23574 ) ??? ( System.pas:22018 ) ??? ( System.pas:22108 ) Project1.Three ( Project1:14 ) Project1.Two ( Project1:19 ) Project1.One ( Project1:24 ) Project1.Project1 ( ??? ) ??? ??? It resembles what went on, but I have some missing information which I was unable to find. I have two questions... is this the way to reconstruct the call stack from a map file? And if yes, how I can find the missing information? Project1.zip

TWSocket also implements this, you can call it by WSocket1.MessagePump.

Thank. You.

Wtf...? Btw I never experienced random crashes of my applications, not one since Windows 2000. I mean of course I did, but all of them was the fault of my code, not the OS silently attempting to kill it. And I would be REALLY surprised if it was true (especially now since Embarcadero / Idera has MS links if I'm not mistaken).

We do have this combination at work. SCM is Git, client is written in Delphi, server is written in C#. Recently changed the process to use MSBuild to compile the Delphi project too. Works like a charm.

They could use this information combined with the location to show "There are redhead / brunette / etc coders in your area" popups

You are completely right, I should have answered 哦□� That should have helped the devs to find out that there is nothing wrong with their input encoding 🙂

Orly...

I had ~2 releases with DebugEngine, then I switched back to MadExcept. It's stack traces are less messed up when packed with UPX. I'd personally prefer DebugEngine as it is not installing hooks (thus - not having the issues I mentioned) getting stack traces is it's main purpose. Performance wise - you won't feel a difference tbh. None of these tools will make your application less stable or significantly slower.

I gave DebugEngine a try and it is very good. Sometimes it provides stack traces strange (method where exception happened, two inner methods of DebugEngine and then the real stack trace) but it's really easy to install and use. It is also unaffected by the two issues I have with MadExcept (TThread.FatalException and Exception.InnerException is rendered useless). It comes with a utility to attach the map (or it's own compressed smap) format to the .EXE itself, however the final executable is larger than with MadExcept (guess the .map compression is not that advanced in DebugEngine than in MadExcept). I don't have much experience with JclDebug... I tried it once, and I disliked every bit of it. Only to be able to see stack traces I had to include ~30 extra files in my project and the stack traces were not accurate.; so I gave up on it. If you can fit into the free usage conditions of MadExcept I'd say go with that. Otherwise, DebugEngine (or a license for MadExcept) would be my choice. P.s.: keep in mind that also MadExcept and DebugEngine is known to have stack issues if the .exe is packed with UPX.

This question is way too broad to be able to be answered correctly. In general, have Try..Except blocks. What you do inside the exception handler completely depends on the kind of application you are writing. If you don't want your application to crash / misbehave after an exception happened you have to make sure you "reset it to a default state". Roll back transactions, close datasets, free up objects, closing TCP connections, etc. You might want to make a note of it too for debugging purposes so write details to a log file and let your user know that something went south. It's also good to have stack traces so look into MadExcept / DebugEngine - both are really easy to install and can be used for free - with restrictions of course.

Off: leaving my like because of hMailServer 🙂

#3. You might also want to look into WebDav. That way you simply can copy the file without any additional code (what you have to maintain) on the webserver.

Thank you for the explanation, it all makes sense now. I don't really need workarounds; if this area will be touched it will be properly changed instead to use a hack-of-a-hack... Don't get me wrong - I know this should not be done because it won't work; this is why I was this surprised that it does in our case. The sole purpose of this topic was for me to understand why it does, when it should not 🙂

Update: wrong. #0s are not present. Var ss: TStringStream; s: TStream; tb: TBytes; begin ss := TStringStream.Create('Árvíztűrő tükörfúrógép'); Try s := ss; SetLength(tb, s.Size); s.Read(tb, Length(tb)); ShowMessage(TEncoding.Default.GetString(tb)); Finally FreeAndNil(ss); End; Lossy conversion as you mentioned, though.

Not most likely, it does. Was Delphi 6 or 7, way before I joined the company. I know, this is why I was really surprised that it actually works like this. We are just lucky with our locale it seems 🙂 First one was only a demonstration; I knew it won't work. I found it strange that the output byte count is the same as the input (because of the double size as you pointed out) though. Guess I was lucky with the random choice of exe. So if I get it right... we read the binary data, doubling it's size as we pad each character with a #0 during AnsiString -> String conversion? The real code is creating a TStringStream out of this and passing it as a parameter of a method, which is expecting a stream. That method will access the contents with .Seek and .Read I suppose. I didn't test this, but am I safe to assume that this would include the extra #0s, causing the binary data to be corrupted?

A long time ago I found this document, which shows the power of the .Filter property of DataSets. However it is Zeos-referenced I doubt that majority (or all) will not work on a regular dataset component. Feel free to take a look: ZeosLib - Browse /documentation at SourceForge.net and download zExpression.pdf.

Are you sure CONTAINING and STARTS are valid filter keywords? I'd try UPPER(ITEMNAME) LIKE ''' + SearchText + '''' instead.