It actually should look like '\\.\DISPLAY<n>' (since it comes from user mode),
which the function expects, and not '\\Device\\Video<n>', like done in the
kernel mode. Otherwise, passing wrong name causes a mismatch.
Fix the problem with video device access (failure with status 0xc0000022 when
trying to open it). Hence, it also fixes the following debug log spam:
'err: Could not open device \Device\Video0, 0xc0000022'.
Addendum to 77e891b8. CORE-17719 CORE-17786
This fixes the age-long annoyance that wherever you ran a DOS program
with NTVDM, its cmos.ram file would be created in the same current
directory the DOS program was being started.
This created at least two problems:
- useless pollution of directories with cmos.ram files;
- for installers, e.g. of Turbo C 1.x that enumerate the install files
from their directories to be copied/extracted somewhere, the cmos.ram
file could then be enumerated along and cause the installation to
interrupt and/or fail.
Now the cmos.ram file is created in the same directory NTVDM resides
(usually in System32...).
Also, debug-print out only loading errors instead of successes as well.
- NLS: Change weekdays name to capital letter.
- USETUP: Fix typos to pt-PT translation.
- SYSSETUP: Update pt-PT translation.
+ Sync IDS_USER_ADMINISTRATOR_NAME and IDS_ADMINISTRATOR_NAME (in samsrv).
The server-side CsrSrvIdentifyAlertableThread and CsrSrvSetPriorityClass
functions are completely removed in Win2k3+, and are since stubbed by
CsrSrvUnusedFunction instead. They however were present up to Windows XP,
albeit with an extremely minimal implementation.
The corresponding client-side CsrIdentifyAlertableThread and CsrSetPriorityClass
now become just stubs that either trivially succeed or fail, respectively.
See https://www.geoffchappell.com/studies/windows/win32/csrsrv/api/srvinit/apidispatch.htm
for more information.
- Fix typo "al*T*ertable" --> "alertable".
- Remove ROS-specific CSRSS_IDENTIFY_ALERTABLE_THREAD that was
deprecated since ages (at least before 2005)!
GTK applications call GetQueueStatus(QS_ALLINPUT), where QS_ALLINPUT
specifies the QS_RAWINPUT flag as well, when these are compiled for
Windows XP+, and they expect the call to succeed on this platform.
On one side, ReactOS does not currently support this flag at all, but
since it claims to be XP/2003-compatible, applications may implicitly
expect the flag to be supported by GetQueueStatus() and the function
*NOT* failing when this flag is set.
(Later GTK apps don't care and just call GetQueueStatus(QS_ALLINPUT)
that includes QS_RAWINPUT, and therefore would fail as well on e.g.
Windows 2000...)
Otherwise, an observable effect is that some versions of libgdk-win32-2.0.0.dll
enter into an infinite loop when calling GetQueueStatus(QS_ALLINPUT),
since this call always failed on ReactOS.
On the other side, however, we should honour our winetests that handle
the presence of the QS_RAWINPUT flag and behave differently accordingly.
But since we do not support QS_RAWINPUT yet, we should keep their old
behaviour where QS_RAWINPUT is unused.
Thus, in order to accomodate both sides, we don't fail the GetQueueStatus()
call, but just set the ERROR_INVALID_FLAGS last error and continue it.
This fixes CORE-15686, CORE-17551 and probably CORE-11850.
Fixes also all user32:TrackMouseEvent tests.
Co-authored-by: Hermès BÉLUSCA - MAÏTO <hermes.belusca-maito@reactos.org>
In particular, define the compound QS_MOUSE, QS_INPUT, QS_ALLEVENTS
and QS_ALLINPUT flags based on the other elementary QS_*** flags,
instead of having magic values for these.
Actually, RegCloseKey() is here a dummy macro that just "returns"
success. Indeed, the internal implementation of RegOpenKey() doesn't
really allocate internal structures: it just returns a "pointer" to
already existing allocated data. Therefore nothing needs to be closed/freed
later on.
- Move a few lines around.
- Switch to RtlZeroMemory() from memset().
- Make while() more explicit.
For CORE-12802:
- Add/Fix FrLdrHeapAlloc() failure handling and related.
Especially, add/fix FrLdrHeapFree() calls.
- Add/Improve ERR() to some FrLdrHeapAlloc() failure cases.
Co-authored-by: Hermès BÉLUSCA - MAÏTO <hermes.belusca-maito@reactos.org>
