Re: About VS C++

"Craig" <craigvn@xxxxxxxxx> wrote in message
news:4589d3f9$1@xxxxxxxxxxxxxxxxxxxxxxxxx
I think that is the big problem. CG will *NEVER* be able to completely
support .NET to the level that MS does. They will *NEVER* catch up.
Instead they have to have a different .NET support plan. What that is, I'm
not really sure, but it has to be something that is really distinctly
different from the MS product, not just a second rate VS.

People said the same thing about Win32 programming, that Borland would
always be lagging behind and therefore always be second-rate in the Win32
space. Yet, Delphi has been the best Win32 development tool since 1996 when
Delphi 2 came out.

Nevertheless, I agree with those that say the best idea would be to supply
great added value in the native and cross-platform space, not the .NET side.
C++ is still king out there in the real world, and CG needs to move C++ from
the second-tier status it has suffered in the last ten years at Borland and
propel it into the forefront. A LOT of native code is done in C++, and a lot
of cross-platform code is done in C++ too.

Back in 1995 when Delphi came out, I wondered why they hadn't used C++
instead of Object Pascal as the language hosted by Delphi. Then they came
out with C++ Builder, raising hopes that were quickly dashed when quality
problems doomed that product to market irrelevance and therefore chronic
inattention from Borland. Even in BDS 2006, it was the nearly forgotten
step-sister. I've tried using C++ in BDS 2006 quite a bit lately, but was
unable to get it to compile the C++ code I need to use (a free set of
classes that handle PAR2 files), which compiles fine in VS2005 C++. A Visual
C++ compatibility mode would be most welcome, where we could take a Visual
C++ project and open it in the BDS. As it is now, at least some C++ code
that compiles fine in VS2005 needs heavier tweaking in order to compile in
BDS 2006 than I was willing/able to do. I doubt I'm the only one in this
position, so if CG can remedy that problem, they would be in a very good
position.

Of course they could also gain a lot of traction by bringing Win32 Delphi up
to rough equivalence in language features with C#, such as with generics.

And as I have stated before, they could provide tools/functionality that
makes interop between Win32 and .NET so seamless as to be invisible to the
programmer that wants it to be invisible.


.

Relevant Pages

  • Re: Dvorak on Microsoft and .NET
    ... We can now compile both a Win32 and DotNet version of our code, ... one of the powers of Delphi is that we can write single source ...
    (borland.public.delphi.non-technical)
  • Re: I have seen some fat client Dot Net apps
    ... Essentially, following that logic, its a comparison between Win32 and .Net. ... 1a) Because you can compile Delphi code. ... 2b) Its simply yet another platform our code can be ported to. ...
    (borland.public.delphi.non-technical)
  • Re: Delphi 8: Confusion
    ... Having a environment which can compile for .NET and Win32 sounds nice:D ... But now Delphi for .NET only has come out. ... Or maybe assembler calls to .NET bytecode libraries. ...
    (alt.comp.lang.borland-delphi)
  • Compiling errors regarding Q libraries - Delphi 7 to 2005
    ... I have some source code from Delphi 7 I am attempting to compile ... I select "Win32" for conversion. ...
    (borland.public.delphi.thirdpartytools.general)
  • Re: 64-bit Windows for AMD 64 is here...
    ... Of course the VCL for NET is ... classes (or structs in Win32) around. ... although not as extreme as the Win32 API. ... Delphi is also very strong on native compilation. ...
    (borland.public.delphi.non-technical)