DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 6 of 6

Thread: Who will port VB.NET?

  1. #1
    Patrick Steele Guest

    Who will port VB.NET?


    There's been some discussion on the DevelopMentor DOTNET mailing list
    about possible porting issues with VB.NET developed apps due to their
    reliance on Microsoft.VisualBasic.* namespaces.

    Of course, this issue assumes the CLR gets ported. But, supposing it
    does -- will Microsoft also port the Microsoft.VisualBasic.* namespaces
    too? Or will VB.NET apps only get ported in "version 2" of the Linux
    CLR (for example)?

    Does anyone see this as a possible issue with developing VB.NET apps?
    Does C# have some "advantage" because it doesn't seem to have any
    reliance on a Microsoft.CSharp namespace?

    --
    Patrick Steele
    (psteele@ipdsolution.com)
    Lead Software Architect
    Image Process Design

  2. #2
    Mattias Sjögren Guest

    Re: Who will port VB.NET?

    Patrick,

    >Of course, this issue assumes the CLR gets ported. But, supposing it
    >does -- will Microsoft also port the Microsoft.VisualBasic.* namespaces
    >too?


    If a company can produce a VB.NET compiler for another platform, they
    can surely create a runtime library compatible with
    Microsoft.VisualBasic.dll too.


    Mattias

    ====================================
    Mattias Sjögren - mattias @ mvps.org

  3. #3
    Patrick Steele Guest

    Re: Who will port VB.NET?

    In article <3af2d1c6.54284456@news.devx.com> (from Mattias Sjögren
    <mattias.dont.want.spam@mvps.org>),
    > Patrick,
    >
    > >Of course, this issue assumes the CLR gets ported. But, supposing it
    > >does -- will Microsoft also port the Microsoft.VisualBasic.* namespaces
    > >too?

    >
    > If a company can produce a VB.NET compiler for another platform, they
    > can surely create a runtime library compatible with
    > Microsoft.VisualBasic.dll too.


    Why is a new compiler required? Can't we just run the (machine
    independant?) MSIL on any platform where the CLR resides?

    --
    Patrick Steele
    (psteele@ipdsolution.com)
    Lead Software Architect
    Image Process Design

  4. #4
    Mattias Sjögren Guest

    Re: Who will port VB.NET?

    Patrick,

    >Why is a new compiler required? Can't we just run the (machine
    >independant?) MSIL on any platform where the CLR resides?


    I guess it depends on which platform you're talking about. Even if IL
    is platform independent, it's still put into PE binaries, with a small
    piece of native bootstrap code.

    I don't know which platforms do and do not use the same PE executable
    format. But for those that don't, you'd either need a compiler for
    that platform, or some kind of bootstrap executable that can read the
    IL in the PE files.


    Mattias

    ====================================
    Mattias Sjögren - mattias @ mvps.org

  5. #5
    David Bayley Guest

    Re: Who will port VB.NET?

    Patrick,

    > Why is a new compiler required? Can't we just run the (machine
    > independant?) MSIL on any platform where the CLR resides?


    Yep, and that applies to the V.B.dll as well ;-)

    The portability problem discussed will apply to any native calls to the
    Win32 API. A large part (a huge majority even) of the CLR frameworks,
    appear to be just wrappers around native Win32 libraries. V.B.dll in the
    main, just calls upon the CLR frameworks. The "Beep" statement (as
    discussed on the developMentor list) is the first native call I've come
    across in V.B.dll, and I would be suprised if even that is moved into the
    frameworks.

    In short, yes porting the CLR frameworks is a huge job because of it's
    dependancy on Win32. The V.B.dll is a drop in the ocean by comparison.

    --
    David.




  6. #6
    David Bayley Guest

    Re: Who will port VB.NET?

    David Bayley wrote ...

    > The "Beep" statement (as
    > discussed on the developMentor list) is the first native call I've come
    > across in V.B.dll, and I would be suprised if even that is moved into the
    > frameworks.


    Correction... I would be surprised if even that is *not* moved into the
    frameworks.

    > In short, yes porting the CLR frameworks is a huge job because of it's
    > dependancy on Win32. The V.B.dll is a drop in the ocean by comparison.


    Emphasis... And if there are no other native calls in V.B.dll it will be
    100% portable, and also any VB.NET code that uses it. (Yep, "AndAlso" fits
    in with BASIC semantics, I feel a devil's advocate arising!!)

    --
    David.




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