It allows to properly pass the surface handle (and palette entry pointer) from MS ddraw into win32k.
Otherwise, they are passing into the wrong parameters of actual NtGdi* function, and due to this,
since they're detected as invalid, they become NULL, and that function does not work correctly.
See https://docs.microsoft.com/en-us/windows/win32/devnotes/-dxgkernel-ntgdiddgetdc for the reference
(and confirmed by our headers).
Required by MS DirectDraw stack (ddraw.dll & dxg.sys).
CORE-17561
flip_fix_9.patch fixes:
CORE-16984 " 'SPINA Thrulg' / 'SPINA Thyr' / 'Sim Thyr' have images flipped"
CORE-17194 "StretchDIBits test" isn't work correctly"
"Output of 'Project 3 Test'"
CORE-14701 "DVDStyler 3.0.4 transparent toolbars"
CORE-14701 "DVDStyler 3.0.4 erroneously black around icons of welcome-dlg"
CORE-14671 "'Peazip' shows icons in buttons and menubar vertically flipped"
"Double Commander shoes icons flipped in buttons, menubar, listview and the treeview"
CORE-13273 "Welcome to Lazarus" icon shows flipped
CORE-13026 "'CudaText app' icon shows flipped"
Not all of those are duplicates, although they appear to be at first glance.
It affects different controls and some of those tickets do have different 'guilty revs' than others.
The patch does consist of 3 parts:
1.) win32ss/gdi/ntgdi/dibobj.c
This one is the most clean part of it, that addresses most of the flipping issues now.
2.) The hack in comctl32.h redefining the version:
We used that in the past to appease some, but not all of the issues listed above.
But it does hide additional issues, e.g. in DvDStyler, therefore we seem to still need that appeasement even today.
Most likely it would make sense to aim to avoid this part in the future.
part 2.) was committed as first appeasement on its own already into
0.4.14-RC-24-g 198b61e
0.4.13-RC-7-g 67211fa
0.4.12-RC-5-g 8449527
0.4.11-RC-16-g b906163
0.4.10-RC-7-g f1e80fe
0.4.9-RC-34-g 9d758ae
3.) toolbar.c change
That part fixes at least the toolbar case for DvDStyler
without relying on the comctl32.h hack any longer,
but it was still not enough to completely get rid of part 2.) yet.
Many thanks to all contributors: 'I_kill_Bugs', Doug Lyons and also 'Julenuri' for testing.
The patch gave nice testbot results:
KVM: https://reactos.org/testman/compare.php?ids=75704,75714
VBox: https://reactos.org/testman/compare.php?ids=75705,75715
and we also created a summary of manual test-results:
https://jira.reactos.org/browse/CORE-17415?focusedCommentId=126668&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-126668
If you read this comment via git blame and your goal is to get rid of the hack in comctl32.h, I would highly recommend
to redo the tests of that testing table, and if that is asked too much, then please test at least the following cases:
CORE-14701 "DVDStyler 3.0.4 transparent toolbars"
CORE-14701 "DVDStyler 3.0.4 erroneously black around icons of welcome-dlg"
"DVDStyler 3.0.4 erroneously black/transparent within comboboxes of properties of VMGM menu"
and try to add what might be needed to fix them, and double-check again:
"DoubleCommander optionsDlg the most complex testcase, contains flip-prone icons in treeview, listview, menubar, buttons, statics". Only some of its flipped icons were impacted by the comctl32.h change before.
- Change INIT_FUNCTION and INIT_SECTION to CODE_SEG("INIT") and DATA_SEG("INIT") respectively
- Remove INIT_FUNCTION from function prototypes
- Remove alloc_text pragma calls as they are not needed anymore
ReactOS has no Raster fonts today, so compensate for this affecting the editbox margins.
CORE-1091
This patch fixes the inability to see all of the characters in the CD-KEY box of Starcraft and Visual Basic 5 and Visual Basic 6 Installs. It supersedes #2656
In return of GetGlyphOutline function call, gm.gmBlackBoxX and gm.gmBlackBoxY must be non-zero to avoid Division by Zero. At epilogue of ftGdiGetGlyphOutline, we adjust the values. CORE-15949
By Reverting beginnings of raster-fonts-works (*.fnt and *.fon)
Thanks Katayama Hirofumi MZ for helping with this revert.
The regression was introduced by 0.4.13-dev-681-g
ae99df1675
I will also port this revert back into 0.4.13-RC
CORE-12149
VIDEOPRT:
=========
Improve interfacing with INBV, so as to detect when an external module
acquired INBV display ownership, and whether ownership is being released
later on. (This does NOT rely on hooking!)
For this purpose we improve the IntVideoPortResetDisplayParameters(Ex)
callback that gets registered with an InbvNotifyDisplayOwnershipLost()
call during initialization, and we add a monitoring thread.
The callback is called whenever an external module calls
InbvAcquireDisplayOwnership(), for example the bugcheck code or the KDBG
debugger in SCREEN mode. When this happens, a flag that tells the
monitoring thread to start monitoring INBV is set (ReactOS-specific),
and the display adapters get reset with HwResetHw() (as done on Windows).
Due to the fact that this INBV callback can be called at *ANY* IRQL, we
cannot use dispatcher synchronization mechanisms such as events to tell
the INBV monitoring thread to start its operations, so we need to rely
instead on a flag to be set. And, since INBV doesn't provide with any
proper callback/notification system either, we need to actively monitor
its state by pooling. To reduce the load on the system the monitoring
thread performs 1-second waits between each check for the flag set by
the INBV callback, and during checking the INBV ownership status.
When the INBV ownership is detected to be released by an external module,
the INBV callback is re-registered (this is *MANDATORY* since the
external module has called InbvNotifyDisplayOwnershipLost() with a
different callback parameter!), and then we callout to Win32k for
re-enabling the display.
This has the virtue of correctly resetting the display once the KDBG
debugger in SCREEN mode is being exited, and fixes CORE-12149 .
The following additional fixes were needed:
VIDEOPRT & WIN32K:
==================
Remove the registration with INBV that was previously done in a ReactOS-
specific hacked IRP_MJ_WRITE call; it is now done correctly during the
video device opening done by EngpRegisterGraphicsDevice() in the VIDEOPRT's
IRP_MJ_CREATE handler, as done on Windows.
WIN32K:
=======
- Stub the VideoPortCallout() support, for VIDEOPRT -> WIN32 callbacks.
This function gets registered with VIDEOPRT through an
IOCTL_VIDEO_INIT_WIN32K_CALLBACKS call in EngpRegisterGraphicsDevice().
- Only partially implement the 'VideoFindAdapterCallout' case, that just
re-enables the primary display by refreshing it (using the new function
UserRefreshDisplay()).
VIDEOPRT:
=========
- PVIDEO_WIN32K_CALLOUT is an NTAPI (stdcall) callback.
- In the IntVideoPortResetDisplayParameters(Ex) callback, reset all the
"resettable" adapters registered in the HwResetAdaptersList list.
We thus get rid of the global ResetDisplayParametersDeviceExtension.
- Make the IntVideoPortResetDisplayParameters(Ex) callback slightly more
robust (using SEH) against potential HwResetListEntry list corruption
or invalid DriverExtension->InitializationData.HwResetHw() that would
otherwise trigger a BSOD, and this would be disastrous since that
callback is precisely called when INBV is acquired, typically when the
BSOD code initializes the display for displaying its information...
Extras:
- Validate the IrpStack->MajorFunction in IntVideoPortDispatchDeviceControl()
and implement IRP_MJ_SHUTDOWN handling. Stub out the other IOCTLs that
are handled by VIDEOPRT only (and not by the miniports).
- VIDEOPRT doesn't require IRP_MJ_INTERNAL_DEVICE_CONTROL (unused).
- Implement IOCTL_VIDEO_PREPARE_FOR_EARECOVERY that just resets the
display to standard VGA 80x25 text mode.
- Delete ItalicFromStyle and WeightFromStyle functions.
- Don't use FT_FaceRec.style_name for font style but pOS2->fsSelection, pOS2->usWeightClass, WinFNT.italic and WinFNT.weight.
- Don't use the bitmap glyph as possible if the glyph will be oblique'd.
- Tahoma Italic is working!
CORE-9614
