Re: D8 may be 32 bit only

From: Dennis Landi ([none][at][none][dot][com])
Date: 03/18/04 

Date: Thu, 18 Mar 2004 10:25:13 -0500

"Craig Stuntz [TeamB]" <cstuntz@nospam.please [a.k.a. vertexsoftware.com]>
wrote in message

> > Compilation of the IL
> > specifically for the CPU target to ensure "bitness"-awareness in the
> > compiled assembly is the issue.
>
> No, I strongly disagree. IL does not have a "target CPU." It targets
> the CLR.
>

You disagree about what the topic of conversation is about?

Here is the intor to the Blog post:
<quote>
I mentioned that the 1.0/1.1 compilers didn't know anything about "bitness".
Basically they spit out a PE image that said "Hey! I'm managed! Run me with
the CLR!" (gross simplification), whereas the v2.0 compilers produce images
that range from "Hey! I'm managed, and I can run everywhere!!" to "Hey! I'm
managed and I only run on x86!" etc...
This brings us to the fundamental question of this post -- what to do with
1.0/1.1 assemblies?

Option 1: call them "Legacy" assemblies since they don't know about
 "bitness". Require them to run in the WOW64 under the 32bit CLR as we
can't say for sure that the developer who created them was thinking about
64bit compatibility when they were created (remember that many of these were
created years before even a 64bit alpha of .NET was available at PDC last
year). Additionally, make the loader get angry and spew something along the
lines of "BAD_IMAGE_FORMAT" if you try to load a legacy assembly in a native
64bit managed process just as if you had tried to load a v2.0 assembly
marked x86 only.

Option 2: treat them like the v2.0 notion of MSIL assemblies, allow them to
be used from both 32bit and 64bit managed processes. By default if they are
an exe kick off the 64bit CLR when someone tries to start them. This would
cause them to run as a 64bit process even though their creators probably
didn't have that potential in mind when the code was written and tested.
</quote>

That's what the topic of converstation is about. In a nutshell "universal
deployment" based on assumptions of developer intent, versus strict CLR
run-time constraints bases upon the "bitness" flags of the assembly.

But if you still disagree with me about what we are talking about, FINE. I
won't pursue you... <eg>.

-d

Relevant Pages

  • Re: Can not reuse mixed-mode functions in VC++
    ... By a mixed-mode function I mean a function whose signature has one or more CLR types and one or more non-CLR types. ... This worked fine, but because of the loader lock bug, I did not pursue my use of C++ mixed-mode programming in .NET assemblies. ... Trying the exact same thing I did in VS 2003, I now receive the error message telling me, for the mixed-mode functions, that a function with the clr calling convention can not be exported. ... In fact the native wrapper type has been defined as a private type for some good reasons. ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Reflection permission denied
    ... In order for the CLR to know where your code came from, ... uses a host to give it information about your code. ... The CLR then performs a permission grant based on the evidence from ... >> assemblies are not allowed to create application domains. ...
    (microsoft.public.dotnet.security)
  • Complex Problem with AppDomains, Assembly Loading Contexts and COM Interop
    ... My team has been struggling with an issue involving assemblies ... extension running in a third party executable via COM Interop. ... C++ code (say to custom host a CLR). ... mechanism and end up in the default loading context. ...
    (microsoft.public.dotnet.framework)
  • Complex Problem with AppDomains, Assembly Loading Contexts and COM Interop
    ... My team has been struggling with an issue involving assemblies ... extension running in a third party executable via COM Interop. ... C++ code (say to custom host a CLR). ... mechanism and end up in the default loading context. ...
    (microsoft.public.dotnet.framework.interop)
  • Re: Using COM DLLs from SQL
    ... Your subject line says it's a COM dll, which means that all the CLR stuff is ... You have to add the assembly to the database. ... of assemblies loaded into the database. ...
    (microsoft.public.sqlserver.programming)