Recent

Author Topic: Porting bad Delphi 7 code.  (Read 9281 times)

muxecoid

  • Newbie
  • Posts: 2
Porting bad Delphi 7 code.
« on: January 13, 2009, 03:10:42 pm »
Hey. 6 years ago I was a fan of mostly open-source (not free like stalman) PBEM(play by e-mail) game written in Delphi. The game was terribly designed, but it worked. It was a client server application with several build targets (Server, client, unit editor, scenario editor, web-interface in PHP) sharing parts of common code-base. There were lots of non-unicode string constants in Russian in the middle of the code, the design was procedural, all member variables were public and no client function used accessors. There were no pointers, only fixed width arrays. It used 2 closed source components (HTTP and SMTP), one of them pirated another no longer supported.

 Five years ago I had much less programing knowledge than today, "design patterns" and "unit testing" were a "WTF?" for me. Back than I tried to fix some problems in the project. While some of them provided additional functionality (almost working English-language client, loading rules-set from DLL...) the quality of my code was terrible even compared to the existing code and it was rejected from trunk (did I say the project did not have a real RCS?)

During the 5 years since I stopped playing that game I discovered many great books on software development. Recently I was reading "Refactoring: Improving The Design Of Existing Code" (hint: excellent book, read it) and I thought that old game coded in Delphi is a great place to practice methods described. I checked the status of the project and realized that some refactoring of server code was made since, but it is still under-maintained. I thought that if I fail to find a job after finishing M.Sc it would be nice to work on some open source project to improve my skills.

I want to port the project to Lazarus and translate documentation to English to increase the number of potential contributors (license change is also needed to attract FOSS enthusiasts, but it is a touchy subject).

Some questions:
Is it easy to port the code that uses standard Delphi 7 VCL to Lazarus? Any extra work to achieve cross-platformness?
Is it easy to replace components for SMTP/POP3 and for HTTP (functions used: send email with attachment, get email with attachments, HTTP auth, HTTP request)?
Is it easy to make automated tests (should I use DUnit?)?
Does Lazarus generate DLL-greedy executibles?
Will it be hard to add Unicode support? What about gettext for Delphi?
Anything else I should keep in mind?

Phil

  • Hero Member
  • *****
  • Posts: 2737
Re: Porting bad Delphi 7 code.
« Reply #1 on: January 13, 2009, 03:40:01 pm »
"Standard" VCL should port quite well, with the exception of a couple controls like TRichEdit, which don't exist in the Lazarus LCL.

If you have custom controls that are dependent on Win API, these will take some work to housebreak them of that.

Use Indy and other packages for your HTTP needs, same as on Delphi.

LCL supports Unicode.

Not sure what "greedy-executables" means. FPC/LCL executables on Windows have about the same dependencies as Delphi executables.

Surprising how Win-dependent some programmers can make their Delphi code, with assumptions about "C:" drive, Documents and Settings, registry, help, installers, etc. These things would need to be rewritten or excised to be cross platform ready.

If you want to maintain Delphi compatibility in your code, convert the units and forms with this toolkit rather than using Lazarus IDE conversion tools:

http://wiki.lazarus.freepascal.org/XDev_Toolkit

Also, I wonder if it would not be a bad idea to maybe improve the "bad" code a bit before attempting to port it. Then you won't find yourself in a quandary at some point wondering whether the problem you're having is the port or just the "bad" code you started with.

There's a huge amount of info on the wiki and also lots of ported packages:

http://wiki.lazarus.freepascal.org/Components_and_Code_examples

Some things written and ported can be out of date as you would expect with this sort of project, but there's lots of useful stuff there still.

Thanks.

-Phil


Thanks.

-Phil

muxecoid

  • Newbie
  • Posts: 2
Re: Porting bad Delphi 7 code.
« Reply #2 on: January 13, 2009, 04:27:02 pm »
Thanks for the answers. Surely I understand the need for improving the old code before porting. Only after de-coupling GUI code from game-logic code RichEdits can be replaced with something else.

Yes there are lots of Win-Dependable parts in the existing code, I already see assumptions about help and installers and there are more to come.

Speaking of Delphi compatibility - what can I do if I want to maintain a shared repository?

From you answer I conclude that it is possible given enough time.

Phil

  • Hero Member
  • *****
  • Posts: 2737
Re: Porting bad Delphi 7 code.
« Reply #3 on: January 13, 2009, 04:39:16 pm »
I wouldn't think that maintaining a shared repository would be a problem.

You might start by porting to Windows, using the stable 0.9.26 Lazarus. That way you're not mixing problems of original code, cross-platform issues, and instability issues together. You might find that getting it basically functional on Windows is not that difficult. Once that's done, you can concentrate on the cross-platform things and decide whether you want to experiment with the daily snapshots. I stopped using snapshots as I found I wasn't getting anything else done.

There are lots of commonalities between OS X and Linux, as you might expect. This is also a place to decide how true of a Mac app you want to create. When you compile an app against the Carbon widgetset on Mac and create an app bundle, that's a true native app. But that only takes you part of the way. Where a Mac app stores preferences and that sort of thing is different from Linux. Lazarus IDE itself still shows some of its Linux heritage on Mac, for example using a hidden ".lazarus" folder for preferences, even though OS X has a dedicated folder called Preferences that is just perfect for a Lazarus subfolder containing settings. The problem with using a hidden "." folder is that you can't browse it using Finder. You can always tell the Linux/Unix apps ported to Mac by this sort of shiboleth.

Thanks.

-Phil

Phil

  • Hero Member
  • *****
  • Posts: 2737
Re: Porting bad Delphi 7 code.
« Reply #4 on: January 13, 2009, 06:07:58 pm »
Other things to watch out for:

- Assembler (asm). The normal best practice for assembler code is to write it first in the higher-level language (Pascal), then rewrite it in assembler. The high-level code is then left in the file commented out. Not only do Delphi programmers almost never, ever do this, but they almost never include so much as a single line of comments. This shows how even great, hotshot programmers can write terrible code (read: hard to maintain, difficult to enhance, almost impossible to port). I chalk this up to a lack of adult supervision when they started out. With a good manager who is also an actual developer, a new programmer should never develop bad habits like this.

- Font assumptions. Windows and Mac both come with many of the same TrueType fonts, such as Courier New, Times New Roman, and Arial. As such, you can use these fonts in your forms without problem. By default, Delphi uses MS Sans Serif - you can change this to Arial without much difference in look and then the form will display the same on Mac. With GTK, these fonts generally look terrible. Fortunately it appears as though the GTK(1) widgetset is being phased out with Lazarus. The more recent GTK libraries used by the GTK2 widgetset do a much better job of matching up a similar font so you should be able to continue using TrueType if you want on the Windows/Mac side and let the GTK smarts handle the mapping so you don't have to use two different form design files.

- All the extra Win-specific units such as MMSystem, etc. that Delphi makes so easy to use.

- Lots of programs use TMetaFile to do preview-mode stuff. TMetaFile is not available cross-platform in the LCL. I believe there is a Windows-only version. On Mac, you really don't need a preview mode. Any program that can print can also preview as well as save to PDF, all from the Print dialog. That just leaves Linux...

- If you're on top of your game and you're porting a large codebase, you will almost certainly find bugs in the Lazarus LCL or Free Pascal RTL. Once logged, generally these bugs are fixed pretty fast, but then you have to decide whether you can continue using the stable version. Sometimes fixes are so tied up to other changes that you have no choice but to move to a snapshot/SVN version so as to get the fixes you need.

- Other things that can usually be worked around pretty easily: Differences in clipboard, loading resources like cursors, shelling to external apps, etc.

- Hardwired backslash as part of file paths, even though Delphi has always provided IncludeTrailingBackslash and similar functions for avoiding this.

Thanks.

-Phil

 

TinyPortal © 2005-2018