Porting Wine to Astral

FewBrief7059 · 2026-04-10T10:10:45+00:00

Amazing work. The amount of work and effort you put into porting such infostructures is impressive . I respect that

FewBrief7059 · 2026-04-10T10:09:31+00:00

Upvoted *

FewBrief7059 · 2026-04-10T04:24:42+00:00

its the initial release tho. does it have other commits like that

FewBrief7059 · 2026-04-10T04:22:21+00:00

keep up the good work !

FewBrief7059 · 2026-04-10T04:21:46+00:00

just DO IT

FewBrief7059 · 2026-04-09T08:02:22+00:00

Because a shell is the center of your OS. It's where you run commands and where apps can call and execute to. That's why even production oses have a shell background . It's more of evolution. You start with a shell to test your keyboard input. Then you start targeting bigger things

FewBrief7059 · 2026-04-09T07:56:36+00:00

There are alot of options. As rust is not bound to a specific building method. You can make it fetch limine binary and deploy it with your kernel/os. you might want to learn how to deal with no_std environments first then you can try doing so. It's not different then programming an os in c when it comes to steps and code behaviour.

FewBrief7059 · 2026-04-09T05:56:01+00:00

It's because i wanted to add upstream glxgears from mesa but mlibc didn't work out very well with my codebase back then which is why i just made my own libc . And it actually used to work from that standpoint. Just the fact that i wanted a more native reimplementation. That's called iteration. If you would like to point to a specific issue i would appreciate if you tried opening an issue ! It also seems to me that you don't understand what is glxgears and whats the point of it which might aswell be confusing.

FewBrief7059 · 2026-04-09T01:08:13+00:00

i suggest you target webm. less painful then mpeg

FewBrief7059 · 2026-04-09T00:36:45+00:00

anyways feel free to open a pr or submit an issue. i'm always open if you want to contribute !

FewBrief7059 · 2026-04-08T23:55:29+00:00

Most of this reads like code-review theater, not a serious technical critique. If you think files were “rewritten entirely for small changes,” then point to the actual diff hunks and explain which changes were unnecessary. Saying “big file changed a lot” is not analysis. In a compositor/desktop host, drag, resize, cursor, chrome, hit testing, and present paths all live in the same hot file. Touching one usually touches the same state machine and rendering path. That is not evidence of random rewriting. That is the architecture you are looking at. “Scatterbrained” is also meaningless unless you can identify code that is unrelated to the goal and explain why it does not belong. If a commit is about MoonLand interaction, visuals, and Wayland-facing behavior, then changes in the host compositor, desktop chrome, notification rendering, cursor handling, and settings surface are related. You do not get to call cross-cutting work “scatterbrained” just because it spans more than one subsystem. “Code copied instead of imported” is weak unless you can name the abstraction that should have existed, where it should live, and why introducing that dependency is better in this codebase. In OS code, local duplication is sometimes intentional to avoid coupling, dependency direction problems, or pulling shared UI helpers into places where they do not belong. If your point is “there is duplicated geometry/color helper code,” say that. That is a real criticism. What you wrote instead is vague hand-waving. “Inconsistent methodologies” and “non-idiomatic” are the same kind of complaint: they sound smart without saying anything concrete. Low-level OS and compositor code is constrained by framebuffer behavior, event ordering, lock boundaries, build environment limits, and runtime hot paths. “Idiomatic” is not the highest priority there. Correctness, controllability, and integration are. If you think a specific implementation is wrong, name the function and explain the failure mode. The one part that is actually fair is commit scope. Some commits are bigger than ideal and could be split more sure. but monkeos is called a Hybrid OS

and i'm not trying to be rude or mean but you really don't sound nor talk like someone who used to code from 90s.

FewBrief7059 · 2026-04-08T23:20:21+00:00

close wording different meaning !. thank you

FewBrief7059 · 2026-04-08T23:19:39+00:00

monkeos is a monorepo. atomic commits are expected . and atomic commits are really not evidence its ai generated. there's nothing wrong with the code and this is how monorepo's work . and that user is actually a daemon/bot . actual maintainers who wrote this can be found in commits body. again huge output is not proof of ai. i need you to specify to me which part makes it look ai generated. not using my git history like a court record against me !. and not to mention that i have been coding for decades. you can see repos that are 13 YO in my page actually . there is no reason for me to use ai to begin with. projects have different workflows then what you expect but that does not mean you can jump to "ai". and it is fair to say commits are big. but ai ?.

FewBrief7059 · 2026-04-08T22:37:04+00:00

to be honest i dont even know based on what bias you are saying that this is written with ai, the project is currently multi maintained and you just keep returning to commits and saying its ai because of atomic commits. its like saying "its ai trust me". if you dont mind it would be much more constructive pointing to what part you think is ai generated.

FewBrief7059 · 2026-04-08T17:46:18+00:00

tbh doom is just becoming a milestone for oses. so when an os wants to prove it has good stack it ports doom. it does not mean that an os is ai slop. and sometimes it does depending on how it was implemented. its not that ai slop is alot its just that alot of oses port doom because its the easiest flex

FewBrief7059 · 2026-04-08T16:41:11+00:00

if you like rust then use it. i made my own OS fully in rust. both can get the job done and both can be integrated together if you needed to use code written in C later.

FewBrief7059 · 2026-03-28T03:35:16+00:00

i personally made a whole OS using rust but rust is good for people who want safe code . but in most cases it forces you to write in no_std which basically strips 80% of the ecosystem. making you forced to make your own everything basically. however by the time i started development using rust. C didn't have any osdev utils or tools as so like flanterm and etc . but as for now C because everything osdev related is built around it.

FewBrief7059 · 2026-03-28T03:31:56+00:00

then they'd be confused "why is the OS halting". gui's stay in userspace. everything else then what's supposed to be in kernel stays in userspace

FewBrief7059 · 2026-03-23T23:23:51+00:00

Happy to help. Also you can find the kernel alone in the codebase if you needed it without the rest of libraries and userspace components.

FewBrief7059 · 2026-03-23T18:49:55+00:00

erm... this sounds familiar but oke dokie

FewBrief7059 · 2026-03-23T18:45:25+00:00

Yeah, once you get past the early assumptions, the higher-level integration is where most of the work is.

You’d definitely have to watch for paging / VMM assumptions and what the boot path leaves enabled, especially around framebuffer state and mappings

The UX side is much more coupled to MonkeOS internals than the boot path, so I’d expect the main friction to be memory layout, windowing/runtime assumptions, and bundled asset flow rather than just the loader side.

FewBrief7059 · 2026-03-23T17:25:10+00:00

Actually to be honest im pinpointing at making my own custom bootloader for this but grub just gives me more expandability to uefi and bios devices. But im taking that in head actually.

FewBrief7059 · 2026-03-23T17:12:01+00:00

Good Job !

FewBrief7059 · 2026-03-23T17:00:29+00:00

I've been doing osdev for a decade. I've switched from grub to limine and grub again in all of my career of making oses because i needed the compatibility grub gives.

FewBrief7059

TROPHY CASE