3 ms·

You can sort of imagine that there is a faction that hates the idea of moving to managed code, and that is causing an impasse. Personally, attaching a managed

You can sort of imagine that there is a faction that hates the idea of moving to managed code, and that is causing an impasse. Personally, attaching a managed code port to the 64-bit migration sounds misguided. The managed code port sounds much more involved and disruptive than migrating the existing native code would be. It's probably some manager's pet project and it makes no technical sense.

wtetzner 10y ago
There are already large chunks of managed code in VS. It might be that they are pushing to fully convert to managed code for other reasons, and as a side benefit they get 64-bit support for "free".
- mtdewcmu 10y ago
  Probably the parts that are still in native code include stuff that is performance-sensitive, like the guts of the compilers. It's probably intricate and finely-tuned.
  - pjmlp 10y ago
    Only C++ ones, the main goal of Roslyn was to bootstrap C# and VB.NET compilers and get rid of their former C++ implementation. Now with Roslyn and .NET Native, they are planning to increasingly move more runtime stuff into C#. .NET Native backend is of course shared with Visual C++, aka C2, a kind of Microsoft's own LLVM-like approach.
    - mtdewcmu 10y ago
      .NET Native is new to me. It looks like it helps CIL languages to perform better. I'm not sure what it does to C/C++. I can't tell what the grand strategy is, but I guess they are catching up to Apple in some ways. It's amazing what Microsoft's resources allows them to do. Apple uses LLVM, and, of course, they would not be Microsoft if they adopted LLVM. Microsoft writes their own LLVM from scratch. I think it's good to have additional implementations, even if they are rather insular about it.
      - pjmlp 10y ago
        Actually Microsoft had their own LLVM first. :) It was called Project Phoenix, developed at MSR. https://en.wikipedia.org/wiki/Phoenix_(compiler_framework) https://en.wikipedia.org/wiki/Phoenix_(compiler_framework)
        mtdewcmu 10y ago
        Microsoft Research is the genuine article. It's a world class research institution. I guess Phoenixey/LLVM type stuff is probably the way the winds were blowing in the compiler community at large. It's interesting how a lot of things that used to seem impossible are now in multiple software packages. You figure that once MS is rolling out a compiler technology in a big way, it can't get much more mainstream than that. I still don't totally understand why it was important for MS to push into JIT-compiled bytecode on Windows. From the end-user's standpoint, it just makes software slower.
        Const-me 10y ago
        Security, safety. Also GC is easier to make. It doesn’t always makes software slower. Not all software is CPU bound, a lot is IO bound, and .NET framework implements event-based asynchronous I/O since version 1.0.
pjmlp 10y ago
> You can sort of imagine that there is a faction that hates the idea of moving to managed code, and that is causing an impasse. Probably the same one that caused the issues with Longhorn. Now we have UWP with .NET Native, which is creating an OO ABI similar to Longhorn ideas.

wtetzner 10y ago

There are already large chunks of managed code in VS. It might be that they are pushing to fully convert to managed code for other reasons, and as a side benefit they get 64-bit support for "free".

mtdewcmu 10y ago
Probably the parts that are still in native code include stuff that is performance-sensitive, like the guts of the compilers. It's probably intricate and finely-tuned.
- pjmlp 10y ago
  Only C++ ones, the main goal of Roslyn was to bootstrap C# and VB.NET compilers and get rid of their former C++ implementation. Now with Roslyn and .NET Native, they are planning to increasingly move more runtime stuff into C#. .NET Native backend is of course shared with Visual C++, aka C2, a kind of Microsoft's own LLVM-like approach.
  - mtdewcmu 10y ago
    .NET Native is new to me. It looks like it helps CIL languages to perform better. I'm not sure what it does to C/C++. I can't tell what the grand strategy is, but I guess they are catching up to Apple in some ways. It's amazing what Microsoft's resources allows them to do. Apple uses LLVM, and, of course, they would not be Microsoft if they adopted LLVM. Microsoft writes their own LLVM from scratch. I think it's good to have additional implementations, even if they are rather insular about it.
    - pjmlp 10y ago
      Actually Microsoft had their own LLVM first. :) It was called Project Phoenix, developed at MSR. https://en.wikipedia.org/wiki/Phoenix_(compiler_framework) https://en.wikipedia.org/wiki/Phoenix_(compiler_framework)
      - mtdewcmu 10y ago
        Microsoft Research is the genuine article. It's a world class research institution. I guess Phoenixey/LLVM type stuff is probably the way the winds were blowing in the compiler community at large. It's interesting how a lot of things that used to seem impossible are now in multiple software packages. You figure that once MS is rolling out a compiler technology in a big way, it can't get much more mainstream than that. I still don't totally understand why it was important for MS to push into JIT-compiled bytecode on Windows. From the end-user's standpoint, it just makes software slower.
        Const-me 10y ago
        Security, safety. Also GC is easier to make. It doesn’t always makes software slower. Not all software is CPU bound, a lot is IO bound, and .NET framework implements event-based asynchronous I/O since version 1.0.

pjmlp 10y ago

> You can sort of imagine that there is a faction that hates the idea of moving to managed code, and that is causing an impasse. Probably the same one that caused the issues with Longhorn. Now we have UWP with .NET Native, which is creating an OO ABI similar to Longhorn ideas.