Standalone EXE

[Aamir]

If its true that both VB and C# is design from ground up. Then how come we
don't follow DELPHI path where all their controls are designed in DELPHI,
so that when they produce an executable, its standalone. How come we have
to rely on big bulky runtime files? How come we don't get large group of
controls like in DELPHI so that we don’t have to buy a third party control
that ships an extra OCX file?

[Patrick Troughton Patrick]

"Aamir" <aamir@hotmail.com> wrote:
>
>If its true that both VB and C# is design from ground up.

Yes, it is true.

>Then how come we
>don't follow DELPHI path where all their controls are designed in DELPHI,
>so that when they produce an executable, its standalone.

Because Microsoft choose to follow the Java model, not the Delphi one. In
fact, I would even so far as to say that VB and C# are not tools for Windows
development anymore. Instead, they're targeting a completely new platform
call .NET which you can sort of compare to Java's VM. This new platform,
in turn, runs on Windows. .NET can be ported to other platforms, such as
Linux or Mac.

>How come we have
>to rely on big bulky runtime files?

In a sense, we don't. Virtually all applications require some sort of platform.
In Delphi's case, it requires Windows. VB.NET and C# require .NET.

/Pat

[Aamir]

>Because Microsoft choose to follow the Java model, not the Delphi one. In
>fact, I would even so far as to say that VB and C# are not tools for Windows
>development anymore. Instead, they're targeting a completely new platform
>call .NET which you can sort of compare to Java's VM. This new platform,
>in turn, runs on Windows. .NET can be ported to other platforms, such as
>Linux or Mac.

>In a sense, we don't. Virtually all applications require some sort of platform.
>In Delphi's case, it requires Windows. VB.NET and C# require .NET.
>
>/Pat
>
>
So can we aspect same performance between VB and C# verses DELPHI at windows
platform.

[Patrick Troughton Patrick]

"Aamir" <aamir@hotmail.com> wrote:
>
>So can we aspect same performance between VB and C# verses DELPHI at windows
>platform.

Good question. Right now, VB.NET and C# aren't even ready for beta so there's
no way to tell. However, Microsoft has said that they expect C# to be about
15% slower than traditional C++. Because VB.NET and C# have almost identical
performance, that should mean that VB.NET is also about 15% slower than C++.
We do know from benchmarks performed by VBPJ that VB6 can be much slower
than just 15%. Given that, one could draw a conclusion that this means VB.NET
should be faster than VB6. OTOH, the counter argument to that is that every
generation of product Microsoft gives us is usually slower than that last.
And of course, it's in Microsoft's best interests to paint the best picture
possible for their new platform. We won't know for sure, one way or another,
probably for a while.

As far as web applications are concerned, everything I've read says that
ASP+ should be much faster than ASP.

/Pat

[Keith Franklin, MCSD]

The thing that we need to keep in mind is that in some very specific areas
Microsoft has done a great deal of work to improve performance.

For one (and a big one in my eyes) they have take a good hard look at String
performance...Especially concatenation...

They have built a new object that sole purpose is to build string through
concatenation..Take a look at the StringBuilder object...

I also read something on the DOTNET list a couple days ago about how they
handle something like the following:

sWhatever = "Some Long String that you choose to continue" & _
"this string could be a SQL statement or other" & _
"that keeps going and going"

In VB.NET the compiler will make it one big string and get rid of the
concatenation at compile time. This could help a little also...



Later

[Eduardo]

<Patrick Troughton Patrick> escreveu nas notícias de
mensagem:39ef0430$1@news.devx.com...
> In a sense, we don't. Virtually all applications require some sort of
platform.
> In Delphi's case, it requires Windows. VB.NET and C# require .NET.

So IOW VB will produce "stand-alone" EXE, the way Delphi does today?

Eduardo

[Patrick Troughton Patrick]

No, what I'm saying is that virtually all applications require a pre-existing
platform. Delphi's dependecy is on Windows. Java's dependency is on its VM.
VB.NET's and C#'s dependency is on .NET. IOW, .NET is its own platform. In
fact, I'm not even sure if I still consider VB to be a Windows development
tool. It's a whole new ballgame. I don't think the traditional concept of
"stand-alone" really applies.

/Pat

"Eduardo" <alertbr@bestway.com.br> wrote:
>
><Patrick Troughton Patrick> escreveu nas notícias de
>mensagem:39ef0430$1@news.devx.com...
>> In a sense, we don't. Virtually all applications require some sort of
>platform.
>> In Delphi's case, it requires Windows. VB.NET and C# require .NET.
>
>So IOW VB will produce "stand-alone" EXE, the way Delphi does today?
>
>Eduardo

[Matthew Solnit]

Eduardo <alertbr@bestway.com.br> wrote in message news:39ef2c90@news.devx.com...
>
> So IOW VB will produce "stand-alone" EXE, the way Delphi does today?

No. All Visual Basic and C# code will require the Common Language Runtime. In
fact, any language that produces managed code (Eiffel.NET, COBOL.NET, ME C++)
will require the CLR.

Microsoft is telling us that they will try to get the CLR on everyone's desktop
for us, but I really don't think it will be safe to assume the user already has
it.

BTW, the CLR is much bigger than the VB runtime.

-- Matthew Solnit

[Phil Weber]

> So IOW VB will produce "stand-alone" EXE, the way
> Delphi does today?

Eduardo: Sort of. Delphi's executables are not really "stand-alone" -- they
require Windows in order to run. Similarly, VB.NET's and C#'s executables
will require the .NET platform, which, in turn, will require a host
operating system. So .NET executables will require one additional support
layer relative to Delphi.

I'm not sure how Kylix will work -- if it will function as a "virtual
machine" to allow Delphi executables to run on Windows or Linux, then Kylix
and .NET will be very similar in function.

As far as I know, .NET will not provide a way to compile binary components
into the .EXE, so Delphi will still have the edge here.
---
Phil Weber

[David Zajac]

"Phil Weber" <pweber@devx.com> wrote in message
news:39ef3287@news.devx.com...
> > So IOW VB will produce "stand-alone" EXE, the way
> > Delphi does today?
>
>
> I'm not sure how Kylix will work -- if it will function as a "virtual
> machine" to allow Delphi executables to run on Windows or Linux, then
Kylix
> and .NET will be very similar in function.
>
Kylix provides source code compatibility between Windows and Linux not
run-time compatibility. As a matter of fact, two seperate families of the
compilers will exist: The Kylix versions will only produce native Linux
executables and next releases of Delphi/C++Builder for Windows.will only
produce native Windows executables.

[Robert Kozak]

"Keith Franklin, MCSD" <ka_franklin@empowered.com> wrote in message
news:39ef2010@news.devx.com...
>
> sWhatever = "Some Long String that you choose to continue" & _
> "this string could be a SQL statement or other" & _
> "that keeps going and going"
>

Sure that is okay for constants but alot of times we use strings because
they are dynamic:

sWhatever = "Some Long String that you choose to continue" & _
sUserSuppliedString & _
UpperCase(sAnotherStringfromDatabase)

I don't use VB much anymore so if UpperCase is not a builtin function assume
I wrote it <g>

-- Robert Kozak

[Robert Kozak]

"Phil Weber" <pweber@devx.com> wrote in message
news:39ef3287@news.devx.com...
> > So IOW VB will produce "stand-alone" EXE, the way
> > Delphi does today?
>
> Eduardo: Sort of. Delphi's executables are not really "stand-alone" --
they
> require Windows in order to run. Similarly, VB.NET's and C#'s executables
> will require the .NET platform, which, in turn, will require a host
> operating system. So .NET executables will require one additional support
> layer relative to Delphi.
>
> I'm not sure how Kylix will work -- if it will function as a "virtual
> machine" to allow Delphi executables to run on Windows or Linux, then
Kylix
> and .NET will be very similar in function.
>

Kylix produces native ELF executables. There are two component libraries for
Delphi now. VCL is for native windows development and CLX for crossplatform
development. This is a source code compatiblity you still need to compile on
Windows or on Linux. There is no runtime involved in either case.

-- Robert Kozak

[Keith Franklin, MCSD]

Robert,

In that case you would use the stringbuilder object

Dim sStringValues As System.Text.StringBuilder
sStringValues = New System.Text.StringBuilder
sStringValues.Append("Some Long String that you choose to continue")
sStringValues.Append(sUserSuppliedString)
sStringValues.Append(UCase(sAnotherStringfromDatabase)

msgbox(sStringValues.ToString())

Later

[Robert Kozak]

Ahh thanks for the enlightenment.

-- Robert Kozak

"Keith Franklin, MCSD" <ka_franklin@empowered.com> wrote in message
news:39ef3f17$1@news.devx.com...
> Robert,
>
> In that case you would use the stringbuilder object
>
> Dim sStringValues As System.Text.StringBuilder
> sStringValues = New System.Text.StringBuilder
> sStringValues.Append("Some Long String that you choose to continue")
> sStringValues.Append(sUserSuppliedString)
> sStringValues.Append(UCase(sAnotherStringfromDatabase)
>
> msgbox(sStringValues.ToString())
>
> Later
>
>

[Larry Triezenberg]

Just so I understand this, are you saying that:
sTemp = sTemp & "Some value"
won't be faster if sTemp is defined as string
but will be faster if defined as
System.Text.StringBuilder ?

Keith Franklin, MCSD wrote in message <39ef3f17$1@news.devx.com>...
>In that case you would use the stringbuilder object