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

Loss32: Let's Build a Win32/Linux

loss32.org

Post reply on HN
Print view View original

411–420 of 493 posts

Re: Loss32: Let's Build a Win32/Linux

#411

Post by muth02446 »

mook wrote: post #169
muth02446 wrote: post #118

Earlier quoted context omitted.

Wasn't there also DLL hell on Windows? My understanding is that very old statically linked Linux images still run today because paraphrasing Linus: "we don't break user space".

Unfortunately you can't really statically link a GUI app. Also, if you happened to have linked that image to a.out it wouldn't work if you're using a kernel from this year, but that's probably not the case ;)

> Unfortunately you can't really statically link a GUI app.

But is there any fundamental reason why not?

> Also, if you happened to have linked that image to a.out it wouldn't work if > you're using a kernel from this year, but that's probably not the case ;)

I assume you refer to the retirement of coff support (in favor of elf). I would argue that given how long this obsolete format was supported was actually quite impressive.

Re: Loss32: Let's Build a Win32/Linux

#412

Post by rcxdude »

chrismorgan wrote: post #392
ben-schaaf wrote: post #224

Earlier quoted context omitted.

Only because people aren't putting in the effort to build their binaries properly. You need to link against the oldest glibc version that has all the symbols you need, and then your binary will actually work everywhere(*). * Except for non-glibc distributions of course.

I don’t understand why this is the case, and would like to understand. If I want only functions f1 and f2 which were introduced in glibc versions v1 and v2, why do I have to build with v2 rather than v3? Shouldn’t the symbols be named something like glibc_v1_f1 and glibc_v2_f2 regardless of whether you’re compiling against glibc v2 or glibc v3? If it is instead something like “compiling against vN uses symbols glibc_…

Individual functions may have a lot of different versions. They do only update them if there is an ABI change (so you may have e.g. f1_v1, f1_v2, f2_v2, f2_v3 as synbols in v3 of glibc) but there's no easy way to say 'give me v2 of every function'. If you compile against v3 you'll get f2_v3 and f1_v2 and so it won't work on v2.

Re: Loss32: Let's Build a Win32/Linux

#413

Post by rcxdude »

jhasse wrote: post #368
grishka wrote: post #289

Earlier quoted context omitted.

Yeah and nothing ever lets you pick which versions to link to. You're going to get the latest ones and you better enjoy that. I found it out the hard way recently when I just wanted to do a perfectly normal thing of distributing precompiled binaries for my project. Ended up using whatever "Amazon Linux" is because it uses an old enough glibc but has a new enough gcc.

You can choose the version. There was apgcc from the (now dead) Autopackage project which did just that: https://github.com/DeaDBeeF-Player/apbuild

It's not at all straightforward, it should be the kind of thing that's just a compiler flag, as opposed to needing to restructure your build process to support it.

Re: Loss32: Let's Build a Win32/Linux

#414

Post by rcxdude »

cesarb wrote: post #296
Const-me wrote: post #288

Earlier quoted context omitted.

> versioned symbols are a thing on Windows There’re quite a few mechanics they use for that. The oldest one, call a special API function on startup like InitCommonControlsEx, and another API functions will DLL resolve differently or behave differently. A similar tactic, require an SDK defined magic number as a parameter to some initialization functions, different magic numbers switching symbols from the same library;…

> There’re quite a few mechanics they use for that. The oldest one, call a special API function on startup [...] Isn't the oldest one... to have the API/ABI version in the name of your DLL? Unlike on Linux which by default uses a flat namespace, on the Windows land imports are nearly always identified by a pair of the DLL name and the symbol name (or ordinal). You can even have multiple C runtimes (MSVCR71.DLL, MSVCR…

Linux can do this as well, the issue is that just duplicates how many versions you need to have installed, and it's not that different in the limit from having a container anyway. The symbol versioning means you can just have the latest version of the library and it remains compatible with software built against old versions. (Especially because when you have multiple versions of a library linked into the same process you can wind up with all kinds of tricky behaviour if they aren't kept strictly separated. There's a lot of footguns in Windows around this, especially with the way DLLs work to allow this kind of seperation in the first place).

Re: Loss32: Let's Build a Win32/Linux

#415

Post by rcxdude »

immibis wrote: post #409
ogogmad wrote: post #172

Earlier quoted context omitted.

This might be why OpenBSD looks attractive to some. Its kernel and all the different applications are fully integrated with each other -- no distros! It also tries to be simple, I believe, which makes it more secure and overall less buggy. To be honest, I think OSes are boring, and should have been that way since maybe 1995. The basic notions: multi-processing, context switching, tree-like file systems, multiple user…

Because Linux not an OS. The flagship OSS OS is Ubuntu, and it's mostly pretty stable. But OSS inherently implies the ability to make your own OS that's different from someone else's OS, so a bunch of people did just that.

Ubuntu still suffers the same kind of breakage though. You can't take an moderately complex GUI application that was built on ubuntu 2014 and run it on the latest version. Heck, there's a good chance you can't even build it on the newer version without needing to update it somehow. It's a property of the library ecosystem around linux, not the behaviour of a given distro.

(OK, I have some experience with vendors where their latest month-old release has an distro support release where the most up-to-date option is still 6 months past EOL, and I have managed to hack something together which will get them to work on the newer release, but it's extremely painful and very much not what either the distros or the software vendors want to support)

Re: Loss32: Let's Build a Win32/Linux

#416

Post by singpolyma3 »

0xbadcafebee wrote: post #365
singpolyma3 wrote: post #330

Earlier quoted context omitted.

> Linux hardware support is still crap What are you talking about? The majority of hardware is supported by only Linux at this point.

There is plenty of hardware that is either unsupported or poorly supported. I have personally run into a dozen different devices and several architectures that were unsupported. And I'm just one person buying normal stuff in stores.

Sure but this is true of every OS. I can't install macOS or Windows on most of the hardware around me and have it support all the hardware either.

Re: Loss32: Let's Build a Win32/Linux

#417

Post by yx827ha »

LegionMammal978 wrote: post #311
ben-schaaf wrote: post #224

Earlier quoted context omitted.

Only because people aren't putting in the effort to build their binaries properly. You need to link against the oldest glibc version that has all the symbols you need, and then your binary will actually work everywhere(*). * Except for non-glibc distributions of course.

But to link against an old glibc version, you need to compile on an old distro, on a VM. And you'll have a rough time if some part of the build depends on a tool too new for your VM. It would be infinitely simpler if one could simply 'cross-compile' down to older symbol versions, but the tooling does not make this easy at all.

Check out `zig cc`. It let's you target specific glibc versions. It's a pretty amazing C toolchain.

https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...

Re: Loss32: Let's Build a Win32/Linux

#418

Post by cosmic_cheese »

Klonoar wrote: post #344
layer8 wrote: post #262

Earlier quoted context omitted.

The problems with cloning the exact look is fear of copyright/IP issues with Microsoft. You can be pretty sure they won’t look away if such a desktop becomes really popular. Remember how Apple sued Samsung over using rounded corners on icons?

It is becoming obvious that some people didn't live through the Lindows era.

I remember Lindows, but I think their problem had more to do with their branding and marketing and the fact that it was sold commercially than it did with its UI resembling Windows, and all of those mistakes are trivial to avoid.

That said, even if the UI looking the same is an issue, it’s not that difficult to come up with a look and feel that is legally distinct but spiritually aligned and functionally identical… random amateurs posting msstyle themes for XP/Vista/7 on DeviantArt did that numerous times.

Re: Loss32: Let's Build a Win32/Linux

#419

Post by TazeTSchnitzel »

fithisux wrote: post #351
TazeTSchnitzel wrote: post #279

Earlier quoted context omitted.

Isn't that the OS from the 1990's that never got anywhere, and then the same people made ReactOS? googles Ah, no, that was FreeWin95. What on earth is Free95, it feels like history repeating itself…

One month ago their site went dark https://github.com/versoft-software/free95/ They also forked Uinxed kernel so as to run their userland. I believe they are the same. Still, it makes sense what they are trying to do.

To be honest, this seems like a project by some kid or something that has absolutely no idea what they're doing. It's a little painful to witness.

Re: Loss32: Let's Build a Win32/Linux

#420

Post by andrewf »

tssva wrote: post #59
andrewf wrote: post #13

Starting with FreeBSD might be easier than starting with Debian then removing all the GNUisms. But perhaps not as much Type II fun.

Using Linux gets you much more hardware compatibility especially for the consumer desktop and laptop systems this is targeted towards.

True
Post reply on HN