Re: New Delphi roadmap is coming: NO UNICODE PLEASE!

"Jolyon Smith" <jsmith@xxxxxxxxxxxxxxxxxxxxx> wrote in message
news:MPG.2024276cb21c4ba2989bad@xxxxxxxxxxxxxxxxxxxxxxxxx
In article <45b95888$1@xxxxxxxxxxxxxxxxxxxxxx>, says...

I'm the project manager of a .NET desktop application at our company.
As a result, I'm confirmed in my disinterest in .NET *desktop*
applications.
AFAICS, no one has demonstrated a need for .NET desktop applications,
let alone Delphi.NET desktop apps. More than ever, I think native is the
way to go.

This is very relevant to me right now.

When you say you are disinterested in .NET on the desktop (to paraphrase
slightly) does this mean you are actively *not* interested in .net on
the desktop or that .net on the desktop is of no great benefit from your
pov, but neither is it any great concern?

Hmm. How to phrase this?
1)
I personally don't like the user experience that I'm getting with the
new app. Startup is slow. Paint is slow. Redraw is slow.
Not exactly, but it's sort of like you can see the wireframe drawn
before the rest of the form and texture fills in.

I've done a bit of research on it, not much mind you, and I've been told
that yes, if you just use it out of the box it is a bit slow, but there are
some things you can do to speed up the drawing. But my developers
say they are already doing those thing, and this *is* the faster version.
I don't have time to look up the details right now, but GDI and GDI+
always come into the conversation.
I've also been told that future versions of .NET will deal with this.
Personally, I wouldn't put any money on that. I don't think MS is
putting their eggs in the WinForms basket.
Is this enough for me to actively campaign against using .NET for
a new project. Probably not by itself, but it is a factor that I will weigh
in.

2)
Strong naming. I was excited about this at first. No one can quietly
replace
a dll with a trojan. That's good for security. Avoids DLL hell, because it
always only uses the DLL that it came with.
Hmm. In practice, the reason I put things in a DLL instead of in the
exe is so I can swap them out. Now I can't. I have a bug in the DLL.
The app is deployed and the user is getting an error. I could fix it
by replacing the DLL. But then the app won't run at all. This really
sucks.
Yes, this happened. It is a unique circumstance from the fact that we
have different departments providing different functionality.

3)
DLL hell.
..NET was supposed to prevent this. But we have had several
instances where upgrading .NET broke things that were working.
1.0 -> 1.1
1.1 -> 1.1 upgrade
1.1 -> 2.0
all broke a few things. Very irritating when you were told that
..NET was the answer to this. I never had this much problem
upgrading Win32.

There are clearly some things about .NET that are good.
C# as a language is a huge step above VB, C, C++. It allows you
to write more secure applications much easier than those languages.
Coming from Delphi, this isn't any big deal of course.

The .NET framework handles a lot of things that we used to have
to do on our own. It has some really nice functionality.

But my perspective is that they clearly don't have religion as far
as backward compatibility. I have no idea whether a given app
is going to work when a user upgrades their version of .NET
or what the next automatic upgrade is going to do to us.
Apparently, with VB runtime supported through the lifespan of
Vista, now VB apps are more stable than C# apps.

Delphi is looking pretty good to me.

i.e. do you see concrete _dis_advantages of choosing .NET for the
desktop, or merely not perceive any real _ad_vantage?

This isn't intended to trigger a flame war.

I am actively looking at the task of migrating a significant 32-bit
Delphi codebase to 64-bit.

I'm using 64 bit IDs in my database today. Delphi 6 couldn't handle
this, but I posted the issue in QC and it was fixed in D2005. What
exactly can't you do today that you need to?

Currently of course there is no way to do this natively and to stay with
Delphi and for numerous reasons Delphi.NET is not #1 on the list of
candidates for a .NET targetted approach.
Agreed.

We use D.N to wrap some Win32 DLLs so that they can be used
in the .NET app. It works fine for that.

If there are concrete disadvantages to using .NET on the desktop from
your pov, this could be a factor in any eventual decision to wait for
64-bit Delphi or not.





--
HTH,
Brad.


.

Relevant Pages

  • Re: Problem closing app with big UDT
    ... Are you trying to pass the UDT between VB and Delphi, ... Passing it back and forth between a Delphi .dll to a VB application. ... ALL the data is of one of 3 types: Long, Double, or Byte array. ... In any one app, maybe, but this dll is in production use in several ...
    (microsoft.public.vb.general.discussion)
  • Re: Setting up a TMessage trap
    ... It needs to be in a DLL and to send notices back to your own ... of your main window. ... memory segment to hold the handle of your app. ... delphi isn't able to create a DLL with a shared ...
    (comp.lang.pascal.delphi.misc)
  • Re: calling application procedure from a dll
    ... In the main App I have a fancy decendant of TStream that reads its ... I suppose the DLL goes rooting around in the memory of the main App, ... Delphi 5, ...
    (comp.lang.pascal.delphi.misc)
  • Re: Problem closing app with big UDT
    ... Are you trying to pass the UDT between VB and Delphi, or do you just mean that the Delphi equivalent works fine? ... All the array sizes are multiples of 4, so the 4-byte alignment should be maintained throughout unless we screwed up somewhere. ... In any one app, maybe, but this dll is in production use in several different apps, in 3 different languages. ... So coming at it from a different direction is there any way I can, just in my VB app, send and receive the structure I need without actually passing it as a structure? ...
    (microsoft.public.vb.general.discussion)
  • Re: legacy app .net 1.1 using .net 2.0 component. is it possibile?
    ... will try porting the component to v1.1 as upgrading the main app is ... would fail if "in process" (dll), since it would still end up calling back ...
    (microsoft.public.dotnet.general)