Please point me the same thing. Two or three implementations.
Windows uses the screen, COM1, DBWIN_BUFFER, WMI and ETW to write trace output during/after boot to various locations. Starting with Windows Vista, WMI creates an active trace channel during the boot process which is allot more effective than dmesg so I would look at evntrace.h. Only errors are logged. Windows later writes to COM1 once the driver loads, WMI is implemented in the kernel and (should be loaded) very early into the boot process.
At points before these services are available (I.E. NTLDR) Windows writes output to the console or does a KeBugCheck, then later to WMI/ETW, COM1, then DBWIN_BUFFER in that order. I would prefer output to the screen as much as possible until these services are up and it can write to the bootlog file and ETW for the Event Log.
What compartability did you mean?
How do you propose someone obtain these messages during and after boot without writing new tools? Since the goal of ROS is more or less compatibility, not all devs coming from Windows would expect something like that to be holding trace/debug output. I can use windbg, dbgview, event viewer and ETW log files to view this stuff on Windows so why implement something else completely different for ROS? The goal should be increased compatibility with Windows, not less.
Any bugs, errors occurred during that process of printing into that
MappedView associated with "DBWIN_BUFFER" FileMapping are reported to kernel with DbgPrint.
Where should these errors be stored?
DebugPrint uses OutputDebugString.
Linux in past has such shared memory object, but practically, now, it is
overridden by the system call.
So my question remains Subject: Advice required on User-mode to Kernel mode call for syslog(2) analog in ROS
From user-mode to kernel, My advice would be anything that lets me use
existing user-mode tools like Winbdg, dbgview, Event Viewer, notepad.