React OS Build?

[MichaelAndrew]

2 notable forks of Palemoon work on React OS and there is a thread on the React OS forum about the best browser for react OS
https://reactos.org/forum/viewtopic.php?f=22&t=19312
So according to the thread MozGlue.DLL is the thing that breaks compatibility and its based on 4 things in Kernel32.dll
but according to another thread those features exist in react os but are hidden from regular applications unless the developer explicitly looks for it
https://reactos.org/forum/viewtopic.php?t=17468

This is a **TEMPORARY dll FOR INTERNAL REACTOS USAGE ONLY** before we establish and implement the correct way of forward-compatibility with dll redirection.

MozGlue.DLL requires these
GetTickCount64
InitialiseSRWLock
AcquireSRWLockExclusive
ReleaseSRWLockExclusive
but they exist in Kernel32_vista.dll

i'm curious as to the feasibility of patching the DLL in the source code to really on Kernel32_vista.dll for these functions for a react os specific build, maybe not now because K-Meleon fork works so good on react os at present and other components might need the same treatment in the near future.

opinions and thoughts please

[athenian200]

Like, we probably wouldn't bother producing a custom build for ReactOS ourselves, especially since they are more than likely going to implement those features soon enough, but that said it probably wouldn't be that difficult to recompile a UXP application so that it looks for those functions elsewhere if you really wanted to.

https://learn.microsoft.com/en-us/windo ... srw--locks

Most of those functions are related to SRW locks, a key feature introduced in Vista, and mostly in Windows-specific code. The way we include them, is by including Windows.h header files. So all you would really need to do is either include a different header file instead of Windows.h in the places where we use those functions, or else use an alternate (ReactOS version) of Windows.h instead of the one Microsoft ships.

The issue is that ReactOS is likely trying to avoid using the Windows SDK, so none of the developers will want to look at this info or compile with Visual Studio against ReactOS headers for fear copyrighted code might sneak in.

EDIT: Though, if I understand the second thread correctly, recompiling apps to target ReactOS isn't the way they do things, and what you actually need to do to find a way to make the DLL exports work by messing with compatibility shims like they were talking about, or recompile ReactOS itself to target a newer version of Windows than the shipped build. The main problem is that ReactOS is targeting an older Windows API than what we support. We target NT6+, ReactOS is NT 5.2, which is too old. ReactOS has enough of NT6+ that it could theoretically run Pale Moon (possibly in a buggy fashion), but they turned it off for some reason.

[Moonchild]

ReactOS targets NT5 class compatibility, I see no reason to introduce specific code for it.
See https://reactos.org/architecture/ at the bottom

The ReactOS kernel currently targets NT 5.2 and supports both x86 and x64 platforms.

NT 5.2 is the version used in Windows XP Pro x64.

Targeting that would equal reintroducing Windows XP specific code (like using CriticalSection instead of SRW locks, and similar slower/deprecated/obsolete API calls). I really don't want to go that route.

[athenian200]

Yeah, I was going to say that SRW locks were a lot better than XP style locking mechanisms, and that I suspected it was a big part of the reason for dropping XP, but I didn't want to speak for you without confirming that. And the irony is that ReactOS has the NT6-style SRW locks for their own internal use, but deliberately restricts access to them by third-party applications, just because they want to target an older Windows API. Honestly, I don't get why the ReactOS project thinks an open source Windows XP is what everyone needs. Most XP applications run on later Windows, and even Windows XP itself supports more applications than ReactOS at this point.

My thinking is that ReactOS needs to stop bogarting the SRW locks for their own internal use and let third-party applications use them. LOL. That is, this is 100% something to be laid at the feet of ReactOS devs, with very little excuse, not even the excuse of not having done the work to implement the features we need. They themselves are clearly not happy with NT5 locking mechanisms, enough that they implemented the SRW locks for their own stuff despite wanting to bury the API because it's "too new."

[jobbautista9]

Yeah, they're really shooting themselves in the foot right there. I'm pretty confident that a lot of Windows 7 holdouts would greatly appreciate it if ReactOS just focused on NT6 entirely instead of bothering with NT5. NT5 is just too unfeasible and old for 2023 and beyond.

[MichaelAndrew]

EDIT: Though, if I understand the second thread correctly, recompiling apps to target ReactOS isn't the way they do things, and what you actually need to do to find a way to make the DLL exports work by messing with compatibility shims like they were talking about, or recompile ReactOS itself to target a newer version of Windows than the shipped build. The main problem is that ReactOS is targeting an older Windows API than what we support. We target NT6+, ReactOS is NT 5.2, which is too old. ReactOS has enough of NT6+ that it could theoretically run Pale Moon (possibly in a buggy fashion), but they turned it off for some reason.

I think the reason is to be able to continue testing modulus with NT5.x systems but apparently there is a way to compile the reactos kernel32.dll to have these functions by amending kernel32.spec but then CompareStringEx, GetLocaleInfoEx and presumably others are the problem(they don't show up in dependency walker for some reason ) they are either turned off or just placeholder code
https://reactos.org/forum/viewtopic.php?f=4&p=148003
but i do get an error with "Pale Moon" "Couldn't load XPCOM" after so swaping out the dll does SOMETHING towards getting it running

you also need an XP friendly Microsoft Visual C++ 2015-2019 Redistributable to attempt to run it on react os but one exists

Like, we probably wouldn't bother producing a custom build for ReactOS ourselves, especially since they are more than likely going to implement those features soon enough, but that said it probably wouldn't be that difficult to recompile a UXP application so that it looks for those functions elsewhere if you really wanted to.

you'd probably need to patch both to get it to run lol

Most of those functions are related to SRW locks, a key feature introduced in Vista, and mostly in Windows-specific code. The way we include them, is by including Windows.h header files. So all you would really need to do is either include a different header file instead of Windows.h in the places where we use those functions, or else use an alternate (ReactOS version) of Windows.h instead of the one Microsoft ships.

good to know

[athenian200]

I think the reason is to be able to continue testing modulus with NT5.x systems but apparently there is a way to compile the reactos kernel32.dll to have these functions by amending kernel32.spec but then CompareStringEx, GetLocaleInfoEx and presumably others are the problem(they don't show up in dependency walker for some reason ) they are either turned off or just placeholder code
https://reactos.org/forum/viewtopic.php?f=4&p=148003
but i do get an error with "Pale Moon" "Couldn't load XPCOM" after so swaping out the dll does SOMETHING towards getting it running

you also need an XP friendly Microsoft Visual C++ 2015-2019 Redistributable to attempt to run it on react os but one exists

Looking more closely at ReactOS, it looks like they do intend to implement an NT6+ compatibility layer, they're not planning to stick to the NT5 API forever. But right now their code is in a weird state where it is actually a mix of the NT5 way of doing things and the NT6 way of doing things, and if they just expose all the APIs, they are in an unexpected state that would do a worse job of running most applications for the most part, that assume you are running either NT5 or NT6, not an implemention that does some things in the NT5 way, and other things in the NT6 way.

So while I was being a bit harsh on them earlier (mostly because I was misunderstanding from that thread that they were going to stay on NT5 support forever), I think that right now their NT6 APIs break and confuse applications because right now because too many parts work more like XP than like Vista, but they are trying to change that or compensate somehow. Hopefully ReactOS can catch up to Pale Moon... Pale Moon isn't exactly going heavy on NT6 APIs here, so if it can't run Pale Moon, I doubt there are many other Vista/7+ applications ReactOS can run well.

[Moonchild]

Looking more closely at ReactOS, it looks like they do intend to implement an NT6+ compatibility layer, they're not planning to stick to the NT5 API forever. But right now their code is in a weird state where it is actually a mix of the NT5 way of doing things and the NT6 way of doing things

This has been the case for the last 10 years. I have little hope of them coming out of it unless they go fully for NT6 which they out of principle seem to have been rejecting despite a lot of devs (including myself) giving them feedback on it. it's like someone made this decision way back when and just refuses to revisit it. And now they're having a bunch of kludges on top of NT5 and basically implementing 2 incompatible systems, doubling their work. Just not very smart.

[Basilisk-Dev]

Off-topic:
In my opinion, at this point if you want open source "Windows" then you're better off theming a Linux distribution to look like Windows and then running Windows applications in Wine.

[leothetechguy]

I am a little more hopeful about ReactOS, seeing the release schedule slowing down as a sign of bigger changes in the works, and the new newsletter proudly mentions preparing for NT6+ application compatibility. I can understand the skepticism towards the project due to slow development over the years. But they seem to be implementing so many important things now. (64 bit, UEFI boot, more work the Kernel itself), that I don't see it as an operating system stuck in the past anymore.

[MichaelAndrew]

My thinking is that ReactOS needs to stop bogarting the SRW locks for their own internal use and let third-party applications use them. LOL. That is, this is 100% something to be laid at the feet of ReactOS devs, with very little excuse, not even the excuse of not having done the work to implement the features we need. They themselves are clearly not happy with NT5 locking mechanisms, enough that they implemented the SRW locks for their own stuff despite wanting to bury the API because it's "too new."

so you can compile react os to expose those functions
ReactOS build enviroment: configure.cmd -DDLL_EXPORT_VERSION=0x600

I am a little more hopeful about ReactOS, seeing the release schedule slowing down as a sign of bigger changes in the works, and the new newsletter proudly mentions preparing for NT6+ application compatibility. I can understand the skepticism towards the project due to slow development over the years. But they seem to be implementing so many important things now. (64 bit, UEFI boot, more work the Kernel itself), that I don't see it as an operating system stuck in the past anymore.

Palemoon and SeaMonkey were tried with some wine dlls which have stuff reactos doesn't yet
https://reactos.org/forum/viewtopic.php ... 0&p=148017

Pale Moon
Couldn't load XPCOM
Seamonkey
*freezes reactos*

[ron_1]

Off-topic:

Off-topic:
In my opinion, at this point if you want open source "Windows" then you're better off theming a Linux distribution to look like Windows and then running Windows applications in Wine.

Wine is too "hit and miss" to bother with (IMO).

[Night Wing]

Off-topic:

Off-topic:

Off-topic:
In my opinion, at this point if you want open source "Windows" then you're better off theming a Linux distribution to look like Windows and then running Windows applications in Wine.

Wine is too "hit and miss" to bother with (IMO).

A linux version which looks like Windows 11 is already here. It is named "Wubuntu".

There was a person who came into the shop who "hates the Windows operating system, but wanted a linux distro that looked like Windows 11". I told him I had never seen a linux distro which looked like Windows 11. Why this person wanted this linux "distro" is beyond me.

The customer had the link to it and it is below. I had to put Wubuntu on his desktop computer (the Plasma version) and I took an immediate dislike to it. Keep in mind I dislike the Windows operating system so I am biased against Windows. And I already use and run two linux distros which are Linux Mint and MX Linux.

https://www.wubuntu.org/

And the YouTube video for it is below.

https://www.youtube.com/watch?v=59eWvbFQel0

And if one likes the look of Windows 10 (Cinammon look), there is a video of it too.

https://www.youtube.com/watch?v=LPuBmKpVA9k

[MichaelAndrew]

Seamonkey
Application failed to initialize properly (0xc0000142)
Pale Moon
Application failed to initialize properly (0xc0000005)
anybody know workarounds or at least whats happening there?

the boot-disk needs to be made in react OS build environment to compile the latest build with this command
configure.cmd -DDLL_EXPORT_VERSION=0x600
that should take care of kernel32.dll

you need to alter the settings compiling these files too to take care of the c ++ run time thingy
api-ms-win-core-localization-l1-2-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-utility-l1-1-0.dll
if you cant be bothered making each file under the very specific settings required to unlock the functions here they are
https://files.catbox.moe/f1ndlj.zip

this needs to be done on the bleeding edge nightly build ReactOs 0.4.15 0x600 edition

[athenian200]

Pale Moon
Application failed to initialize properly (0xc0000005)
anybody know workarounds or at least whats happening there?

That sounds like a memory access violation of some kind, which usually happens on actual Windows if the system is damaged or certain resources aren't where the application expects. For ReactOS, I'm thinking it suggests that something isn't implemented properly and it's causing Pale Moon to freak out.

Does ReactOS currently run any applications compiled with VS2022 that require the runtime? It's possible that it just doesn't support anything produced with that compiler that actually includes Windows headers. Might want to test with a simpler program first. It's possible that ReactOS would not even run the VS2022 equivalent of a "Hello World" program at this point, so might want to do a sanity check with something like that first.

[moonbat]

https://www.wubuntu.org/

Wow, all the lovely aesthetics of Windows 11 and the same UX down to charging for activation that gets you a bunch of PowerToys!

[MichaelAndrew]

That sounds like a memory access violation of some kind, which usually happens on actual Windows if the system is damaged or certain resources aren't where the application expects. For ReactOS, I'm thinking it suggests that something isn't implemented properly and it's causing Pale Moon to freak out.

Does ReactOS currently run any applications compiled with VS2022 that require the runtime? It's possible that it just doesn't support anything produced with that compiler that actually includes Windows headers. Might want to test with a simpler program first. It's possible that ReactOS would not even run the VS2022 equivalent of a "Hello World" program at this point, so might want to do a sanity check with something like that first.

was able to get it to post that error on Microsoft Visual C++ 2015-2019 Redistributable version 14.28.29213
installing 14.36.32532.0 causes the error TryAcquireSRWLockExclusive could not be loaded in dynamic link library KERNEL32.DLL

i checked the spec file and its not on there so its not a matter of me compiling it wrong
https://raw.githubusercontent.com/react ... nel32.spec

the code for the other SRW locks
AcquireSRWLockExclusive(ptr) NTDLL.RtlAcquireSRWLockExclusive so maybe they put it in NTDLL.DLL or NTDLL_VISTA.dll im not sure if that code has been ported from wine yet because that's hidden deeper than the other stuff if it is.

[athenian200]

installing 14.36.32532.0 causes the error TryAcquireSRWLockExclusive could not be loaded in dynamic link library KERNEL32.DLL

i checked the spec file and its not on there so its not a matter of me compiling it wrong
https://raw.githubusercontent.com/react ... nel32.spec

the code for the other SRW locks
AcquireSRWLockExclusive(ptr) NTDLL.RtlAcquireSRWLockExclusive so maybe they put it in NTDLL.DLL or NTDLL_VISTA.dll im not sure if that code has been ported from wine yet because that's hidden deeper than the other stuff if it is.

https://learn.microsoft.com/en-us/windo ... kexclusive

Well, it's a pretty simple function to implement, all it does is pretty much test whether the program successfully acquired a the Windows equivalent of a standard read/write lock. I'm surprised ReactOS is getting hung up on this particular kind of API, almost every OS has an equivalent of it. Like on Linux or anything that uses the POSIX threads API, for instance...

pthread_rwlock_trywrlock() is pretty much equivalent to TryAcquireSRWLockExclusive, while the regular AcquireSRWLockExclusive is the same as pthread_rwlock_wrlock(). The difference in both cases, is that in one case it simply blocks until available, and in the other it returns immediately if it failed to acquire the the lock. But this isn't obscure Windows functionality that's hard to implement, this is basic stuff most operating systems have.

[MichaelAndrew]

https://learn.microsoft.com/en-us/windo ... kexclusive

Minimum supported client Windows 7!? methinks code was ported from wine when it matched Vista

Well, it's a pretty simple function to implement, all it does is pretty much test whether the program successfully acquired a the Windows equivalent of a standard read/write lock. I'm surprised ReactOS is getting hung up on this particular kind of API, almost every OS has an equivalent of it. Like on Linux or anything that uses the POSIX threads API, for instance...

pthread_rwlock_trywrlock() is pretty much equivalent to TryAcquireSRWLockExclusive, while the regular AcquireSRWLockExclusive is the same as pthread_rwlock_wrlock(). The difference in both cases, is that in one case it simply blocks until available, and in the other it returns immediately if it failed to acquire the the lock. But this isn't obscure Windows functionality that's hard to implement, this is basic stuff most operating systems have.

React OS seems to be focusing on hardware which is needed because it keeps corrupting disks but the failure to catch up to windows 7 is definitely a handicap that is limiting its potential.

maybe its just that they don't have enough manpower to review and test and code to the level that's needed

[Moonchild]

it keeps corrupting disks

What's the most common reason for corruption? concurrent access. what prevents concurrent access corruption? mutexes. Hey guess what, these locks are mutexes
I'm guessing something is definitely wrong there. maybe the very existence of "hidden" API calls around locking and having 2 locking mechanisms side-by-side is what causes it.

Just saying, and all...