#ReactOS's Modern Hardware Woes
1 messages · Page 3 of 1
holy based
how cursed was implementing this? I assume this is just implementing UVC?
would the version that can be downloaded from the web support smp or id need to build it myself ?
I think you need to build it yourself from a specific branch on darkfire's GitHub fork. It's kind of a bitch though
I tried building the UEFI branch and got build errors on files that were, AFAIR, unmodified from upstream
Not very cursed
yeah it’s kinda a mess but I’m cleaning it up
I genuinely don't think it was your fault 😂
Yo thats pretty awesome
How hard was this to implement?
desktopuefi, not PR-uefildrcontinues, is the one I want for booting through UEFI right? and do you know if I need anything other than ROSBE to build it properly?
None of them boot properly
We’re working on getting everything merged for it though, so don’t feel a need to rush’
does ReactOS know how to handle the x2apic locked at handoff?
actually, does ReactOS even do smp 
does ReactOS know how to handle the x2apic locked at handoff?
nooooooope :3
It's easy 
I'll be showing off reactos on real hardware with SMP this year at CLT2026
This also means ill be showing off uACPI integrated into with a modern (ish) gaming laptop with all ACPI features suported
honestly? yeah at this point
my biggest blocker finally got resolved
there's one more thing im a little hesitant on but it now seems optional
I just have been doing other things to start that process
nice
what im upstreaming first isn't going to have everything the long term goal to have... is. But it's a start
and well, obviously works
fair fair
I did all this stuff for ACPI sleep, but the Po development is getting paused
I could actually get ros to resume finally
Why is Po getting paused?
Eh its personal stuff with the dev
damn, sad
Yeah a bit of a bummer but I think we might be doing something critical first for it
A handlful of the kernel devs are going to be ina hackfest (myself included) for a week
and we're going to discuss very deeply about the Mm
Mind you last year when we did this we discussed a bunch of things and now GPUs work in master :)
Ohh thats exciting
Yeah! i didnt post it here because this thread is more about.. in dev stuff
but every GPU you've seen in this threadnow works in the nightlies
even the titan x
2560x1440p, 4x Multisample AA, 16x Anisotropic Filtering.
Software and hardware used:
ReactOS nightly 0.4.16-2331
-Nvidia GeForce GTX 960 with 368.81 drivers
-SoundBlaster Audigy with Audio Support Pack drivers:
Install from Audigy_SupportPack_7_0\Audio\Drivers\Setup.exe
-WineVDM from Application Manager for 16-bit i...
2560x1440p, 4x Multisample AA, 16x Anisotropic Filtering.
Software and hardware used:
ReactOS nightly 0.4.16-2331
-Nvidia GeForce GTX 960 with 368.81 drivers
People been actively using it
reactos new task manager?
windows taskanager working on ROS?
ah, yeah that Sounds more realistic
ah, yeah that Sounds more realistic
average discord experience
when direct x on the direct x box
very pog
yoo
so
you may have heard the news
about reactos's arm64 builds
this is funny
but you know whats even funnier
a mobile UI
It’s just a funny gui
no way ROS mobile
Did anyone try running it on the 950 or some other Windows Phone?
yeah me
ros itself is running into issues still
but the moble UI on win10 looks coool
that would be sick if the center button was the reactos logo in the style of the other 2 buttons
tiny battery icon
Massive respect to ReactOS devs btw
wait, how does debugging over ethernet work
you'd have to run a whole TCP stack .... at high IRQL
how does it do... anything
how does serial do anything?
or maybe it's UDP
serial is super trivial compared to networked debugging
Is it?
yes?
its the same idea though
its literally wait until a port has a bit clear then write a byte, all in a loop
i wasn't pointing out serial debugging though
but windows also has kdnet, which deserves the PCI device
i was specifically pointing out networked debugging
yeah i know im explaining it
You store the network stack in a kernel transport DLL
once stuff is configured its really only RX and TX
so outside of initialization it's the same packets getting sent through
do you use TCP or UDP for the protocol?
There's both supported in windows kdnet
do you reserve a network card specifically for debugging, or do you somehow manage to share the network card with userspace
Im using UDP atm
You reserve it
ah, makes sense
and do you implement a whole (small) tcp/udp stack for the actual kernel debugger?
Yeah!
to, yknow, tx/rx
KDNET.dll is the network stack and than there's network drivers
kd_02_8086.dll (Intel e1000)
and i guess it also has to run at high irql and poll, just like serial debugging?
oh, interesting
It's the same as kdcom
so you have your own network drivers for debugging
yup
it makes sense
but they're really even in windows shimmed EDK2 drivers
kinda impossible to use normal drivers for debugging because they're not designed for that purpose
and kernel debugging has tons of restrictions
oh yeah, and than starting in win11, there's ethernet over usb debugging
interesting
for that, do they reserve the host controller that the ethernet adapter is connected to, or...
i assume communication via USB has to go through the host controller's registers
I think it reserves the host controller, i dont know how that works yet since i am only doing about win10 1607 atm
i see
Yooo
Finally no more painful serial 🙏
now that we have kdnet in PRs i can finally test my MSI/MSI-X code
and so far so good
so
We've been discussing all kinds of modern hardware
But let's take a step back and talking about the other side of the IRQ assignment coin and
sometimes
people want to boot on pentium MMX
issue is similar to what uACPI and HAL improvements solved for modern hw
(hal/halx86/pic/pic.c:1249) IRQ 30 is too high!
(hal/halx86/legacy/bus/sysbus.c:131) Vector 0 is ALREADY IN USE!
(hal/halx86/legacy/bussupp.c:1605) Returning IRQL 0, Vector 0 for Level/Vector: 30/0
(hal/halx86/legacy/bussupp.c:1608) Old HAL would've returned IRQL eb and Vector 60
(hal/halx86/legacy/bussupp.c:1605) Returning IRQL 0, Vector 0 for Level/Vector: 30/30
(hal/halx86/legacy/bussupp.c:1608) Old HAL would've returned IRQL eb and Vector 60
(ntoskrnl/io/pnpmgr/pnpres.c:1057) Failed to translate interrupt resource (Vector: 0x30 | Level: 0x30)
(ntoskrnl/io/pnpmgr/pnpres.c:1189) Failed to translate resources for PCI\VEN_0E11&DEV_AE33&SUBSYS_AE330E11&REV_03\2&b3ac4ede&2E
System PCI config space gives garbage
we need to program the IRQ from the table
fixing that wasn't so bad!
it takes some effort and is some seriously old code
But once it works we can boot on all sorts of legacy hw
That's sick
Like the mp table?
Nope, thats APIC.
I mean $PIR
Didn't even know that existed
Because no one cares about anything pre pentium 4
It’s how you program PCI IRQs with PIC
Anything with a functional pic has this in theory
But honestly anything newer than core 2 good luck lol
Interesting
It turns out the interrupt line can be filled with trash so on these old bioses
Great stuff
But these fixes allow ROS to use old hardware pretty much perfectly
Not that it’s a primary focus of ours…
But it’s cool :)
Don't you just look at the interrupt line field (not the pin one) in configuration space
Oh you mentioned that nvm
For an incredibly long amount of time I've been developing improvements to ReactOS hardware support, we've seen enormous stability improvements from this in testing but ofc trying to get master to the point its ready for this has been a rather aggressive battle
Anyway I believe I have a reasonable enough confidence in reactos's final design for ACPI I can start building out a project I've been looking to build for months
I'm going to build a separate repo that can be build with vs2022/2026 that will build reactos's up and coming ACPI.sys driver as replacement for the standard win11 ones
Obviously the intention here isn't for it to be the most ultimate stable 100% feature parity thing in the world at first, but it IS however a great way to test uACPI updates going forward
I've found the work you've spearheaded on reactos to be genuinely super exciting and cool
You've been single-handedly fixing its reputation lol
well I appreciate that thank you lol, though honestly ReactOS has gotten a lot of new core members that have been caring about stuff. I care a lot about kernel mode stuff. but the usermode side has been insane
In random consumer oriented places ill see reactos come up and someone goes "isn't it a super unstable mess" and someone will reply "they've actually improved it a LOT lately" so it's definitely showing
I wish i could help work on mm or something but im tainted to hell and back lol
honestly at this point the open mind approach you've taken to us helps infinitely, we'd rather admit our flaws and fix stuff at this point
2560x1440p, 4x Multisample AA, 16x Anisotropic Filtering.
Software and hardware used:
ReactOS nightly 0.4.16-2331
-Nvidia GeForce GTX 960 with 368.81 drivers
-SoundBlaster Audigy with Audio Support Pack drivers:
Install from Audigy_SupportPack_7_0\Audio\Drivers\Setup.exe
-WineVDM from Application Manager for 16-bit i...
lots of people just using it on real hardware lately for gaming
pretty insane
Wait so you intend to use it for both ros and as a windows driver? Will it eventually get merged into ros or do you expect to keep it separate permanently?
Yeah thats definitely true, incredible work by the darkfire fixing all sorts of stuff for ros
It’s going to get merged! I just have been daily driving uACPI for awhile, and it’s time to split it up into readable commits so PRs move fast
It’s going to be the same version that’s in the reactos repo just using the win11 interfaces
I like how in the age of internet pseudonyms people just say shit like "The Dark Fire has done wonderful kernel dev work" makes it sound like we live in like 1253 medieval england
Ah thats pretty cool
Idk if you saw, we also have a full linux port to uacpi as well now 
you also wanted more examples of how modern standby and sleep works. so this will help.
Reactos is a LONG way from doing that
thats insane
All you need now is a macos kext
Yeah lol, only bsds remain
I suspect uACPI will likely grow into a bigger thing pretty fast here
Its not perfect since its completely vibecoded, but full suspend resume works on some hardware we tested, while some other did see some issues but its unclear whether its the vibecoded parts or who knows what else
I’m hearing about uACPI in the IHV world now
And we fixed some edge cases in uacpi that were never uncovered earlier due to hobby osses not using more advanced features
What is that?
Bioses, hardware vendors
Damn lol
ACPIca gets integrated into EFIs to sanity check ACPI implementations before things are sent out
so… give it time I suspect people will do the same with uACPI
That would be pretty damn cool
Idk if you saw some recent vibecoded prs merged with barely any review in acpica causing regressions all over the place
And the maintainer managed to push them into the latest stable release
Yeah its pretty sad as I rely on iasl in my tests
I had to work around it
hobbyiest OSDev with AI is such a weird thing
I don't know why people don't realize you can damage hardware with osdev work
Anytime I use it I get fucking depressed, even if it's just for a bug fix
I genuinely enjoy working on things myself
it's not the end of the world if you understand what's going on
If you don't bother to understand though you're going to quickly lose track of what's going on
Thanks! working on that, and some of the first real code PRs are the goal for the week
and then we can add Win11 to the leaderboard

This is why anything I EVER use it for I heavily review and it's targeted
And never like oh yeah go implement X
I like saying go implement x for tests tbh
"here's the headers, generate me some API tests"
Or for things where it needs to duplicate / stub a bunch of shit
Same, its really good for generating tests and I hate writing those by hand
I still wouldn't feel compfy pushing thoes
I use it to make tests that I then delete after
I don't like having code I haven't reviewed well enough to say it atleast looks okay
Well the point of tests is to also catch regressions so id keep them tbh
but I don't have a good test harness anyways
I dont think anyone actually daily drives it to tell
I need to situate that when I have a schedular and userspace
Since I'm doing a rewrite
But on one box it gave some fps improvement in glgears lol
I feel like I've gotten a solid 45~ ish minutes more with it
That's interesting
It genuinely could be very good
You're going to have to fight linus on that a bit
He's horribly ignorant about ACPI
#showing-off message
Okay but given how it works
It's generally a drop in shim
that is so incredible lol
And optional
And since ACPICA is killing themselves
Like
There is a good shot to enter
yeah, I imagine intel is going to come knocking for infy in the next few years
Especially if we convince something like cachyOS to have it in their kernels
Lmao
Which I think some cachyOS people know some limine people
So there is a shot we can get in
And have a more wide spread use of it
Im down to do acpi for Intel 
I'd use a uACPI cachyos
Same
"hire me to keep uacpi updated to your new specification revisions"
Lol
Oh uh make sure to get me a job too
Il uhhhh
Massage you while you work to keep you efficient

But yeah for cutting edge distros like cachy it could be an optional module replacement
If stabilized and slop code is properly reviewed
and the bar isnt high, considering how awful ACPICA is
From what I know the slop code isn't even that bad
It would not take much to do that work infy
I remember the days when infy was a cherno dweller and wasn't even in here yet
Indeed
Yeah lol
either uacpi is forgetting to do something or acpica is bust
yeah that's weird..
acpica IS bust anyway
But if that FPS is from GPU performance
was the test system an nvidia card? with the new "open source" driver?
Probably
hm
dumb question how does acpi come into play with glxgears at all
NVIDIA GPU driver DOES depend on some stuff in ACPI though
Yeah ofc
even in Windows it has a habit of manually override the hal dispatch table and going underneath ACPI.sys
They usually have a separate SSDT
I've killed many GPUs by playing with this stuff in ros
I'd watch that a bit, if its performing that big of a difference it's probably going to kill itself
Or it's totally fine, and in which case who cares :3
damn
Just by messing with ACPI?
not exactly that alone
but that's been a factor before
at least with really really new GPUs
I struggle to imagine why a GPU driver needs to directly affect ACPI though?
ask nvidia
I remember there was a version of optimus
was it win7?
That when it detected your processor speed reached a certain mode in speedstep
it would just.. fire an interrupt
How strange
to be clear I'm not saying i think it's a HUGE concern :), just I'd really look at it before trying to pitch uACPI to linux distros lol
Well that was never going to be a quick thing either way
Yeah this needs further investigation and is likely a result of misconfiguration of either uacpi or acpica
Could be related to power governor settings on linux
gotta love ACPI, basically the only module HIGHER numbers is scary
Speaking of which, actually, I'm curious: what's the main kernel you use to test uACPI right now?
I know you do userspace testing too
Me?
No Infy
Dont really have one unfortunately, managarm used to be the reference impl
It's an Nvidia card, it would kill it's self anyways
Well still is sort of
It doesn't do anything advanced tho
what would be the more advanced ACPI features
Suspend and resume
right
dont forget mOdeRn stAnBy
True
The ACPI killer
the issue with suspend is that its extremely annoying to get right and then you have to bring the entire harddware back up including gpu
😭
Yep
Hence why im making this seperate repo
it's impossible to get ros to do that right now
You're literally turning off all the devices yeah I imagine it would
Yeah basically only ram is kept alive in s3
all of it
A bunch of firmware MSRs?
Yeah but like I need a list because I don't know how much crap there isn
But the rest is up to you
Ah thank God because that means I can forget about them 😭
As much if not more than what you did on boot
Yeah
Much more than on boot
Like the entire PCI subsystem is dead
You have to reinit all bars etc
And do gpu modesetting
Mmm yep
It's just one of those things... It looks lame but is way harder to do...
Just like how Astral and Zinnia got mogged by Shrek on r/osdev 
ShrekOS is impossible to beat
Yeah lol
I need to get to work redoing my device subsystem and making it work out of a proper acpi tree
at some point
I've been saying this for liek 2 years at this point
:sopb:
Hah... you're in devicesys pain too?
more so right now its just a bunch of foo_init() calls from my initialization system
which then check for the existance of the hardware
which yknow
yeah
mmm yep
Serenityos style
That sounds just like my original ultranaive devicesys impl
serinity is the best os
True
dedicated amd gpu
based
Holy pog
:0
😭 what the fuck
NT subsystems were designed for this :3
also fun fact
this runs on NT4.0
this is funny
but yeah for those who don't know, NT actually has a fork syscall
for this reason
MOTIF ON REACTOS POSIX SUBSYSTEM LMAO i might make more of the gui work but im passing this along to other people now :) i just wanted to do this for fun
open source interix
now replicate the "cross-compiling linux from windows xp" video by ncommander 
i think that's where im headed towards
how so btw
interix didnt use the true subsystem code as much
its a little closer to cygwin
This is a true NT subsystem so it has other... quirks
will the posix subsystem be compatible with not reactos (windows) as well 
yup it works on NT4.0->Vista
holy shit
yeah idk wtf 7 did
i dont have screenie atm
but fun fact
that xeyes demo?
works on win2000+
nt4.0 has weird gdi bs but otherwise yeah
ah interesting
i thought interix was a proper subsystem
No
i think early days they called it a hybrid idk
but real subsystems never tried to do cross communication like this
or the GDI stufff im doing here
well i could be wrong, im a reactos dev not windows after all :)
This is so cool
I always wanted a true NT subsystem for Unix
My dream of GNU/NT is getting closer 
so I guess you can say it’s already GNU/NT
that’s it I’m moving to ReactOS as my daily driver
finally my dream has been realized
killed it in favor of WSL
or rather killed it for the complexity and later replaced it with WSL
could you run wine in the POSIX subsytem and go full circle?
Yes.
btw i did some research and i was entirely wrong!
Internix was just the og psx code licensed out to allowed to be modified it seems
They still have a psxss.exe and psxdll.dll
In fact it’s so close I accidentally (due to me properly using named exports)
Basically just made internix!
To the point the original internix tool chain target works, and I can compile ROS PSX binaries! And vice versa
It seems my x server runs in internix’
Isn’t the work a little interesting?
I mean wine doesnt even need that much
huh thats really cool
Yup
i made a package that runs in msys and ships the reactos posix headers
and newlib libc i ported
so stuff not runnning ros can compile reactos posix apps
and its helped a lot
like with really dumb stuf
Lol

depending on how you compile reactos in about 6~ ish more PRs
you can use win 2k3 PCI -> win 10 1607
Nice, I see you're moving fast
Yup, and even if it doesn’t seem like it this chunk is a huge amount of the complicated work
This screenshot has literally every PNP change I’m gonna need for modern hardware to install / boot
It’s the finished ntoskrnl side changes
was a ~ forgotton 
how does one play with reactix
call it Flux cause idk Flux feels react-y and also flux 
ill repost it here
Win10 style ACPI and WIn10 STyle PCI are communicating with eachother in reactos for the first time!
We're very close to the coolest screenshot ive ever posted in this thread
uACPI 6.0.0 that works on win10+
A PCI that works on win10+ with resizable bar support
and reactos arbiter
all working together for the first time
Wait, does that mean you could install uACPI on windows machines?
yeah
yeah he has been using uacpi on windows for like the last year, this is kinda old news
np lmao
its kind of convoluted to setup too
but for reactos this is the first time everything has slotted in
but yeah my windows install is a franken monster
wait what
isn’t NT closed source
how does it let you replace its ACPI manager
It's a separate DLL afaik?
HAL.DLL? 


ACPI.SYS
the HAL is statically linked against the kernel now
the dll just redirects to the functions in the kernel
can you run the posix subsystem thing without the win32 one
🙏
i wonder if its somehow possible to rip the win32 subsystem entirely and have an x11 server instead, maybe with the video drivers as well
or at least strip down the win32 subsystem to its absolute bare minimum and just have the absolute basics for an x11 server
maybe there could be a drm/kms-like interface on top of the bare minimum win32 so that we could have some kind of freely usable framebuffer????
with the drm/kms-like interface basically being a full-screen win32 window
ah
i was more so referring to win32 as the gui layer
i thought the gui is heavily dependant on win32 existing
i don't really know how nt did the gui tbh
i see
oh and uh
we interrupt your arbiter progress
for tiny quick side quest i did
uh ntfs support

Nice
Holy shit
Out of curiosity how long have you been developing for ReactOS?
like 6 years
a lot of this stuff is just a long time coming
Still pretty cool to see so many important features finally come together
This really makes me want to contribute to ReactOS one day
I’m untainted, never seen any NT code leaked or otherwise, so I think I should be fine
Yeah it's fun! though we need to improve our PR process quite a bit is my biggest complaint
we can be hella slow
I would also like to contribute one day but it seems scary lol
and foreign
I think I looked at the source code of space cadet pinball indirectly
you only cant work on parts that you've seen the code of specifically
if you've seen notepad code that doesnt mean you cant work on mm
the worst fate of all
Just use the posix system to run wine to run space cadet
reactos subsystem for linux
I did try to compile wine in my posix subsystem
Couldn’t get much working yet
damn
the hell are you working on now


