...but wait until the partitions are actually updated on disk.
CORE-13525
DeletePartition() deletes partitions only in the virtual partitions list
in memory; the partitions still exist on the disk and are written only
later when committing all partition changes.
Thus, we do the same for file system volumes that lay on top of these
partitions being deleted: we move the linked VOLENTRY structures to a
list of "pending volumes to unmount", while they still actually stay
mounted on the system. Only when partition changes are about to be
committed to disk, the "pending volumes to unmount" list is processed
and the volumes actually unmounted, prior to modifying the partitions.
Someone familiar with this should do a more proper fix.
C:/ReactOS/reactos/sdk/lib/atl/atlcom.h: In instantiation of 'class ATL::CComObject<CRShellClassFactory>':
C:/ReactOS/reactos/sdk/include/reactos/shellutils.h:357:45: required from 'HRESULT ShellObjectCreatorInit(T1, const IID&, void**) [with T = CRShellClassFactory; T1 = _GUID; HRESULT = long int; IID = _GUID]'
C:/ReactOS/reactos/base/shell/rshell/misc.cpp:256:55: required from here
C:/ReactOS/reactos/base/shell/rshell/misc.cpp:210:28: error: 'virtual HRESULT CRShellClassFactory::CreateInstance(LPUNKNOWN, const IID&, void**)' was hidden [-Werror=overloaded-virtual=]
210 | virtual HRESULT WINAPI CreateInstance(LPUNKNOWN pUnkOuter, REFIID riid, LPVOID *ppvObject)
| ^~~~~~~~~~~~~~
In file included from C:/ReactOS/reactos/base/shell/rshell/misc.cpp:33:
C:/ReactOS/reactos/sdk/lib/atl/atlcom.h:171:27: note: by 'static HRESULT ATL::CComObject<Base>::CreateInstance(ATL::CComObject<Base>**) [with Base = CRShellClassFactory; HRESULT = long int]'
171 | static HRESULT WINAPI CreateInstance(CComObject<Base> **pp)
| ^~~~~~~~~~~~~~
While our glob is a dummy anyway and always returns NULL, the basic idea is that glob returns a NULL terminated array of pointers. The original code only calls blkfree to free any allocation in the array after the first one and doesn't free the array itself. Our code tried to be "smart" and free the array as well, but the array pointer was already changed by a "globbed++", resulting in trying to free an invalid address. Also the free was only called, when glob returned more than one result. This is now fixed by removing the "++", doing the blkfree on "&globbed[1]" and calling free on the originally returned array in all cases.
Fixes GCC 13 warning:
C:/ReactOS/reactos/base/applications/network/ftp/cmds.c: In function 'globulize':
C:/ReactOS/reactos/base/applications/network/ftp/cmds.c:1684:25: error: 'free' called on pointer 'globbed' with nonzero offset 4 [-Werror=free-nonheap-object]
1684 | free((char *)globbed);
| ^~~~~~~~~~~~~~~~~~~~~
C:/ReactOS/reactos/base/applications/network/ftp/cmds.c:1669:19: note: returned from 'glob'
1669 | globbed = glob(*cpp);
| ^~~~~~~~~~
In our port glob is a dummy that always returns NULL, and the original code does not have a free here, either.
C:/ReactOS/reactos/base/shell/cmd/del.c: In function 'ProcessDirectory':
C:/ReactOS/reactos/base/shell/cmd/del.c:333:17: error: this 'if' clause does not guard... [-Werror=misleading-indentation]
333 | if (!(f.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) ||
| ^~
In file included from C:/ReactOS/reactos/base/shell/cmd/precomp.h:14,
from C:/ReactOS/reactos/base/shell/cmd/del.c:48:
C:/ReactOS/reactos/sdk/include/crt/tchar.h:246:17: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'if'
246 | #define _tcscpy wcscpy
| ^~~~~~
C:/ReactOS/reactos/base/shell/cmd/del.c:338:21: note: in expansion of macro '_tcscpy'
338 | _tcscpy(pFilePart, f.cFileName);
| ^~~~~~~
GCC 13 doesn't like if you keep a dangling pointer around.
C:/ReactOS/reactos/base/shell/cmd/for.c: In function 'ForF':
C:/ReactOS/reactos/base/shell/cmd/for.c:307:20: error: storing the address of local variable 'Variables' in '*fc.values' [-Werror=dangling-pointer=]
307 | fc->values = Variables;
| ~~~~~~~~~~~^~~~~~~~~~~
C:/ReactOS/reactos/base/shell/cmd/for.c:141:12: note: 'Variables' declared here
141 | LPTSTR Variables[32];
| ^~~~~~~~~
C:/ReactOS/reactos/base/shell/cmd/for.c:57:14: note: 'fc' declared here
57 | PFOR_CONTEXT fc = NULL;
| ^~
Make the code simpler, so GCC doesn't get confused.
C:/ReactOS/reactos/base/shell/cmd/misc.c: In function 'add_entry':
C:/ReactOS/reactos/base/shell/cmd/misc.c:216:14: error: pointer 'oldarg' may be used after 'realloc' [-Werror=use-after-free]
216 | *arg = oldarg;
| ~~~~~^~~~~~~~
In file included from C:/ReactOS/reactos/base/shell/cmd/cmd.h:29,
from C:/ReactOS/reactos/base/shell/cmd/precomp.h:34,
from C:/ReactOS/reactos/base/shell/cmd/misc.c:35:
C:/ReactOS/reactos/base/shell/cmd/cmddbg.h:30:31: note: call to 'realloc' here
30 | #define cmd_realloc(ptr,size) realloc(ptr, size)
| ^~~~~~~~~~~~~~~~~~
C:/ReactOS/reactos/base/shell/cmd/misc.c:212:12: note: in expansion of macro 'cmd_realloc'
212 | *arg = cmd_realloc (oldarg, (*ac + 2) * sizeof (LPTSTR));
| ^~~~~~~~~~~
Don't strncpy 0 bytes. Also add an assert that source and dest are not the same.
C:/ReactOS/reactos/base/applications/network/nslookup/utility.c: In function 'ReverseIP':
C:/ReactOS/reactos/base/applications/network/nslookup/utility.c:264:5: error: 'strncpy' destination unchanged after copying no bytes [-Werror=stringop-truncation]
264 | strncpy( &pReturn[k], &pIP[i + 1], (j - i) );
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Instead give IMAGE_PART a complete default contructor. Fixes GCC 13 warning.
In file included from C:/ReactOS/reactos/sdk/include/psdk/minwindef.h:171,
from C:/ReactOS/reactos/sdk/include/psdk/windef.h:17,
from C:/ReactOS/reactos/base/applications/mspaint/precomp.h:17,
from C:/ReactOS/reactos/base/applications/mspaint/history.cpp:9:
C:/ReactOS/reactos/base/applications/mspaint/history.cpp: In constructor 'ImageModel::ImageModel()':
C:/ReactOS/build-gcc-x86/sdk/include/psdk/winnt.h:8732:47: error: 'void* memset(void*, int, size_t)' clearing an object of non-trivial type 'struct IMAGE_PART'; use assignment or value-initialization instead [-Werror=class-memaccess]
8732 | #define RtlFillMemory(Dest,Length,Fill) memset((Dest),(Fill),(Length))
| ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
C:/ReactOS/build-gcc-x86/sdk/include/psdk/winnt.h:8733:36: note: in expansion of macro 'RtlFillMemory'
8733 | #define RtlZeroMemory(Dest,Length) RtlFillMemory((Dest),(Length),0)
| ^~~~~~~~~~~~~
C:/ReactOS/reactos/sdk/include/psdk/minwinbase.h:31:20: note: in expansion of macro 'RtlZeroMemory'
31 | #define ZeroMemory RtlZeroMemory
| ^~~~~~~~~~~~~
C:/ReactOS/reactos/base/applications/mspaint/history.cpp:41:5: note: in expansion of macro 'ZeroMemory'
41 | ZeroMemory(m_historyItems, sizeof(m_historyItems));
| ^~~~~~~~~~
C:/ReactOS/reactos/base/services/dhcpcsvc/dhcp/adapter.c: In function 'AdapterDiscoveryThread':
C:/ReactOS/reactos/base/services/dhcpcsvc/dhcp/adapter.c:326:28: error: 'AdapterFindByHardwareAddress' accessing 16 bytes in a region of size 8 [-Werror=stringop-overflow=]
326 | if ((Adapter = AdapterFindByHardwareAddress(Table->table[i].bPhysAddr, Table->table[i].dwPhysAddrLen)))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:/ReactOS/reactos/base/services/dhcpcsvc/dhcp/adapter.c:326:28: note: referencing argument 1 of type 'u_int8_t[16]' {aka 'unsigned char[16]'}
C:/ReactOS/reactos/base/services/dhcpcsvc/dhcp/adapter.c:544:15: note: in a call to function 'AdapterFindByHardwareAddress'
544 | PDHCP_ADAPTER AdapterFindByHardwareAddress( u_int8_t haddr[16], u_int8_t hlen ) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
Follow-up of #8678. Commonize the definition of
LANGID_... values.
JIRA issue: CORE-20243
- Define LANGID_... values for CJK in <cjkcode.h> and
use it.
Prepare for Console IME Input for East Asian.
JIRA issue: CORE-20243
- Modify .github/labeler.yml.
- Add base/system/conime/ .
- Modify boot/bootdata/hivesft.inf for Console
settings.
- Add imm32!ImmCallImeConsoleIME prototype
into <imm32_undoc.h>.
- Add IMS_CONSOLEIME_1A and IMS_CONSOLEIME_1B
values into <imm32_undoc.h>, for WM_IME_SYSTEM
message.
CORE-20279
PRELIMINARY REMARK: The described bug and code workaround only applies
for x86 32-bit builds.
----
While the Winlogon notification handlers[^1] actually use a `STDCALL`
calling convention, which can be trivially verified by debugging the
official Windows <= 2003 winlogon.exe and its notification extensions,
there exist 3rd-party Winlogon notification DLLs, like the `Ati2evxx.dll`
one from AMD/ATI XP video drivers, that use a `CDECL` calling convention,
or an invalid number (zero) of parameters.
I think the reason why this happens is as follows.
The official documentation[^1] indicates that the handlers have the
following prototype:
```c
void Event_Handler_Function_Name(
_In_ PWLX_NOTIFICATION_INFO pInfo
);
```
The documentation (and possibly the internal header Windows is using for
Winlogon) is sloppy, because it doesn't tell whether the convention is
`STDCALL` or `CDECL`. When compiling routines with such a signature, the
compiler will employ whatever default convention it is set to use.
Windows code is typically compiled with `STDCALL` convention as the default
(see e.g. how the Windows Development Kit is set up), thus, such a
function signature would default to `STDCALL`. Observation (with debugger)
shows that it is what Windows' winlogon.exe is indeed expecting.
However, 3rd-party code using a different development environment, could
set the compiler to use `CDECL` as the default calling convention. As a
result, the function signature from above would use `CDECL` instead.
The difference between the `STDCALL` and `CDECL` conventions is how the
function parameters are passed on the stack and how the stack is cleaned
at the end (`STDCALL`: the function unwinds the stack; `CDECL`: the caller
does it). A calling convention mismatch would therefore corrupt the stack,
and this is exactly what happens with the `Ati2evxx.dll` from the AMD/ATI
drivers, see CORE-20279.
The ReactOS Winlogon crashes from the `_RTC_Failure()` handler just after
the 3rd-party handler returns, since we compile our code with runtime checks
enabled. Windows' winlogon.exe doesn't apparently crash, because neither
in Release nor in Checked/Debug mode did they compile winlogon.exe with
RTC enabled. However, its stack would become more corrupt with time.
In order to alleviate this in ReactOS' winlogon.exe, I decided to use
a "generic" workaround, manually calling the handler with inline ASM
(which is OK since the problem and solution is x86-specific only).
It does something similar to what the RTC support does: it checks the
stack pointer after the call and restores it if needed.
An informative message is then emitted in the debugger telling which DLL
is buggy and needs to be fixed.
[^1]: https://learn.microsoft.com/en-us/windows/win32/secauthn/event-handler-function-prototype
Tray popup window that shows master volume and mute was not updated in real
time if something outside it adjusted master volume or line mute. Now it does.
- Handle `MM_MIXM_CONTROL_CHANGE` window message in `sndvol32.exe!TrayDlgProc`
CORE-12632
- [MSCONFIG] Update Traditional Chinese (zh-TW) translation
- [MSCONFIG_NEW] Update Traditional Chinese (zh-TW) translation
- [MSPAINT] Update Traditional Chinese (zh-TW) translation
- [NOTEPAD] Update Traditional Chinese (zh-TW) translation
- [RAPPS] Update Traditional Chinese (zh-TW) translation
- [SETUP:REACTOS] Update Traditional Chinese (zh-TW) translation
- [CPL:ACCESS] Update Traditional Chinese (zh-TW) translation
- [CPL:APPWIZ] Update Traditional Chinese (zh-TW) translation
Take into account documentation updates in b380d23d6f.
Hermès Bélusca-Maïto