Revert "[PSDK][AFD][VGADDI] Further build and MS PSDK compatibility fixes."
This reverts commit 99efc2ae50.
Revert "[PSDK] Sync winresrc.h with wine-8.20"
This reverts commit 3e83562aa7.
Revert "[OSK][PROGMAN] Fix resource file build."
This reverts commit 84e4ad0a82.
Revert "[PSDK] Use the new .rh files in winresrc.h"
This reverts commit f6fb7c48c9.
- windows.h:
* should define _WINDOWS_ and _INC_WINDOWS instead of _WINDOWS_H
* include winresrc.h if RC_INVOKED and not NOWINRES (Wine also agrees
with that)
* also, some .h included from there should _not_ be included if their
respective NO*** flags are defined.
- batclass.h: Use correct _WINDOWS_ guard.
- winsnmp.h:
* should define _INC_WINSNMP instead of _WINSNMP_H
* use _INC_WINDOWS instead of _WINDOWS_H
- afd.h, vgaddi.h: Use the correct guards.
- winnt.rh: Define the (SUB)LANG_* exactly as they are in the winnt.h,
otherwise we get macro redefinition compile errors.
NOTE: Ideally these .rh files should be auto-generated from their
corresponding .h files.
- afxres.h: Do not include the whole windows.h, but instead, only
the winres.h file, and only if RC_INVOKED is defined.
NOTE: Both afxres.h and winres.h do not really belong to the PSDK,
but belong instead to MFC. The reason why we have them here is twofold:
1. Wine used to have also winres.h (from where we got ours). This is
because the .rc resource files of some non-MFC modules were generated
with Visual Studio, which always includes afxres.h for these, and the
solution was to use a slightly less MFC-specific header: winres.h
(Wine commit cb08c82244673f26842e7a0766de90f091b5a493).
However, this winres.h has been since removed from Wine tree
(Wine commit 197f4059ab2af5f13f9c56faa26e3b4af902f869).
2. Few of our modules either use afxres.h or winres.h in their resource
files, and we still want to be able to compile them.
CORE-19011
Fix a "bug" I introduced in commit 61012eb54.
VideoPortGetAccessRanges() expects the caller to specify at least the
total number of ranges the hardware exposes, otherwise it fails with
ERROR_MORE_DATA. (Tested also with the help of Windows' videoprt.sys.)
On real original XBOX there are three:
```
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation NV2A [XGPU] [10de:02a0] (rev a1)
Subsystem: Unknown [0000:0000]
Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 03
Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
Memory at f0000000 (32-bit, prefetchable) [size=128M]
Memory at 00000000 (32-bit, prefetchable) [size=512K]
```
Thanks to Stanislav and Daniel for tests on the real XBOX.
These are specified for releasing the hardware resources previously
acquired by either a previous call to VideoPortVerifyAccessRanges()
or a call to VideoPortGetAccessRanges().
Contrary to what is (badly) written on MSDN, this parameter is
*mandatory* when the ranges looked for are on a PCI adapter.
Detected when testing with MS Windows' videoprt.sys on XBOX emulator;
thanks to Simone Lombardo for assistance!
Replace framebuf display driver by framebuf_new display driver
Compile framebuf_new as framebuf.dll, and add it to bootcd/livecd
Remove old framebuf from compilation, to not conflict
- deduplication of manufacturer strings
- at some places harmonizes the different length of separator lines within the same file, centers the words (as requested by hbelusca during review), harmonizes those lines to 74characters length each
- moving some strings that are not to be localized into the non-localization string section
- other minor formatting preferences coauthored by StasM
As IOCTL_VIDEO_GET_CURRENT_MODE returns 2 as ModeIndex, wait for the same value
in IOCTL_VIDEO_SET_CURRENT_MODE.
Also change vgaddi to send this hardcoded value.
vga_new also uses 2 as index for 640x480x16
- [VIDEOPRT] Return the real PhysicalDeviceObject in Win32k callbacks.
- [WIN32SS:ENG] Pass PhysDeviceObject into the GraphicsDevice structure
and rename the destination field accordingly.
- [WIN32SS:NTUSER] Request hardware identifiers from device PDO and
fill DISPLAY_DEVICE's DeviceID field with the first identifier.
Now it's correctly passed to the usermode, and Desktop Propertes applet
can open the video adapter device properties.
Thanks to Hervé Poussineau for the help.
CORE-18197 CORE-11715
- Store settings in non hardware-profile registry key.
- Rename driver file to vgapnp.sys to keep in sync with VBE.
- This makes PC-98 video driver working again.
Addendum to 073a1ea3 and f03750de. CORE-18201 CORE-17977
Change it it two places, to handle when 'UseNewKey' is enabled or disabled.
This fixes the Spice guest agent, which searches 'System' case-sensitively in it.
This reverts commit ecf3416f49.
This commit was meant to fix CORE-17688. While its effectively fixed
the problem, it introduced another regression CORE-17719.
In the mean time, commit c05a45e17e fixed
things properly.
CORE-17719
As we are a non PNP driver, the call chain will be
DriverEntry -> VidePortInitialize -> VideoPortFindAdapter -> HwFindAdapter.
If legacy resources are available, we will fail VGAFindAdapter,
so DriverEntry will fail, so vgamp.sys driver won't be used.
CORE-17789
CORE-17688
When a new driver is installed for the same device (like VBoxVideo), it uses the same hardware enum registry key and thus reuses the same DisplayId and the same display registry key. Therefore we need to update the setting in that key, even when the key already exists.
This seems to work good and not cause any issues, but testing indicated that on Windows some values are only updated, when the driver has changed. If neccessary, this can be achieved by updating and querying the ActiveService value in the device enum key (e.g. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\PCI\VEN_80EE&DEV_BEEF&SUSYS_00000000&REV_00\3&267a616a&0&10\Control: ActiveService). If that doesn't match the current device name (from DriverExtension->RegistryPath) the values should be copied over.
