Fix CLIENTINFO usermode pointer access once again.
Based on a patch by Michael Fritscher from CORE-10017.
Addendum to 7052282507 (r68702).
CORE-18728 CORE-19014
The function should return the kernel time for the idle thread in the
first argument, and kernel time + user time for the current thread in
the second argument.
Also retrieve the processor number from the cached PRCB instead of
calling KeGetCurrentProcessorNumber() which retrieves the PRCB again
since the processor could switch in-between those calls.
NdisGetCurrentProcessorCounts() function follows the same prototype
which is the correct one.
- Reimplement the Release and Renew functions using GetAdaptersInfo().
- Check for enabled DHCP and connected medium
- Check for already released Lease in the Release function
- Add required messages
Many thanks for Simone Lombardo for pointing to the code needing attention
and providing a working proof-of-concept solution.
CORE-12377
CORE-18084
CORE-13889
The sum of X and width exceeds the X of next element.
So, change the width to <next x> - <current x>.
All affected translations were changed.
CORE-18829
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().
