* fix CORE-9141 - adding a change to IDEvent after each pass
If the first index is 0 the first returned ID will be 0x8000, which is fine.
Co-authored-by: Joachim Henze <joachim.henze@reactos.org>
Test 1 - test of creating/canceling 20 timers and comparing the raw number of returned messages - without parent window
Test 2 - test of creating/cancelling 20 timers and comparing the raw number of returned messages - with parent window
Test 3 - test creation/cancellation of 40000 timers - without parent window
Test 4 - test of creation/cancellation of 40000 timers - with parent window
Test 5 - test creation/cancellation of 2 timers and compare their index to see if they differ - without parent window
Covers the case in CORE-9141 (see #7087).
CORE-13525
This greatly helps in reducing code complexity in some areas: code that
previously iterated over all partitions of a given disk, just to find
which ones were partitioned and contained a valid file system, now just
have to iterate over mounted volumes.
See in particular, `lib/utils/osdetect.c` and `lib/fsutil.c` .
- Remove FORMATSTATE "Preformatted" enum value;
- Cleanup osdetect code after introducing Volume support;
- Some simplifications for FormatState.
- Differentiate between 'new' partition and 'new' volume:
* "New" partition: it has been created and added in the cached list,
but not yet actually written into the disk.
* "New" volume: newly-created volume (may be backed by a partition or
not), not yet formatted. May exist on either new, or not new partition,
or elsewhere.
- Cache partition and volume NT device names.
These do not change across repartitioning operations, as long as the
partition or the filesystem volume hasn't been deleted/recreated.
This avoids doing \Device\Harddisk%u\Partition%u sprintf's everytime
we need to retrieve the given partition or volume device name.
When a partition/fileysystem volume is "virtually" created (i.e. in
the partition list, but not yet committed to disk and exposed to the
OS), no device partition number and device name are available yet.
In particular, validate that no manipulation of \Device\HarddiskM\Partition0
(i.e. the whole disk) is being made.
According to our declaration/definition, IoChangeFileObjectFilerContext returns NTSTATUS, not BOOLEAN. Zero return (which was actually checked before) for BOOLEAN means failure, but for NTSTATUS it's success. So it should (and now actually does) free and fail appropriately only in failure case, but not in success, when it shouldn't.
This fixes most of problems with fltmgr.sys driver from Windows XP/Server 2003 and a lot of 3rd party filter drivers which use it from many apps (Avast Free Antivirus all versions, Avira AntiVir Personal 8.2, Dr. Web Security Space 8.0, Kaspersky Antivirus 2012 etc. etc.).
CORE-14157, CORE-14635, CORE-19318
GCC8.4.0dbg warns about:
C:/ros/reactos/base/applications/mspaint/lang/it-IT.rc:267: unrecognized escape sequence
Fix that.
the regression was introduced by
0.4.15-dev-8555-g fbcbbd8768 from (#7248)
360 matches, exactly 12 matches for each language, 30 languages.
This will not shrink the binary, it just shortens some long lines within the rc-sources.
Addendum to commit 32e6eed760 (r63715)
CORE-5982
The function assumed that the directory path name to be created
always starts with a harddisk-partition root device name of the form:
\Device\HarddiskX\PartitionY\
Indeed, it can be (when using the volume manager) of the form:
\Device\HarddiskVolumeN\
and could even have a different format if trying to install ReactOS
on an external removable drive or other weird device.
Since the format of this prefix is not 100% always the same,
a different way to create the sub-directories is needed.
The nested-directory creation algorithm is changed as follows:
Suppose that the directory to be created is:
\Device\HarddiskVolume1\ReactOS\system32\drivers
The function first loops backwards each path component in order
to find the deepest existing sub-directory: it will try to verify
whether each of the following sub-directories exist, successively:
\Device\HarddiskVolume1\ReactOS\system32\drivers
\Device\HarddiskVolume1\ReactOS\system32\
\Device\HarddiskVolume1\ReactOS\
\Device\HarddiskVolume1\
(Notice the trailing path separators kept in this step.)
In principle, this root device FS directory must exist (since the
volume has been formatted previously). Once found, the function will
then create each of the sub-directories in turn:
\Device\HarddiskVolume1\ReactOS
\Device\HarddiskVolume1\ReactOS\system32
\Device\HarddiskVolume1\ReactOS\system32\drivers
----
An alternative to the fix could be to always specify the root device
name in a separate parameter, but this hasn't been pursued here so as
to not modify all the callers of this function.
It was introduced in commit 703eb5e8c9 (r7756) in order to hack around
the "dot"-path added in the reactos.dff generator file by the earlier
commit 3bd689f185 (r7269).
Its aim was to describe the installation directory itself, instead of
one of its sub-directories.
That _invalid_ "dot"-path was removed later by commit 027e2bfa3a (r15423);
however the '\.' hack stayed for quite a while in our code.
The correct way to describe the installation directory itself is to use
instead "\", compatible with Windows' setup, as was originally done in
txtsetup.sif, and fixed in reactos.dff(.in) in commit 97bb83fcd9 (r66604).
ID_HELP_HELPTOPICS & ID_HELP_ABOUT are statusbar helptexts, and they do exist
twice for no good reason since 10+ years. Dedupe that.
Also add a few missing accelerators for it-IT.rc
Also strip the trailing dots for some languages for the statusbar helptexts (5 langs: ja-JP,tr-TR,zh-*)
Vast majority of languages did not have them at all (24 languages).
Also en-US was such a good role-model.
Some had it just for some of those texts, but for others not (e.g. pt-PT). Inconsistent.
All statusbar helptexts are within those exact 3 STRINGTABLEs now.
- POPUP() is used on DBG only.
- SND_ERR() and SND_ASSERT() are wanted even when defined(NDEBUG).
- Add a FIXME as !defined(NDEBUG) code compilation remains broken.
Follow-up of c7a4984 (0.4.15-dev-8414).
A small change before PR #5705 was merged caused a severe downgrade in the snap/unsnap handling. Win key handling should work correctly now.
CORE-19165 CORE-19166
Implement Favorites bar.
JIRA issue: CORE-19686
- Introduce CNSCBand class to commonize
some code of CFavBand and CExplorerBand
classes.
- Implement Favorites bar.
- Fix IBandNavigate and INamespaceProxy
interfaces.
Support for system batteries in ReactOS is really minimal to the point of non-existing. We are detecting the presence of any upcoming battery but since there's lacking in critical code that deals with communication
between PO and the battery class driver as the battery systray icon uses GetSystemPowerStatus to gather battery info which in turn inquires the power manager via NtPowerInformation(SystemBatteryState), we have
to report to the user that the remaining capacity is unknown rather than returning a pseudo capacity value.
Technically this so called "pesudo" value is just a construct denoted as BATTERY_PERCENTAGE_UNKNOWN. Not reporting the actual remaining capacity makes sense, as there could be a scenario where the battery may not
properly report its real datum, therefore it's best to be honest to the user what's really going on.
CORE-19452
CORE-18969
