[EP_X0FF]

Making ReactOS Great Again*, Part 1

Imagine running your favorite Windows applications and drivers in an open-source environment you can trust. That's ReactOS.

There is no Windows code in ReactOS. There never was. There was never such an accusation in the first place.

(c) ReactOS frontpage and reactos.org/wiki/Audit.



Prologue If you don't want to read all this bullshit - skip and go to ROCALL chapter.

First time I encountered ReactOS in 2004 year when I was looking for declaration and definitions to the Windows Native API missing in Nebbett book. For that time it was probably one of the best sources for this kind of queries. In 2006 on a first hype train about this "Windows replacement" OS I tried it. Without any success. It wasn't ready for anything even for virtual machine installation. Approximately at the same time access to actual Windows code was acquired and ReactOS have lost any value for me. However I still encountered it pieces of source on various forums etc which actually was total frustration and failure because ReactOS developers in attempt to hide their copy-paste parts turned code into ridicuolus mess of trash. Microsoft code wasn't that extremelly good and they managed to make it even worse. Ok, but there is no Windows code in ReactOS. Remember this. Not a single byte. Sure.

Next encounter was almost ten years after in 2015 year. ReactOS was still alive and still in alpha where "it can but not today". This time it was evaluation of projects on import substitution infrastructure software, https://digital.gov.ru/ru/documents/4662/.

“Creating an open source operating system based on ReactOS for PCs, laptops and other mobile devices”, “Creating an open source operating system based on ReactOS for servers”.

So ReactOS was considered as candidate for client OS for replacing MS Windows products. More info here https://www.reactos.org/project-news/re ... om-effort/

Since this was obviously low quality product at that time (and currently too - nothing changed) if they win it mean waste of Russian government budget funds. Or probably this was a main goal, because entire idea and competitors were merely a joke ;) Fortunately they didn't manage to go through.

Since it was considered as "alternative" on government level, that probably mean this product is ready for something, then I tried it again. Well, it was complete failure. Impossible to work and completely out-dated, uni-processor x86-32 configuration, bugged as hell failed Windows clone running on FAT32 (with broken/incomplete fs driver), clone which barely can support few devices in popular virtual machines. In 2015 year.

It is end of 2018 now and ReactOS is barely "stable" to install in virtual machine, start and do nothing. When you start doing something - it will crash and highly likely reinstall will be the only option after.

What is ReactOS today? Windows replacement - no and never will be. Students learning project? Maybe, but better not to learn anything from it as ReactOS is a perfect example of deep failure in design, positioning and implementation. If you want to learn something - use original Windows source as case of study.

So why this project still need some attention and support? Just a few small reasons why it still need to exist.

1) Wine as they share part of code base, including patches;
2) Good laugh when sometimes you are trying to use this OS;
3) Variability and opportunity to experiment with Windows like code for beginners and noobs;
4) It is free and doesn't demand anything in exchange of it existence.

There was also number 5 - opportunity to get your code signed with ReactOS code signing certificate. Some open-source projects used this opportunity in the past including some project which was initialy planned as malware. But since Windows 10 release this number 5 is gone at forever (https://reactos.org/wiki/Driver_Signing).

Looking on how it works and how it looks (https://github.com/reactos/reactos/) these guys obviously need some help. I mean some real help, not aggressive bullshit advertising attempts by some self-proclaimed evangelists. Instead of help and turning people to the project guys like this one is making a phun from project and turning people against because of total "evangelist" ignorance. However we are not going to do all the job for them. Our goal is give them a direction to move on and finally make their project a little bit more stable.

ROCALL

While looking ReactOS versions from 2006 till now I always noticed out-of-sudden Blue Screen Of Death from anywhere anytime. When I was briefly looking on fresh 0.4.10 "release" I got a BSOD from program I tried to launch on ReactOS. Nothing new, but this time I knew what caused this. Quick looking on ReactOS source confirmed the worse possible scenario.

Software pretending to be "Windows" compatible lacks of basic sanity/security checks implemented in it kernel mode services implementation - functions inside ntoskrnl and win32k syscall tables.

In my case it was NtDeleteValueKey routine, which was missing validation of input parameter. Basically it was derefencing user mode pointer without any error checking. Open-source environment I can trust, remember? Well I can, Windows programs cannot.

In Windows NT world this popular service available at least from Windows NT 3.51 (1995) and ReactOS (1998) for 20 years either doesn't bothered to do it correct implementation or it was messed up while "refactoring" / "audit".
To figure out the problem root I found and downloaded ReactOS code from 2007 year. Apparently it was broken even there (aside with multiple other things around). Well that is not what can surprise here.

Next I got 0.4.12 ReactOS build and to my surprise this issue was addressed. That mean ReactOS developers do not consider their system bugs as "features" as Microsoft often does with it crapware.

But what this bug mean. A very simple thing. They do not test or do not know how to test. Looking on various ReactOS tracker resolved/closed opened issues it seems that stability improvements can be fully described in a just few words:
"hey lets start this shit on reactos, omg it crash/BSOD, ummm lets take a look why, oh we miss some validation here, now fixed! wait, it is still not working?!".

For an average open source project this maybe somewhat ok, for operation system pretending on something - no.

I decided to provide some little help in this area. A simple syscall fuzzer, what every OS must have (do not worry MS also don't know how to use similar tests or some devs from MS suffers from amnesia each Windows 10 "FailWeRollbackUpdate"). Since ReactOS is a very simplified this program was a really easy to write. This is my first program specially designed to run on ReactOS. I swear I didn't copy-pasted anything from ReactOS just like it never copy-pasted anything from Windows.

This program is open-source and link to it you can find in the end of this post. It is bind to ReactOS and do nothing on Windows.

Important note: this will be very superficial fuzzing but it is enough to find a lot of bugs in case if software is weak.

As base for our experiments with ReactOS we need virtual machine, in my case it is VirtualBox running on Linux host since I do not use Windows except in VM.

Virtual machine settings:

CPU 1
RAM 512
Chipset PIIX3
Audio Controller Disabled
COM1 Enabled, Port Mode RawFile (path to existing log file on your physical machine, will be overwritten each ReactOS test relaunch)
Ethernet Adapter PCnet-PCI II (Am79C970A), the only one I got to work with ReactOS, yeah 2018 year that's how we support hardware, even virtual
Everything else default.

Additionally you can log directly to Linux terminal, set Port Mode to TCP and use "screen" utility. Just like on my screenshot above.

We need to do syscall fuzzing and save every syscall name, it parameters and make sure things are saved. What usually happened with ReactOS after BSOD? Unbootable device and reinstall in most cases because of their FAT32. Even more, both 0.4.10 and 0.4.12 install and start with FAT32 volume that already has dirty bit set and various structure errors, facepalm. For note, ReactOS now support BTRFS as main filesystem so you can try it, it must be much more stable because it wasn't made by ReactOS devs.

This is why we use COM1 for logging as we can't rely on bugged fastfat ReactOS driver which corrupts volume as it wants.

Since ROCALL won't be really different to either our NTCALL64 or original Gloomy NTCALL from 1999 (it will even somewhat simpler), so we can skip it implementation details and just in short - it brute-force system services by calling them multiple times with parameters taken randomly from predefined "bad" arguments. Arguments here are not just random junk, they set up that way so we can catch not only bad pointers but also overflows. ROCALL also support system service filtering by blacklist like NTCALL64/NTCALL. Timeout for each service will be set to 30 sec.

Take a note that some system services may crash fuzzer or prevent it from displaying results, so we need to ban them.

Our default blacklist looks like this:

Code: Select all

[ntos]
NtClose
NtShutdownSystem
NtSuspendProcess
NtSuspendThread
NtTerminateProcess
NtTerminateThread

[win32k]
NtUserSwitchDesktop
NtUserLockWorkStation

As target ReactOS we take 0.4.12 Nightly Build because

You can expect ReactOS to work better but there may also be regressions.

I always expect ReactOS to work better, so this definitely is our choice.

Spoiler: 0.4.10 from current "Release" also will be tested for cross-reference.

Copy ROCALL.exe somewhere on ReactOS volume, for example in C:\Tests, place blacklist.ini in the same directory.
ROCALL supports the following parameters:

Code: Select all

ROCALL [-win32k] [-logn | logv ] [-pc value] [-sc value]
* -logn     - enable logging via COM1 port, service name will logged, default disabled;
* -logv     - enable logging via COM1 port, service name and call parameters will be logged( slow), default disabled;
* -win32k   - launch win32k service table fuzzing, default ntoskrnl service table fuzzing;
* -pc value - number of passes for each service (default value 1024);
* -sc value - start fuzzing from service entry number (index from 0), default 0.

1. TEST, System Service Table

Save VM state to snapshot.

Open command line in the ROCALL directory and execute it.

Try 1.

I use:
ROCALL -logn

Almost instantly the our first BSOD appears.

BSOD on: NtAllocateUuids
Source: https://github.com/reactos/reactos/blob ... uid.c#L314

Service marked as "unimplemented" however it does some things and do not return STATUS_NOT_IMPLEMENTED.

It completely miss any parameters validation and just a BSOD-generator.

Rolling back VM snapshot, updating blacklist with this "unimplemented" implemented BSOD-generator.

Try 2.

BSOD on NtDisplayString
Source: https://github.com/reactos/reactos/blob ... nbv.c#L772

Indeed, what could go possible wrong here. Note service not marked as "unimplemented". Implemented and working as expected? BSODing as expected?
Wtf this mean in ReactOS world is unknown. As for me it is not implemented even for alpha state.

Rolling back and updating blacklist.

Try 3.

BSOD on NtRaiseException
Source: https://github.com/reactos/reactos/blob ... ept.c#L172

Calling this function with invalid parameters result in blue screen because of intentionally set debug breakpoint.
How about log exception, check build type and only then break to the debugger? Nah why bother, suffer bitch.



Rollback etc.

Try 4.

BSOD on NtUnloadDriver
Source:https://github.com/reactos/reactos/blob ... er.c#L2107

Finally something marked as "implemented"! Oh well, better not.

It calls IopUnloadDriver with unchecked pointer and then IopUnloadDriver does wcsrchr with it. Nice. I feel strong Windows competitor here.

And I noticed cute todo here

* To do
* Guard the whole function by SEH.
*/

Rollback.

Try 5.

BSOD on NtSetUuidSeed
Source: https://github.com/reactos/reactos/blob ... uid.c#L378

Implemented! Whatever this mean.

0.4.10 additions

The following routines will blue screen on 0.4.10 if called with invalid parameters due to insufficient parameters validations or validations complete absence.

NtLoadKey
NtLoadKey2
NtLoadKeyEx
NtDeleteValueKey
NtQueryValueKey

This is somewhat fixed in 0.4.12

Rollback and go next.

When this fuzzing finished with no more BSOD's but then I got suddenly this:



Entire video mode collapsed and I got resolution like 100x100 4 bit. Must be an easter egg from developers.

2. TEST, Win32k User/Gdi Service Table

Where the most fun begin. In Windows world the win32k component is a exploit factory and effective built-in OS BSOD-generator.

As expected here is the same level of quality.

Save VM state to snapshot.

Open command line in the ROCALL directory and execute it.

I use:
ROCALL -win32k -logn

Try 1.

BSOD on NtGdiClearBrushAttributes
Source: https://github.com/reactos/reactos/blob ... h.cpp#L553

Unimplemented syscall stub breaking into debugger. In 0.4.10 "release" too. Best design practices everywhere. Keep doing the same way.

As you can see from source link NtGdiSetBrushAttributes does the same.

How about set last error "not implemented" and don't suddenly break into debugger if there is no one.

Rollback, update blacklist section "[win32k]" with failing service name.

Try 2.

Stop on NtGdiCreateDIBBrush
Source: https://github.com/reactos/reactos/blob ... h.cpp#L412

Insufficient parameters validation.

Rollback, update blacklist.

Try 3.

BSOD on NtGdiCreateDIBitmapInternal
Source: https://github.com/reactos/reactos/blob ... bj.c#L1457

BSOD located in GreCreateDIBitmapInternal.

What is wrong here. Need more detailed explanation because this service bug is a common for ReactOS, maybe because all the bugged code written by one author.

This routine has the following declarations (key fields in bold)

NtGdiCreateDIBitmapInternal(
IN HDC hDc,
IN INT cx,
IN INT cy,
IN DWORD fInit,
IN OPTIONAL LPBYTE pjInit,
IN OPTIONAL LPBITMAPINFO pbmi,
IN DWORD iUsage,
IN UINT cjMaxInitInfo,
IN UINT cjMaxBits,
IN FLONG fl,
IN HANDLE hcmXform)

Now lets look how they are validated.

_SEH2_TRY
{
if(pbmi) ProbeForRead(pbmi, cjMaxInitInfo, 1);

Re-running ROCALL with -logv parameter (ROCALL -win32k -logv) generated BSOD parameters.

cjMaxInitInfo = 0x0000000
pbmi = 0x00000001

so it passes "if (pbmi)" and enters ProbeForRead(0x00000001, 0x00000000, 1);

Now look on ReactOS ProbeForRead
https://github.com/reactos/reactos/blob ... rin.c#L102

Code: Select all

ProbeForRead(IN CONST VOID *Address,
             IN SIZE_T Length,
             IN ULONG Alignment)
{
    ULONG_PTR Last, Current = (ULONG_PTR)Address;
    PAGED_CODE();

    /* Only probe if we have a valid length */
    if (Length != 0) {
    .... 
    }
}

So this check is bypassed and no validation take place.

Next invalid pointer dereferenced. Blue Screen.

Rollback, update blacklist.

Try 4.

BSOD on NtGdiDdCreateSurface
This routine passes all it parameters to Dxg.sys->intDdCreateSurfaceOrBuffer.
Source: https://github.com/reactos/reactos/blob ... /d3d.c#L43

Nor Win32k nor Dxg.sys are not validating input parameters. The whole Dxg.sys completely trust everything from Win32k. Best design practicies in work. Learn from this. Copy this.

Rollback etc

Try 5.

BSOD on NtGdiDdCreateD3DBuffer
Same as above.
Call Chain NtGdiDdCreateD3DBuffer -> DxDdCreateD3DBuffer -> intDdCreateSurfaceOrBuffer

Try 6 and 7.

BSOD on NtGdiDdLock
BSOD on NtGdiDdUnlock

See DxDdLock
See DxDdUnLock

Same as above, win32k/dxg not validating anything.

Try 8.

BSOD on NtGdiExtCreateRegion
Source: https://github.com/reactos/reactos/blob ... on.c#L3802

Insufficient parameters validation, case similar to NtGdiCreateDIBitmapInternal BSOD.

Try 9, 10, 11

Stop on NtGdiGetCharABCWidthsW
Stop on NtGdiGetCharWidthW
Stop on NtGdiGetFontResourceInfoInternalW

Source: https://github.com/reactos/reactos/blob ... pe.c#L6443
Source: https://github.com/reactos/reactos/blob ... pe.c#L6647
Source: https://github.com/reactos/reactos/blob ... ont.c#L952

Insufficient parameters validation. System hang.

Try 12.

BSOD on NtGdiPolyPolyDraw
Source: https://github.com/reactos/reactos/blob ... hap.c#L376

Insufficient parameters validation, overflow. Similar to NtGdiCreateDIBitmapInternal

Try 13.

Stop on NtGdiSetDIBitsToDeviceInternal
Source: https://github.com/reactos/reactos/blob ... obj.c#L455

Insufficient parameters validation. System hang.

Try 14.

BSOD on NtUserBuildHwndList
Source: https://github.com/reactos/reactos/blob ... ow.c#L1338

Insufficient parameters validation.

Try 15.

BSOD on NtUserConvertMemHandle
Source: https://github.com/reactos/reactos/blob ... rd.c#L1159

Insufficient parameters validation.

Try 16.

BSOD on NtUserCreateAcceleratorTable
Source: https://github.com/reactos/reactos/blob ... tor.c#L229

Insufficient parameters validation, incorrect comparisons.

Code: Select all

NtUserCreateAcceleratorTable(
    LPACCEL Entries,
    ULONG EntriesCount)

....


    if (!Entries || EntriesCount <= 0)
    {
        SetLastNtError(STATUS_INVALID_PARAMETER);
        RETURN( (HACCEL) NULL );
   }

Cool story, bro!

Try 17 & 18.

Stop on NtUserCreateWindowEx
Stop on NtUserEnumDisplayMonitors
Source: https://github.com/reactos/reactos/blob ... ow.c#L2466
Source: https://github.com/reactos/reactos/blob ... tor.c#L543

Insufficient parameters validation. System hang.

Try 19.

BSOD on NtUserGetAsyncKeyState
Source: https://github.com/reactos/reactos/blob ... ard.c#L632

Insufficient parameters validation, integer overflow.

Try 20.

BSOD on NtUserGetCursorInfo
Source: https://github.com/reactos/reactos/blob ... con.c#L645

Incomplete parameter validation. Input parameter not checked before read access but checked before write access, rofl.

Try 21.

BSOD on NtUserGetDCEx
Source: https://github.com/reactos/reactos/blob ... ndc.c#L973

Insufficient parameters validation.

Try 22.

BSOD on NtUserGetKeyboardLayoutList
Source: https://github.com/reactos/reactos/blob ... out.c#L496

Insufficient parameters validation, overflow.

Try 23.

BSOD on NtUserSBGetParms
Source: https://github.com/reactos/reactos/blob ... ar.c#L1218

Input parameters not validated.

Try 24.

Stop on NtGdiEngUnlockSurface
Source: https://github.com/reactos/reactos/blob ... ace.c#L615

Best design practices. RtlAssert wait for debug input.

There are few more but I tired copy-pasting from logs.

Note another fun bug from ReactOS ntoskrnl. When fuzzing win32k with logging call parameters I experienced multiple BSOD's from ntoskrnl KeBugCheck(CRITICAL_PROCESS_DIED). The last one thing I want to do is debug ReactOS, so it is up to developers figure out what is wrong here. For ROCALL this behavior resulted in adding "-sc" switch to start from given service index and not from beginning.

3. TEST complete

When our fuzzer with help of blacklist finished working, ReactOS was alive, but barely unusable, just like if it was at death's door. Impossible to do anything, the reset (and reinstall for sure on fat32) was the only option. Reset confirmed quality of ReactOS FS driver with unbootable state and this fun message




Even if ReactOS syscalls passed this superficial test - it doesn't mean they are not bugged as hell. More deep and smart fuzzing will for sure find more bugs ;)

For example
BSOD on NtQuerySecurityObject
Source: https://github.com/reactos/reactos/blob ... ure.c#L803

This service is a BSOD generator in case of simple race condition.

RC attack of this type is something I used 12 years ago against some Chinese antirootkits and some crapware mainstream antiviruses. For more recent info's you may refer to j00ru series of blogposts where he multiple times crashed Windows using the same principle. Idea is simple, two threads access same memory simultaneously, first thread does read/write while second thread running in loop making changes to memory region protection.

Code: Select all

 g_sdBuffer = VirtualAlloc(NULL, 0x1000, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);
            if (g_sdBuffer) {

                hThread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)ThreadFunc, NULL, 0, &threadId);
                if (hThread) {

                    SetThreadPriority(hThread, THREAD_PRIORITY_HIGHEST);

                    do {
                        NtQuerySecurityObject(hFile,
                            OWNER_SECURITY_INFORMATION,
                            (PSECURITY_DESCRIPTOR)g_sdBuffer,
                            0x1000,
                            &returnLength);
                    } while (1);
                    CloseHandle(hThread);
                }
            }

Run a few seconds and voila.



4. Win32k, CSRSS

There is also small amount of Win32k services that are unaccessible for programs except CSRSS.

You can find them by this code (or similar)

Code: Select all

if (PsGetCurrentProcess() != gpepCSRSS)
return STATUS_ACCESS_DENIED;

Obviously ROCALL can't fuzz such services without ROCALL modification and injecting it to the csrss. However this is not implemented in current version and judging on services available with such csrss bind - it is not worth it.

Conclusions.

Overall, my impressions after looking on how ReactOS works and how it implemented can be described by this picture. Quite obvious.




Not each syscall is properly covered by tests. Besides obvious BSOD's there is a hell and mess in ReactOS source code. Dropped, incomplete code, useless junk, copy-pasting Microsoft style of early 90x-00x (wow wtf who told you it is good?). No usage of static analyzers or their results ignoring. Some of the above bugs can be detected by simple static code analyzer at compilation.

What I can suggest to ReactOS developers. Concentrate exceptionally on fixing bugs and refactoring code, especially this one dropped by authors 10-12 years ago. Reconsider your great idea "lets break to the debugger" from syscalls that's are not implemented. It is very cool to watch your system completely not responsive at any time. I may somehow understand why you did this, but such trash should not present in "release". Even if you "alpha". You alpha for 20 years and nothing changes. This is not a excuse anymore. ReactOS is out-dated code base trash that screams about attention to it bugs.

Q: Does ReactOS can replace Windows (in perspective) on desktops?
A: No it can't. There is giant gap between this project and actual Windows 10 or Windows 7. When ReactOS will come closer to Windows 7 (2030-2040? I'm joking - never) MS product will be completely outdated and unused by major audience.

Q: Why this isn't reported directly to ReactOS devs?
A: Because I don't value this project as worth for any kind of official reports. Twenty years of unworkable alpha. Pff. This is my report. Part 1. You either fix your ridiculous bugs or GTFO. This is how I work.

This is first part end. I do believe that while some people tried to use this project for their own selfish goals (like these clowns from prologue part) most part of ReactOS dev involved actually loved what they do and put their best effort in this project. As for now ReactOS need some love from experienced and professional developers so if you can and want - why not to waste some of your time. There is big surface for various tests and fixes to make this OS at least somewhat stable (I'm not even talking here about "usable").

The only possible good scenario for ReactOS future is to become a VM bind-only OS.

Collection of ReactOS Blue Screens

Some of the above BSOD's, I was doing screenshots until got finally bored.























ROCALL project
https://github.com/hfiref0x/ROCALL

*well it actually never was and highly likely never will be

[EP_X0FF]

Bonus to Part 1.

ReactOS PR (or one of the reasons why it so terrible)

There is an official twitter -> http://twitter.com/reactos/

Sometimes it post bullshit and bizarre pictures. Sometimes just real news related to project and project announcements.

I will teach you how to became a ReactOS evangelist that worth guy(s) like that one who is behind this twitter account or that clown from habr (see first post).

1) First and most important thing - you should mention ReactOS everywhere in open-source software news. Saw announcement about some open source OS study project? Jump in with ReactOS posts! This is your target.
2) Post any screenshots from ReactOS where it is still working (no matter if it crash few seconds later - it works!).
3) An exploit or critical bug found in Windows/Linux/AnyOtherOS? Jump in discussion and tell that ReactOS is protected from this by design (of course if you can't run something it can't work).
4) When someone ask you why screenshots of ReactOS UI are on different language than poster native - say it is official screenshots.
5) When someone ask you about feature this OS missing - say it is in near future plan, just wait a little bit.
6) When someone ask you why current feature that is anounced like implemented not working as expected - say "it can but not today".
7) Encourage your opponent to install ReactOS on his real hardware. Doesn't working? Hah you just doing it wrong way. Show some screenshot (from VM) as proof of OS working on real hardware.
8) Always use "we don't have much resources/developers/bitcoins as Microsoft" as general excuse for everything.
9) If it is not enough use the following excuse "It was 20xx when I/we/them(and my cat/dog/goldfish) added/did/reworked %something% in ReactOS. It is not my %fault% that nobody didn't contributed later".
10) If this is not working switch to classic "why do you %care%, why don't you %care%" posts.
11) If none of the above worked - post screenshot from Doom 2 running on ReactOS. People love Doom 2. Especially on their 4/8K monitors. No joke, some love.
12) In case of questions about real hardware usage, use the following trick:

- Install ReactOS on virtual machine. If failed, try again by using as much of legacy virtual hardware and lower VM general settings as possible, try different combos;
- Run something in ReactOS, simple "winver" is enough;
- Go to VM settings and switch it to the full screen (make sure to setup correct resolution);
- Done, take a beer and do a photo posing next to your desktop/notebook "running" ReactOS, do as much smart/serious (hacker) face as you can.

For example, have a look on this tweet -> https://twitter.com/reactos/status/1031 ... 76/photo/1
While it can be real photos did with help of antique hardware and tons of specific hardcoding (or just photoshop used) the truth behind this maybe quite different.

13) If you confused by opponent in discussion - tell him that this guy is working on Microsoft and against open-source in general;
14) In case if someone found bug while trying to install/use ReactOS - send them to bug tracker - don't forget that you actually don't give a single fuck about that;
15) use multi-accounts to defend your posts and keep discussion alive;
16) when someone ask you from where you type this -> tell it is from your Iphone/other mobile device but at home I have ReactOS installed at my desktop.
17) in case if nothing worked tell them they are trolls and log-off from your primary account but keep posting from your other accounts - if you can't beat them - then just trash discussion.

Done, you are now certified ReactOS evangelist. Does it help this project? Not that much.

[EP_X0FF]

For a note:

ReactOS devs have made several fixes to the above bugs. Just a few but it is better than nothing and perhaps other will be addressed too improving stability of this OS.

Regarding to that idiot from Germany with IP 79.247.162.58 who tried to spam here - this thread is premoderated. Any kind of such posts will be removed and poster will be permanently banned.

I don't need your excuses, your hysterics (like that one from windoze celebrity or that german idiot) - fix your shit.

[Brock]

Nice write-up, EP_X0FF.

#16 (NtUserCreateAcceleratorTable) was my favorite faux pas

2pzz26.jpg (33.91 KiB) Viewed 646 times

[EP_X0FF]

@Brock,
Yeah this thing is full of ridiculuos bugs and fun, as well as it community throwing money to the monitor for nothing.


We are happy to present another gift to ReactOS.

https://github.com/hfiref0x/BSODScreen

This time it is BSOD Screensaver, which is very relevant for this Operation System.

This screensaver is a simple OpenGL scene, fully describing long life of that OS up to date.

It has "easter egg". If configurred it will trigger real Blue Screen of Dead in ReactOS (0.4.10 or current 0.4.12 doesn't matter this primitive bug is likely 20 years old).
By default this behaviour is disabled. Aside from ReactOS this screensaver can work in Windows too. BSOD part won't work however due to obvious reasons.
To enable it (in ReactOS), right click on screensaver and select "Configure".

WARNING, image traffic.



More fun things and tons of shitpostings will follow in 2019. So Happy New Year and ReactOS too. Don't BSOD too much (unless triggered).

Also looking forward for this https://github.com/reactos/reactos/pull/1171 - it is exactly what this "OS" need, as this is seems to be it main and only purpose of existence now.

[emuandco]

Well, looks like we got some attention in here huh? @EP_X0FF it's quite sad that you are tainted by MS code access, otherwise you would be very welcome to help fixing all/many of our bugs we have. We always are looking for ppl skilled in low level Windows parts as these can't be found in every corner all over the world... As you said, it's open source and thus everyone can help fixing stuff as long as he does not use any leaked code or abuses MS code access for his fixes. If you have any reason to claim that ROS already does that, I would be very happy about some facts between all the claiming and ranting against a project in alpha state done by devs in their spare time. I will not excuse any bugs we have though as there are plenty of them and we all know. There you can see our lack of human resources. But which human resources should speed up the development if there are no paid devs and no way to pay them easily and in a egal and safe way? Anyways, we accept patches to speed up our development ;) Some long time missing validation checks should be fine even by a tainted person. Still would have to be confirmed by our main devs, but as you say "trivial" fixes should be very fine.

Greetings

Daniel Reimer
Deputy Chairman
ReactOS Deutschland e.V.

[EP_X0FF]

Hello,

At first, the previous fanboy post have been disapproved. Project that is in alpha state 20 years is a dead project. So don't waste your time posting this again. I usually don't repeat things twice or more.

At second, the fairy tales about "clean rooms", "super-developers", "great contributors", "writting NT clone from zero" and other typical reactos "content" please leave for your partially brain dead fanboys. This doesn't work with me. I know too much about your project and several personalities from it. Well I would say, even more than I needed or I wanted to know.

Under "you" I mean whole this comedy section project so don't take this as personal.

There was a paid audit of all your code made in 2015. Results were really terrifying. You might say that 3 years have passed and things have changed. Well, looks like not. You have a big room for fixes. Good luck with that, however I don't really care will you fix them or not it is just sort of courtesy. I generally don't care about you at this level. My job was done long before this topic even was created and my personal impressions of working with your project remained sharply negative. Sorry this can't be helped. I hate intellectual property thiefs who failed in copy-paste and pretending to be "open-source community" while defending yourself with absolute level demagogy and bullshit. I might be different opinion if you were succeeded but you did not, not in 2006, not in 2015, not in 2018. I will clap my hands when Microsoft will sue you, but you have absolute and total defense from this case - simple because your product will never be competitor for MS even for their EOL'ed products. You will remain "don't know what" at forever. Well I can be wrong of course - miracles happen sometime. This is probably sounds a bit rough and ugly, but I'm sorry I just went down to your level.

You must be thankful that I shared this little piece of information with you. I might be doing some twitter shitpostings instead about "how great this project", et cetera like some of your previous developers did (and don't forget also shitposting about shitposting, recursion from self-proclaimed windoze "expert"). Or do like your infamous jeditobe clown. Or I can simple try to create CVE's entries for your bugs just like one smart guy did in 2007 (we all supposedly know who) - thus making fun of his own work. This is all stupid isn't it? Instead of this bullshit you got your bugs, fuzzer you unable to do 20 years, nice screensaver and what you deserve. For free.

What you do now:
Go to your project, dig in, fix these bugs (if not already), and wait for more if I want to continue.
So after bugs are fixed I say - great job guys, you can take a cookie! I have some cookies for you, you know? Some of them with govno, but this will be sort of russian roulette.

That is all, take this as hint.

Well, looks like we got some attention in here huh? @EP_X0FF it's quite sad that you are tainted by MS code access, otherwise you would be very welcome to help fixing all/many of our bugs we have. We always are looking for ppl skilled in low level Windows parts as these can't be found in every corner all over the world... As you said, it's open source and thus everyone can help fixing stuff as long as he does not use any leaked code or abuses MS code access for his fixes. If you have any reason to claim that ROS already does that, I would be very happy about some facts between all the claiming and ranting against a project in alpha state done by devs in their spare time. I will not excuse any bugs we have though as there are plenty of them and we all know. There you can see our lack of human resources. But which human resources should speed up the development if there are no paid devs and no way to pay them easily and in a egal and safe way? Anyways, we accept patches to speed up our development ;) Some long time missing validation checks should be fine even by a tainted person. Still would have to be confirmed by our main devs, but as you say "trivial" fixes should be very fine.

Greetings

Daniel Reimer
Deputy Chairman
ReactOS Deutschland e.V.

[porcamadonna]

There was a paid audit of all your code made in 2015. Results were really terrifying.

Really? I'm very curious about this.
Who did this paid audit in 2015? Can you provide a link to where I can see more about this paid audit of ReactOS code?

[EP_X0FF]

There was a paid audit of all your code made in 2015. Results were really terrifying.

Really? I'm very curious about this.
Who did this paid audit in 2015? Can you provide a link to where I can see more about this paid audit of ReactOS code?

What else do you need? GPS coordinates of some rare pokemon? Are you seriously think that I will give you (an unknown account with zero posts registered few month ago) anything? No.

[EP_X0FF]

Post disapproved as offtopic. Currently your devs only succeeded in what they are presumable do better than anything else - in adding "their copyrights"





This one doesn't even bothered to fix intentionally left bug in rocall, ofc he was busy adding "copyrights" and "proper attribution". ROFL.

Since except reactos fanboys and nonsense replies (didn't mean your post Brock) nothing else popup here, this thread is now closed.