Tweet Disematkan
Feoramund
1.3K posts
Feoramund
@Feoramund
Archiver, programmer, sculptor.
The Old Web Bergabung Nisan 2024
9 Mengikuti719 Pengikut
A week fraught with small computer troubles has passed, but I've found my way. I've been forking and packaging the software I use myself, getting a bit away from the automated package managers.
I'll have some cool stuff to share this month. The sun is setting once again.
English
Yesterday was busy; I got some craftsmanship done. The old headphones had worn down so much that the earpads were crumbling, so I sewed new ones from cloth and stuffing. They ought to be less harmful to the skin than the fake plastic-leather stuff.
Time to try them out.
English
I'm gonna start removing everything from AUR, and after that do the same thing with as much stuff from extra and multilib as possible.
Ideally, the only thing that is installed from Arch repos is core.
The end goal is to have all non-critical software come only from official flatpaks/appimages/targz, or built manually. I'm not sure how feasible it is, but feels like a worthwhile experiment.
I really don't want to go down Guix/Nix rabbithole again, but those still remain as a backup plan
English
@Jonathan_Blow Supporting evidence: Starships and time machines in the first game, before the land was called Britannia.
English
Just put 2 and 2 together: Having moons called Trammel and Felucca means Britannia was founded by already-technological humans. (insert astronaut "always has been" gif)
English
I built Wine from source yesterday to try out a custom feature in the native Kernel32 DLL. Despite the weight, this is easier than trying to build a proxying Winelib DLL (which might be impossible) or overwriting the executable memory of certain functions with trampolines.
English
The "We don't break userspace" stance indeed belongs to Linus and Linux, but the operating system most people are using is GNU/Linux, and GNU and all that is tied to it are not the same project as the Linux kernel.
I am not using glib for my own projects any more (where avoidable), as I have written my own C standard library.
I think this problem can be solved by moving most functionality from the myriad C libraries (graphics, audio, windowing, and so on) that people use on Linux, into the operating system itself, but that's a whole architectural shift that would be more easily done on a new OS.
x.com/Feoramund/stat…
Feoramund@Feoramund
It depends on what you mean by Linux; the joke about "GNU/Linux" holds some truth to it. To give a clear idea of where I am: I've built a standard library from nothing more than C89 code, syscalls, and x86 assembly that runs on Linux and FreeBSD, and I experimented with the Win32 API for several hours on a Windows 98 virtual machine back in March; I have far more experience working directly with the Linux kernel. Linux is barebones in what it can do, and significant chunks of the OS are scattered across a handful of C libraries, usually with a couple different options. So, if you're determined to write your own C standard library with no dependencies but the actual kernel, you have to write a lot from scratch. For instance, if you want to know the local timezone, you have to write a TZif parser from scratch; there is no syscall in Linux to get that information. If you want to resolve an internet domain name address, you have to write a DNS client and resolv-conf parser; there is no syscall in Linux to get that information. I've done both of these and more. In that view, Win32 is easier because I have seen significant upsides to using their C libraries against the idea of trying to write syscalls on Windows. Win32 provides everything in a consistent interface, and it has compatibility in mind; there's a good chance that a program made for Windows 98 can still run on a Windows machine of today. The same is hard to say for GNU/Linux in terms of binary reliability over time. If Linux had syscalls for everything: windowing, graphics, audio, DNS, datetime, and so on, it would be easier.
English
@biorr99 @Feoramund If that is the case, then why use glibc?
Pardon my ignorance here - I come from a windows development background.
If glibc does not provide a stable ABI, why link against it? (Is linking against it required? Why isn't glibc ABI stable?)
English
It depends on who's using this technique and what they need.
If you have Wine, you should have winegcc and do not need such a compiler. I'm going to use this to prototype some ideas and get a feel for the Win32 API before putting together more elaborate systems. That will be helpful for me in terms of iteration speed.
You also get a native Linux binary which can interface with the kernel or the various POSIX libraries. It's not a usual thing for Windows toolkits to know how to do that.
I think this might be a neat way to have a Windows-styled alternative to SDL, too.
There may be changes in performance, but that would require rigorous research and is not something I will personally look into right now, but someone else might find worth taking up.
As with everything, there's tradeoffs depending on the goals; maybe someone can't make use of this because they rely on certain specific features of a Windows compiler.
I think it's a cool technique worth sharing, given some chatter I've seen lately.
English
@Feoramund What's the advantage over just compiling a win32 exe as normal (using tcc, mingw, etc.) given it's gonna run through wine anyways?
English
@petey_fo_really @valigo So long as Wine is on the system path, it will run.
English
@valigo Do you have to bundle anything, or its just find wine on the system and go?
English
This might seem like "oh what's big you could cross-compile to windows exe for a long time", but I want to emphasize - this is Linux-native ELF executable! That uses win32 api! Through Wine, as if Wine were SDL or something like that. This is actually amazing!
Feoramund@Feoramund
Wine can help build C code on Linux that uses the Win32 API. You get ELF programs that talk to Wine directly, and it's easy to setup. You can even get DirectX running. The second picture is showing the OpenWatcom Direct3D9 example code from the year 2004 with no modifications.
English
@jakubtomsu_ It is not. My original approximation of cosine would not have yielded such a clean result when inverted.
English
While working on geometry I went off on a tangent: I used my newest Algebraic might to solve for the inverse function of the polynomial approximation of cosine that I posted a few days ago.
So now I have an approximation of arc cosine too. That can be put into code. Math is fun.
English
@refinism Not such as it is. The makefile created by winemaker makes an executable shell script that runs Wine with your resulting program as a target.
It is still a native Linux binary, but Wine (and all of its infrastructure) is needed as the implementation layer of the Win32 API.
English
Wine can help build C code on Linux that uses the Win32 API. You get ELF programs that talk to Wine directly, and it's easy to setup.
You can even get DirectX running. The second picture is showing the OpenWatcom Direct3D9 example code from the year 2004 with no modifications.
English
@CitizenTwice Despite its flaws, Win32 has been more stable than anything else so far.
I will be using this to iterate faster on rough draft planning for Windows development, so I don't have to boot up a VM until testing is needed.
English
@Feoramund Excellent, this is exciting! Beside d3d, I'd be interested in working with the Win32 API for GUI on Linux, I know it doesn't get a lot of love for its archaic design, but personally I still prefer it to most modern alternatives.
English
@CitizenTwice With Winelib; that's right. I've talked about the steps here and in another reply. It's easy to make a native Linux program that uses the Win32 API.
x.com/Feoramund/stat…
Feoramund@Feoramund
@valigo All I had to do was run "winemaker .", add "d3d9" to the list of DLLs in the makefile that it generated, and run make. This could truly be an alternative to SDL.
English
@Feoramund ELF program... so not an EXE. How is that done, with WineLib?
English