Jump to content

omnibrain

Members
  • Content Count

    53
  • Joined

  • Last visited

Community Reputation

6 Neutral

Technical Information

  • Delphi-Version
    Delphi 11 Alexandria

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. omnibrain

    ICS V8.70 announced

    Thanks for the clarification. I misunderstood what you want to do with the new server component then. I currently use THttpAppSrv and I'm curious what your future developments are going to offer.
  2. omnibrain

    ICS V8.70 announced

    I would really like to continue to be able to use webservers without SSL/TLS for several reasons: In a more complex setup ssl gets offloaded from the application servers to load balancers, reverse proxies or web application gateways modern reverse proxies like caddy are ridiculously easy to use and just work with ACME certificates (or self signed) with almost zero config, it's not even funny it's usually easier to update a reverse proxy/load balancer or WAG for new openSSL versions than the applications itself webservers embedded into the application, bound only to localhost, don't need ssl/tls (for internal APIs) it's easier during development if you don't have to wrangle self signed certs and browser errors But I don't care if the ssl/tls code get's compiled into the program or not. I just want to be able to use a server without SSL/TLS.
  3. omnibrain

    Looking for a localization tool

    Ah, did not know that. Is there a way to convert our 100+ existing DFMs?
  4. Sure, but coming from Java and .Net it's just a basic language feature missing. Maybe it's easier to implement if everything runs in a VM...
  5. As suspected unsave byte/char handling. We converted the offending parts to TByte now. But it was also a problem because the code expected a byte converting to an integer value, but the message could have had legit anything else at this point. The trigger was an unusual message. Once we had a trace we could recreate it with our test hardware and it was obvious. The exception was many calls deep into the processing code and got only caught on the top of the call stack so we would have probably taken a few more days to really find this part. Perhaps we should add something like MadExcept. It's a shame that Delphi offers no inbuilt StackTrace at runtime.
  6. Good news everybody, we got a trace and it looks like we can provoke this issue with our test hardware.
  7. They should keep their "value". It could for example be the "length field" and $A9 for the 3rd byte/char received would mean that we have to work with the next 169 characters, the 171st char/byte received would then be a checksum over all bytes/chars received, which could be $F3 for example. It could very well be that it has been broken forever, but we processed millions of "messages" per month and never had this problem. But like I said, I can't totally rule out, that we just never received such a message before. It could be just a single character causing this trouble by getting converted and only in few positions it would cause (visible) trouble. Today we traced all the "messages" at a customer, but of course it did not happen. Tomorrow I'm going to add additional logging code, so we pinpoint closer where the exception happens and then we should know what the "wrong data" is.
  8. The value can be basically anything from $01 to $ff. It's serial communication with various protocols. Some text based, some byte based and some of them a mix of both. Some of them are delimited by EOT ($04), for some we need to calculate the lengths, for some we need to calculate CRCs, etc. Not all in the same process, but the pattern ist the same for all of them and the tfr_com.dataavail ist the same. The serial communications components provides ansichars. And we don't expect to receive multi byte characters via serial communications anyway. We communicate with old hardware, with old protocols. Most of the time there is no encoding specified, but for the text parts (if there are some) most of the times just plain ascii characters are used.
  9. I tried to condense the code: procedure tfr_com.dataavail(sender:TObject; Count:integer); var i : word; c : char; // serielles zeichen empfangen ac : ansichar; s : string; begin for i:=1 to count do if com.ReadChar(ac) then begin c:=char(ac); {$R-} showinchar(c); if assigned(receivecharproc) then receivecharproc(c); {$R+} end; end; //receivecharproc is procedure tfi_m.receivechar(ach:char); begin //state machine that works with the chars to parse the various protocols and adds them to a string typed variable for further processing end; ReadChar provides us ansichars, so I guess it's easiest just to stay with ansichars for further processing. But why did it work for 10 years and suddenly stopped? I can't rule out, that we see a new type of input we haven't seen before. But I still have no trace of what we actually receive...
  10. omnibrain

    Turbopower Visual Planit??

    Are you going to put it on github?
  11. Yeah, me neither. That's why I ask in general terms. Like if someone asked if anything with pointers and DLLs has changed in the latest release. Then we would answer "of course, ASLR and HE-ASLR is enabled by default. Look into the linker options." I hope for something like that. I suspect the code has been broken since the unicode migration and now some (undefined?) behaviour in edge cases may have changed. I'm afraid I won't be able to avoid reworking it, into proper datatypes for stuff received via serial connection. (A proper mix between raw byte protocols, text protocols and protocols that mix both). The discussion in Best type for data buffer: TBytes, RawByteString, String, AnsiString, ... - Algorithms, Data Structures and Class Design - Delphi-PRAXiS [en] (delphipraxis.net) goes into a similar direction, thoguh starting at another angle.
  12. "transliteration" is a good word. My gut feeling is, that we receive some byte value that translates to a char, that get's "transliteraded" to a unicode glyph and when we try to work with the byte value again we get the value of the unicode glyph. Yes, I'm currently thinking about converting everything to ansichars and ansistrings, or even rawbytestrings, or possible TBytes (though we depend heavily on pos() for protocol parsing). But it may very well be, that I'm chasing ghosts. So if someone could chime up and say "yes, something really changed", that would give me confidence. ?
  13. Are there any (known) changes to the compiler regarding string handling from Delphi 10.2 (or 11.0)to 11.2? I don't have code, because I can't reproduce it yet, it's more of a feeling, that something is wrong. We do a lot of serial communication. Parts of the code are rather old, but survived man Delphi version changes. Some of the code may be pre-Unicode but got modernized before my time and thus before source control, so I can't check the history. We read the ansichars that come via the serial connection and put them into chars and them into strings and work from there. I think that's not ideal because strings are unicode (nowadays) but so far it worked fine. Recently we switched from Delphi 10.2 to 11.2 (with a short stint in 11.0, but I'm only 80% sure the error wasn't there). And now it only works like 99.9% of the time. (With our test systems everything works, but our customers have more "traffic). The error is, that we get symbols we can't explain in positions where they don't belong. It looks like chars get converted to other hex values. At the moment I'm just poking around, because the error is rare enough and we don't have a trace yet. But perhaps someone knows of a possible change to string/char handling with the most recent compiler versions.
  14. Can you show a bit more code? How do you setup the stream? Perhaps you need to (re)set the position of the stream to 0 before sending.
  15. omnibrain

    CodeInsight: Loading project [...] hanging

    Thanks, but it looks like that the classic version is gone from 11.2.
×