Re: Meanwhile, sounds like the unicode update is coming along ...

In article <47ed92a1$1@xxxxxxxxxxxxxxxxxxxxxx>, troy.wolbrink@xxxxxxxx
says...
Delphi.NET doesn't "play nice" in .NET.

It all depends on what you're trying to do. If your goal is to become a
3rd-party component vendor, Delphi is probably not be the best language if
you want to market to non-Delphi programmers. But other than that scenario,
I don't see what the big deal is. It consumes .NET assemblies from other
languages very well. Its assemblies can be consumed by other .NET languages
just fine, although there might be some extra non-CLS "noise" for some of
the Delphi-specific features (and I personally don't want to give up these
features such as virtual class methods). If you are planning for this, you
can take some measures to make your assemblies more CLS compliant.

It's hugely compatible with Delphi.32 though.

Which is awesome if you're starting with a legacy Delphi code base.

Yep.

But a legacy codebase is going to struggly in the .NET environment where
runtime conditions are very different.

In a very similar way, it seems, that an ANSI codebase is going to
struggle in a Unicode environment for which it was never designed.


You can make it so that the codebase compiles and runs with as few
source changes as possible, but you can't make it so that the codebase
is magically properly designed for the new environs in which it finds
itself suddenly placed.

So as a long term solution it's a dead end for all but the most trivial
of legacy code.

You'll never get away from the fact that that legacy code simply was
never designed for .NET (Delphi.NET) or Unicode (Tiburon) without
actually re-designing it.

At which point the ability to migrate legacy code becomes only a small
factor, and possibly not even an advantage, when it comes time to decide
the tool chain with which to implement the redesigned system.

.

Relevant Pages

  • Linker Error Cant Open LIBCI.LIB
    ... legacy code from a Borland environment. ... Code4 CodeBase; ... I have some old versions of this header file from my Borland ...
    (comp.databases.xbase.codebase)
  • Re: Has the EULA changed?
    ... time because of compiler deficiencies). ... It's not like Delphi is the sole product that is .net capable ... If getting the existing codebase up to usable level requires ...
    (borland.public.delphi.non-technical)
  • Re: X-Plataform, again
    ... Delphi into a language with advanced features that would still support the ... about the VCL and the language, but where its identity comes from is its GUI goodness and superior native windows support. ... possible FFI to access our existing codebase. ...
    (borland.public.delphi.non-technical)
  • Re: Losing My Religion
    ... Object Pascal has bindings for Qt 4 since more then 1 year now: ... I think you have to accept that one possible reason for many people to use Delphi in the first place is the fact that it offers a very powerful IDE. ... Sure, my legacy code would potentially go down the drain, but on the other hand I would have access to tons more of C++ code, while if I was to go FPC/Lazarus, I would be using a niche product that falls far behind Delphi. ...
    (borland.public.delphi.non-technical)
  • Re: Anyone Else Waiting for Delphi 8 for Win32?
    ... > Are you using the same codebase for the components, ... I don't recall the need to change code for Delphi 7. ... > project that crashes the IDE on shutdown, ... > one by one until it doesn't crash any more. ...
    (borland.public.delphi.non-technical)
Loading