Change the Blue Screen Font hardcoded into bootvid.dll to the Open Source "Anonymous Pro" font, which makes a nice 8x13 font.
Blue Screens now look like this: http://fs5.directupload.net/images/160106/ehv6245t.png
[BOOTVID_FONT_GENERATOR]
In case you find an even better font, you now have a nice little tool to test that font and generate the corresponding FontData array for bootvid.
svn path=/trunk/; revision=70507
For MSVC builds (using KDCOM kd64 WinDbg protocol): Bail out for droppable packets after a given number of retries, if no debugger is attached (list of droppable packets can be found in http://articles.sysprogs.org/kdvmware/kdcom.shtml section "KDCOM protocol", subsection "Droppable packets").
CORE-10541 #resolve #comment Finally fixed in revision r70417!
CORE-7106
svn path=/trunk/; revision=70417
Do not use the "LoaderBlock->u.I386.CommonDataArea;" hack to use FreeLdr's DbgPrint function inside KDCOM, for the simple reason that while it works when KDCOM just initializes, the memory area where FreeLdr's DbgPrint function is, gets erased when ReactOS is running. As a result, all attempts to call the DbgPrint function when tracing something in KDCOM at the end of life of ReactOS, just fails lamentably (it hangs).
We therefore cannot rely on external code to provide us with DbgPrint. Instead, implement a very simple DbgPrint function inside KDCOM, as done by KDGDB.
The KD serial port serving for debugging KDCOM is chosen dynamically amongst the other free COM ports.
This needs to be also fixed in KDVM.
[KDGDB]
Instead of hardcoding the KD serial port number serving for debugging KDGDB, determine it dynamically amongst the other free COM ports.
svn path=/trunk/; revision=70405
Implement support for decentralized registry inf files.
This is done with the new add_registry_inf() cmake function, which takes one or more inf files, which are then converted to UTF-16 and merged into a single registry.inf, which is then used to create the livecd hives and imported by usetup. Move the registry entries for some drivers out of hivesys.inf into separate files next to the driver.
svn path=/trunk/; revision=66952
Implement a virtualkd compatible kernel debugger transport DLL. I started this, because I didn't manage to get the original one working, but it turned out, the original one works, you only need to use the correct virtualkd version. Anyway, it's there now. A virtualkd version that works with VBox 4.3.16+ can be found here: http://forum.sysprogs.com/viewtopic.php?f=4&t=3370 or here: http://public.avast.com/~hnanicek/VirtualKd.zip
The folder is called kdvm, since I thought about adding support for VMWare as well, but here the original one probably works as well.
Also fix my email address in some files.
svn path=/trunk/; revision=65813
Int32x32To64 used with unsigned input values will cause unintentional sign extension. There is a lot of code in ROS that is still not fixed!!
Fixes BEEP sound. See also r64020, CORE-8502 and CORE-8505 for more details.
CORE-8505 #comment CsrCaptureTimeout and BEEP code fixed.
svn path=/trunk/; revision=65325
- Introduce the kerneldll module type (like kernelmodedriver, but ending with .dll) and use it in various places
- vfatx.dll whould in fact be a native DLL
svn path=/trunk/; revision=64526
- As pid and tid 0 have a special meaning in GDB, use off-by-one thread and process ID when communicating with it
- Properly read registers and memory from foreign thread and processes. (This time it was tested and proved to work reliably. __writecr3 ftw!)
- Loop the list of processes and threads when trying to find them from ID, as PsLookupProessByThreadId and friends can't be used since we can be at any IRQL.
- Add a few more debug prints to help diagnosing problems.
CORE-8531
svn path=/trunk/; revision=64166
- Fix an embarassing works-for-me but uncommited cast.
- Add support for reading registers and memory from foreign threads. Highly experimental and nearly untested, use at your own risk.
svn path=/trunk/; revision=64156
- Always pass down the result of gdb_receive_packet up to KD, so that it knows when a breakin packet was received. (CTRL-C) now works!
- Generalize the use of the Send <-> ManipulateState callbacks for a better code reading.
- Get the exception context as soon as it is thrown (instead of playing with the PRCB)
- Improve the way we attach to GDB: on the first KD call, we set KdContext->ControlCPending so that KD throws an exception. That way we can first initialize our KD stuff, and then quietly attach to GDB
- Implement the 'p' (get one register) GDB request.
GDB is now much more reliable.
svn path=/trunk/; revision=64154
- It can happen that GDB issues something else than qsThreadInfo after qfThreadInfo
- Properly clean up the callbacks after handling a custom Send/ManipulateState loop
svn path=/trunk/; revision=64146
- Add a callback mechanism permitting to "simulate" KD send <-> receive loop without having to actually communicate to GDB
- Use that to update the program counter when cont'ing a breakpoint
Now cont'ing an assertion failure is possible, since we actually get beyond the int 3 instruction
svn path=/trunk/; revision=64127
- introduce KDGDB, a KDCOM-like DLL, wrapping the KD protocol and the GDB remote protocol together.
It is not fully functional, but for now it permits source-level debugging in some modules. More will be added as I feel the need and find the time to work a bit more on it. (That is, unless an angel comes and resume the work)
To use it, set GDB and _WINKD_ to TRUE in your CMakeCache.txt. Using separate debug symbols is also a good idea.
svn path=/trunk/; revision=64121
- Synchronize correctly arm/bootdata.c with i386, as it was done previously.
- Code formatting: whitespace fixes, add braces/brackets and spaces where needed; comments styling.
- Correctly put braces for casts and around macro parameters.
- Add some IN/OUT.
- Fix parameter names of a function.
[INBV]
- Fix parameter names of two functions.
svn path=/trunk/; revision=64017
Fix incompatible definition of a number of NTOSKRNL data imports. These imports are declared in MS DDK in a way that is usually not how you would declare data imports. The proper way of doing it is using _DECLSPEC_INTRIN_TYPE(dllimport) or in this case NTKERNELAPI, which will cause the compiler to directly dereference the __imp__FooBar symbol. MS has declared some of these variables directly as pointers without using dllimport. This works with MS DDK, since it's import libraries contain aliases (like _FooBar) to the import symbols (__imp__FooBar). Neither MS LINK nor DLLTOOL create these aliases in the import libs, which is good, since hacks like these are dangerous. To make the original declarations work without using macros (which can conflict with other things, like for example the KdDebuggerEnabled member in KUSER_SHARED_DATA) these aliases have to be generated differently. Luckily both MSVC and GCC support a pragma that does exactly this. Fix the incompatible use in our drivers and the broen(!) use of KdDebuggerEnabled in kdcom (which was writing a PBOOLEAN value (FALSE == 0 == NULL, so no warning) into the location that is really a BOOLEAN, possibly overwriting other data. Finally get rid of a number of hacks in ntoskrnl, where prefixed versions were used to not conflict with the DDK definitions.
svn path=/trunk/; revision=63247
* Remove one time inclusions from the main header and put them back where they belong.
* Improve header inclusions.
CORE-7716
svn path=/trunk/; revision=61853
* Remove one time inclusions from the main header and put them back where they belong.
* Improve header inclusions.
CORE-7716
svn path=/trunk/; revision=61852
* Remove one time inclusions from the main header and put them back where they belong.
* Improve header inclusions.
CORE-7716
svn path=/trunk/; revision=61841
- Hey Arch! You're displaying Major function codes, not IOCTL codes. Also, remove unnecessary casts (coming from some old code), and a use-after free.
- Add some memory helpers.
svn path=/trunk/; revision=59448
Initial commit of the ReactOS Console Driver.
For the moment, it's just able to load/unload, creating a "controller" device
and being able to DPRINT1 lots of messages when you try to access to it.
svn path=/trunk/; revision=59447
- FreeLdr is able now to load personalized Kernel Debugger Transport DLLs by reading at the kernel command line and interpreting the /DEBUGPORT=xxx entry (--> loads KDxxx.DLL dll in \SystemRoot\System32\).
Therefore we can not only load the "default" kdcom.dll, but also 3rd-party ones such as kdbazis.dll from VirtualKD (from revision 58902).
- The GCC-compiled-only version of kdcom, containing legacy COM code, was removed and put directly along KDBG. It remains only a stub / template for future kdcom-like dlls. The MSVC-version remains untouched.
- Make those functions ^ use directly the CPORTLIB library.
svn path=/trunk/; revision=58974
The idea then would be to have the following behaviour (when specifying the following options in the kernel command line):
/DEBUGPORT=COMi --> load KDCOM.DLL and use COMi port (i == 1,2,3,4) if possible.
/DEBUGPORT=FOO --> load KDFOO.DLL (useful for KDUSB.DLL, KD1394.DLL, KDBAZIS.DLL for VirtualKD, etc...)
/DEBUGPORT=ROSDBG:[COMi|SCREEN|FILE|GDB|...] --> load KDROSDBG.DLL which contains the ROS kernel debugger, and use COMi or SCREEN or... as output port.
svn path=/branches/kd++/; revision=58883
- Use stdlib.h header instead of declaring the atol function's prototype (caught by Jérôme).
- Clarify the loop in KdpSendPacket (by Timo).
NOTE: I also noticed that it was not this loop-change that fixed reconnection (see commit message of r58823), but one of the changes of revision r58822 (certainly the one in the KdpReceiveByte function) (ironically I said "Seems to fix..." since I noticed that change of behaviour when I was trying to play with the code in KdpSendPacket with modifications of r58822, but I didn't notice that in fact it happened with changes of r58822. It is only today that I constated that, during a revert of r58823 + test + a remark from Timo).
svn path=/trunk/; revision=58834
- Code reorganization: put all the port control functions together.
- Little simplifications of some functions (from CORE-7106).
svn path=/trunk/; revision=58825
