Regression: ReactOS does no longer boot into desktop with native video drivers

To reproduce the bug:

1. Install ReactOS in VMWare or on any real hardware which has XP/2003 compatible video driver for its GPU (it is reproducible there as well too). For VMWare, you can simply install the VMWare Tools for XP and 2003. VirtualBox is not affected by this issue however.
2. Install XP compatible version of native video driver for your graphics card from manufacturer. Note that on real hardware, videoprt.sys replacement it badly required for most of drivers.
3. Reboot the system to allow video driver to initialize properly.

After 1st booting with the driver, this issue becomes visible.

- Up to 0.4.15-dev-6164-g3fa613b, the system is booting without issues (if all the steps described above are done correctly):

- Starting from 0.4.15-dev-6165-ge034377, it does not boot into Desktop anymore:
vmware-dxg.log

The problem is caused by a lot of unimplemented features in our DirectX Graphics Driver (dxg.sys). The loading fails to initialize display driver when calling the unimplemented functionality, in essence, DxDdHeapVidMemAllocAligned, as visible from the log above:

(win32ss/reactx/ntddraw/eng.c:34) Calling dxg.sys pfnHeapVidMemAllocAligned

DXG: DxDdHeapVidMemAllocAligned

(win32ss/reactx/ntddraw/eng.c:34) Calling dxg.sys pfnHeapVidMemAllocAligned

DXG: DxDdHeapVidMemAllocAligned

(win32ss/reactx/ntddraw/eng.c:34) Calling dxg.sys pfnHeapVidMemAllocAligned

DXG: DxDdHeapVidMemAllocAlignedEntered debugger on embedded INT3 at 0x0008:0x8059E2DE.

kdb:> 

kdb:> bt

[?7hEip:

<ntoskrnl.exe:19e2de (sdk/lib/rtl/i386/debug_asm.S:33 (DbgBreakPoint))>

Frames:

<vmx_fb.dll:ab8a>

<win32k.sys:18842 (win32ss/gdi/eng/pdevobj.c:320 (PDEVOBJ_pSurface))>

<win32k.sys:190b5 (win32ss/gdi/eng/pdevobj.c:594 (PDEVOBJ_Create))>

<win32k.sys:14686 (win32ss/gdi/eng/mdevobj.c:113 (MDEVOBJ_Create))>

<win32k.sys:1980d (win32ss/gdi/eng/pdevobj.c:921 (PDEVOBJ_lChangeDisplaySettings))>

<win32k.sys:9b21d (win32ss/user/ntuser/winsta.c:266 (co_IntInitializeDesktopGraphics))>

<win32k.sys:4783f (win32ss/user/ntuser/guicheck.c:27 (co_AddGuiApp))>

<win32k.sys:478b3 (win32ss/user/ntuser/guicheck.c:61 (co_IntGraphicsCheck))>

<win32k.sys:89250 (win32ss/user/ntuser/windc.c:44 (DceCreateDisplayDC))>

<win32k.sys:8931d (win32ss/user/ntuser/windc.c:94 (DceAllocDCE))>

<win32k.sys:89b37 (win32ss/user/ntuser/windc.c:488 (UserGetDCEx))>

<win32k.sys:8a71e (win32ss/user/ntuser/windc.c:985 (NtUserGetDCEx))>

<win32k.sys:8a83c (win32ss/user/ntuser/windc.c:1016 (NtUserGetDC))>

<ntoskrnl.exe:3fe5 (:0 (KiSystemCallTrampoline))>

<ntoskrnl.exe:160e41 (ntoskrnl/ke/i386/traphdlr.c:1840 (KiSystemServiceHandler))>

<ntoskrnl.exe:3e2f (:0 (KiFastCallEntry))>

<ntdll.dll:f47d>

<user32.dll:454f9>

<user32.dll:490e6>

<msgina.dll:3e01>

<kernel32.dll:1c97b>--- Press q to abort, any other key to continue ---kdb:>  

Theoretically, after implementing this function, it might fail on another one instead, but it needs to be fixed and tested further to know exactly.

The guilty commit is my commit into win32k, which adds a proper DirectDraw management during display mode switching. My changes fix the dxg.sys initialization, so now it is loaded correctly and can be used by higher-level user-mode components those need it (ddraw, d3d8, d3d9 etc). It's indeed caught only by missing functionality in our dxg.sys, because I've tested and ensured many times that with MS dxg.sys from Windows XP/Server 2003, it is booting correctly again.

Might be fixed by WIP 5604 PR in the near future, since that possibly will implement missing functionality required by native display drivers.