Flexibility of C++

I am getting pretty feed up with the hugh runtime required by VB. Do you think
MS has any plans to make an option to keep the BASIC language but make more
powerful options for compiling? So that if a VB programer wanted to they
could do away with the runtime and make a stand alone EXE?

Thanks again,

Ossu

Ossu,
You have touched on a very sensitive subject that has been debated in countless
forums by very smart people (smarter than me that is :-) ). That not withstanding,
here is my two-cents worth (My book also has a section that talks about this
very thing).

VB5 introduced the ability to create a native .exe file in Visual Basic with
no runtime interpreter required. This meant that a Visual Basic app now contained
native machine instructions that could execute right on the chip just like
a C++ application. However, the VB team still put all of the VB language
calls like Mid$, Asc, InStr and MsgBox in the MSVBVM50.DLL/MSVBVM60.DLL.
So even though you no longer required the MSVBVM50.DLL/MSVBVM60.DLL to run.....
well - you still required them to run! A lot of people thought that they
should have made a "light weight" version of the DLL for native .exe VB apps,
but they didn't
Now, as not to cast aspersions without investigation - C++ apps built with
MFC (the C++ equivalent of VB) require a huge runtime library. In fact, distributing
them is just about as painful as distributing VB apps.
The upside is that .NET makes a lot of this go away. All languages will be
interpreted in .NET so that it there will be no requirement for a runtime
library.

Hope this answers your question.

Thanks,
Jonathan
"Ossu Chang" <ossu@netzero.net> wrote:
>
>I am getting pretty feed up with the hugh runtime required by VB. Do you
think
>MS has any plans to make an option to keep the BASIC language but make more
>powerful options for compiling? So that if a VB programer wanted to they
>could do away with the runtime and make a stand alone EXE?
>
>Thanks again,
>
>Ossu

I understand what you are saying, and I agree. But will .NET allow you to
make an application that is truely stand alone. meaning here is my EXE and
that is my entire program. I dont think so. In todays world I dont even think
you can REALLY do this anymore. I mean even if you write directly to the
API so when you compile you have a single (C,C++) EXE. That EXE still depends
on hundreds of DLLs that are shipped with Windows.

I miss DOS..... ;-)

"Jonathan Morrison" <jonathanm@mindspring.com> wrote:
>
>Ossu,
>You have touched on a very sensitive subject that has been debated in countless
>forums by very smart people (smarter than me that is :-) ). That not withstanding,
>here is my two-cents worth (My book also has a section that talks about
this
>very thing).
>
>VB5 introduced the ability to create a native .exe file in Visual Basic
with
>no runtime interpreter required. This meant that a Visual Basic app now
contained
>native machine instructions that could execute right on the chip just like
>a C++ application. However, the VB team still put all of the VB language
>calls like Mid$, Asc, InStr and MsgBox in the MSVBVM50.DLL/MSVBVM60.DLL.
>So even though you no longer required the MSVBVM50.DLL/MSVBVM60.DLL to run.....
>well - you still required them to run! A lot of people thought that they
>should have made a "light weight" version of the DLL for native .exe VB
apps,
>but they didn't
>Now, as not to cast aspersions without investigation - C++ apps built with
>MFC (the C++ equivalent of VB) require a huge runtime library. In fact,
distributing
>them is just about as painful as distributing VB apps.
>The upside is that .NET makes a lot of this go away. All languages will
be
>interpreted in .NET so that it there will be no requirement for a runtime
>library.
>
>Hope this answers your question.
>
>Thanks,
>Jonathan
>"Ossu Chang" <ossu@netzero.net> wrote:
>>
>>I am getting pretty feed up with the hugh runtime required by VB. Do you
>think
>>MS has any plans to make an option to keep the BASIC language but make
more
>>powerful options for compiling? So that if a VB programer wanted to they
>>could do away with the runtime and make a stand alone EXE?
>>
>>Thanks again,
>>
>>Ossu
>

Ossu,
I too miss DOS on a certain level, but with cool features comes complexity
- and yes - more DLLs. As far as what .NET will provide in the way of simplifying
the way things are today .... we'll just have to wait and see.

-Jonathan
"Ossu Chang" <ossu@netzero.net> wrote:
>
>I understand what you are saying, and I agree. But will .NET allow you to
>make an application that is truely stand alone. meaning here is my EXE and
>that is my entire program. I dont think so. In todays world I dont even
think
>you can REALLY do this anymore. I mean even if you write directly to the
>API so when you compile you have a single (C,C++) EXE. That EXE still depends
>on hundreds of DLLs that are shipped with Windows.
>
>I miss DOS..... ;-)
>
>"Jonathan Morrison" <jonathanm@mindspring.com> wrote:
>>
>>Ossu,
>>You have touched on a very sensitive subject that has been debated in countless
>>forums by very smart people (smarter than me that is :-) ). That not withstanding,
>>here is my two-cents worth (My book also has a section that talks about
>this
>>very thing).
>>
>>VB5 introduced the ability to create a native .exe file in Visual Basic
>with
>>no runtime interpreter required. This meant that a Visual Basic app now
>contained
>>native machine instructions that could execute right on the chip just like
>>a C++ application. However, the VB team still put all of the VB language
>>calls like Mid$, Asc, InStr and MsgBox in the MSVBVM50.DLL/MSVBVM60.DLL.
>>So even though you no longer required the MSVBVM50.DLL/MSVBVM60.DLL to
run.....
>>well - you still required them to run! A lot of people thought that they
>>should have made a "light weight" version of the DLL for native .exe VB
>apps,
>>but they didn't
>>Now, as not to cast aspersions without investigation - C++ apps built with
>>MFC (the C++ equivalent of VB) require a huge runtime library. In fact,
>distributing
>>them is just about as painful as distributing VB apps.
>>The upside is that .NET makes a lot of this go away. All languages will
>be
>>interpreted in .NET so that it there will be no requirement for a runtime
>>library.
>>
>>Hope this answers your question.
>>
>>Thanks,
>>Jonathan
>>"Ossu Chang" <ossu@netzero.net> wrote:
>>>
>>>I am getting pretty feed up with the hugh runtime required by VB. Do you
>>think
>>>MS has any plans to make an option to keep the BASIC language but make
>more
>>>powerful options for compiling? So that if a VB programer wanted to they
>>>could do away with the runtime and make a stand alone EXE?
>>>
>>>Thanks again,
>>>
>>>Ossu
>>
>