12

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.

SamB
  • 9,039
  • 5
  • 49
  • 56
Vilx-
  • 104,512
  • 87
  • 279
  • 422
  • 1
    I really don't remember Delphi 5 as bug-ridden. Admittedly the debugging features left some wishes compared to VS. – Uli Gerhardt Oct 22 '09 at 08:52
  • I think it is more important to solve the cause, in stead of work on the symptoms: Which 3rd party components are holding you back to migrate to newer versions of Delphi? – Jeroen Wiert Pluimers Oct 22 '09 at 09:12
  • That I don't know exactly, that is not my area of work currently. But they tell that bright minds have studied it and are still working hard to find a solution. – Vilx- Oct 22 '09 at 10:16
  • Then that's your first step: getting to know why. It will make it a lot easier than getting (very limited) PDB information and going the VS route (most likely having no local variables to look at all). I have done a lot of migrations, even skipping many Delphi versions. With a methodic approach, it is a job that can be done very well. – Jeroen Wiert Pluimers Oct 22 '09 at 14:09

5 Answers5

12

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.

Martin Prikryl
  • 188,800
  • 56
  • 490
  • 992
Rob Kennedy
  • 161,384
  • 21
  • 275
  • 467
  • 2
    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- Oct 22 '09 at 10:15
  • I know that more recent Delphi debuggers are much better in that respect. – Jeroen Wiert Pluimers Oct 22 '09 at 14:07
  • 3
    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.) – Vladimir Panteleev Nov 02 '09 at 21:46
  • 3
    @Rob: that was exactly the point, right? None of the Borland/Codegear/Embarcadero compilers can generate PDB symbols and therefore Minidumps are pretty much useless, preventing any user from making use of WinQual in a sensible manner, for example. – 0xC0000022L Apr 25 '12 at 22:44
  • No, @Status. The question was about whether Delphi can generate PDB files, not whether it can consume minidump files. The ability to do one does not control the ability to do the other. My answer addresses the question. My comment addresses Cybershadow's comment, which is only tangentially related to the question; there's nothing stopping Embarcadero from giving Delphi the ability to consume minidump files (and possible consume associated PDB files) even without giving it the ability to generate new PDB files. – Rob Kennedy Apr 26 '12 at 02:23
  • @Rob: that is a pretty strange view. Of course that is possible, but there are plenty of debuggers, WinDbg being my favorite, that offer this, so no need to teach Delphi to understand a format that it cannot write out. The issue here is that WinQual uses Minidumps so that when you have associated PDB files as a developer you can get bug reports through that channel. Without the ability **inside** Delphi to create PDBs this is simply a useless facility for anyone using the Embarcadero compiler(s). – 0xC0000022L Apr 26 '12 at 17:11
  • OK, we need to back up, @Status. I'm confused about what you're saying. Vilx asked whether Delphi can generate PDB files, and I answered *no*. Cybershadow asked whether Delphi can load minidump files, and I answered *no*. You asked whether that was the point. I answered *no* again, but perhaps I didn't understand your question; what are you suggesting was the point of what? What point did I miss in my answers? – Rob Kennedy Apr 26 '12 at 17:53
  • @Rob: see the second paragraph of your own answer. CyberShadow was giving one of those examples, even though you didn't get it from Vilx. – 0xC0000022L Apr 26 '12 at 18:02
  • I thought Vilx was looking for live debugging, @Status, and his or her own response reinforces my assumption by complaining only about how Delphi's debugger displays values of COM objects. Postmortem debugging is something else entirely. (I don't usually think of that as something Visual Studio does, either, though; to me, that's WinDbg's job.) On the other hand, if Delphi supported postmortem debugging of minidump files, there's no reason to assume it couldn't just use the DCU files like it does at run time. – Rob Kennedy Apr 26 '12 at 21:40
  • Apparently, only one debugger can be attached to a process, so it's impossible to debug and step through a process that loads .NET assemblies and Delphi DLLs. That's what I'm trying to do. I'd like to step through the source code from the .NET into the Delphi and back. If I start the .NET in debugging mode I cannot attach the Delphi debugger, and if I launch the .NET assembly from the Delphi debugger, I can't attach the MSVS debugger. – Kevin S. Miller Feb 22 '19 at 17:38
5

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.

Alex
  • 5,477
  • 2
  • 36
  • 56
  • Nice, but I needed it for Delphi 5. I don't think they are going to upgrade THAT. ;) – Vilx- Apr 15 '10 at 18:15
  • 1
    It's a nice idea, but [PDB format](http://stackoverflow.com/questions/9250379/convert-dbg-into-pdb) is, has-been, and presumably always will be, [undocumented private format for Microsoft](http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/05/11/pdb-files-what-every-developer-must-know.aspx). Borland/Imprise/CodeGear/Embarcadeo *can't* generate *Portable Database* (PDB) files because nobody knows the format. And Microsoft won't release any tools to *write* to them. – Ian Boyd May 03 '12 at 15:32
5

I've tried tds2pdb and it works great for me.

Zach Saw
  • 4,308
  • 3
  • 33
  • 49
0

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-
  • 104,512
  • 87
  • 279
  • 422
  • 2
    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 Oct 22 '09 at 17:01
  • @Allen: So MS is (was) not willing to engage in negotiations to allow you to embed that functionality? I can't quite believe that, tbh. – 0xC0000022L Apr 25 '12 at 22:45
  • @RohitGupta - I **am** the author! :D – Vilx- Oct 17 '15 at 18:47
  • @RohitGupta - It's already being signaled by the blue background of the poster's name. :) But you're right - this isn't a very good answer, and says the same thing as the accepted answer, so I should delete it. Tell me when you've read this comment and I'll delete it. – Vilx- Oct 18 '15 at 08:37
0

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
  • 758
  • 4
  • 10
  • 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- Oct 22 '09 at 11:33
  • Sorry - missed your comment above. Too eager to post :-) – dcraggs Oct 22 '09 at 11:52
  • And the creation of `Types.pas`, `Variants.pas` and the repercussions of moving where things are declared – Ian Boyd Oct 27 '11 at 15:56