From ReactOS Wiki
Jump to: navigation, search

My patches to ReactOS// My Bookmarks with useful info// Future place for Manifest-like texts.

My Patches/WIP

(WIP = Work in Progress)

  • [Done] dmesg/kmesg command in ReactOS native kernel debugger CORE-5452, described there.
    • --
  • [Done/not-included] dmesg.exe User-mode utility: done. but not applied (.rbuild system was broken/removed then at the moment + 3 month delay of community considering accepting my kmesg patch).
  • [Almost done:forming a patch] (Important thing): MMIO for serial card at kernel early-boot. (MMIO serial cards doesn't work at all in ROS.)
    • Now it works but I don't know how I will test this on real hardware with CORE-8062 bug leaving the computer in non-working state after every restart and turn-off.
  • [Done] micropatch: print CPUs count and available RAM at ROS start (work related with low-memory related bug)
  • (..describe later..: partitions' bug, FAT32-moved-root-node, etc)
  • usetup.c - series: CORE-7969 submitted patch at 08.03.2014: will see how long it will stay not applied. (needed to retest new hanges required by multilanguage support; will do after early-Serial-MMIO)

Issues: Reported and not yet

  • CORE-7978 - ReactOS boot code of MBR can't boot USB-HDD due to error reading sectors with int13h_ah=42h
    • Added there link to very good explanation how does GRUB stage1 loader work! Just an amazingly detailed description (and also even with joke in stage2!) This link.
    • Workaround: use grub-2 to load freeldr.sys
    • freeldr.ini also requires editing the rdisk() parameter addressing the disks:


rdisk(1)partition(2) here means: 2nd disk, 2nd partition. (partitions are 1-counted, rdisks - 0-counted.)

  • [Yet old bug of 2010/11 times until now] (On my machine: AcerAspire5920g) ReactOS loading process stuck on line ...\Drivers\DISK.SYS when Disk operation mode in BIOS is set to AHCI. Changed the mode to IDE "workarounds" the problem: ntoskrnl.exe reaches the last line ...\Drivers\NDIS.SYS -- and is stuck somewhere more later -- eating 100% CPU. (//Debug-log is required)

So the summary: SATA2 is not fully supported by ReactOS, forced to use IDE.

  • CORE-8062
    • Initial note: Nasty bug made me thing my laptop monitor (matrix chip) or videocard goes fried with some code of reactos; Luckily it was just wrong settings somewhere there. Unhealthy bug; leaves bad mood on any tester, it needed to be corrected by any mean.
    • Postmortem update*: ***TBW***

Bookmarks on Topics

Interesting topics, links (Started at 2011-04-03)

Here I will keep links to forum topics, wiki pages or other, that seemed to be interesting:

Development generic

Repositories: bootCD and liveCD

Core-doc: ReactOS startup procedure described (partly)

Building ReactOS: Hands-on

Tmp: Small notes

  • Strange thing become clear: Ctrl+D doesn't work in 1st stage setup
  • FreeLdr debug settings:
 BootOptions=DbgOsLoadOptions = "/NOGUIBOOT /DEBUGPORT=COM:io,0x3f8,115200n8 /DEBUGPORT=SCREEN" 

Filesystems generic

ReactOS Registry: Editing offline

From here

Editing ReactOS registry hives outside ReactOS? --2006-12

> Is it possible at this moment to edit the registry hives outside the ReactOS environment? > I wanted to automate a process to load these registry hives onto the local registry, > add all my changes, unload the hives and create a new ISO.

Simply change registry sources and build your own binary hives from them.

by hto

> I guess "make" is the prefered way, there isn't any other method for creating these hives?

There is hive maker in tools\mkhive. You can build it with mingw32-make.exe mkhive

Copy it from output-i386\tools\mkhive\mkhive.exe to (say) Windows\mkhive.exe. Then run this command:

mkhive.exe boot\bootdata output-i386\livecd\reactos\system32\config boot\bootdata\livecd.inf boot\bootdata\hiveinst.inf

Where output-i386\livecd\reactos\system32\config -- is output folder for hives. This is how make livecd does it. And yes, you can add your foo.inf to the end of that command.



Serial extension card and MMIO programming

    • Note: I have much info/hands-on to add here...

Debug prints in ROS

They (articles) discuss internals and mechanism of OutputDebugString. Definitely Windows too (as unices) uses system calls to store and receive debug messages data to/from kernel debug messages buffer.

Unix dmesg Internals Analysis

for comparison and for creating something equivalent/analogous in ROS Shortly:

  • Linux has special system call "syslog" (man 2 syslog)
  • FreeBSD uses its special sysctl interface to kernel along with "kern.msgbuf" parameter.

Do we need special system call like Linux, or even more, the whole family of them (sysctl('*')) as in BSD? How to implement simple system call for it, now?


Detailed info for unices:

Linux case:

  • syslog(2) - read and/or clear kernel message ring buffer; set console_loglevel

int syslog(int type, char *bufp, int len);

  • also /proc/kmsg virtual file, which when being read returns buffer contents

Excerpt from "man proc":

                   This file can be used instead of the syslog(2)  system
call  to  read  kernel  messages.   A
                   process  must  have  superuser privileges to read this
file, and only one process should read
                   this file.  This file should not be read if a syslog
process is running which uses  the  sys‐
                   log(2) system call facility to log kernel messages.

                   Information in this file is retrieved with the dmesg(1) program.

dmesg in FreeBSD:

  • Parameter 'kern.msgbuf' given to sysctl(3) returns contents of kernel message buffer.
  • There is also 'kern.msgbuf_clear' to clean the buffer.


These could be probably outdated in sense the USB now is in better working state.


FreeLoader, debug information, getting

Related with low-memory bug: 1) 4Gb was recognized as 25Mb 2) ROS started with 25Mb silently eat up 100% CPU and infinitely read from boot CD/HDD.


SVN how-to links