Taskmgr used a mixture: Sometimes _countof(), sometimes ARRAYSIZE()
and sometimes it calculated the count plain by sizeof(var)/sizeof(TYPE).
Harmonize everywhere to _countof() as it is the shortest solution.
Fix some formatting sins, like placing comments before else-statement.
Shorten the length of some very long line
intentionally *without introducing additional linebreaks* !
Shorten vertical length of some functions to increase their chance to
fit on the screen without scrolling.
Fix wrong indentation level in TaskManagerWndProc().
*.rc: Remove superfluous and redundant comment in all langs
No functional change intended.
I spotted yet another flip:
translation of IDS_TAB_PFDELTA and IDS_TAB_VMSIZE were flipped.
I spotted that by toggling all columns off entirely
in the View-Options dialog where the columns can be selected
and then added only one column at a time. I did that for all options.
I do recommend translators of other langs to do the same test,
I was shocked about the amount of bugs I spotted for german.
And it is very subtle / easy to miss, if you enable/disable multiple columns
together!
Let's call it a day now!
This is an addendum to 0.4.15-dev-413-g ed7196d964
binary size shrinks slightly although that dlg was unused:
taskmgr.exe RosBEWin2.2.2 GCC8.4.0dbg 715.264 -> 708.608
This fixes several issues:
- add a few missing translations, e.g. ID_PROCESS_PAGE_PROPERTIES & ID_PROCESS_PAGE_OPENFILELOCATION
- IDS_TAB_PEAKMEMUSAGE translation was flipped with IDS_TAB_MEMDELTA
- IDC_MEM_USAGE_FRAME had text truncation, fix that by structurally switching to "Speicher"
- waste less space for the listview headers in the Processes tab so user can display more columns conveniently without the headers unnecessarily being crippled to "..."
- Sync some controls sizes back to en-US in the performance tab
- Translation for ID_VIEW_CPUHISTORY_ONEGRAPHALL and ID_VIEW_CPUHISTORY_ONEGRAPHPERCPU was swapped accidentally
- Strip comment lines in the end, which were outdated anyway
- avoid monsters that not even a german person can read like "Auslagerungsdateiauslastungs-Verlaufsanzeige" which is like "Donaudampfschifffahrtselektrizitätenhauptbetriebswerkbauunterbeamtengesellschaft"
- [EXPLORER] Set maximum balloon width for notification area
- [COMCTL32] Fix balloon tooltip shape
- Limit balloon tooltips from extending past the edges of the monitor, not the edges of the work area.
- Instead of simply repositioning the main rectangle when the balloon is too far towards one edge of the screen,
try flipping the balloon the other way. This is the same behavior as Windows Server 2003.
- Tweak some values used to draw the balloon tooltips to more closely follow the Windows balloon tooltip style.
- Removing trailing whitespace.
- While the new changes are guarded, consider cancelling our Wine sync for common controls.
Our common controls are responsible for many graphical issues and lack of features throughout ReactOS.
CORE-19109
Adds the option to set the address edit box to use the display name or the full path. Also refreshes the window title and edit box in all open explorer windows when changing these settings using the folder options dialog.
## PROPOSED CHANGES ##
- Create a new CabinetStateSettings type that inherits from the CABINETSTATE type. This allows us to add additional cabinet state settings not exposed in the CABINETSTATE type as well as adding a Load() method to easily populate the cabinet state settings.
- Add a global cabinet state settings object. While most settings in browseui are stored independently in each shellbrowser window, cabinet state settings are global and apply to every shellbrowser window. This can be confirmed on Windows Server 2003 and Windows 7.
- When receiving the WM_SETTINGCHANGE window message from the folder options dialog, refresh the title of the window and the text in the address edit box. This is the same behavior as Windows Server 2003 and Windows 7.
Add a DWORD registry value to HKCU\...\Explorer\CabinetState\FullPathAddress to allow users to toggle this setting on or off in our folder options.
CORE-9277
It's simpler and only needs to be included once at the beginning of the
header file. It generates an unique identifier for the file automatically,
so maintainers wouldn't need to choose unique names for the macros.
It will be helpful if any future refactoring takes place.
Signed-off-by: Sarthak Roy <sarthakroy2002@gmail.com>
During an open or create procedure of a registry key, the registry parser grabs
a key control block (KCB) from the parser object and uses its information to do the
necessary work in order to obtain a pointer to the newly created or opened registry key.
However, the registry parsers faces several issues. First, we don't do subkey cache cleaning
information against gathered KCBs so whenever we do a registry parse we end up with KCBs
that have cache inconsistencies. Moreover we don't do any locking of whatever KCB we
are grabing during a parse procedure.
=== PROPOSED CHANGES ===
* Implement CmpComputeHashValue and CmpLookInCache functions. With CmpComputeHashValue we can
compute the convkey hashes of each subkey in the path name of a key so we can lock them
with CmpBuildAndLockKcbArray. CmpLookInCache is a function that searches for the suitable
KCB in the cache. The factors that determine if a KCB is "suitable" are:
-- the currently found KCB in the hash list has the same levels as that of the
given KCB from the parse object;
-- The key names from the computed hash values match with the block name of
the KCB;
-- The currently found KCB is not deleted.
The KCB will be changed if the key path name points to a partial match name in
the cache. The KCB from the parse object will be used if we have a full match
of remaining levels.
* Add missing CMP_LOCK_HASHES_FOR_KCB flags on CmpCreateKeyControlBlock calls
that create KCBs during a parse procedure. Such lock has to be preserved until
we're done with the registry parsing.
* On CmpDoCreateChild, preserve the exclusive lock of the KCB when we are
enlisting the key body.
* On CmpDoCreate, make sure that the passed parent KCB is locked exclusively and
lock the hiver flusher as we don't want the flusher to kick in during a key
creation on the given hive. Cleanup the subkey info when we're creating a key
object. Also implement missing cleanup path codes. Furthermore, avoid key
object creation if the parent KCB is protected with a read-only switch.
* Soft rewrite the CmpDoOpen function, namely how we manage a direct open vs
create KCB on open scenario. When a KCB is found in cache avoid touching
the key node. If the symbolic link has been resolved (aka found) then lock
exclusively the symbolic KCB. Otherwise just give the cached KCB to the caller.
If it were for the caller to request a KCB creation, we must check the passed
KCB from the parser object is locked exclusively, unlike on the case above
the caller doesn't want to create a KCB because there's already one in the cache.
We don't want anybody to touch our KCB while we are still toying with it during
its birth. Furthermore, enlist the key body but mind the kind of lock it's been
used.
* On CmpCreateLinkNode, avoid creating a key object if the parent KCB is protected
with a read-only switch. In addition, add missing hive flusher locks for both
the target hive and its child. Cleanup the subkey information of the KCB when
creating a link node, this ensures our cached KCB data remains consistent.
* Do a direct open on CmpParseKey if no remaining subkey levels have been found
during hash computation and cache lookup, in this case the given KCB is the
block that points to the exact key. This happens when for example someone tried
to call RegOpenKeyExW but submitting NULL to the lpSubKey argument parameter.
CORE-10581
ROSTESTS-198
CmpSecurityMethod is a method used by the Object Manager and called by this
subsystem whenever a security operation has to be done against a key object.
As CmpSecurityMethod is a specific OB construct we should not make any direct
call attempts to CmpSecurityMethod, only OB is responsible for that. This fixes
a deadlock where CmpSecurityMethod acquires a push lock for exclusive access
even though such lock is already acquired by the same calling thread in
CmpDoCreateChild.
This prevents a deadlock in DelistKeyBodyFromKCB when we delete a key
object because of an access check failure during a open procedure of a
registry key, as we are already holding a lock against the target KCB of
the key body.
Whenever a security request is invoked into a key object, such as when requesting
information from its security descriptor, the Object Manager will execute
the CmpSecurityMethod method to do the job.
The problem is that CmpSecurityMethod is not aware if the key control block
of the key body already has a lock acquired which means the function will attempt
to acquire a lock again, leading to a deadlock. This happens if the same
calling thread locks the KCB but it also wants to acquire security information
with ObCheckObjectAccess in CmpDoOpen.
Windows has a hack in CmpSecurityMethod where the passed KCB pointer is ORed
with a bitfield mask to avoid locking in all cases. This is ugly because it negates
every thread to acquire a lock if at least one has it.
The CmpUnLockKcbArray, CmpLockKcbArray and CmpBuildAndLockKcbArray routines
help us to lock KCBs within array so that information remains consistent when
we are doing a cache lookup during a parse procedure of the registry database.
Implement CmpBuildAndLockKcbArray and CmpUnLockKcbArray prototypes, we'll gonna need these
to do the locking/unlocking of KCBs stacked up in an array. In addition implement some CM
constructs specifically for cache lookup implementation (more at documentation remarks).
=== DOCUMENTATION REMARKS ===
CMP_SUBKEY_LEVELS_DEPTH_LIMIT -- This is the limit of up to 32 subkey levels
that the registry can permit. This is used in CmpComputeHashValue to ensure
that we don't compute more than the limit of subkeys we're allowed to.
CMP_KCBS_IN_ARRAY_LIMIT -- This is equal to CMP_SUBKEY_LEVELS_DEPTH_LIMIT
plus the addition by 2. This construct is used as a limit of KCB elements
the array can hold. 2 serves as an additional space for the array (one for
the root object and another one as extra space so we don't blow up the stack
array).
CMP_LOCK_KCB_ARRAY_EXCLUSIVE & CMP_LOCK_KCB_ARRAY_SHARED -- These flags are used exclusively
for CmpBuildAndLockKcbArray and CmpLockKcbArray. Their meaning are obvious.
CM_HASH_CACHE_STACK -- A structure used to store the hashes of KCBs for locking. It is named
"stack" because the way we store the hashes of KCBs is within an auxilliary "outer stack array".
CmpAcquireKcbLockSharedByKey can come in handy for use to lock KCBs by their convkey with a shared lock, specifically we would need this for cache lookup stuff.
- Introduce the concept of "brush width" to the
tools model.
- Enable changing the brush width by Ctrl+Plus/Minus
key combination in TOOL_BRUSH.
- Re-define brush styles.
CORE-19094
- Introduce the concept of pen width (not line width) to the tools model.
- Enable changing pen/line width by Ctrl+Plus/Minus key combination in TOOL_PEN,
TOOL_LINE, TOOL_BEZIER, TOOL_RECT, TOOL_SHAPE, TOO_ELLIPSE, and
TOOL_RRECT tools.
CORE-19094
- Stamp the image of the selection when the user clicks on
the selection while holding down the Ctrl key.
- Draw the image of the selection continuously when the user
starts dragging the selection while holding down the Shift key.
CORE-19094
We do use the birth year 1996 instead of 1998
within our msgina pictures already,
and also within the [SDK] for autogenerated file-info.
Since SHELL32 IDD_ABOUT is used by many applications it makes sense to harmonize with that.
Was done already during 0.4.15-dev for SHELL32, but we have to do it again,
since some recent translation PRs to match the en-US.rc again.
Can be observed on the buildbots:
2023-09-17T14:19:34.2051345Z [10663/14808] Building CXX object drivers\wdm\audio\drivers\CMIDriver\cmicontrol\CMakeFiles\cmicontrol.dir\main.cpp.obj
2023-09-17T14:19:34.2052611Z D:\a\reactos\reactos\src\drivers\wdm\audio\drivers\CMIDriver\cmicontrol\main.cpp(818): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data
