David Heffernan

Lots of us deal with legacy code. After all, we are Delphi developers.

Deadlocks are perfectly possible in this scenario. The fact that you talk about the likelihood of deadlocks is frightening. I really don't get such a defeatist approach.

@Lars Fosdal you can't have a deadlock with only a single recursive lock. I think that was mentioned earlier in the thread.

Start by following a tutorial on how to create a dll and export a simple function. Work up from there.

Build the dcus into a dll and link to that. You can't use packages because you can only link packages that were compiled with the same compiler. That's a short term solution. Long term you should replace the library.

If you use the right techniques then it is perfectly possible to achieve write software that won't deadlock.

You can't deadlock with a single lock, so long as the lock is recursive. These blanket statements are not helpful.

That's because your design was broken, not that per field locks are inherently a problem. What matters is the algorithm, and having a deep understanding of the issues. Superficial rules like the one you gave do harm in my view. Data needs to be aligned. That's really the key point.

Not sure I agree with this sweeping statement. Can you provide a rationale for that statement? I don't think that thread safety can be boiled down to rules like this.

It's just an artifact of the debugger visualiser. You are seeing some octal representations. The values are fine. As others have told you already. Your real problem is the misuse of strings to perform binary operations.

It's not possible to run most of the code you presented as it doesn't compile. As for my points regarding encryption and text/bytes, those points don't require any code to be run. Please feel free to ignore my advice if you feel I am wrong.

If you are working with AES encryption then the entire topic is moot because you should not be using text at all. Your entire code should operate on bytes.

https://stackoverflow.com/questions/56724326/find-longest-utf-8-sequence-without-breaking-multi-byte-sequences Self synchronisation is the keyword. Once you understand that then the code will emerge.

Everything is fine here. No bug in Delphi. However, your code that performs xor on character ordinal values and pushes the output back into strings is defective.

That code is completely different from the original post, which did not compile. The new code doesn't compile either. The code can't do anything useful because you will generate strings that are invalid with respect to their encoding. What are you actually trying to do here? It's hard to get enthused for an algorithm that is so clearly flawed.

What is this code meant to be doing? As presented here it won't compile: C := Byte(S xor T); You can't use xor with pointers. If you are hoping to perform bytewise xor on a UTF8 buffer and then interpret that as a string, that won't work. You can't guarantee that the output will be valid in any text encoding. You talk about operations on Char, but you aren't using Char. Char is a UTF-16 character element. You are (I think) attempting to operate on bytes. It's pointless to call SetLength to allocate a string S and then write S := because the first string you allocated is just thrown away. Each of your calls to SetLength is pointless and can be removed without changing the meaning of the program. Your for loop doesn't increment the pointers, and doesn't refer to the loop variable. That can't be right. You have a smiley face emoji in your code. Is that meant to be a variable named D? I guess you need to make sure that the code that you paste is correct. I recommend that you produce a complete program that you verify compiles, that produces the output you describe, and that you reproduce faithfully here.

Of course it is just an interface to the system task scheduler service.

API

Eventually when you discover all the flaws in your solution you'll come back to using the system scheduler.

Why don't you use the system scheduler?

It allows the system loader to take decisions at the time it starts up the process and before any code of the process executes. For instance, it allows the loader to make decisions about how to resolve dependencies (assemblies). Those decisions need to be made by the loader because implicit load time dependencies are resolved by the loader. There are many other things that are influenced by settings in the manifest. You can find out what they are by reading the documentation.

I can't see your rc file. Can you include it.

What is in the rc file?

The language documentation is pretty good. I'm sure you could read that and be up to speed.

Why? You mean the choice between nil and Default(T) as the result of Default(Nullable<T>)? In C# the default value is nil.