Standalone EXE


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 2 12 LastLast
Results 1 to 15 of 17

Thread: Standalone EXE

  1. #1
    Aamir Guest

    Standalone EXE


    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?

  2. #2
    Patrick Troughton Patrick Guest

    Re: Standalone EXE


    "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



  3. #3
    Aamir Guest

    Re: Standalone EXE


    >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.

  4. #4
    Patrick Troughton Patrick Guest

    Re: Standalone EXE


    "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



  5. #5
    Keith Franklin, MCSD Guest

    Re: Standalone EXE

    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



  6. #6
    Eduardo Guest

    Re: Standalone EXE


    <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



  7. #7
    Patrick Troughton Patrick Guest

    Re: Standalone EXE


    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



  8. #8
    Matthew Solnit Guest

    Re: Standalone EXE

    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



  9. #9
    Phil Weber Guest

    Re: Standalone EXE

    > 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



  10. #10
    David Zajac Guest

    Re: Standalone EXE


    "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.



  11. #11
    Robert Kozak Guest

    Re: Standalone EXE


    "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





  12. #12
    Robert Kozak Guest

    Re: Standalone EXE


    "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




  13. #13
    Keith Franklin, MCSD Guest

    Re: Standalone EXE

    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



  14. #14
    Robert Kozak Guest

    Re: Standalone EXE

    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
    >
    >




  15. #15
    Larry Triezenberg Guest

    Re: Standalone EXE

    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




Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center