Standardizing WASI: A system interface to run WebAssembly outside the web
hacks.mozilla.org
hacks.mozilla.org
0 - https://github.com/CraneStation/wasmtime-wasi/blob/wasi/docs...
Yes, that's the list.
And the layout of structs, strings, etc is up to the compiler, within the bounds of the restrictions WebAssembly imposes.
We'll definitely have a test suite, but this is all early days, so a lot of all that isn't yet in place.
And yes, this can be targeted by LLVM-based and other compilers. In fact, Emscripten could use this as the foundation for their POSIX-like libc and library packages. The syscalls are indeed exposed as Wasm function imports.
I have worked on file APIs. There are so many differences between Windows and Posix that abstracting them away just doesn't work. Undoubtedly, there will eventually be platform-specific APIs that implement one or the other, and cross-platform APIs that implement the intersection.
/tmp/[DE][AD][BE][EF].txt # ext2 / linux
# OR
C:\stuff\[DEED][FFFE].txt # ntfs / windows
# where [hex] indicates a single filesystem charater with that valueConcerning character encodings, and potentially case sensitivity, the current high-level idea is that paths at the WASI syscall layer will be UTF-8, and WASI implementations will perform translation under the covers as needed. Of course, that doesn't fix everything, but it's a starting point.
Here's a link: https://github.com/gwsystems/silverfish -- although the README is pretty sparse, so you'll have to look at the code.
I thought Java was supposed to do this with the JVM...
I thought .Net was supposed to do this with the CLR...
What's different now?
It can be an enabler for new innovations. Even if it runs 2-10x slower than native code.
And what if the answer was just: just because I can? That's how a lot in our industry got started.
Honestly, it shouldn't need to be that big. There's plenty of cruft even in .NET core.
I did evaluate WASM as a native runtime environment recently, pre-WASI. If what you're doing can coexist with memory mapped I/O, you don't have to have an explicit interface of this type, you can just say "lower region of linear memory is where the I/O goes" and hardcode all APIs against that. It's more "honest" in certain ways than a syscall interface since it doesn't lead to any parsing of intent or variable expectations around resource usage.
Anything other than Electron if it comes to it
If someone could explain the difference between WASI and JVM the way you can explain the difference between C, C++ or Rust, it would help a lot. If there is no such explanation, I think we should really question what is being accomplished here.
As it stands currently, WebAssembly seems to integrate nicely with browsers, whereas JVM works nicely in native environments. I'm a younger developer and only partly remember the days of Java on the web, but is there a reason for why JVM is not suitable in web environments? I.e. why WebAssembly -> Native, not JVM -> Web?
I'll take a stab at it. While both WASM and the JVM aim to be portable virtual machines, WASM prioritizes sandboxing / security and a smaller runtime. A host should be able to easily set up WASM with restricted access and expect that the WASM program is secure. As far as I know, the JVM doesn't have an equivalent feature, or if it does, it's a lot more complicated.
On the other hand, I seem to remember that the security model was (somewhat) adapted to the threat at hand when it was designed (~25 years ago). I haven't kept tabs on it, so I don't know how well it has aged, but there's a chance it doesn't work anymore.
1. WASM is an open standard
2. WASM spec is smaller, so it's easier to integrate into the Javascript VM, which itself brings many benefits
Since WASM wins on the web, I guess it makes sense for developers to want to develop one version of their code for both the web as well as native environments. Thus, WASM -> Native seems to totally make sense.
[0] https://words.steveklabnik.com/is-webassembly-the-return-of-...
So is the web, but that didn't stop anyone from extending it in incompatible ways and all implementations being subtly different enough that you still have care about which one you're running on and, oh yeah, it's also becoming dominated by a single player who steers the whole thing pretty much wherever they want it.
JVM is pretty complicated and not open source(? I'm not entirely sure who owns the standard, if there is one). WebAssembly has the advantage of hindsight and being able to be designed to completion rather than evolved
The JVM and CLR seem like they're language platforms first and VMs second
Ding ding ding ding ding.
There are lots of extant application VMs out there, but effectively all of them were implemented specifically to be able to run a specific language (Java → JVM, C# → CLR, Perl 6 → Parrot/NQP/whatever, Erlang → EVM/BEAM, etc.). Other languages have been implemented on top of those VMs, but they have to adopt the semantics of the actually-targeted language; you'd have a hard time taking a pure C codebase and compiling/running it on the JVM or CLR or BEAM.
WebAssembly is not that much different, technically; its actually-targeted languages are C, C++, and Rust, and you can reasonably think of it as a VM for those languages. However, it seems to be making an effort to not get caught up in the semantics of any specific language, much like how machine code tends to not really care about whether the instructions it's executing were compiled from C or Rust or Java or Ruby or COBOL or Brainfuck.
Parrot was intended as a more universal VM, and was started before the Perl6 design solidified. So in the end it didn't actually fit that well with Perl6.
NQP is a small subset of Perl6 that is used for bootstrapping Perl6, and provides an isolation layer from the vagaries of the various VMs it targets. It used to target Parrot, and now targets MoarVM, the JVM, and JavaScript. (NQP is an acronym for Not Quite Perl6.)
MoarVM (Metamodel On A Runtime) was built specifically for Perl6, but its design is minimal. Most of the Perl6 specific features are built using Perl6 and NQP.
For example, MoarVM only provides only enough of an object/type system to bootstrap the full object system. That is MoarVM gets taught how Perl6 objects work every time it loads the Perl6 runtime.
MoarVM also has a pluggable optimizer where you write the plugins in a higher level language. It could be any language that compiles down to MoarVM bytecode. The Perl6 ones are written in NQP.
I think this dynamism makes MoarVM an interesting target for other languages.
Or, more accurately, its easy to make UIs for it?
I'm personally bearish on the whole idea from a community / technical standpoint (in that I'd like us to return to more native stuff than follow JS into the browser), but I can't argue that WASM and co won't enable some really cool uses.
My takeaway from WASI is that it would allow for a single universal runtime with near-native execution. The near-native aspect being what other universal runtimes like the JVM and CLR lack due to their bundling of a GC and other non-essential features.
On top of that, JS devs would be the ones who get the short end of the stick, because js is the one language that does not compile to WASM because where WASM comes from, you already have a JS environment, no need to build a second one inside WASM.
Node always struck me as a strange trend but using web tech for UIs seems like a good fit for a lot of cases
They put in huge amounts of effort into things that don't need solving, and the things that need to be solved they do in the most roundabout way possible.
What we _really_ need is a sandboxed VM for running C code securely and efficiently.
The JVM is pretty much the opposite of that; it's not sandboxed, not secure and certainly not efficient as a target for C code.
We're hoping WASM starts over from scratch and does things right this time around.
JVM, CLR, and WASM suck balls. People have been breaking the sandbox for the better part of a decade.
We're hoping Cool New Thing™ starts over from scratch and does things right this time around.
I mean, maybe they really will be, but history suggests otherwise.
Android apps are sandboxed Java apps.
Containers turn almost any Linux process into a sandboxed process.
Am I wrong ?
The most successful attempts that i'm aware of are Jazelle[2] and Java-card[3] plans to augment the software solutions
[1] https://en.wikipedia.org/wiki/Java_processor
WASI would give me near-native performance for this one without any additional work, and also fix issues like how file watchers don't work correctly, provided the source language has a compile-to-WASM option.
It's a massive game changer that could solve this issue after the fact. Even a 2x performance cost from native would mean a massive boost in performance and management in comparison to running it through Docker Desktop.
[0] https://twitter.com/linclark
[1] https://code-cartoons.com/
[1] https://hacks.mozilla.org/category/code-cartoons/
[1] https://twitter.com/codecartoons
[2] https://www.youtube.com/playlist?list=PLIIHcC8epcPqhBrQ1dRmI...
Did they just invent Java again? Aren't they promising what Java promised? Won't they hit the same problems that Java hits during its write-one-run-anywhere promises?
I'm asking honestly - why is WebAssembly outside of the browser needed?
Java still exists and is a valid deployment platform.
Why is WebAssembly outside of the browser needed?
It's not really a legal liability either. Lawyers for companies who use Java go over those agreements with a fine tooth comb and approve them before they're signed. There are no surprises (if your attorneys aren't frauds.)
https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google....
Java is not a responsible or ethical choice for anybody to use for any purpose.
They deserve what they get.
https://www.java.com/en/download/faq/chrome.xml
The Java Plugin for web browsers relies on the cross-platform plugin architecture NPAPI, which had been supported by all major web browsers for over a decade. Google's Chrome version 45 and above have dropped support for NPAPI, and therefore Java Plugin do not work on these browsers anymore.
All the other browsers killed it as well.
There's probably some way you can do it outside the browser, but I've never seen it used. Was it called Java WebStart or something?
I think it's because the sandbox had too many holes, and it was large and clunky. It didn't integrate well with the browser.
Java is obviously still extremely popular, but it's used in trusted contexts, like on the server, or "semi-trusted" contexts, like the Android app store. Although that is a different JVM which is probably easier to secure. And in that case there has to be a manual review process before allowing arbitrary code to execute (which is imperfect, but better than nothing.)
That is, computation and I/O are treated separately. It's more like capability-based security. WASM modules have no capabilities except the ones explicitly injected when you instantiate it.
As far as I understand, the JVM wasn't as rigorous about this, although to be fair I don't know all the details.
So WASI could still have a lot of holes, but WASM would survive and be useful. And then maybe someone else could come around and do it in a different, better way. That hasn't happened with Java.
Java runs just fine outside of the browser. You don't even need a browser installed to run Java applications.
Javascript and WASM run fine inside the browser, and that's not what I'm talking about or making comparisons to.
I'm talking about running WASM binaries outside of the browser. Similar to how Java runs outside of the browser. Very similar, actually. Java needs a runtime to be installed or available, so will WASI. Java is a write-once-run-anywhere type of platform, so is WASI.
Why does WASI need to exist if Java already exists for the intended uses?
This is important for a lot of reasons- huge amounts of existing code you can now use without JNI or whatever, a higher ceiling for optimization, more freedom to implement new kinds of languages.
The core WebAssembly standard is also much smaller than Java, as a consequence of this design. This makes it easier and/or more feasible to deploy in more scenarios, even without subsetting things the way mobile/embedded Java does.
(But this is pedantry, you clearly know what I meant.)
You can run all those languages on top of the JVM!
The JVM also runs many other languages which weren't designed for it, like Ruby and Python.
Do you have a source for this? I'm sure it's theoretically possible in a Turing-completeness sense, but considering Java lacks any concept whatsoever of a pointer, and considering that most (if not effectively all) C code uses pointers pretty extensively, I find it unlikely that this statement is meaningfully true without some severe efficiency penalties.
I use it to run unmodified C extensions for the Ruby programming language on top of the JVM.
Truffle C is another example https://www.manuelrigger.at/downloads/trufflec_thesis.pdf.
That would suggest (again IIUC) Graal/Truffle as a mechanism for using the JVM as a WebAssembly runtime. The WebAssembly format and its associated environment/binding system are a portable way to encode C binaries, with significant benefits over JVM bytecode- that's probably the comparison I should have made.
But I wasn't comparing to WebAssembly, so you'll need to argue that point with someone else.
You could build a WebAssembly interpreter on Truffle, yes. I'm not sure anyone's tried it yet so that project is available.
IMO, the reason is that the market showed that Java never got used like that. I can only speculate on the reasons, but as far as I can tell it comes down to:
1) The sandbox isn't good enough. See my sibling comment -- the separation between WASM and WASI makes a lot of sense, and I don't think Java had that.
2) The fact that you can't port C code to the JVM easily. In fact WASI addresses exactly that -- the API is more like POSIX than a brand "new" bunch of JVM APIs, which makes it easier to port existing native apps (C, C++, Objective C, Rust, etc.)
In other words, there's still a lot more "value" in native code apps than JVM apps. And it's too hard to port native code applications to the JVM.
For example, Photoshop, Illustrator, Word, Excel, etc. were never ported to the JVM. There are actually better analogs in the browser than on the JVM.
I ran windows for 15 years and Linux for 10-15 years. On neither of those platforms have I ever needed a JVM. I used to play online chess in a Java applet, and that's about it. Most common desktop apps avoid dependencies on the JVM. Probably the only reason I could think of installing one is to use Eclipse or IntelliJ.
The browser is the main reason why anybody had a JVM installed in the first place. Without that hook, the JVM becomes much less important on the client. It's still very important on the server.
Java is important and successful, but it empirically did not succeed at some of its design goals. Of course, WASM and WASI may also fail -- that remains to be seen. But to me they look like a good attempt, based on significantly different technical foundations.
There seems to be such a compiler here: https://github.com/bedatadriven/renjin/blob/master/tools/gcc...
1) There's a large difference between a compiler that exists and an efficient one. The JVM is designed for Java and not C, which makes efficient compilation hard / impossible. Graal as mentioned is an extremely unusual research technique that may make it feasible.
This comment is related:
https://news.ycombinator.com/item?id=19065829
Basically people underestimate how hard it is to make a VM that can run multiple languages. JRuby and Jython work, but it takes heroic efforts.
2) The interface to the OS, as mentioned. You can maybe run some algorithms like image processing, but try running the native sqlite code on the JVM, or something even hairier involving networking. It's not straightforward.
WASI provides something that's closer to what C programs expect than what Java provides. As I said, the market voted with its feet. All the friction adds up. If you try hacking on that compiler or manually porting code, you'll probably get a sense of why that is.
> Why: Developers are starting to push WebAssembly beyond the browser, because it provides a fast, scalable, secure way to run the same code across all machines.
It allows you to use the same code both inside and outside of the browser. For example, Figma might use it, they already have a web app and a regular app, both using WebAssembly, so WASI would perhaps simplify their code or allow them to add more native integration to their app.
Making a product that's a slight variation of an existing product is often enough to gain significant market share. For example, was Chrome needed when there was Firefox? Was Figma or Adobe XD needed when there was Sketch? Is Rollup or Parcel needed when there is Webpack and Gulp? This could go forever. I mean, should Java be the only universal deployment platform?
It isn’t that the JVM is bad, it is that it isn’t the universal compilation target that WASM is.
Remember folks getting excited about LLVMIR, Bitcode? WASM is this but with a clean sandbox and minimal tractable semantics.
The JVM is awesome, esp with Graalvm and Truffle. WASM is the next evolutionary step.
It's arguably a better standard runtime than Java, for certain use cases. You don't see modern compilers targeting the JVM as an output target, but you do see them targeting WASM, there's probably good reason(s) for that (both technical and political/legal).
Furthermore, my understanding of WASI is that it allows standardization of _multiple_ runtimes, each domain specific.
For example, Functions as a Service. Currently AWS Lambda requires building a blob specially for them targeting their APIs and ABI. But what if Fastly, Fly.io, and the other "App CDN" FaaS providers come up with their own standard for "syscalls" for a WebASM-FaaS-1.0 spec? As a really bad example, the syscalls could be:
- 1 GET URL
- 2 POST URL
- 3 Cache Read
- 4 Cache Write
- 1 Storage Read
- 2 Storage Write
- 3 Contract Call
Furthermore, the barrier for entry as a syscall provider becomes much simpler too! If I want to make a local sandbox for FaaS testing, I just need to implement the syscalls from WebASM-FaaS-1.0 using local stubs, now I can test my FaaS locally. Way easier than the months/years probably spend reverse engineering the lambda environment for local testing. And if I come up with a novel solution for servicing one of those syscalls, hey, maybe I'll take my own stab at being a FaaS CDN. :)
Likewise for Ethereum and eWASM. Maybe I want to make a local test environment sandbox. Instead of re-implementing the EVM I "just" need to implement those syscalls outlined in the eWASM WASI spec (if such a spec existed). So now maybe light clients ship those syscalls over the wire somehow, and don't need to keep gigabytes of block chain data locally anymore.
edits: minor formatting
No matter what language I use, no matter what platform I deploy to, if I want to interact with a service or with infrastructure, I'm going to have to use the provided API(s), WASM included.
If I deploy a pre-compiled binary to an AWS Lambda and an Azure Function, and it works on both, it's because I had to have that in mind when I wrote that software. Will that not be true for a runnable WASM binary? It sure seems like it would be true that I would need to detect which platform I'm running on and then execute the proper stuff for the detected platform.
If all APIs are going to be compatible with each other, so that, say, storing a file uses the same API call no matter what system or platform you're on (never going to happen; bear with me) implementing that in WASM outside of the browser does not suddenly make it possible.
This is an opinion, and on HN this is likely to be a very unpopular opinion. I don't expect anyone to adopt this opinion, nor do I expect to sway anyone's thought with this opinion. This really (really, really, really) feels like JavaScript/web people wanting to do things outside of the browser, with performance better than JavaScript alone can provide, and then, rather than simply using an existing language and runtime, deciding that the best route forward is to pave their own road to this destination with web technologies. This does not feel like the best route to take if you want to write software that performs well outside of a browser.
There are lots of other languages, runtimes, and platforms, that allow this today. And the web is a bag of chaos: I can't even get a consistent design or UI language across major websites, today. Buttons sometimes look like links, links sometimes look like menus, and buttons sometimes look like any of those, but somehow WASM outside of the browser is something everyone (except me) can agree on?
I'm skeptical that this is a good idea for anything serious.
Just like there are implementation problems with Java, there are going to be implementation problems with these runtimes that every platform is going to need in order to run this code, now. There are going to be many security concerns because (warning: incoming opinion) nearly all developers are terrible at thinking about preventing security vulnerabilities. Those same developers are usually OK when it comes to fixing them, and terrible at thinking about vulnerability prevention.
Right now there's no reason to conclude that this will turn into something that's no better than Java.
the solution is not to create another sandbox to run software in.
One advantage in this new push to build another sandbox is that Rust is leading the charge and is the de facto language of choice when building a greenfield WASM project. Given its propensity for memory safety and WASI's emphasis on capability-oriented security, I think the WASI team has a good chance of building something with a lot of value. Nothing here is novel (except perhaps Rust's extreme prioritization of memory safety) but that doesn't mean it can't or won't be an improvement over prior attempts.
I wonder how many of the previous sandbox vulnerabilities were viable due to some quirky memory manipulation techniques? Quite a few I would imagine.
It's _not_ a requirement, but at least to me it seems like a pretty good _possible_ solution.
I sense you're pretty jaded about web development, and I get that, but I don't agree this is "web people" trying to do things outside the browser, but rather I see it more as "systems people" trying to bring _some_ order to the chaos.
> nearly all developers are terrible at thinking about preventing security vulnerabilities
I totally agree. Which is why you should have a solid abstraction between the sandboxed code and what it's allowed to do, which WASM seems particularly good at (by only exposing services as syscalls). In theory, sandbox escapes in WASM should be the same level of difficulty as modern kernel exploits, so still _possible_ but _pretty hard_. And if multiple runtimes are using WASM for different things, if one is exploited it can be a learning lesson for all the other WASM runtimes, vs. the bespoke scenario where each custom VM has to go through the security bug discovery process by itself.
If _think_ what you're against is some sort of future where a "WASM-based-Electron" becomes the de facto standard for modern apps, and _that_ I largely agree with. In fact, re-reading the WASI standard I do feel like they are already "baking in" too much w/ WASI-core; I was expecting the core to just focus on a simple syscall ABI, not to include syscalls like filesystem reads and writes.
Some maybe what I'm really looking for is a "wasi-minium-abi" that just standardizes _how_ syscalls are made without actually standardizing any actual syscall numbers.
In summary, I feel like syscalls are a _very_ tried and true way to specify the API/ABI for a runtime, and that I hope we see more runtimes use WASM and a syscall ABI vs. rolling their own VM, but I agree that I'm in no rush to see WASM/WASI become the "Electron 2.0" of local app deployment.
The web development community haven't even solved their own problem space very well; spreading to new problem spaces will likely not suit them as much as they believe it will.
But this technologie comes not from javascript webprogrammers, but from browsermakers.
People who specialize in sandboxing, performance and portability since years. And they had to do this with javascript... and now they want a better foundation, BECAUSE of the flaws of javascript.
So I don't know if they will succeed making a better jvm either, but they certainly have the expertise that they might succeed.
This REEKS of developers who are psyched about WASM and want to create solutions where no problem exists.
If they want performant code outside of the browser, use any one of the 2-3 dozen languages that already do this! WHY is a new runtime, with the inevitable serious security issues that will be exposed throughout it's life, needed for this?
This basically means your language needs to work nicely with stop the world garbage collection.
(And yes, I know that modern garbage collectors aren't really stop the world, but the tradeoffs are still there.)
Go dig one of those .NET 1.0 SDK release CDs from 2002, plenty of sample languages on it.
The problem is that the CLR comes with the the C# memory model and garbage collection.
If you don't want that, then what's the point of the CLR? You can't use most of the .Net API without objects and garbage collection.
That basically rules out any kind of real-time application. The more modern garbage collectors allow soft real time applications, but you still can't do things like use the CLR to run an airplane.
If you want to use the CLR for a real-time application, you basically have to replace most of the .Net API with a completely pointer-based version, and consider implementing your own real-time memory management model.
At that point, you might as well target your language to compile natively and use standard libraries in the operating system.
Also contrary to WASM, there are real hardware devices actually shipping stripped down versions of it.
And if real time is a concern, then not using a real time OS is already the big first mistake, there is nothing here for WASM to prove, only to catch up with existing battle tested solutions.
No. Like Java, they just reinvented DEL again:
2. WASM is designed from the ground up as a compile target, not a language. We already see many languages with support for building to WASM. C, C++, Rust, and eventually when WASM supports garbage collection we'll probably see Python, JS, Go, all with support for compiling to WASM.
GCs usually need low level system acces in a way that is not supported by WASM for obvious reasons (security, sandboxing, ...). Go also has problems with the way they implement Goroutines if I remember correctly.
WASM will definitely need some kind of GC bridge to make things efficient for garbage collected languages. Potentially with certain primitives exposed that make shipping your own GC efficient. We'll see how it develops.
(2) the JVM was designed from the ground up as a compile target also, for Java, but is also used by Kotlin, Clojure, Ruby (JRuby), Python (Jython) and Scala, among others. Even JavaScript (Rhino, Nashorn and Graal).
C, C++, Rust, etc. do not fit into that model at all. There's a lot of software written in C, and there's a lot of performance to be gained by dropping down to that level when necessary.
The JVM is (and was from the start) a lot more dynamic than Java.
[1]: https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google....
Patiently waiting for when eBPF gets it's turn inside the browser.
1. Backwards compatibility with existing libc. (Maybe pick musl)
2. Platform agnostic wasm generation: the same wasm file should run in the browser (with emscripten polyfills) and across ALL OS-es, mobile included. List: iOS, Android, Mac, Linux, Windows, FreeBSD
#1 shall enable decades of legacy programs to work with minimal porting, while #2 shall enable true cross platform capabilities without multiple codebases. Specifically, don't repeat what node did: digress from browser js semantics, instead of polyfilling them
Honestly, that ought to be a non-goal. We already know that POSIX often enforces models that we don't want--filesystem permissions and the fork model are two good examples of things that are broken. So why start with "implement POSIX"?
Also, goading legacy maintainers to adopt the newer, safer paradigms is likely more effective if you show them the traction the new platform is gaining
On 1, the libc we're working on[1] is based on musl. It won't ever be 100% compatible with all code, because that runs into constraints imposed by our security goals, but the vast majority of code should eventually just compile when targeting this. (Eventually, because this is all early days.)
On 2, yes, that is explicitly the goals. I'd add that it's not just about OSes, but also about platforms and hardware form factors.
Well, besides keeping competition/innovation alive.
Now this is the same idea but, this time, one layer lower so that we can have performance, the language we want, etc. This is kind what I always wished would happen.
It will be interesting to see how the sandboxing will work with already existing sandboxing solutions. For e.g a WebAssembly app packaged as a Android/Flatpak/UWP/etc. , there will be the need to make mappings between the permissions of the two sandbox systems. Or even maybe one day we'll have the Webassembly sandbox as the only sandbox (like in https://github.com/nebulet/nebulet)
* Self-hosting (WASI can run inside WASI)
* GCC can run in it
* Linux can run in it
* Quake can run in it
* Chrome can run in it
Second, I can run an emulator in WASI that implements WASI, including multiple processes. They might not be true OS processes. But as long as I have threads, I can do something.
Also, maybe we get WASI without high precision clocks. /shrug
0: https://www.destroyallsoftware.com/talks/the-birth-and-death...
The problem with JS was never that it's a web technology. It's that it's a bad technology that happened to be in the wrong place at the wrong time to get a first mover advantage.
https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGard... (from https://www.webassemblygames.com/ )
https://www.figma.com/blog/webassembly-cut-figmas-load-time-...
https://github.com/mdn/webassembly-examples/
https://github.com/emscripten-core/emscripten/wiki/Porting-E...
https://github.com/CraneStation/wasmtime-wasi/blob/wasi/docs...
I suppose this would have pretty big implications for Electron or a similar successor to aid in the UI portion of this endeavor.
Why the chip on the shoulder?
I hardly see the difference.
No chip on the shoulder, just an old guy that has seen dozens of VMs since the mid-80s, delved into others from earlier decades, which doesn't buy into WASM marketing.
With /clr:pure (which produces CIL only, although it is allowed to use memory-unsafe features like pointers), the entirety of ISO C90 is supported on CLR, with the sole exception of setjmp/longjmp.
C++/CLI adds language extensions that allow one to interact with the CLR object model from C++ code. It is only needed if you need to call into the .NET standard library, or other managed libraries - i.e. if your C code is not portable to begin with.
The problem is always complexity. It can be difficult to reason about safety with so many features on bytecode level. There have been exploits using dynamically-generated methods, exception filters, and vararg handling - note the near-lack of any common patterns here other than they're all obscure features of the platform, the security impact of which wasn't fully analyzed.
For example, a long time ago, I reported the vararg exploit, which boiled down to the fact that you can have ArgIterator over an argument list containing another ArgIterator, allowing the latter to be mutated via the former. Thus, you can stash away an ArgIterator to the arguments of a function call that has already returned. This is basically the same as having a managed reference to a managed reference, and it's exactly why CLR prohibits this - but they forgot that ArgIterator is also a kind of a managed reference.
Forcing internal corruption of code produced from C compilers (like doing a stack out of bounds data overwrite due to incorrenct params size) is perfectly viable.
Yeah the exploit doesn't leave the sandbox, so what. It can still be used to direct the sandboxed code to produce other outcome from the called functions.
Actually JVM got there first with JS-interoperabily.
Nothing like that exists (it's too early) but it would be interesting to know if anyone is planning anything.
If it didn't have "web" in the name, I think people would hate it a lot less.
I'm not really pro-WASI so much as I am against the idea that the browser is a good application platform.
Ultimately, if a vendor refuses to support something, it doesn't matter if it is an 'open standard' or not. The openness means absolutely nothing in this instance.
Yes, there are, and those uses are already solved with Steam, the Windows Store, Play Store, App Store, etc....
And there's also your answer. All those are fragmented, proprietary plattforms.
WASI is not.
Also, WASI is literally fragmented by design. It does not have a singular target, it instead is a bunch of modules (aka, shared libraries), and what modules you get and how they behave is up to the platform.
Real native has already long since solved distribution, dependency management, and portable abstractions. WASI does not appear to be doing anything interesting, new, or novel here.
For example do you consider C++ on Windows to be a proprietary platform, even though C++'s STL isn't proprietary? If so, then WASI on Windows must also be proprietary, no? And if you don't consider C++ to be proprietary, then, you know, you can pick just about anything. They almost all have a standard library that abstracts OS differences and are generally portable.
All that aside, .NET Core is MIT license and already exists. So you can literally be non-proprietary, multi-platform, single-binary today with a mature ecosystem, language & library support, and tooling.
Also in the context of shipping apps let's not forget that this isn't really viable on the 2 biggest consumer app platforms, iOS (no JIT) & Android (majority APIs require Java interop), and for games it's also not viable on the other dominant platforms in those markets - Xbox One & PS4.
And apart from that, yes .NET is the only alternative I see today. But you don't see the benefits, of a new lower level option, entering the field?
In a world where CI servers are plentiful, does this actually matter in the slightest?
And aren't you going to end up doing multiple compiles with WASI anyway since the list of required modules for a platform isn't mandatory?
And even if you only use wasi-core, you're still going to be doing platform-specific builds for either the installer to fetch the required runtime or a fat binary that just bundles it. Most likely the latter, like Electron does.
> But you don't see the benefits, of a new lower level option, entering the field?
Not unless it does something new or acknowledges why previous attempts didn't succeed and how this one will be different.
Plans on doing all the same things but years later and with worse tooling isn't exactly a compelling story for why anyone should touch it.
Of course there is. You can open a new "application" without installing, just by clicking a link or entering a URL. The beauty of browser as a platform is simplicity of navigation between apps you haven't previously installed.
Also, note that the distinction between a document and an application is vague. Is interactive document, perhaps containing an interactive map, an application? If yes, do you really want to install these interactive documents before accessing them?
A benefit of applications in the browser is that they share and benefit from the same security policy decisions which are made for web pages. I think the closest thing to what you're suggesting is mobile apps, which don't always compare favourably. Users are often coerced into giving up unnecessary permissions, and they have less control over the user experience (can't block ads or change styles).
Yes. And the benefit of that is that it building a new WASI implementation is almost certainly going to be much easier than building a new web browser currently is. If web browsers were to revert to being simple hypertext renderers, then those would be orders of magnitude easier to implement as well.
> Users are often coerced into giving up unnecessary permissions
How is that different from the web?
> and they have less control over the user experience (can't block ads or change styles).
If I have control over who the WASI VM can and cannot talk to, I can block ads using exactly the same mechanism that is used today. Styling would depend on precisely what interface ends up in common use to render graphics for WASI applications, it is totally possible to style native widgets or something like QT/GTK. You can't style anything that uses a canvas regardless.
With HTML/CSS we get the relatively easy ability to add extensions to dig deep into the data of a page. One of my favorite extensions is rikaikun which adds popup translation of Japanese words. It can only do this because it can inspect a standardized data structure (the DOM) with standardized APIs.
I also love the ad blockers. They let me not only block ads but also hide parts of websites I find distracting. For example I hide the "Hot posts from other stack exchange sites" section of stack overflow because I find I get sucked into 20-40-60 minute distractions if I don't hide it.
I can also copy and paste nearly any content and link to almost any content.
An a world of native apps none of this is really possible. Every native app will use its own internal representations of data. Different UI kits or libraries. Much of it is un-linkable, un-copyable, It drives me nuts when I can't copy and paste of phone number, or address in a native app.
I don't believe getting rid of the web for a WASI based app world would be a good thing for users.
PS: I think WASI is a great idea. I just think trying to replace HTML based apps with WebAssembly apps using WASI and rendering with WebGPU is the wrong direction for most web apps.