Nick Hodges

TurboPower Update #1

29 Sep

Wow – I think that my TurboPower blog post has generated more comments than any has in a while.  The response has been gratifyingly positive.  There have been a couple of issues and questions raised, so I’ll make a few further points:

  • Okay, first things first:  Is it Turbopower or TurboPower?
  • Please go to this one question survey and tell me what you think are the five most important projects in the list.
  • I want to be clear that this isn’t an “official” Embarcadero project.  I’m doing stuff “on company time” and off, but this is strictly a community project.  We Embarcadero folks are delighted that this code is “coming back to life”, but this is a more of a “Delphi Community” thing than anything else.
  • I’m going to be, for a very large degree, simply try to be a manager here.  I’m probably not going to do a lot of coding, but instead will be counting on you guys to do most of the development here.  I’m going to view my role here as a facilitator, cheerleader, and “Making Things Happen” type guy.
  • I’m not really up on how SourceForge works, so that will be my initial focus here – finding out what you can do on SourceForge and getting things updated.
  • I’m going to focus on getting these projects working for the post-Unicode world.  If the community wants to keep them working for the pre-Unicode world, that is great, and I’ll fully support that.  But the focus of my efforts will be on getting the projects working for current versions.  I know that this won’t make everyone happy, but given limited resources and focus, that seems like the obvious choice.

19 Responses to “TurboPower Update #1”

  1. 1
    Xepol Says:

    Just remember, if you get frustrated with the Async library and want to just do a search and replace of String with RawByteString, Char with AnsiChar, and PChar with AnsiPChar:

    PAnsiChar(UnicodeString) is decidedly unsafe (all the compiler magic mysteriously vanishes here). You need PAnsiChar(RawByteString(UnicodeString)).

    Then you’ll also find all the other areas the "unicode" migration magically don’t work as well (Can someone please tell me why AnsiCompareText uses Unicode strings??? PLEASE? Oh, and you gotta love little things like how string constants tend to be interpreted as unicode strings even in what is clearly an ansistring context)

    I think this will be a great project for everyone at Embarcadero to wet their beaks in so to speak - I expect it will have an interesting impact on the next delphi version and how it supports unicode! (hoping the edge conditions get reduced)

  2. 2
    Julian M Bucknall Says:

    Nick: It’s TurboPower.

    The domain is still active by the way ( Roy (our old sysadmin) is the keeper and the owner, and, as far as I can gather, he’s the one who’s paid for the domain renewals.

    Cheers, Julian

  3. 3
    Nick Hodges Says:

    Julian –

    Wow, very impressive.

    And for some reason that I can’t understand, I seem to have a very strong but fuzzy memory of Roy, the TurboPower SysAdmin. Compuserve? Newsgroups?

  4. 4
    Julian M Bucknall Says:

    Nick: Newsgroups most probably. Although he used to look after our network, servers, etc, he also did development and support on the products. My memory fades on the details, but I’m sure he was involved in Internet Professional. I’ll have to ask him.

    Cheers, Julian

  5. 5
    delphigeist Says:

    I just want to say…
    Thank you Nick for doing this!

  6. 6
    Anders E. Andersen Says:

    @Xepol -

    You can use AnsiStrings in AnsiCompareStr and AnsiCompareText. That should work fine. They will of course be converted to unicode strings, but is this an issue?

  7. 7
    Olivier Beltrami Says:

    Missing from the list is SleuthQA. The best non-invasive profiling tool. Tried AQTime from AutomatedQA but it is just way too complicated. SleuthQA is a real gem, and a good part of the reason why I stay with Delphi 7 for mission-critical software.

  8. 8
    Atle Smelvær Says:

    x2 on the SleuthQA. Could you please look into if there is any possibility to get that back in the world? It’s a shame that this product is lost.

  9. 9
    Paul Graham Says:

    x3 on the SleuthQA. In my mind the biggest loss when TurboPower went under. Does anyone "own" this product (i.e. codebase) anymore? If not, how could this project obtain it?

  10. 10
    Christian Wimmer Says:

    What comes next? Maybe you want to become the godfather of the JEDI projects? :-)

  11. 11
    Olaf Says:

    x4 on SleuthQA Suite. A tool like "MemorySleuth" which catches resource leaks for newer Delphi releases would be very nice.

  12. 12
    Andreas Hausladen Says:

    @Christian: We already have more gods than lemmings.

  13. 13
    Mason Wheeler Says:

    @Anders: Yes, it’s an issue. It’s ridiculous and confusing. If the name says Ansi, it ought to work with AnsiStrings, not UnicodeStrings.

  14. 14
    Warren Says:

    It is no big deal to make the TurboPower project source code compile with all modern Delphi versions.
    The JEDI JCL and JVCL team recently decided to drop ancient Delphi version support for all upcoming and future releases. We now support Delphi 5 and later. This was because there are too many {$IFDEFs} required to keep supporting all versions of Delphi forever.

    However, delphi 5 to 2010 source code can be very cleanly managed. The UNICODE specific changes that require IFDEFS are generally few and far between when you move any Chars that had to be bytes to AnsiChar, and any byte strings that had to be single character or byte strings to TBytes or AnsiString as the case may be. The JEDI JCL and JVCL codebase is huge, and is well organized to support all reasonably recent (less than 12 years old) versions of Delphi.

    However, the classic TP code ZIP archives install easily onto Delphi versions prior to 2007, so if you want to cut it off at Delphi 2009, for the new ongoing work, there are reasonable reasons for doing so. (People can still download old ZIP files containing ancient Turbo versions for their ancient delphis.)


  15. 15
    dag Says:

    It’s funny. I made the point to Anders in one of his user group presentations on the 2009 rollout tour that a real world library like Async Pro was decidedly NOT easy to migrate to Unicode. There are plenty of rabbit holes in the code, especially the dispatcher. Serial port code is very decidedly a byte by byte (or char by char) proposition. If you do something here, it would be very much appreciated. I have many, many projects over the last 12 years using Async Pro, and nary a one has been migratable to anything beyond the Unicode adoption, as they come up for maintenance.

  16. 16
    Jeff Says:

    I used Async Proo during the days of Turbo Pascal. The turbo products have been around a very long time and used by many people. No Surprise you get a lot of attention. I still use Async Pro, and Systools in my D2007 projects. I hope they continue to thrive… or be incorporated in to current Embarcadero releases :-) That’d really turn my crank.

  17. 17
    Christian Wimmer Says:

    @Andreas: Godfathers also working at Embarcadero? Who?

  18. 18
    Anders E. Andersen Says:

    @Mason Wheeler

    I think actually it is better that AnsiCompareStr takes generic string types (which now maps to an unicode string).

    The definition is the same as it was before. It is only the implementation that has changed. If you changed the definition to take only AnsiStrings, you would have to change application code to avoid warnings. This way it takes a string value, like it has always done, and oh, by the way, it will also work as intended on unicode strings, which means less risk of bugs in your code when you convert your app from pre-unicode Delphi. Yet another benefit is that if you need to maintain code across different versions, it means there is one less thing to worry about. It will ‘Just Work(TM)’.

  19. 19
    Alf Christophersen Says:

    Long time. no more hear ??

    How goes the plans?
    Seem to be at least an update to several packages, but in common, they don’t seem to be available via the sourceforge page, but spread more or less over the while Internet.

    Maybe gathering the new 2009 and evt. 2010 updates back in the sourceforge project should be the first step ?

    And also maybe a common place to discuss further events?

    I would suggest the or the old turbopower news place

    On the turbocontrol.announce could be perhaps a place ??

© 2016 Nick Hodges | Entries (RSS) and Comments (RSS)

Your Index Web Directorywordpress logo