Follow bugs did I notice in our modf
1. bug did not clear the st reg before it was use
2. bug did not load the reg right
3. bug did not handler all case
svn path=/trunk/; revision=21937
- Overlay MADDRES_SPACE over MM_AVL_NODE. Even though our structures are currently incompatible, they represent the same thing (The EPROCESS's Address space).
svn path=/trunk/; revision=21934
ntoskrnl/ex/error.c
- Alex Ionescu states the implementations are clean: I just re-orgznied the *harderror functions. The SEH filter is a trivial/well-known return of a single value, and __purecall is a stub.
svn path=/trunk/; revision=21932
ntoskrnl/dbgk
(according to functions_list.txt in audited branch comments by Alex Ionescu, and comments by me)
- debug.c: Clean/trivial implementation based on the object's structure. I merely create it and then initailize all its members. Other functions are stubs
- dbgkutil.c: Code is #if0'ed, and doesn't belong to Alex Ionescu. Author is unknown.
- Unified / prettified formatting, STDCALL -> NTAPI
svn path=/trunk/; revision=21931
ntoskrnl/ex
(according to functions_list.txt in audited branch comments by Alex Ionescu, and uuid.c comments by me)
- dbgctrl.c: Modified the function slightly for compatibility with some keys, still has nothing to do with Windows'
- lookas.c: File is clean. I merely rewrote existing versions based on a GPLed IBM driver I found on google, OSR documentation and some DDK sample code. The implementation is trivial and only calls caller-defined functions which are the ones doing the work.
- uuid.c: Added programmers, unified formatting, STDCALL->NTAPI change. Code doesn't look suspicious, plus stubbed functions
- win32k.c: Alex Ionescu only changed the functions to call Win32K instead of having the code in ntoskrnl. It was a cut/paste job. Aleksey Bragin: The code looks very trivial and straightforward, certainly it's written based on clean sources of information
- zone.c: Based on David Welch's code, which Alex Ionescu merely cleaned up, using clean development. He's not even sure if the Zone functions are still in Windows.
svn path=/trunk/; revision=21930
ntoskrnl/inbv
- Functions are written mostly by dwelch and chorn, are exported and don't look like containing dirty code. They have some comments too. Filip confirmes this file is clean.
- Unified formatting throughout the file
svn path=/trunk/; revision=21927
Filip Navara: Contains only two functions, one of them is unimplemented Windows function and the other one is ROS specific and doesn't even follow the NT design.
svn path=/trunk/; revision=21926
ntoskrnl/ex/init.c
- Alex Ionescu: File is clean. Most of these are ReactOS-internal and specific to our booting cycle, which is entirely incompatible with Windows and broken beyond explanation.
svn path=/trunk/; revision=21924
ntoskrnl/mm/mpw.c
- Filip Navara: mpw.c is surely clean. it's totally wrong and besides it was described in The Book (Inside Windows NT)
svn path=/trunk/; revision=21922
1) ReactOS is extremely long to parse .inf files (no .pnf files as on Windows). Remember we want to keep ReactOS fast (when running) and small (on disk).
2) nVidia already provides a .inf file for its devices. You will still need it for other devices, so why not also use it for PCI System Management and Memory Controller?
3) Windows doesn't recognize natively the nVidia chipset, even with lastest updates.
4) I only care about devices emulated by VMware/Qemu/Bochs/Virtual PC, ie virtual machines.
5) If you add PnP IDs of some nVidia devices, someone else will want to add PnP IDs for other chipsets (Via, C3, Intel, ...)
6) While you are at it, why don't you add 40Mb to recognize the same amount of devices as Windows XP?
svn path=/trunk/; revision=21905
- Add System Bus Extender service group (used by pciide driver)
- Fix tags for Boot Bus Extender services
- Remove deprecated entries for ide.sys
- Let not the hardware wizard display the "Unknown device" (hack)
svn path=/trunk/; revision=21896
