This will be used (later) to store the list of all enabled display devices.
Add a global variable gpmdev (should really be stored in DISPLAYINFO structure)
Replace global variable gppdevPrimary by pmdev->ppdevGlobal.
- change first argument to be a PGRAPHICS_DEVICE instead of a device name
- add ldevtype (for now, only LDEV_DEVICE_DISPLAY is allowed)
- always pass a devmode if ldevtype is LDEV_DEVICE_DISPLAY
- insert the ppdev into gppdevList on success
- change callers to adapt them to new rules
- Change LDEVOBJ_bEnableDriver to directly take the entry point
(pGdiDriverInfo not required anymore)
- Add LDEVOBJ_pLoadInternal to load and start an internal driver
- make it return a new allocated PDEVMODEW instead of a pointer into
existing PGRAPHICS_DEVICE (usefull when available display modes can
dynamically change: VirtualBox, RDP, ...)
- update all callers
LDEVOBJ_bBuildDevmodeList() only queries the available display modes, without
choosing the one to use on the graphic device, and without immediately
creating a PDEV.
Replace first part of EngpPopulateDeviceModeList() function by a call
to this new function LDEVOBJ_bBuildDevmodeList().
Keep second part of EngpPopulateDeviceModeList() function, which
chooses the default display mode.
- implement LDEVOBJ_ulGetDriverModes (which get modes from a not yet loaded driver),
and use it in EngpPopulateDeviceModeList
- remove now useless LDEVOBJ_pdmiGetModes (replaced by LDEVOBJ_ulGetDriverModes)
MSVC amd64
'...\dll\win32\winmm\midimap\midimap.c(474): warning C4133: 'function': incompatible types - from 'LPDWORD' to 'DWORD_PTR *''
Import missed parts of
29b00e1a8c
Addendum to b40e7f0 (r47900).
CORE-7538
CORE-18140
This was introduced historically in commit 583de66b3 (r7460) to
workaround some compiler problems (or replace already existing
GCC-specific __attribute__((packed)) annotations); however these
structures are in-memory-only, do not describe any on-disk data
format and don't describe hardware-specific data. So they should
have the "natural" alignment of the target platform.
They also have to match the documented layouts at:
https://reactos.org/wiki/Techwiki:Win32k/THREADINFOhttps://www.geoffchappell.com/studies/windows/km/win32k/structs/threadinfo/index.htm
at least for the compatible parts that ReactOS shares.
This also removes the following warnings, that were present because,
as the ACPICA acpi.h header was used as PCH (instead of none, or the
hal's own main header), it was "included" before any other header
-- and in particular, before hal.h -- and as a result, colliding defines
were still defined even if the #undef tricks were used for them.
rosbuilds\sdk\include\reactos\mc\bugcodes.h(1417): warning C4005: 'ACPI_BIOS_ERROR': macro redefinition
reactos\drivers\bus\acpi\acpica\include\acoutput.h(243): note: see previous definition of 'ACPI_BIOS_ERROR'
reactos\hal\halx86\include\hal.h(41): warning C4109: unexpected identifier '_read'
reactos\hal\halx86\include\hal.h(42): warning C4109: unexpected identifier '_read'
Typos introduced in commit 4d1ea554c.
These had the effect of enumerating "NetworkProviderRemoteValidation"
and "Extended BasePCI Configuration" as groups, which were of course
invalid/non-existent.
The actual groups are: "NetworkProvider", "RemoteValidation",
"Extended Base", and "PCI Configuration".
Fixing this may correct the loading order of drivers that belong to
these groups (if we do have such drivers).
In MS Windows all control panel applets are started in single instance.
This prevents conflicts of concurrent accesses to the configuration data.
Before starting applets, look up the dialog window of the existing instance
by checking several atoms, such as the applet path, CPLName, and CPLFlags.
If the dialog is found, it's brought to the foreground, and a new applet
instance not started.
CORE-7921 CORE-17025
Signed-off-by: Raymond Czerny <chip@raymisoft.de>
Reviewed-by: Hermès Bélusca-Maïto <hermes.belusca-maito@reactos.org>
Reviewed-by: Joachim Henze <joachim.henze@reactos.org>
Reviewed-by: Mark Jansen <mark.jansen@reactos.org>
Turns out, that rtl/amd64/rtlmem.S doesn't currently compile fine with
ML64, and it wasn't included for compilation anyways in the original RTL.
So, just remove it from there as well.
This allows: (i) to shorten dramatically the lengths of the static
registry path strings being used (and thus, allow for reduced binary
file size), and (ii) to prepare future support for selecting different
control sets (and related Last-Known-Good configurations).
- Use UNICODE_STRINGs wherever possible.
- Retrieve the OEMHAL font file name. TODO: Load it!
- In WinLdrLoadNLSData(), don't open/close each file twice (and showing
we are loading them twice). Instead, open all files at once (and keep
them that way), retrieve their sizes and do the calculations, then
load their respective contents one by one -- giving loading feedback
only at that point -- and finally close all of them at once.
... as it should have always been done (and must be done for NTDLL
and NTOS kernel as well). This allows using the RTL with the correct
definitions and the reduced functionality available at boot-time.
+ Make the RTL main header compatible.
In addition, this will permit re-using existing code that already
uses the RTL (mostly string conversions).
See commits 427c90af3 (r36761) and b46e8cc18 (r36980) for some
background.
