"Native" Code in VB6

[Douglas]

Hi all,

Could someone please verify this statement:

>I believe that VB6 can generate native code .EXE

Visual Basic does indeed have options to compile to either pcode or native
code. I personally don't know what the difference is but it still requires
the Visual Basic virtual machine to run (MSVBVM60.DLL). Put simply, Visual
Basic is still an interpreter and not a real compiler despite what it might
claim. This poses a problem because DESlock cannot be in control of the
application when it is executed and thus we cannot be 100% happy with the
security DESlock provides.

Thanks,
Doug

[Mattias Sjögren]

Douglas,

>Put simply, Visual
>Basic is still an interpreter and not a real compiler despite what it might
>claim.

Not true. When you compile to native code, you get the real thing, and
the runtime file does not perform any interpretation at runtime. The
runtime file is still needed, but for completely different reasons.


Mattias

____________________________________________
Mattias Sjögren - mattiass @ hem.passagen.se
http://hem.spray.se/mattias.sjogren/
Docendo discimus

[Matthew Solnit]

In addition to what Mattias said, I would like to add that Visual C++
programs also need a runtime library, but it's included with Windows so you
don't have to distribute it. Also, Visual C++ has an option to statically
link the library, which means that it's all packed into the EXE.

I'm posting this because people always think of VB as some sort of freak
exception, which is just not true.

The only way to avoid a run-time library under Windows is to write in
Assembler... I think. Please correct me if appropriate

-- Matthew Solnit
msolnit@yahoo.com

"Douglas" <hot_n_cold_2000@hotmail.com> wrote in message
news:38fcb71f@news.devx.com...
> Hi all,
>
> Could someone please verify this statement:
>
> >I believe that VB6 can generate native code .EXE
>
> Visual Basic does indeed have options to compile to either pcode or native
> code. I personally don't know what the difference is but it still requires
> the Visual Basic virtual machine to run (MSVBVM60.DLL). Put simply, Visual
> Basic is still an interpreter and not a real compiler despite what it
might
> claim. This poses a problem because DESlock cannot be in control of the
> application when it is executed and thus we cannot be 100% happy with the
> security DESlock provides.
>
> Thanks,
> Doug
>
>

[Adam Dawes]

Visual C++ only requires a runtime library (MFC42.dll or similar) if MFC is
actually being used. If you write an application in standard C++ without
using any of the MFC classes, you don't need to distribute the MFC DLL *or*
link it with your project. That's a somewhat easier way of writing
stand-alone executables than using assembly language. :-)

--

Adam.


Matthew Solnit <msolnit@yahoo.com> wrote in message
news:38fdae22@news.devx.com...
> In addition to what Mattias said, I would like to add that Visual C++
> programs also need a runtime library, but it's included with Windows so
you
> don't have to distribute it. Also, Visual C++ has an option to statically
> link the library, which means that it's all packed into the EXE.
>
> I'm posting this because people always think of VB as some sort of freak
> exception, which is just not true.
>
> The only way to avoid a run-time library under Windows is to write in
> Assembler... I think. Please correct me if appropriate
>
> -- Matthew Solnit
> msolnit@yahoo.com

[Phil Weber]

> Visual C++ only requires a runtime library (MFC42.dll
> or similar) if MFC is actually being used.

Adam: This does illustrate, however, that the fact that an .EXE requires a
runtime does not necessarily indicate that it is not native code, as Doug
asserted in the message that started this thread.
---
Phil Weber

[=?iso-8859-1?Q?Herv=E9?= Thouzard]

Matthew Solnit wrote:
>
> The only way to avoid a run-time library under Windows is to write in
> Assembler... I think. Please correct me if appropriate
write windows programs with "pure" C (no mfc) and you don't have any
runtimes...

Bye,
Hervé

[Jim Pragit]

Or as someone else put it, compilers compile, linkers link.

- Jim

"Phil Weber" <pweber@teleport.com> wrote:
> > Visual C++ only requires a runtime library (MFC42.dll
> > or similar) if MFC is actually being used.
>
>Adam: This does illustrate, however, that the fact that an .EXE requires
a
>runtime does not necessarily indicate that it is not native code, as Doug
>asserted in the message that started this thread.
>---
>Phil Weber

[Dan Barclay]

On Tue, 18 Apr 2000 21:28:22 +0200, "Douglas"
<hot_n_cold_2000@hotmail.com> wrote:

>Hi all,
>
>Could someone please verify this statement:
>
>>I believe that VB6 can generate native code .EXE
>
>Visual Basic does indeed have options to compile to either pcode or native
>code. I personally don't know what the difference is

I do, and others here do as well.

>but it still requires
>the Visual Basic virtual machine to run (MSVBVM60.DLL). Put simply, Visual
>Basic is still an interpreter and not a real compiler despite what it might
>claim.

The runtime module contains *both* the interpreter engine as well as
the runtime library. The interpreter engine is only around 100k of
the total file size. MS considered (very briefly) shipping the
interpreter engine as a separate file but, as you can see, the impact
would be very small on the overall file size. They left it in the
main library to simplify distribution issues.

EXE's compiled to native code are just that. Compiled to native code.
They do not use the interpreter engine, even though the engine gets to
go along for the ride.

Dan

[Matthew Solnit]

What about msvcrt.dll?

"Adam Dawes" <adam.dawes@editrack.com> wrote in message
news:38fdbdcd$1@news.devx.com...
> Visual C++ only requires a runtime library (MFC42.dll or similar) if MFC
is
> actually being used. If you write an application in standard C++ without
> using any of the MFC classes, you don't need to distribute the MFC DLL
*or*
> link it with your project. That's a somewhat easier way of writing
> stand-alone executables than using assembly language. :-)