views:

358

answers:

4

We've got this large application written in Delphi 5, and development is ongoing to this day. There is research going on into migrating to newer versions, but so far there is no success, as some 3rd party components have not been updated in ages and do not work on later versions.

In the meantime however people need to continue work on it. Now Delphi 5 IDE is no real treat. It's pretty bug-ridden and lacks a lot of features of contemporary IDEs which makes it difficult to use. Especially when it comes to debugging.

So I was wondering - would it be possible to use Visual Studio in the process? As far as I know the .PDB file format is pretty old and is well documented. Could it be possible to make the Delphi compiler to somehow generate a .PDB files for it's compiled results? Then the program could be debugged with Visual Studio, possibly to a much greater extent than in the original IDE.

Well, the absolute Holy Grail would be to move all development to VS, just keeping the compiler from Delphi, but I imagine that would be pretty impossible.

A: 

Apparently you can't. Seems that PDB is after all a propieritary Microsoft format without documentation, and as such there are no other tools generating it. Pity. :(

Vilx-
Agreed. This is extremely frustrating to many tool vendors, not just us on the RAD Studio team. Maybe MS should support the Turbo Debugger format which is actually documented and we even provide a library to read them. :-).
Allen Bauer
+5  A: 

No, and neither can any other version of Delphi. You can use Map2Dgb to turn a detailed map file into a dbg file, though, and you can use that in WinDbg.

I'm curious what debugging features you're expecting to use in Visual Studio that aren't in Delphi 5 and that also don't rely on the IDE understanding the Delphi language. I was always rather pleased with Delphi 5.

Rob Kennedy
The inspector feature in the debugger often does not show values of different objects (especially in COM world). Sometimes the results are mind-boggling and do not at all depict what is happening in reality. I should also note that the project is both huge and messy, being something like 15 years old. There are...things...living in there. The compiler struggles.
Vilx-
I know that more recent Delphi debuggers are much better in that respect.
Jeroen Pluimers
Delphi's debugger can't load minidumps, can it? Minidumps are EXTREMELY useful. Your process crashes, freezes or misbehaves on the customer's machine? Get a minidump, load it, and you're in the debugger as if you're debugging that process. (Of course you can't do anything except examine call stacks and variables.)
CyberShadow
Delphi doesn't load any Microsoft debugging formats.
Rob Kennedy
A: 

I would recommend moving to a later version of Delphi. We have done this with various applications for clients. Moving to a newer version of Delphi is normally straightforward, but there were issues moving from D5 to D6 due to changes in the way components were handled (design time code being separated from run time) and the change to Unicode in D2009 was a bigger change.

The main thing is to sort out the third party components. We only ever use third party components that come with source so if the worst happens and the vendor disappears, we can still work on the components ourselves.

Which components are causing the issues?

dcraggs
I told you - I don't know. I just know that it's a big problem that they haven't been able to solve for now (and they've spent quite a bit of effort on it).
Vilx-
Sorry - missed your comment above. Too eager to post :-)
dcraggs
Is ok. Happens. :)
Vilx-
A: 

BTW, you can vote for this feature here.

Note, that VS-compatitible debug info will be useful not only for debugging application (I agree: it's better to use Delphi), but it will be useful for using tools like Process Explorer. For example, Process Explorer may be able to show human-readable call stack, instead of RAW numbers.

Alexander
Nice, but I needed it for Delphi 5. I don't think they are going to upgrade THAT. ;)
Vilx-