8 ms·

Windows 10 and .NET Native

158 points by WhitneyLand 11y ago

greggman 11y ago
How do I verify the app I downloaded was made by the developer? I suppose on phones there's no way to do that now anyway or at least I don't know how on iOS. My point being if ms is compiling then how do I sign the executable as proof it's from me?
- pcunite 11y ago
  Good question. I assume you upload a cert? My question: what happens when I side load on my phone with a different compiler but ship it to MS who uses a different version and the app runs differently?
- neurostimulant 11y ago
  Probably MS will re-sign it with their certificate, like what Apple did in their app store.
jameshart 11y ago
One consequence of these 'app store compiled' models is that the compilation units you upload will have to be licensed to the app store in such a way that the derived native apps are legitimately licensed. That probably rules out, for example, even including LGPL libraries in your app, since the resulting application will statically compile that library code in with .NET components.
- dchest 11y ago
  LGPL doesn't forbid static linking, you'll just have to provide linkable object files (or source code) separately to enable re-linking. (https://www.gnu.org/copyleft/lesser.html#section4 https://www.gnu.org/copyleft/lesser.html#section4)
GermainSmith 11y ago
I don't see why anybody should be surprised about the swing back to Ahead-of-Time compiled native code. I'm actually surprised it has taken as long as it has. Although interpretation and Just-in-Time compilation were not new ideas at the time, Java first brought them to a wide audience around 20 years ago with its use of the JVM. Anyone who remembers those times, and even many years beyond then, will remember how slow JVM-based applications were compared to native apps. Even today, there's still a noticeable difference between JVM-based software and native software, although the exceptionally massive increase in computation power have rendered the differences easier to overlook in many cases. Since then we've seen similar techniques used by a variety of other platforms. Despite many years of effort and research, and much investment, we've yet to see Just-in-Time compilation rival Ahead-of-Time compilation in terms of the performance. While Just-in-Time's supporters will claim that it allows for better optimization or better portability, or they can show some contrived benchmarks where it has a slight edge, we haven't seen such techniques stand up in the real world. Ahead-of-Time C and C++ compilers have consistently compiled software that's very fast, lean, and the best performer in real-world scenarios. For years, we've had people pointing out this very obvious reality regarding how Ahead-of-Time compilation proves to be superior to Just-in-Time compilation in realistic scenarios. Yet we've seen their claims very forcefully denied by the Just-in-Time advocates. Maybe after 20 years, it has finally become clear that the Just-in-Time supporters were wrong, and that Ahead-of-Time compilation is the better approach. With battery-powered devices more prevalent than ever, the need for high-performing and efficient binaries is greater than it has ever been. Returning to Ahead-of-Time compilation is just what we need given these circumstances. It's just a real shame it has taken so long for this important reality to be recognized.
- brianwawok 11y ago
  I mean, it's almost a moot point. Each year the number of native apps I run goes down by a couple, and the number of webapps I use go up by a few. Native apps I use right now? Chrome - Already native compiled IntelliJ - Full JIT mode, but due to the fact I start it once and run it for a month, not a huge deal. Command line unixy stuff - Already native compiled (On gaming computer) Games - Already native compiled I mean desktop apps DO exist, but just not that many to use day to day... from what I have seen of the windows app store, I can find 20 colors of calculator apps, but nothing that impressive.
mrec 11y ago
> they [desktop apps] really want to move to the new app platform anyway 1. Stop anthropomorphizing desktop apps, they don't like it. 2. Can't tell if the author means "desktop devs want to" (false IMO), "desktop devs ought to" (also false IMO) or "MS wants desktop devs to" (undeniably true). 3. It depresses me that just as MS is genuinely 'getting' open source, they're completely missing the appeal and value of an open platform. One step forward, two steps back. EDIT:typo
- bitwize 11y ago
  I think the referent for "they" here is "Microsoft", not "desktop apps".
- bad_user 11y ago
  I don't see how MS is getting open source. What makes people say that? Is it the 14 years it took for them to open-source .NET Core, an event that is happening at a point in time when .NET is most irrelevant? What really pisses me off however is that it's 2015 and Windows 10 and Outlook still don't support CardDAV and CalDAV. They'll get their hand forced by market pressure of course and as usual they'll end up supporting the minimum they can to get away with, which means they'll provide special hooks for Google and probably iCloud. All of this in the context of Edge, yet another buggy and proprietary incarnation of IExplorer in a world in which Chromium and Firefox exist. And of course, we mustn't forget the patents racketeering they are doing at the expense of the open-source projects that compete with them But oh boy did they change. Their PR department is genius though.
- edgyswingset 11y ago
  > "MS wants desktop devs to" (undeniably true) What makes you say this, the publishing of a third app model for Windows, messaging, some combination of the two, something else?
  - mrec 11y ago
    Both, plus the fact that significant new tech infrastructure projects like the Windows Runtime are (mostly) restricted to Store apps. I'm not anti- app stores or declarative UI in general, and I think things like standardized sandboxing would be great for many desktop apps too. But a platform that places you at the whim of a single distribution path, and cripples portability to boot, isn't worth it.
stevoski 11y ago
I'd love to have the JVM equivalent of this for my company's main desktop product, written in Java. Due to being Java (and having an embedded JRE) the app has slow startup, due to the JVM having to be started up. The installer is 90 MB on OS X, 55 MB on Windows, much of which is the embedded JRE. So our our fortnightly updates are much bigger than they need to be. We tried an AOT compiler called JET. It was fine, albeit expensive. But it has an extremely long build time, no great for our continuous build system. It's support Java version also lags considerably behind the current Oracle Java release.
- mwcampbell 11y ago
  Check out Avian (http://oss.readytalk.com/avian/ http://oss.readytalk.com/avian/). You can use it with the OpenJDK class library. You can even run your application plus the class library through ProGuard, then AOT-compile the whole thing to generate a boot image for fast startup.
- pjmlp 11y ago
  Oracle is planning to finally add it to the standard JDK around Java 10 timeframe, but it might be a premium feature similar to the mission control licensing. https://www.youtube.com/watch?v=Xybzyv8qbOc&list=PLX8CzqL3ArzUo2dtMurvpUTAaujPMeuuU&index=16 https://www.youtube.com/watch?v=Xybzyv8qbOc&list=PLX8CzqL3Ar...
- jacques_chester 11y ago
  As I understand it, a big part of the slow load time for Java apps is sucking everything on the classpath into RAM, even though most apps will use a fraction of the classes that are loaded. Java 9's module system should make that a lot less of a problem by giving the JVM guidance on what it should load and skip. I am not a Java expert, though, so I may have misunderstood what's going on.
  - fiatmoney 11y ago
    The JVM class loader by default reads a class on first reference to it in the code it's executing. Never refer to it, never gets loaded. Startup on the JVM is more affected by the JIT warming up, and the heap getting into a "stable" configuration.
simfoo 11y ago
> At this time, it is not available for desktop apps, although that is certainly something that could come with a future update. It’s not surprising though, since they really want to move to the new app platform anyway. Thanks, but no thanks. I'm not investing time and effort into a toolchain that ultimately targets only a single platform, namely Windows 10, because they don't want me to be able to just xcopy a .exe without touching their store
deleted 11y ago
[deleted]
saosebastiao 11y ago
It's frustrating that the .NET Native compilation is so tied to the Rosylyn toolchain that it can't be used for other languages like F#, even though they're using the same IR.
- sixbrx 11y ago
  Yeah this seams to me like a repudiation of the whole idea of .NET, as a multi-language system. They may add support for F# later, but by that time, the damage will have been done because the message is clear: "use anything other than C# or VB at your own peril". Currently F# is completely shut out - it can't even be used to make libraries to be included in these kinds of apps! That makes it more dangerous career-wise to use F# going forward, lest your team get wedged into a position of having to rewrite one of your libraries because of your choice of using your "pet" language. Not good for the career. The whole point of bytecode is to make things like this language independent. Big failure of vision to let this group do such a hack, IMO.
  - kevingadd 11y ago
    This is most likely just an artifact of F# producing unusual IL that's harder to handle. In my experience, it's less 'we only support C#' and more 'compilers other than C#/VB.net produce very strange IL that is hard to handle well' - which is true. Given the small # of users that rely on those weird compilers, it's hard to justify supporting them first, especially if they aren't performance-sensitive.
    - MichaelGG 11y ago
      I emailed the .NET Native team asking them about this. They confirmed that they reverse out IL to higher-level constructs. So they aren't really working at the IL level, they're working on C# represented as IL. This isn't entirely uncommon. A lot of code that deals with Expression<T> does so very poorly and won't work on many valid trees because they weren't able to get C# to emit certain expressions.
  - MichaelGG 11y ago
moomin 11y ago
You know, this is all very well, but the Windows 10 app market is pretty much non-existent. You know who really uses .NET on Windows? LOB applications, front ends to complex systems. The kind of thing you don't see in the app store. And that market is better served with, you know, a compiler, that runs on the command line, on a machine under a developer's control.
- MichaelGG 11y ago
  The Windows Store was traditionally just scams with blatant trademark infringement. This has severely damaged their rep. A quick search now shows a lot of it is cleared up. Unfortunately, that just leaves the shovelware junk. Here is an interesting point: Right now, the #3 top free app is "Freeflix/Free Movies Unlimited"[1] and #4 is a "free Mp3 downloader". The publisher for the free movies is "Wamba Dev" which results in no related hits on Google outside of Windows Store. Contact is a hotmail account, and the privacy policy is on "dopeware.com". So Microsoft isn't even able to get real publishers in top positions on its own Store. Pretty damn sad. Also the Metro runtime is diseased and broken. Opening the Store app right now to do these searches took about 15 seconds. On a decently high-end ThinkPad. It's embarrassingly bad. Even the Metro calc takes 2-3 seconds to open, ffs. 1: https://www.microsoft.com/en-nz/store/apps/freeflix-free-movies-unlimited/9nblggh1z0m4 https://www.microsoft.com/en-nz/store/apps/freeflix-free-mov...
graycat 11y ago
I just wrote 18,000 programming language statements in Visual Basic .NET, in files with 80,000 lines including comments, blank lines, etc., compiled much of it with a command line script with line programPath = dq || SystemRoot || , '\Microsoft.NET\Framework\v4.0.30319\vbc.exe' || dq and give the rest to the Microsoft Internet Information Server (IIS) to compile and run as Web pages, and it all works, but, still, I can't make any sense out of the OP at all. E.g., my command line compiles result in a file with extension EXE. What's in that? Sure, I have the Microsoft .NET Framework 4.0 installed, and the VBC.EXE invoked as above is, of course, one of the files in the installation of that .NET Framework. When from a command line I just run that script that runs that VBC.EXE, I get nice output showing the command line options for the program -- simple, direct, explicit, terrific. So, how do I connect what that .NET Framework 4.0 VBC.EXE does with the discussion in the OP? BTW: Why use Visual Basic .NET instead of C#? C# borrows too much of the old C syntax, and Visual Basic has syntax more traditional and more like that of Pascal, PL/I, Fortran, etc., and I find that more traditional syntax easier to write and read and less error prone. But, likely and apparently, the difference between C# and Visual Basic .NET is mostly just syntactic sugar anyway. By the way, where does the famous CLR -- common language runtime -- enter this picture? Thanks.
- kyberias 11y ago
  What?
  - graycat 11y ago
    What part of my question do you not understand?
    - marvy 11y ago
      What is the question?
      - graycat 11y ago
        The question was: > So, how do I connect what that .NET Framework 4.0 VBC.EXE does with the discussion in the OP?
redcalx 11y ago
Every poorly performance problem I've ever encountered has been due to poor design choices, poor choice of algorithm or, most often, badly implemented algorithms. Once past the JIT compilation delay the execution speed is not significantly different for AOT and JIT code for mature platforms such as .Net and Java. There are issues in CPU and RAM resource limited systems such as mobiles and embedded systems. And also web servers - where small improvements in scalability can dramatically affect business viability and profitability.
- MichaelGG 11y ago
  IIRC the .NET Native literature says the main benefits are reducing RAM by a fair amount. Which makes sense - no runtime to load type info and no JIT to run. AFAIK, they aren't claiming the compiled code is _that_ much better than what the JIT does. Of course it's probable that reducing RAM footprint significantly might improve runtimes if it makes better use of cache.

158 points by WhitneyLand 11y ago

How do I verify the app I downloaded was made by the developer? I suppose on phones there's no way to do that now anyway or at least I don't know how on iOS. My point being if ms is compiling then how do I sign the executable as proof it's from me?

pcunite 11y ago
Good question. I assume you upload a cert? My question: what happens when I side load on my phone with a different compiler but ship it to MS who uses a different version and the app runs differently?
neurostimulant 11y ago
Probably MS will re-sign it with their certificate, like what Apple did in their app store.

jameshart 11y ago

One consequence of these 'app store compiled' models is that the compilation units you upload will have to be licensed to the app store in such a way that the derived native apps are legitimately licensed. That probably rules out, for example, even including LGPL libraries in your app, since the resulting application will statically compile that library code in with .NET components.

dchest 11y ago
LGPL doesn't forbid static linking, you'll just have to provide linkable object files (or source code) separately to enable re-linking. (https://www.gnu.org/copyleft/lesser.html#section4 https://www.gnu.org/copyleft/lesser.html#section4)

GermainSmith 11y ago

I don't see why anybody should be surprised about the swing back to Ahead-of-Time compiled native code. I'm actually surprised it has taken as long as it has. Although interpretation and Just-in-Time compilation were not new ideas at the time, Java first brought them to a wide audience around 20 years ago with its use of the JVM. Anyone who remembers those times, and even many years beyond then, will remember how slow JVM-based applications were compared to native apps. Even today, there's still a noticeable difference between JVM-based software and native software, although the exceptionally massive increase in computation power have rendered the differences easier to overlook in many cases. Since then we've seen similar techniques used by a variety of other platforms. Despite many years of effort and research, and much investment, we've yet to see Just-in-Time compilation rival Ahead-of-Time compilation in terms of the performance. While Just-in-Time's supporters will claim that it allows for better optimization or better portability, or they can show some contrived benchmarks where it has a slight edge, we haven't seen such techniques stand up in the real world. Ahead-of-Time C and C++ compilers have consistently compiled software that's very fast, lean, and the best performer in real-world scenarios. For years, we've had people pointing out this very obvious reality regarding how Ahead-of-Time compilation proves to be superior to Just-in-Time compilation in realistic scenarios. Yet we've seen their claims very forcefully denied by the Just-in-Time advocates. Maybe after 20 years, it has finally become clear that the Just-in-Time supporters were wrong, and that Ahead-of-Time compilation is the better approach. With battery-powered devices more prevalent than ever, the need for high-performing and efficient binaries is greater than it has ever been. Returning to Ahead-of-Time compilation is just what we need given these circumstances. It's just a real shame it has taken so long for this important reality to be recognized.

brianwawok 11y ago
I mean, it's almost a moot point. Each year the number of native apps I run goes down by a couple, and the number of webapps I use go up by a few. Native apps I use right now? Chrome - Already native compiled IntelliJ - Full JIT mode, but due to the fact I start it once and run it for a month, not a huge deal. Command line unixy stuff - Already native compiled (On gaming computer) Games - Already native compiled I mean desktop apps DO exist, but just not that many to use day to day... from what I have seen of the windows app store, I can find 20 colors of calculator apps, but nothing that impressive.

mrec 11y ago

> they [desktop apps] really want to move to the new app platform anyway 1. Stop anthropomorphizing desktop apps, they don't like it. 2. Can't tell if the author means "desktop devs want to" (false IMO), "desktop devs ought to" (also false IMO) or "MS wants desktop devs to" (undeniably true). 3. It depresses me that just as MS is genuinely 'getting' open source, they're completely missing the appeal and value of an open platform. One step forward, two steps back. EDIT:typo

bitwize 11y ago
I think the referent for "they" here is "Microsoft", not "desktop apps".
bad_user 11y ago
I don't see how MS is getting open source. What makes people say that? Is it the 14 years it took for them to open-source .NET Core, an event that is happening at a point in time when .NET is most irrelevant? What really pisses me off however is that it's 2015 and Windows 10 and Outlook still don't support CardDAV and CalDAV. They'll get their hand forced by market pressure of course and as usual they'll end up supporting the minimum they can to get away with, which means they'll provide special hooks for Google and probably iCloud. All of this in the context of Edge, yet another buggy and proprietary incarnation of IExplorer in a world in which Chromium and Firefox exist. And of course, we mustn't forget the patents racketeering they are doing at the expense of the open-source projects that compete with them But oh boy did they change. Their PR department is genius though.
edgyswingset 11y ago
> "MS wants desktop devs to" (undeniably true) What makes you say this, the publishing of a third app model for Windows, messaging, some combination of the two, something else?
- mrec 11y ago
  Both, plus the fact that significant new tech infrastructure projects like the Windows Runtime are (mostly) restricted to Store apps. I'm not anti- app stores or declarative UI in general, and I think things like standardized sandboxing would be great for many desktop apps too. But a platform that places you at the whim of a single distribution path, and cripples portability to boot, isn't worth it.

stevoski 11y ago

I'd love to have the JVM equivalent of this for my company's main desktop product, written in Java. Due to being Java (and having an embedded JRE) the app has slow startup, due to the JVM having to be started up. The installer is 90 MB on OS X, 55 MB on Windows, much of which is the embedded JRE. So our our fortnightly updates are much bigger than they need to be. We tried an AOT compiler called JET. It was fine, albeit expensive. But it has an extremely long build time, no great for our continuous build system. It's support Java version also lags considerably behind the current Oracle Java release.

mwcampbell 11y ago
Check out Avian (http://oss.readytalk.com/avian/ http://oss.readytalk.com/avian/). You can use it with the OpenJDK class library. You can even run your application plus the class library through ProGuard, then AOT-compile the whole thing to generate a boot image for fast startup.
pjmlp 11y ago
Oracle is planning to finally add it to the standard JDK around Java 10 timeframe, but it might be a premium feature similar to the mission control licensing. https://www.youtube.com/watch?v=Xybzyv8qbOc&list=PLX8CzqL3ArzUo2dtMurvpUTAaujPMeuuU&index=16 https://www.youtube.com/watch?v=Xybzyv8qbOc&list=PLX8CzqL3Ar...
jacques_chester 11y ago
As I understand it, a big part of the slow load time for Java apps is sucking everything on the classpath into RAM, even though most apps will use a fraction of the classes that are loaded. Java 9's module system should make that a lot less of a problem by giving the JVM guidance on what it should load and skip. I am not a Java expert, though, so I may have misunderstood what's going on.
- fiatmoney 11y ago
  The JVM class loader by default reads a class on first reference to it in the code it's executing. Never refer to it, never gets loaded. Startup on the JVM is more affected by the JIT warming up, and the heap getting into a "stable" configuration.

simfoo 11y ago

> At this time, it is not available for desktop apps, although that is certainly something that could come with a future update. It’s not surprising though, since they really want to move to the new app platform anyway. Thanks, but no thanks. I'm not investing time and effort into a toolchain that ultimately targets only a single platform, namely Windows 10, because they don't want me to be able to just xcopy a .exe without touching their store

deleted 11y ago

[deleted]

saosebastiao 11y ago

It's frustrating that the .NET Native compilation is so tied to the Rosylyn toolchain that it can't be used for other languages like F#, even though they're using the same IR.

sixbrx 11y ago
Yeah this seams to me like a repudiation of the whole idea of .NET, as a multi-language system. They may add support for F# later, but by that time, the damage will have been done because the message is clear: "use anything other than C# or VB at your own peril". Currently F# is completely shut out - it can't even be used to make libraries to be included in these kinds of apps! That makes it more dangerous career-wise to use F# going forward, lest your team get wedged into a position of having to rewrite one of your libraries because of your choice of using your "pet" language. Not good for the career. The whole point of bytecode is to make things like this language independent. Big failure of vision to let this group do such a hack, IMO.
- kevingadd 11y ago
  This is most likely just an artifact of F# producing unusual IL that's harder to handle. In my experience, it's less 'we only support C#' and more 'compilers other than C#/VB.net produce very strange IL that is hard to handle well' - which is true. Given the small # of users that rely on those weird compilers, it's hard to justify supporting them first, especially if they aren't performance-sensitive.
  - MichaelGG 11y ago
    I emailed the .NET Native team asking them about this. They confirmed that they reverse out IL to higher-level constructs. So they aren't really working at the IL level, they're working on C# represented as IL. This isn't entirely uncommon. A lot of code that deals with Expression<T> does so very poorly and won't work on many valid trees because they weren't able to get C# to emit certain expressions.
- MichaelGG 11y ago

moomin 11y ago

You know, this is all very well, but the Windows 10 app market is pretty much non-existent. You know who really uses .NET on Windows? LOB applications, front ends to complex systems. The kind of thing you don't see in the app store. And that market is better served with, you know, a compiler, that runs on the command line, on a machine under a developer's control.

MichaelGG 11y ago
The Windows Store was traditionally just scams with blatant trademark infringement. This has severely damaged their rep. A quick search now shows a lot of it is cleared up. Unfortunately, that just leaves the shovelware junk. Here is an interesting point: Right now, the #3 top free app is "Freeflix/Free Movies Unlimited"[1] and #4 is a "free Mp3 downloader". The publisher for the free movies is "Wamba Dev" which results in no related hits on Google outside of Windows Store. Contact is a hotmail account, and the privacy policy is on "dopeware.com". So Microsoft isn't even able to get real publishers in top positions on its own Store. Pretty damn sad. Also the Metro runtime is diseased and broken. Opening the Store app right now to do these searches took about 15 seconds. On a decently high-end ThinkPad. It's embarrassingly bad. Even the Metro calc takes 2-3 seconds to open, ffs. 1: https://www.microsoft.com/en-nz/store/apps/freeflix-free-movies-unlimited/9nblggh1z0m4 https://www.microsoft.com/en-nz/store/apps/freeflix-free-mov...

graycat 11y ago

I just wrote 18,000 programming language statements in Visual Basic .NET, in files with 80,000 lines including comments, blank lines, etc., compiled much of it with a command line script with line programPath = dq || SystemRoot || , '\Microsoft.NET\Framework\v4.0.30319\vbc.exe' || dq and give the rest to the Microsoft Internet Information Server (IIS) to compile and run as Web pages, and it all works, but, still, I can't make any sense out of the OP at all. E.g., my command line compiles result in a file with extension EXE. What's in that? Sure, I have the Microsoft .NET Framework 4.0 installed, and the VBC.EXE invoked as above is, of course, one of the files in the installation of that .NET Framework. When from a command line I just run that script that runs that VBC.EXE, I get nice output showing the command line options for the program -- simple, direct, explicit, terrific. So, how do I connect what that .NET Framework 4.0 VBC.EXE does with the discussion in the OP? BTW: Why use Visual Basic .NET instead of C#? C# borrows too much of the old C syntax, and Visual Basic has syntax more traditional and more like that of Pascal, PL/I, Fortran, etc., and I find that more traditional syntax easier to write and read and less error prone. But, likely and apparently, the difference between C# and Visual Basic .NET is mostly just syntactic sugar anyway. By the way, where does the famous CLR -- common language runtime -- enter this picture? Thanks.

kyberias 11y ago
What?
- graycat 11y ago
  What part of my question do you not understand?
  - marvy 11y ago
    What is the question?
    - graycat 11y ago
      The question was: > So, how do I connect what that .NET Framework 4.0 VBC.EXE does with the discussion in the OP?

redcalx 11y ago

Every poorly performance problem I've ever encountered has been due to poor design choices, poor choice of algorithm or, most often, badly implemented algorithms. Once past the JIT compilation delay the execution speed is not significantly different for AOT and JIT code for mature platforms such as .Net and Java. There are issues in CPU and RAM resource limited systems such as mobiles and embedded systems. And also web servers - where small improvements in scalability can dramatically affect business viability and profitability.

MichaelGG 11y ago
IIRC the .NET Native literature says the main benefits are reducing RAM by a fair amount. Which makes sense - no runtime to load type info and no JIT to run. AFAIK, they aren't claiming the compiled code is _that_ much better than what the JIT does. Of course it's probable that reducing RAM footprint significantly might improve runtimes if it makes better use of cache.