This is really ReactOS-specific, so I surround them with __REACTOS__
(even if this is our code) to differentiate these from Win2k3 behaviour,
even though they were strongly inspired by what was possible in the beta
versions of NT 3.1 (pre-3.10.404).
Interestingly, Windows 7+ partially re-introduced that functionality
(just in differencing "Windows=On" from "Off").
See https://reactos.org/wiki/User:Hbelusca/CSRSS for more information.
Partially revert some aspects of commits 5696e4ba4 and bf40c7a31.
(See PR #4340.)
In order for Win2k3 kernel32.dll to operate with our basesrv.dll (or our
kernel32.dll to operate with Win2k3 basesrv.dll), we need in particular
to have the CreateNlsSecurityDescriptor() helper to exactly take the
expected parameters. Namely, a pointer to a **user-allocated**
SECURITY_DESCRIPTOR buffer, its size (and an access mask).
The function expects its caller to provide all this, and the caller expects
the function to initialize the security descriptor buffer. Note that the
function does *NOT* allocate a new descriptor buffer to be returned!
Indeed, with the way it currently is in master, using Win2k3 kernel32
with our basesrv is now failing with the errors:
```
NLSAPI: Could NOT Create ACL - c0000023.
(subsystems/win/basesrv/nls.c:279) NLS: CreateNlsSecurityDescriptor FAILED!: c0000023
NLSAPI: Could NOT initialize Server - c0000023.
(dll/ntdll/ldr/ldrinit.c:867) LDR: DLL_PROCESS_ATTACH for dll "kernel32.dll" (InitRoutine: 77E40D95) failed
```
(and, if we ever attempted to increase the so-claimed "dummy parameter"
descriptor size in the basesrv call, we would end up with its stack
corrupted and a crash).
Conversely, using our kernel32 with Win2k3 basesrv, would end up with
basesrv receiving a wrongly-initialized descriptor that would not work
(the buffer not being initialized with the contents of a descriptor, but
instead receiving some address to a descriptor allocated somewhere else).
- Changed some wording according to the translation requirements.
- Fixed some mistakes.
- Changed my name.
Reviewed-by: He Yang <1160386205@qq.com>
Reviewed-by: Stanislav Motylkov <x86corez@gmail.com>
Implement code that deals with the security side of NLS, more specifically, create two security descriptors for NLS directory and NLS section names and let the server use such code.
When increasing the base priority at shutdown, acquire the necessary
SE_INC_BASE_PRIORITY_PRIVILEGE in CsrSetToShutdownPriority(),
called by CsrShutdownProcesses(), which is necessary due to the increase
of process base priority (i.e. increase of scheduling) being done.
Dedicated to George Bișoc :)
The Shutdown privilege is however unnecessary (or unwanted) since this
has been already dealt with by the shutdown caller. Also, it will be
needed only by the caller of NtShutdownSystem() -- that we don't call
at all here.
Reviewed all Chinese Simplified translation files and updated those
inappropriate or outdated ones.
Co-authored-by: Liu Wenyuan <15816141883@163.com>
Reviewed-by: Chan Chilung <eason066@gmail.com>
Reviewed-by: He Yang <1160386205@qq.com>
Reviewed-by: Zheng Jianping <robsean@126.com>
Reviewed-by: Luo Yufan <njlyf2011@hotmail.com>
Reviewed-by: Hermès Bélusca-Maïto <hermes.belusca-maito@reactos.org>
Reviewed-by: Stanislav Motylkov <x86corez@gmail.com>
- Added zh-HK translation for following files:
- [BASE/SERVICES/W32TIME]
- [BASE/SYSTEM/...] (except CMD console only applications)
- [FDEBUG]
- [DLL/CPL/...] (except Wine related applications)
- [DLL/SHELLEXT/...]
- [DLL/WIN32/...] (not all applications are translated, and Wine related applications are excluded from this part)
- [MODULES/ROSAPPS/APPLICATIONS/...] (not all applications are translated)
- [SCREENSAVERS]
- [NTVDM]
- [USERSRV]
- Translation Improvement
- Fix header for zh-TW and zh-HK translation files
Reviewed-by: Luo Yufan <njlyf2011@hotmail.com>
Reviewed-by: Hermès Bélusca-Maïto <hermes.belusca-maito@reactos.org>
Reviewed-by: Stanislav Motylkov <x86corez@gmail.com>
- Added translation for:
- [W32TIME]
- [MODE]
- [TIMEOUT]
- [MODEMUI]
- [ARPING]
- [FRAGINATOR]
- and more
- Updated existing translation
- [WINNLS] Update cht (zh-TW) and zhh (zh-HK)
- [DOC] Update rules in Chinese translation notes.txt
- Wine translation sync
Some of the punctuation use in WIne has been converted to half-width,
so the punctuation will no longer synced.
This became a requirement, following a previous CMake update.
Otherwise the built EXEs would not export their intended functions.
Addendum to commit d8e92b5a (see PR #1335)
CORE-15406
[LOADCONFIG] The GCC rant had nothing to do with GCC, but everything with CMake...
[SPOOLSV] Add the missing exported stubs.
We get file matches when their attributes match and we can obtain
a valid 8.3 file name. This last condition is of upmost importance.
We cannot reliably use GetShortPathName() on the filename returned by
FindFirstFile()/FindNextFile() because the result is uncertain (one
either needs to build a full path before calling the function just to
get the final short path form, or change the current working directory
to the one where the search is being made, etc.)
The Find*file() functions return anyway the short file. name (in the
cAlternateFileName member) if the file does have such 8.3 filename and
its real name (in cFileName) is longer. Otherwise, cFileName could
already be *THE* short filename because it has the correct format for
it. Check this latter case with RtlIsNameLegalDOS8Dot3() and use it if
so. Otherwise this means the file has a long filename that cannot be
converted to short filename format (because e.g. it is in a volume where
short filenames are unavailable), and we skip such files: they wouldn't
be accessible from DOS anyways.
- Doxygen-document demFileFindFirst(), demFileFindNext() and associated
flags and structures. Update their annotations.
This fixes TurboC 2.x installation.
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.
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)!
With introduction of 74e527b, a330b56 and subsequently 2791ecd ReactOS can now properly set IOPL (I/O privilege level) for user mode trusted processes. With that said, enable the compilation of raise hard error function call code back.
ProcessUserModeIOPL is strictly implemented for 32-bit architecture so it doesn't make any sense for CSRSS to gather user mode I/O privilege when that won't work anyway.
CORE-17545
subsystems/win32/csrsrv/api.c:63:9: warning: variable 'ServerDll' is used uninitialized whenever '||' condition is true [-Wsometimes-uninitialized]
if ((ServerId >= CSR_SERVER_DLL_MAX) ||
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
subsystems/win32/csrsrv/api.c:67:76: note: uninitialized use occurs here
DPRINT1("CSRSS: %lx is invalid ServerDllIndex (%08x)\n", ServerId, ServerDll);
^~~~~~~~~
Addendum to commit 0a392b18.
The actual problem that existed all along was that the buffers being
validated with CsrValidateMessageBuffer() were not the correct ones!
What had to be checked is the string buffer **INSIDE** the UNICODE_STRING
structures! Indeed, it is these buffers that we are allocating on client side,
see https://github.com/reactos/reactos/blob/9b421af1/dll/win32/kernel32/client/dosdev.c#L324-L336
Dedicated to Pierre Schweitzer.
