speaking of which ..

[ASHBeN]

What is meant by "Unmanaged Code"?

[Robert Scoble]

Code that runs outside of the .NET Common Language Runtime.

See the FAQs at http://www.devx.com/dotnet/resources/

--

Robert Scoble
Editor, Conferences
http://www.thunderlizard.com -- CONFERENCES WITH CONTENT
A subsidiary of Fawcette Technical Publications, Inc.

###
"ASHBeN" <NOSPAM@ashben.8m.com> wrote in message
news:3a123e45$1@news.devx.com...
>
> What is meant by "Unmanaged Code"?
>

[Zane Thomas]

Robert,

> Code that runs outside of the .NET Common Language Runtime.

Which includes things like creating and using DIB sections. As it turns out
the best way to get graphics performance - at this time anyway - in vs.net
is to use DIB sections. Unfortunately API calls are required to use DIB
sections and so the calling code should be attributed as being unmanaged.
In the case of components, that propagates to any code which uses the
component and right on up to the assembly level.

Zane

[Alan Carter [MSFT]]

VB will not support "unmanaged code". Of the Visual Studio languages,
unmanaged code
is only supported by VC++.
There is no problem calling into unmanaged code from managed code except
that the
execution of any unmanaged code requires that the code be fully trusted.

Alan Carter
VB Language PM
Microsoft

"Zane Thomas" <zane@mabry.com> wrote in message
news:3a12ff21$1@news.devx.com...
> Robert,
>
> > Code that runs outside of the .NET Common Language Runtime.
>
> Which includes things like creating and using DIB sections. As it turns
out
> the best way to get graphics performance - at this time anyway - in vs.net
> is to use DIB sections. Unfortunately API calls are required to use DIB
> sections and so the calling code should be attributed as being unmanaged.
> In the case of components, that propagates to any code which uses the
> component and right on up to the assembly level.
>
> Zane
>
>
>

[Zane Thomas]

On Wed, 15 Nov 2000 20:14:40 -0800, "Alan Carter [MSFT]"
<alanc@microsoft.com> wrote:

>There is no problem calling into unmanaged code from managed code except
>that the execution of any unmanaged code requires that the code be
>fully trusted.

Minor details? :-)

Apparently primarily due to the alpha-blending stuff and the fact that
gdi+ uses 32bits internally for bitmap manipulation, drawing with gdi+
while reasonably fast still pales in comparison to using dib sections.
It's a pity that getting good performance requires trust from code which
wouldn't ordinarily need it. I hope y'all can do something to get a
dibsection into the framework by beta 2.



---
Ice Z - Straight Outta Redmond

[Ray Mercer]

"Zane Thomas" <zane@mabry.com> wrote in message
news:3a1d6b19.725506984@news.devx.com...

> Apparently primarily due to the alpha-blending stuff and the fact that
> gdi+ uses 32bits internally for bitmap manipulation, drawing with gdi+
> while reasonably fast still pales in comparison to using dib sections.
> It's a pity that getting good performance requires trust from code which
> wouldn't ordinarily need it. I hope y'all can do something to get a
> dibsection into the framework by beta 2.

The main problem here is that they *won't* be able to put everything in the
framework (AViFile* functions, Vidcap, mmio, DrawDIB*, etc...) and that
naturally means that as soon as you need something that is not in there you
are shafted.

-Ray

[Michael \(michka\) Kaplan]

Well, shafted is a relative term.... it just means the new security model is
useless to you. As a feature, it does not make much sense in a LOT of
situations until/unless the OS is a lot more something that can be trusted
in large part.

--
MichKa

a new book on internationalization in VB at
http://www.i18nWithVB.com/

"Ray Mercer" <raymer@mvps.org> wrote in message
news:3a137b30@news.devx.com...
>
> "Zane Thomas" <zane@mabry.com> wrote in message
> news:3a1d6b19.725506984@news.devx.com...
>
> > Apparently primarily due to the alpha-blending stuff and the fact that
> > gdi+ uses 32bits internally for bitmap manipulation, drawing with gdi+
> > while reasonably fast still pales in comparison to using dib sections.
> > It's a pity that getting good performance requires trust from code which
> > wouldn't ordinarily need it. I hope y'all can do something to get a
> > dibsection into the framework by beta 2.
>
> The main problem here is that they *won't* be able to put everything in
the
> framework (AViFile* functions, Vidcap, mmio, DrawDIB*, etc...) and that
> naturally means that as soon as you need something that is not in there
you
> are shafted.
>
> -Ray
>
>