If your program works on Windows XP or Windows Server 2003, then there are nothing more to "make it work" on ReactOS: it should work there too. If not, this means that it's a bug/missing functionality in ReactOS that needs to be corrected in ReactOS only.

> from someone who had gone out and read out the entire Windows XP source code No, but by doing the clean-room reverse engineering (someone does the job of doing some disassembling/analysis of debug symbols/etc. and documents, while someone else bases oneself on that to write an implementation and s...

In case you didn't notice, the file wrk2003.c contains copy-pasted code from the WRK, and this is illegal.

The x64 builds of ReactOS available in the getbuilds page are not for everyone usage and won't work. These are just builds to control that the existing code compiles in x64 mode too. The actual x64 development is done in a separate branch, for which no builds are publicly available. Also, these are ...

The only official ReactOS mirror, besides the GitHub one that use used for active development, is: https://git.reactos.org/

karlexceed wrote: ↑

Wed Jul 29, 2020 11:13 pm

[ external image ]

https://www.youtube.com/watch?v=1Kgv8gQYE58

Ask yourself the following question: If your hypothesis was correct, then how is it possible that our kernel is still much incomplete and buggy, after all those years?

All ReactOS releases so far (available on sourceforge) are debug builds.

When the ISO is analysed by these scanners, usually you will get the list of the files (in the ISO) that the scanners think they contain a virus.
So you can then look at their source code in our repo, to see whether they contain weird-looking code.

Then maybe wait until ReactOS becomes more user-friendly.

And what would be the difference compared to the current state of ReactOS?

It seems they are using ReactOS' command line interpreter (cmd.exe), which is itself based on the one from FreeDOS (hence "Tim Norman" appearing in the copyright license). Do you say this based only on the Tim Norman reference, or is there something else you found? All I can see from FLIR themselve...

It seems they are using ReactOS' command line interpreter (cmd.exe), which is itself based on the one from FreeDOS (hence "Tim Norman" appearing in the copyright license).

1. Optional RamDisk loaded. 2. SYSTEM hive loaded: a. Boot file system enumerated, a. Boot drivers enumerated, b. NLS data loaded. 2b. Firmware Errata INF file loaded. 3. ntoskrnl.exe and hal.dll (exact files depending on whether you use standard vs. ACPI vs multiCPU....) loaded. 3b. KD transport DL...

The bootloader code will tell you exactly all what you need:
Starting from this function
https://git.reactos.org/?p=reactos.git; ... =HEAD#l819
just follow the ones it calls.