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

BSD on Windows: Things I wish I knew existed

virtuallyfun.com

Post reply on HN
Print view View original

91–100 of 115 posts

Re: BSD on Windows: Things I wish I knew existed

#91

Post by AshamedCaptain »

rollcat wrote: post #83
bheadmaster wrote: post #72

Earlier quoted context omitted.

POSIX only defines source-code level compatibility. However, all OSes are free to implement their system calls any way they want. In order to run binaries compiled for a specific OS, you need to emulate that OS's (i.e. kernel's) ABI. There's no way around that. The only way to achieve true binary compatibility would be to use a system-level virtual machine, ala Inferno [0] or PhantomOS [1]. [0] https://www.inferno-os…

What's funny is we've tried so many different, "better" solutions to build once, run anywhere. I truly love Inferno - learned SO much reading the dis VM bytecode spec; JVM was and still is a thing; there's even .NET IR which was built with the specific, explicit goal of getting JIT'ted for the target CPU. The two de-facto solutions ended up being: - win32/wine; - Linux emulation - the kernel itself has an incredibly…

The kernel does _not_ have an incredibly stable interface. It is in the fact part of the reason older statically linked versions of glibc no longer work. I personally count at least two breaking changes, and only one of them got an option in Kconfig (which was related to ASLR iirc, so distros rushed to enable the "break compatibility" option). . Yet another example dynamic linking almost always makes things easier for your future users, despite the preconceptions.

Just grep your kernel's Kconfig for "ancient" -- the euphemism every developer uses to refer to stuff they don't care about and want to break.

Also, stuff in /proc, /sys, or the like is moving every other day, and some programs depend on it (sigh).

Re: BSD on Windows: Things I wish I knew existed

#92

Post by scruffyherder »

boomboomsubban wrote: post #53

The author reached out to Hiroshi Oota on github, who said they created it to use emacs on Windows. Not sure why it's not in the article, but figure there might be a reason so won't link it.

yes I was hoping to do an update after I had help finding the author, and to see if there was any potential of an update. It's late breaking & live. And it seems all the engagement is here not on the blog so I didn't see this as I was sleeping.

Re: BSD on Windows: Things I wish I knew existed

#93

Post by zlg_codes »

rollcat wrote: post #81
zlg_codes wrote: post #71

Earlier quoted context omitted.

This is relevant to my interests. What roadblocks did you run into when you attempted to build statically? I assume your goal was to have a single binary of Love2D so you can swap it around and not worry about glibc version? (As God intended imo; not religious but games should be one contained thing imo) Am curious to see what it does to avoid a static build.

The love2d static build story was a tangent to my 2016 challenge to ship one game every month of the year. The tangent ended up delaying the March game indefinitely, and thus ending the challenge... My memory is a bit hazy, so apologies for the scarce/imprecise details. I really, really wanted to ship binary builds for the three major platforms: Windows, Mac, and Linux; so that my friends and strangers could actually…

Thanks for sharing this journey! I've been considering Love2D for a while so it's important to read about the challenges others run into. You should definitely not have to package Mesa to ship a game! I wonder why it hooks so far deeply..

Coming from PICO-8 myself, I'm wondering if I should just skip the frameworks to babystep and just jump into C+SDL, or pygame or something. I like the different ways that games can be made -- like your procedural graphics not needing a graphics library.

Re: BSD on Windows: Things I wish I knew existed

#96

Post by rollcat »

zlg_codes wrote: post #93
rollcat wrote: post #81

Earlier quoted context omitted.

The love2d static build story was a tangent to my 2016 challenge to ship one game every month of the year. The tangent ended up delaying the March game indefinitely, and thus ending the challenge... My memory is a bit hazy, so apologies for the scarce/imprecise details. I really, really wanted to ship binary builds for the three major platforms: Windows, Mac, and Linux; so that my friends and strangers could actually…

Thanks for sharing this journey! I've been considering Love2D for a while so it's important to read about the challenges others run into. You should definitely not have to package Mesa to ship a game! I wonder why it hooks so far deeply.. Coming from PICO-8 myself, I'm wondering if I should just skip the frameworks to babystep and just jump into C+SDL, or pygame or something. I like the different ways that games can…

The "can I link Mesa statically" journey was futile, I had much less understanding how things worked back then (not that I'm any kind of an expert now, but you shouldn't be one to ship a f.in game). See, a pretty big chunk of the graphics driver stack on Linux sits in the .so's provided by Mesa: the i915_dri.so, r600_dri.so, nouveau_dri.so, libvulkan_intel.so, libvulkan_radeon.so, etc are ALL exactly what it says on the package. It's not just 50+MB of x86-64 code, it's also your peace of mind that whenever AMD/Intel/NVidia/Apple/RPi/etc drop a new GPU model, or whenever the kernel changes things on their end, you don't need to relink and re-release.

I'm torn between "all of this stuff belongs in the kernel goddammit" and "these guys probably know better". OpenBSD and macOS actually force all syscalls to go through a dynamically linked libc, so perhaps it's the latter.

Libraries/frameworks/engines such as PICO-8, Love2d, SDL, Allegro, Pygame, Godot, etc exist precisely to abstract away these details; you're not meant to care for libGL.so.1, you're meant to care for fixing your physics engine's timestep and using cubic splines to interpolate animation. Love2d was not a mature choice in 2016, so don't take my horror story or my hubris as any indication of what it looks like today; do your own research and pick the tool for the job ;)

TBH I would love to go back to making games, but recently got too absorbed by StarCraft 2 and shitposting.

Re: BSD on Windows: Things I wish I knew existed

#97

Post by ladyanita22 »

krylon wrote: post #77
DeathArrow wrote: post #66

Not sure that NT kernel is inferior to UNIX/POSIX. It was by David Cutler modelled after VMS, which was state of the art at one point.

The kernel, I've been told by people more knowledgeable about this things than myself, is a work of beauty. But the layers and layers of Win32 that sit on top of it do a great job of covering that up.

Well, the benchmarks don't tell that.

Re: BSD on Windows: Things I wish I knew existed

#98

Post by zlg_codes »

rollcat wrote: post #96
zlg_codes wrote: post #93

Earlier quoted context omitted.

Thanks for sharing this journey! I've been considering Love2D for a while so it's important to read about the challenges others run into. You should definitely not have to package Mesa to ship a game! I wonder why it hooks so far deeply.. Coming from PICO-8 myself, I'm wondering if I should just skip the frameworks to babystep and just jump into C+SDL, or pygame or something. I like the different ways that games can…

The "can I link Mesa statically" journey was futile, I had much less understanding how things worked back then (not that I'm any kind of an expert now, but you shouldn't be one to ship a f.in game). See, a pretty big chunk of the graphics driver stack on Linux sits in the .so's provided by Mesa: the i915_dri.so, r600_dri.so, nouveau_dri.so, libvulkan_intel.so, libvulkan_radeon.so, etc are ALL exactly what it says on…

Part of my interest is also getting better at Lua, and it seems to excel in embedded contexts like making small 2D games. So maybe Love2D will still be good for that, and maybe the statically linking story is better now. My eventual goal is similar to yours -- I want to ship a game with a single binary per platform that players don't have to get confused about. Completing a game at all would be good enough, but I want to do it right!

Re: BSD on Windows: Things I wish I knew existed

#99

Post by speed_spread »

minton wrote: post #14
Teever wrote: post #10

Earlier quoted context omitted.

Totally. I don't want to derail the conversation too much but when I look at what Notch has become since he became a billionaire it's frankly pathetic. Princes & Kings Isn't it strange how princes and kings, and clowns that caper in sawdust rings, and common people, like you and me, are builders for eternity? Each is given a list of rules; a shapeless mass; a bag of tools. And each must fashion, ere life is flown, A…

What happened to Notch?

Bought a big house on the Hills, throws big parties with superficial people, tweets shit as if the political opinions of an instant billionaire suddenly mattered.

Re: BSD on Windows: Things I wish I knew existed

#100

Post by pjmlp »

rollcat wrote: post #83
bheadmaster wrote: post #72

Earlier quoted context omitted.

POSIX only defines source-code level compatibility. However, all OSes are free to implement their system calls any way they want. In order to run binaries compiled for a specific OS, you need to emulate that OS's (i.e. kernel's) ABI. There's no way around that. The only way to achieve true binary compatibility would be to use a system-level virtual machine, ala Inferno [0] or PhantomOS [1]. [0] https://www.inferno-os…

What's funny is we've tried so many different, "better" solutions to build once, run anywhere. I truly love Inferno - learned SO much reading the dis VM bytecode spec; JVM was and still is a thing; there's even .NET IR which was built with the specific, explicit goal of getting JIT'ted for the target CPU. The two de-facto solutions ended up being: - win32/wine; - Linux emulation - the kernel itself has an incredibly…

Cosmopolitan only works for basic C APIs, for example working with 3D API, talking to game controllers over LE Bluetooth.

JVM is doing quite alright across desktop, servers, embedded and 80% of mobile phones.

.NET less so due to Microsoft's strategy error to bind it to Windows. Still nowadays my .NET workflow is exactly like my Java one.

Work on Windows, deploy where needed.

I don't think in POSIX since 2006.

Post reply on HN