Can I setup Lazarus to use Virtual Pascal compiler and still debug?

[dfatl]

Hello,

I have a old DOS Borland 7 project that used TurboPower Professional.  I was able to use Virtual Pascal to get it built by using their TurboPower Object Professional port (OP) and some minor modifications to some of the old TP units like TPWindow, TPMenu, .. but the old DOS IDE isn't very nice. 

I have Notepad++ setup to be able to build and highlight errors where you can double click to go to the file/line but I can't debug with that.   

So I'm trying Lazarus with Free Pascal but I know I'll have some porting issues with things used from the old Borland CRT like FastWrite and FastWriteWindow (Gnu Pascal supports those but it requires NCurses/PDCurses under Windows) so I thought, if Lazarus could be used as both the editor and debugger, it be great, I could deal with this port to Windows console application using Virtual Pascal and use Free Pascal for new projects.

So the main question is, Can Lazarus be used to build with Virtual Pascal and be used to Debug the applications?

If so, How do I set that up?

Thanks!

[marcov]

No. And even if there were a theoretical possibility it would be magnitudes more complicated than fixing your porting issues.

Compiler and debugger are tightly connected, and specially for older products often quite unique. Newer targets (like x86_64) are often more homogenous as all compilers usually adhere to the vendors ABI and other platform defaults.

[Martin_fr]

For debugging it would need to generate DWARF debug info. (Or "stabs" if you use the gdb based debugging).

If you have a compiled exe: objdump --dwarf=info  your.exe
will show if there is any dwarf.

If there is, you can open the project (create a project for it), and use "Run Params" > "Host app" to point to the already compiled exe.
(Disable compiling for the project)

[mika]

It's all good and fine with Virtual Pascal, except that there is limitation to project size that Virtual Pascal can handle. I do not remember exactly, but 10k, 15k or 20k lines and you wont be able compile your project due to some internal error. That error wont be fixed, and it's not open source project where you could do something about it by yourself.
Playing around with Virtual Pascal is ok, but not much more.

[MarkMLl]

No. And even if there were a theoretical possibility it would be magnitudes more complicated than fixing your porting issues.

Noting Martin's and Mika's answers, since Lazarus is arguably the best available RAD IDE perhaps expanding it to support more compilers and languages would be a worthwhile goal.

The IDE, i.e. editor and debugger, is IMO at least as good as Eclipse and its open nature makes it attractive relative to MS Visual Studio. The form designer, generating XML and provably useful for multiple target OSes etc., is sufficiently capable that other language communities might consider implementing their own class libraries.

MarkMLl

[marcov]

Noting Martin's and Mika's answers, since Lazarus is arguably the best available RAD IDE perhaps expanding it to support more compilers and languages would be a worthwhile goal.

The IDE, i.e. editor and debugger, is IMO at least as good as Eclipse and its open nature makes it attractive relative to MS Visual Studio. The form designer, generating XML and provably useful for multiple target OSes etc., is sufficiently capable that other language communities might consider implementing their own class libraries.

Usually this leads to a lowest common denominator IDE. One of the things I like about Lazarus is its sharp focus on Free Pascal.  And those sunny uplands somehow never happen.

One way Designers are a dime a dozen. Truly two way designers (code manipulation and incremental GUI development) are rarer.

[Thaddy]

Both Virtual Pascal and GDB can be setup as external tools.
Myself, I use Geany with a similar setup, but that is also possible with Lazarus.

[Martin_fr]

No. And even if there were a theoretical possibility it would be magnitudes more complicated than fixing your porting issues.

Noting Martin's and Mika's answers, since Lazarus is arguably the best available RAD IDE perhaps expanding it to support more compilers and languages would be a worthwhile goal.

The IDE, i.e. editor and debugger, is IMO at least as good as Eclipse and its open nature makes it attractive relative to MS Visual Studio. The form designer, generating XML and provably useful for multiple target OSes etc., is sufficiently capable that other language communities might consider implementing their own class libraries.

MarkMLl

The IDE has support for plug ins already. Extensions for other languages can therefore be done as 3rd party add ons.

If  those plug in interfaces are not sufficient, they can be extended. But that will probably only happen when someone actually shows that they develop such a plugin. (And "shows" in this context means, has already some code as proof of their intend).

Couple of other notes.

Debugger: For users of other IDE, there is a "DAB" interface (written by Joost) to FpDebug. (search wiki)

FpDebug: Is a generic debugging library. It has it's main focus on DWARF. However if someone would supply readers for other generic debug formats that would be within its scope. That would need continuous support as FpDebug is still being shaped... Maybe that could even be an addon package, not sure yet.

FpDebug, DWARF: The implementation has had it's testing against FPC only. But it should not be limited. If you have code by another compiler that generated *valid* DWARF, and FpDebug does not handle it, then that is considered a bug in FpDebug (or missing feature, since FpDebug's DWARF is not 100% complete yet). However since DWARF does not represent all Pascal structures sufficiently, the resulting display for non-FPC may be somewhat generic. If incorrect/buggy DWARF is produced, then it only counts as a bug if FpDebug crashes, otherwise any result (error or incorrect value / the latter, depends on the severity of the incorrectness) is acceptable.
The Display of values in the IDE is (and always will) be Pascal centric). For other display, a plugin would need to do that.

[MarkMLl]

The IDE has support for plug ins already. Extensions for other languages can therefore be done as 3rd party add ons.

Can you point us (collectively) at documentation and examples?

I've always found the whole business of IDE extensions etc. to be extremely opaque: there's quite simply no indication of where to start.

Noting your points, I wonder whether having support for an external language server to help highlighting etc. would be useful (much as I dislike the current "rely on its being available in the cloud" philosophy).

MarkMLl

[Martin_fr]

Generally, the package IdeIntf.
But yes there is limited documentation.

Yet the point is/was, if someone would write code to extend the IDE, and the interfaces weren't there, they need to study the IDE code. But if you do that, then the IdeIntf is covered by the gained knowledge.

There are packages that add menus, key-combos, or buttons to the IDE => so for that, examples of the Intf* can be found.

If you want to add some codetool replacement for another language, then that will likely need an extension. There is a unit to interface with the source editor.

For doing your own compilation: You could define a new set of keys. I am not sure if you can hook and catch existing commands, *before* their default handler.
(Though SrcEditorIntf gives you the TSynEdit, and you can hook that. But if focus is elsewhere in the IDE...., maybe one of the other *Intf units (search for "[User]Command"))

The debugger isn't currently replaceable....
Though search the wiki: Joost done some "add extra debug windows" in one of his DAB debugger packages.
Mind that the debugger code is currently more or less undergoing a major rewrite. (at the end of which I hope to add some Intf units)

Main entry point is probably TLazIDEInterface

[marcov]

From what I gather, VP generates OMF-386 object files and everything else including to debug info in proprietary .VPI files. (see comments $D+ directive)

This might mean that there is no in-exe-file debug info. The manual is not 100%, so I can be mistaken, specially given the fact that external debugging tools on OS/2 are mentioned (see below)  I doubt it is dwarf, as it seem to derive from Intel and Microsoft toolchains, not GCC. Topview is probably a better bet.

For OS/2 it is said to be debuggable with ipmd, so if you can find out what ipmd groks, that would provide a hint for the LE format.

But whatever it does, trying to put it under Lazarus is probably aeons more work than simply fixing that toolkit for FPC.

[MarkMLl]

I'm totally out of things for the moment because of various "legal shit" that I'm having to deal with.

I suppose that a useful general starting point would be something that hasn't had much love for a while, like the IDE's Subversion plugin.

Another thing I'd quite like to look at are some of the text decorations (e.g. for characters in the range $80 through $9f) in the console window, when I was last there I put some stuff in there that I think we were both unhappy with which has since been disabled... possibly as a result of your fpdebug work.

If I might suggest: lots of us have pet grievances or enhancements that we'd like to see the IDE address. What might be useful would be skeletons compiled as part of bigide which showed how a particular facility could be plugged in, e.g. if somebody wanted to enhance the search facilities, add extra criteria to the file open dialog(ue) or support a macro pad directly.

MarkMLl

[Martin_fr]

I suppose that a useful general starting point would be something that hasn't had much love for a while, like the IDE's Subversion plugin.

And git....

Another thing I'd quite like to look at are some of the text decorations (e.g. for characters in the range $80 through $9f) in the console window, when I was last there I put some stuff in there that I think we were both unhappy with which has since been disabled... possibly as a result of your fpdebug work.

One suggestion. IIRC, currently input is converted/formatted as it comes in. It should always be kept in original format, when display options are changed, it should be formatted for display only.

If I might suggest: lots of us have pet grievances or enhancements that we'd like to see the IDE address. What might be useful would be skeletons compiled as part of bigide which showed how a particular facility could be plugged in, e.g. if somebody wanted to enhance the search facilities, add extra criteria to the file open dialog(ue) or support a macro pad directly.

Well, example plugins would be good. They would also be able to document the IdeIntf.

On the other hand, many of the IDE features are deeply embedded into the one big chunk of IDE code. Even if not needed. I started taking the debugger out of it, but it's still a long way to go. Other parts could follow... some day.

[MarkMLl]

One suggestion. IIRC, currently input is converted/formatted as it comes in. It should always be kept in original format, when display options are changed, it should be formatted for display only.

True. OTOH, I did that text decoration work at a time when I was looking at some weird emulation character sets (Minitel etc.), so the interesting thing was being able to have the program report what it thought it was seeing in a useful form. I think that the last time I checked I found hex output etc. working, but not some of the underlines etc. even though their checkboxes are still enabled.

Since that point, the ability of Lazarus etc. to attach to a running program has improved enormously, and this is almost always preferable if either a weird keyboard is expected or it's necessary to implement ANSI-style escape sequences etc.

MarkMLl

[avra]

Hello,

I have a old DOS Borland 7 project that used TurboPower Professional.  I was able to use Virtual Pascal to get it built by using their TurboPower Object Professional port (OP) and some minor modifications to some of the old TP units like TPWindow, TPMenu, .. but the old DOS IDE isn't very nice. 

I have Notepad++ setup to be able to build and highlight errors where you can double click to go to the file/line but I can't debug with that.   

So I'm trying Lazarus with Free Pascal but I know I'll have some porting issues with things used from the old Borland CRT like FastWrite and FastWriteWindow (Gnu Pascal supports those but it requires NCurses/PDCurses under Windows) so I thought, if Lazarus could be used as both the editor and debugger, it be great, I could deal with this port to Windows console application using Virtual Pascal and use Free Pascal for new projects.

So the main question is, Can Lazarus be used to build with Virtual Pascal and be used to Debug the applications?

I would do it the other way around. Drop Virtual pascal idea and go back to original Turbo Pascal project and try to replace parts which do not exist with freepascal alternatives developing replacement parts where needed.
https://wiki.freepascal.org/Mode_TP