David Heffernan

This is a good example of why making a clean reproduction of an issue is such a useful discipline.

You can implement a helper the way you expect, but mutating methods on value types is troublesome. Imagine passing such a type as a const param and then calling such a method. Because Delphi lacks const methods (as found in C++), such things cause havoc.

I've not ever looked at this function but it's not hard to see what must be going on. There is no 4 byte string type. So you'll be getting a dynamic array back. And there will be a null terminator as there is for all non short string types. But since there is no compiler support for treating the type as a string, you just get the dyn array length function, which counts the null terminator.

I don't see how any of that impacts a unit testing library. I wouldn't describe that as unit testing. My take is that the if we had a single language then a well written library would naturally be cross platform. But Dalija is right, there are two languages, ARC and non ARC. And you are also right about the runners. If you expect GUI then they could require distinct UI.

Ugh. How could I have forgotten that Delphi is actually two different languages.

Yeah, I know what cross platform means. What would be platform specific about a unit testing library?

Surely all the widely know unit testing libraries are cross platform.

GetSystemMetrics is from Winapi.Windows. Use a find in files search of the rtl/vcl source to find which unit contains specific functions.

Doesn't seem very plausible that this is the case. And it's tricky for us to dig deeper into "one reason or another".

Given that you weren't aware of using, it seems that you may not be fluent and experienced with C++. Are you sure you are best placed to be offering critiques of the language? Certainly my experience of using local variables in C++ differs greatly from yours. It is incredibly valuable in my experience to declare local variables at the point of use and with a narrow scope.

The example here is of WH_MSGFILTER which I don't think does injection.

Inject code into every process

C++ already has using

What you are trying to do is possible. I guess there is just a mistake somewhere, or some extra detail that we don't know of yet.

graphics32 is generally faster than gdi I believe

Or a pure Pascal library like graphics32

I would have imagined that you'd want some coordination, not everybody having their own copies, all different. Also, git in particular, and dvcs in general are very complex. You sure you want to throw that at your users. But hey, what do I know about your needs. Nothing. If you want to use git then go ahead. For instance with libgit2.

Doesn't sound very much like dvcs is what you need. Sounds more like a central database is what you need.

Probably you'll need to show an complete program, obviously cut down to minimal form, if you want somebody to dig deeper.

Why would you be drawn to Embarcadero C++ tools? If you are going to consider C++ then you have a much wider range of options.

Lars understands that, I think, and wonders why the compiler doesn't take the same view and issue a warning.

That's not right. In order to evaluate expressions the debugger needs to execute code in the target process. Which may lead to allocations. It's a defect that the IDE / debugger leak such objects, but they can't do their job if they can't execute code and perform allocations in the target process.

This is a known bug in the IDE / debugger. Nothing you can do about it. Evaluating certain expressions, often involving strings, seems to be what triggers it.

This is why you should make a repro. Worth bearing that in mind for the future.

Encryption is agnostic of framework. I don't see how you could have a VCL only encryption library. You don't need design time components.