Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WASM 3.0 Completed

webassembly.org

Post reply on HN
Print view View original

421–430 of 520 posts

Re: WASM 3.0 Completed

#421

Post by _nalply »

DaiPlusPlus wrote: post #364
mananaysiempre wrote: post #262

Earlier quoted context omitted.

> Think of the possibilities! Schulman’s Unauthorized Windows 95 describes a particularly unhinged one: in the hypervisor of Windows/386 (and subsequently 386 Enhanced Mode in Windows 3.0 and 3.1, as well as the only available mode in 3.11, 95, 98, and Me), a driver could dynamically register upcalls for real-mode guests (within reason), all without either exerting control over the guest’s memory map or forcing the g…

> The absolute madmen put the upcall entry point inside the BIOS copyright string. Isn’t that an arbitrary string, though? Presumably AMI and Insyde have different copyright messages, so then what?

I thought so, but "Copyright" is always the same? Haha, that's dangerously clever or cleverly dangerous.

Re: WASM 3.0 Completed

#422

Post by _nalply »

zarzavat wrote: post #389
nagisa wrote: post #243

Earlier quoted context omitted.

That's because with 32-bit addresses the runtime did not need to do any masking at all. It could allocate a 4GiB area of virtual memory, set up page permissions as appropriate and all memory accesses would be hardware checked without any additional work. Well that, and a special SIGSEGV/SIGBUS handler to generate a trap to the embedder. With 64-bit addresses, and the requirements for how invalid memory accesses shoul…

> AND-masking does not really allow for producing the necessary traps for invalid accesses. Why does it need to trap? Can't they just make it UB? Specifying that invalid accesses always trap is going to degrade performance, that's not a 64-bit problem, that's a spec problem. Even if you define it in WASM, it's still UB in the compiler so you aren't saving anyone from UB they didn't already have. Just make the trappin…

It's WASM. WASM runs in a sandbox and you can't have UB on the hardware level. Imagine someone exploiting the behavior of some browser when UB is triggered. Except that the programmer is not having nasal demons [1] but some poor user, like a mom of four children in Abraska running a website on her cell phone.

[1]: http://catb.org/jargon/html/N/nasal-demons.html

Re: WASM 3.0 Completed

#423

Post by mananaysiempre »

DaiPlusPlus wrote: post #364
mananaysiempre wrote: post #262

Earlier quoted context omitted.

> Think of the possibilities! Schulman’s Unauthorized Windows 95 describes a particularly unhinged one: in the hypervisor of Windows/386 (and subsequently 386 Enhanced Mode in Windows 3.0 and 3.1, as well as the only available mode in 3.11, 95, 98, and Me), a driver could dynamically register upcalls for real-mode guests (within reason), all without either exerting control over the guest’s memory map or forcing the g…

> The absolute madmen put the upcall entry point inside the BIOS copyright string. Isn’t that an arbitrary string, though? Presumably AMI and Insyde have different copyright messages, so then what?

To clarify: when I said that “the boot code tried to locate the chosen instruction inside the firmware ROM”, I literally meant that it looked through the entirety of the ROM BIOS memory range for a byte, any byte, with value 63 hex. There’s even a separate (I’d say prematurely factored out) routine for that, Locate_Byte_In_ROM. It just so happens that the byte in question is usually found inside the copyright string (what with the instruction being invalid and most of the rest of the exposed ROM presumably being valid code), but the code does not assume that.

If the search doesn’t succeed or if you’ve set SystemROMBreakPoint=off in the [386Enh] section of SYSTEM.INI[1] or run WIN /D:S, then the trap instruction will instead be placed in a hypervisor-provided area of RAM that’s shared among all guests, accepting the risk that a misbehaving guest will stomp over it and break everything (don’t know where it fits in the memory map).

As to the chances of failing, well, I suspect the original target was the c in “(c)”, but for example Schulman shows his system having the trap address point at “chnologies Ltd.”, presumably preceded by “Phoenix Te”. AMI and Award were both “Inc.”, so that would also work. Insyde wasn’t a thing yet; don’t know what happened on Compaq or IBM machines. One way or another, looks like a c could be found somewhere often enough that the Microsoft programmers were satisfied with the approach.

[1] https://jeffpar.github.io/kbarchive/kb/071/Q71264/

Re: WASM 3.0 Completed

#424

Post by wffurr »

jpc0 wrote: post #407
wyldfire wrote: post #265

Earlier quoted context omitted.

> ... document browser ... document reader ... I'm going to assume you're being sincere. But even the crustiest among us can recognize that the modern purpose for web browsers is not (merely) documents. Chances are, many folks on HN in the last month have booked tickets for a flight or bought a home or a car or watched a cat video using the "document browser". > If we think we need a more thoroughly virtualized machi…

So you are telling me I can now directly render from WASM into the viewport of the browser with a11y? Nope, then it’s still restricted to interacting with the DOM through JS or or renderings to a cavas with no a11y support or significantly worse dx for a11y because you would need to render a screen reader only document layout ontop of your actual UI, instead of just handing the browser an interaction tree and allowin…

You can write Wasm bindings to the native UI toolkit of your choice and render with that. It doesn’t have to be in the DOM.

Re: WASM 3.0 Completed

#425

Post by wffurr »

goku12 wrote: post #353
Zariff wrote: post #345

Earlier quoted context omitted.

I'm not familiar with WASM. Can someone explain why this is a good thing? How does this work with languages that do not have a garbage collector, like Rust?

The answer was kind of known before hand. It was to enable the use of GCed languages like Python on Ruby to create WASM applications. Meanwhile, non-GCed languages like Rust, C and C++ were supposed to continue to work as before on WASM without breaking compatibility. This is what they seem to have finally achieved. But I needed to make sure of it. So, here are the relevant points from the WASM GC proposal [1]: * Mot…

Note that the high level language needs a sufficient abstraction in its own runtime to allow substituting the Wasm GC for the runtime’s own GC. Work has been done for Java and Kotlin, but Python, C#, Ruby, Go can’t yet use the Wasm GC.

Re: WASM 3.0 Completed

#426

Post by jesse__ »

norman784 wrote: post #392
jesse__ wrote: post #313

Earlier quoted context omitted.

My bad, didn't fact check myself before I made an annoying quip. For some reason I thought browsers and started to roll out out native support for TS.

Maybe you got confused, because NodeJS is now able to strip annotations (it does not transform enums, etc) to let you run Typescript files directly.

Ahhhh, that was it. Thank you

Re: WASM 3.0 Completed

#427

Post by jesse__ »

chrismorgan wrote: post #382
tormeh wrote: post #260

Earlier quoted context omitted.

Preach. HTML and CSS are markup languages for creating documents. Using them for GUI applications is wild and obviously a bad idea.

Most major GUI frameworks operate on something very similar to HTML + CSS.

Can you elaborate? I don't see how this is true.

Re: WASM 3.0 Completed

#428

Post by biztos »

apatheticonion wrote: post #209
cedws wrote: post #180

When is WASM finally going to be able to touch the DOM? It feels like that was the whole point of WASM and instead its become a monster of its own that barely has anything to do with web anymore. When can we finally kill JavaScript?

Agreed. This and (sane) access to multi-threading. I want to be able to write a Rust application, compile to wasm and load it with Would be great for high performance web applications and for contexts like browser extensions where the memory usage and performance drain is real when multiplied over n open tabs. I'm not sure how code splitting would work in the wasm world, however. v8 could be optimized to reduce its m…
Why not just do the whole DOM out of your WASM?

Re: WASM 3.0 Completed

#429

Post by zarzavat »

_nalply wrote: post #422
zarzavat wrote: post #389

Earlier quoted context omitted.

> AND-masking does not really allow for producing the necessary traps for invalid accesses. Why does it need to trap? Can't they just make it UB? Specifying that invalid accesses always trap is going to degrade performance, that's not a 64-bit problem, that's a spec problem. Even if you define it in WASM, it's still UB in the compiler so you aren't saving anyone from UB they didn't already have. Just make the trappin…

It's WASM. WASM runs in a sandbox and you can't have UB on the hardware level. Imagine someone exploiting the behavior of some browser when UB is triggered. Except that the programmer is not having nasal demons [1] but some poor user, like a mom of four children in Abraska running a website on her cell phone. [1]: http://catb.org/jargon/html/N/nasal-demons.html

The UB in this case is "you may get another value in the sandboxed memory region if you dereference an invalid pointer, rather than a guaranteed trap". You can still have UB even in a sandbox.

Seems like they got overly attached to the guaranteed trapping they got on 32-bit and wanted to keep it even though it's totally not worth the cost of bounds checking every pointer access. Save the trapping for debug mode only.

Re: WASM 3.0 Completed

#430

Post by muyuu »

GeneralMaximus wrote: post #402
prewett wrote: post #259

Earlier quoted context omitted.

I guess I’m just a crusty ol’ greybeard C++ developer, but it seems like a video editor is out of place in a document browser. There’s a perfectly good native operating system that nobody uses any more. If we think we need a more thoroughly virtualized machine than traditional operating system processes give us (which I think is obvious), then we should be honest and build a virtualization abstraction that is actuall…

There is no difference between a "document" and an "app". There has never been a difference between the two, it's a purely artificial distinction. Word and LibreOffice "documents" can run embedded macros. Emacs has `org-mode`, which can call out to any programming language on your $PATH. A PDF document is produced by running code in a stack-based virtual machine. Even fonts have bytecode instructions embedded inside…

the loose implication is that documents don't have access to resources outside of itself and they're somewhat static

imo when you start talking about dynamic documents the distinction starts to blur but it should be fine if it's just a few parameters that are meant to be manually updated... beyond that "document" seems like the wrong term (and tech)

those artificial distinctions are essential and perfectly practical as they can convey expectations just fine

GP is correct in that the browser has generalised to a point it has clear drawbacks for its original intended purpose, but that is just a fact of life at this point

IMO, html should have scaled back from 5.0 to the feature-set of 4, if not 3, with mass deprecations and beyond that it shouldn't be called html even if the main browsers carried on adding features and interoperable OS-like characteristics, so people could see beforehand if they were visiting hypertext documents or application sites, because certainly most of the web right now could not be reasonably called "hypertext"

but that isn't the way it was handled and tbh it was to be expected

Post reply on HN