David Heffernan

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

30 minutes ago, Lars Fosdal said:

My apologies for being unclear: One crit sec per object instance, with separate locking per object field. Return to previous description. 

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. 

2 hours ago, Lars Fosdal said:

Naturally, it is a simplification and doesn't apply to every context, but we used to have lots of micro locking, and lots of lock failures.  

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. 

2 hours ago, Lars Fosdal said:

Straight assignments are atomic, unless they involve logic or reallocation.

Data needs to be aligned. That's really the key point. 

55 minutes ago, Lars Fosdal said:

Never do locking on a per field basis - unless you have one critical section per field.

Otherwise, always lock the entire object

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.

5 minutes ago, Fr0sT.Brutal said:

Do you mean some API functions or taskschd.msc?

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. 

51 minutes ago, Mark- said:

Hello,

 

Thanks for the response.

 

I added in the first post, the error is on the first line.

 

Every example I could find on the web, in many formats.

I could not find a single working example.

 

Mark

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. 

2 hours ago, Lars Fosdal said:

This is going to get interesting if we get nullable generic types.  

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