The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
It's funny because everyone one of us who've experienced code conversion are all just like, "Well, yes, but I wish I didn't have that experience." It's just old wounds to think about now. Nothing else.
I must say that I find Delphi a bit too costly, but there's Lazarus as an open source alternative, the interesting thing is that you can develop cross-platform applications with it and it has a forms designer (seems a rarity nowadays).
Yup. The one person I know who does Delphi gets paid well above the market rate, to the extent that he can't afford to bail for a newer platform, for being one of 8(? unless there's another user than his employer) people in his city who still use the stuff. The gotcha is that the lack of any plan B that'd sustain his current lifestyle if his current employer ever goes under is a huge stressor.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
Place I used to work at used such tools twice. Once from [insert obscure language I forget the name of] to VB.NET, and then from VB to C#.
I wasn't there when it took place, but from what I heard (and saw in the code) results were mixed.
The resulting code would most of the time compile, and also most of the time do mostly what it was supposed to do (although some debugging was required), but the big problem was the readability and maintainability of the code.
It would use almost none of the specific language features (probably because it would make conversion a lot more complex), ignore best practices, make variables global that didn't need to be, and all kinds of headaches ranging in size from minor annoyance to "I swear to god I will set fire to my computer".
To be fair, that took place around 15 or more years ago, so maybe there are better converters today, but I doubt it.
At best, it's a start point from where you can develop the new version. Depending on size and complexity of your code base and requirements, it might be faster, cheaper and more future proof to redo the system from scratch in your tech stack of choice, rather than try and convert the existing code base.
Before you do anything else I'd recommend P2V'ing the physical box into a virtual machine - so if it fails you can still work on the code. Personally I use VM's for all my development environments now - going back to Visual Studio 6 - so if I ever have to revisit some old bit of code I just spin up the old VM and the project is usually still in the MRU list. Many of the old VM's are XP but you can generally just stop them having internet access so they are pretty safe especially if only spun up on demand.
We did a project for machine translation of a large software system originally written in Pascal into a proprietary systems language (in the Pascal/Algol class, but with a number of syntax differences and a number of added features).
The primary reason for doing this was to protect the system from theft: If some competitor got hold of the source code, the effort of utilizing it (i.e. translating it into some other language) would hopefully be so high that it would be considered not worth it.
Our conclusion after completion of the work was quite clear: We would have saved a lot of effort if we had placed a printout of the original Pascal code in the manuscript holder and manually typed in the translation line by line.
The auto-translator had no clue about the semantics of the code. Whenever it was in doubt, it generated new variables, labels and other constructs. For all practical purposes, all comments were ruined - they were there, but often misplaced because the original composite statement had been broken into pieces and reassembled in a different way; if the translator couldn't decide where to attach the comment, it was put at the bottom of the function. Obviously, the translator didn't make use of the extensions of the target language, as there was nothing in the input calling for these facilities...
Cleaning up the result was a tedious chore, and for a long time, there were still traces of the translator's bad semantic understanding of the application semantics. We could have used the translator for subsequent projects, but we never did. We saved work by doing it by hand.
We could have spent effort in trying to improve the translator. If there were a thousand projects waiting to be translated, it might have been worth it, but there was not, and we were already sick of it after the first job it had done - and the job it crated for us in cleaning up.
I use them daily and am writing one. They depend greatly on the power and flexibility of target language. Most do a terrible job at preserving comments and don’t try and do well on simple code. The better ones give up when they find something they don’t understand or do a partial translation leaving the original code as a comment. The bad ones just translate to garbage that will not compile. On evolving languages like C# translators have trouble keeping up. On dead languages they are usually very good and going to C# is a plus since it is very powerful and has many features you need.
Which version of Delphi are you using?
What 3rd party controls are tying it down to XP SP2?
How big is the application? Database requirements?
Generally code converters do not do well with 3rd party controls & you need somebody that understands the Delphi environment and C# that you are converting it to.