fixes symptom CORE-19005 [NETSTAT] crashes when called with -abnop
and no further argument (protocol name missing).
The crash was a regression of
0.4.11-dev-814-g 2b55073360
also meticulously try to match Windows exact screen output and ERRORLEVEL then
instead of e.g.: simply showing the usage help
which means:
ERRORLEVEL 0 for 'netstat -abnop' and displaying Active-string + table header *but without any sane contents*
ERRORLEVEL 1 for 'netstat -abnop bullshit' and displaying usage help
ERRORLEVEL 0 for 'netstat -abnop tcp' and displaying Active-string + table header + contents
ERRORLEVEL 0 for 'netstat -abnop udp' and displaying Active-string + table header + contents
while touching the file do also some unrelated whitespace tweaks.
* [ADVAPI32_APITEST] Add new RegCreateKeyEx tests
* Remove trailing spaces.
* Initialize SECURITY_ATTRIBUTES sa with zeroes.
Add a set of tests for RegCreateKeyExW and -A.
Created to prove the correctness of the already merged PR (#5230)
JIRA issue: CORE-15471
Besides creating the PDO and device node for it, it has to set up the
necessary registry keys, and register PDO at PnP root driver properly.
CORE-18989
The root device object is in fact a PDO and a FDO at the same time. Thus
there is no need in creating two device objects here, one is enough.
This commit also removes the explicit device extension for the root DO,
because the only reason it existed is to distinguish the root driver's
FDO from its PDOs. This can easily be done by comparing with
IopRootDeviceNode.
Also collect some unused garbage while we are here.
- Use `HKCU\Software\Microsoft\Internet Explorer\Main\StatusBarOther` registry key for the setting persistence.
- Set its value to 1 when the status bar is visible, and to 0 when the status bar is hidden.
- Query it when the file browser is initialized to set the correct view state for the status bar.
- Set the default state of the status bar to hidden if the registry key does not exist, matching the behavior of Windows Server 2003.
CORE-19010
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.
Based on the Portuguese translation from Portugal.
Reviewed-by: Hermès Bélusca-Maïto <hermes.belusca-maito@reactos.org>
Reviewed-by: Stanislav Motylkov <x86corez@gmail.com>
These are specified for releasing the hardware resources previously
acquired by either a previous call to VideoPortVerifyAccessRanges()
or a call to VideoPortGetAccessRanges().
- Add missing mnemonic keys
- Remove unneeded mnemonic keys
- Fix some translated strings being too long
- Fix mispositioned elements
- Reposition overlapping elements
Validated the changes with Resource Hacker. CORE-18867
CORE-17561, CORE-17932, CORE-18221
Do it at each system startup instead: Remove old DirectX initialization code.
It's now outdated and not needed anymore.
Previously, the corresponding hackish intEnableReactXDriver() function
did two things: load dxg.sys and enable DirectDraw.
Now loading DirectX graphics is done during WINSRV initialization, and
enabling DirectDraw is called during each (and also first) display mode
switch, as in Windows. As debug analysis proves, there are no any other
calls in NtGdiDdCreateDirectDrawObject, besides the corresponding DXG
function.
CORE-17932
[ENG] Implement DirectDraw management in switch display mode functions
(e.g. resolution change, color depth, display frequency etc.):
- Switch DirectDraw instances between the two PDEVs (the current one and
the new one allocated by ourselves) by calling dxg!DxDdDynamicModeChange
function.
- Suspend them before and resume after the display mode switch, by calling
dxg!DxDdsuspendDirectDraw and dxg!DxDdResumeDirectDraw appropriately.
We currently don't have these functions implemented, but MS DXG has, so
it allows to properly manage DirectDraw PDEVs using this driver, similarly
to Windows.
My analysis confirms that these functions are always called in XP/2k3 on
display mode switch, even when there is no any DirectX app running at the
moment. Analyzing their prototypes show that my guesses are correct.
- Initialize hDev and dhpdev members for EDD_DIRECTDRAW_GLOBAL for newly
created surfaces, switch them during mode change and re-initialize after
it also. They are commonly used by DirectDraw stack.
In addition, enable DirectDraw for old and new PDEVs, by calling
dxg!DxDdEnableDirectDraw function.
[NTDDRAW] Additionally, fix usage of DirectDraw lock count in the PDEVOBJ
structure.
- Enable cDirectDrawDisableLocks member for storing its value, instead of
DxDd_nCount, which is marked as ROS-specific.
- Use it in win32k!DxEngGet/SetHdevData for getting/setting DirectDraw
count appropriately.
My analysis also shows that in Windows, the PDEVOBJ::cDirectDrawDisableLocks
method calls DxEngGetHdevData with type 8, which corresponds to our DxDd_nCount.
So there are no doubts that this member is used there.
- Rename DxEngGetHdevData_dd_count alias of type 8 to DxEngGetHdevData_dd_locks,
to match more accurately an actual member name. Update the enumeration
and fix all code parts appropriately.
All these changes allow to properly change display mode during executing
DirectDraw applications, when they try to switch in full-screen mode.
At least a bugcheck that happened before my changes, does no longer appear.
There are still some games that don't run correctly, as if there is no
3D acceleration (which actually exists). This requires further investigations.
