David Heffernan

https://superuser.com/questions/1163753/converting-text-file-to-utf-8-on-windows-command-prompt

And to think that the question was meant to be about ethics.

What can of worms? It has always been easy enough for me. And clearly we do have a dproj in this instance.

That might make it compile, but you'll also need to specify any other options that are non-default. And then update the code that invokes compilation any time you make a change to the project config being compiled. Why not let msbuild do it for you?

As a programmer, you are aware of the issues around invalid data, missing data, etc. The client who provides the specification is often less aware of these issues, and their consequences. In terms of ethics, I would say that as a programmer it is your responsibility to raise the issue with the client. That's part of being a good professional. How the client responds to that is down to them. If they insist on ignoring invalid data, then that is their choice. But you should strongly advise them against that, and if they do insist, then document that this was their choice. In your case it sounds like the ultimate client is not being advised of this, and the culture in your organisation is to do what the client asks without questioning it. That's a slightly different problem. If the decision takers in your organisation are not receptive to best professional practise then there's only so much you can do.

Using msbuild is the simple way to get this done.

Shouldn't you be using msbuild? That's how you make sure that you get all the project settings. Otherwise you have to manually convert all the project settings into the dcc32 arguments. The msbuild rules do all that for you.

These decisions depend very heavily on what type of coding you are doing. In my case it's a numerical code, whose bottlenecks are floating point calculations. So runtime performance is highly important, and Delphi is very poor in this regard. My working assumption is that C++ would be the right choice, at least for the numerical part of the code. But if and when we come to migrate then I'd need to spend a lot of time evaluating options, and I'd look beyond C++ too. This is not to say that I am a big fan of C++.

Yes. Same argument applies. I use delphi because I have a huge code base written in Delphi. If I was starting from scratch I would categorically not use delphi.

Yes. Same argument applies.

Fossil would be a weird choice. Regardless of how good it is, it's not widespread. git is everywhere, and has so much tooling and resources available. Very hard to see past it.

This __imp_ mangling, IIRC, is used by ms tools when linking using a import lib. Delphi links to DLLs in a different way. Not sure if the difference is important. If it were me I'd compile each source file individually using cl and then link those. Although I don't like to do that very much. It's tempting to be able to link objects statically. But it's fraught with difficulties. It's fiddly. And under x64 you have a further problem. The Delphi compiler doesn't respect the meta data in the object file describing the exception tables. So if exceptions are raised in the linked C code, then it's common for the process to be terminated forcefully. These days I always prefer to link to DLLs using an sxs assembly to avoid problems with dll search paths.

How did you compile the C code?

As for backups with git you can use a cloud repo in addition to any local ones to give you extra redundancy.

The revision control comments are on topic. Revision control is a key part of how you develop new features in an existing code base.

Every effective programmer understands the value of revision control

You only feel the need to develop in such an isolated fashion because you don't use revision control. If you had revision control you'd branch and develop your feature. You'd run your existing tests to prove that you had not damaged existing code. Why do you resist using revision control? It will make you far more productive and effective.

You should drop everything and fix this. I'm sure we've told you this before. We were right then, we are right now.

"with as do" is not a thing in its own right. There is with (expr) do. And here we see as used in an expression. We are just composing different aspects of the language.

LSP isn't about changing the language warning definitions. Never give up hope is a strange message. Keep hoping if that hope is justified.

All problems relating to with could be solved by the compiler warning about such collisions.

More clarity in the question. Full details of error, and a minimal reproduction. And don't post criticism for not receiving a response immediately. That does not motivate people.

Given that so much that is actually important is broken, this should be way down the list of priorities.

Not sure this approach is helpful.

No I don't think it does make them managed records. I don't really understand how such simple code could break the compiler. It's as if Embarcadero don't have comprehensive tests in place.