The idea is that it's a standard and stable runtime environment.

100 years from now we'll still be able to run NES games, but running old windows programs may be nearly impossible. uxn is trying to be like the NES in that regard, but for more general use cases than just games. Write a uxn program once, and it can run anywhere, any time (on any device that can host uxn).

I totally get your point but we are great at running old windows now with dosbox and wine.

For now, but maintaining DOSBox and especially WINE continues to require substantial engineering effort, in part because the platforms they're running on change. Implementing Uxn/Varvara is many orders of magnitude easier than implementing Win32, as evidenced by the fact that many more people have done it despite the much smaller base of applications they can then run. It seems likely that many Win32 applications will execute incorrectly on versions of WINE that are current in 02124, unless they themselves are running on top of something like Uxn.

Probably not Uxn itself, though, because a 16-bit memory space is not a practical way to emulate Win32. Dmitry wouldn't be dissuaded, I suppose.

I understand the argument, and feel good about it. I too would rather our software was made with simplicity and performance in mind not only following the premise that hw resources will only increase so let's ignore those constrains today.

But another perspective for win32 support in future metal is the bigger "community" (users, software, etc) so the increase in support complexity is compensated for much (much) larger incentives for supporting much more diverse and desired old software. WINE and related SW is a testament to this

It might work out that way, or it might not. The current open-source community is very much a product of current social conditions, and those conditions might change. They've changed before, and could change again.

Things like LLMs and the xz backdoor, for example, may make it unappealing to accept code from people you don't know personally; things like Apple's notarization requirements may make it impractical to run open-source software except as part of a proprietary package; software patents or legal liability for third parties using your software could make it legally unappealing to free your code; etc.

Not a problem. You can simply emulate Windows, then emulate Uxn within Windows.

someone already said but it's an emulator the way java vm or python vm are emulators. they emulate a computer architecture and environment that is uniform across different hardware types.

in the uxn case the different hardware types include small raspberry pis, Nintendo DS, etc. So having the baseline be really simple means knowing the code you've written for uxn will run on all these different hardware types.

You can also build a CPU that runs uxn code directly on hardware (I assume).

if you are a user then the only reason you'd run uxn on modern powerful hardware is if there is an app written for it that you wanted to use. Just like java, or python, or rust.

For a developer, grabbing uxn might be an aesthetic or political choice, like the language, or you want to target low power hardware use cases.

Uxn runs on its own VM, so each emulator emulates this VM, just like every java implementation emulates the JVM, etc. In other words, the emulator isn't designed for any specific physical machine to begin with.

It makes it easier to understand what is going on when you realize that Java did it first.

The 'VM' in "JVM" is "virtual machine".