ReactOS (like any other OSes) expects power data to be represented in milliwatts per hour, not in milliamps per hour.
Currently CMBATT defaults the stats to unknown values, if that's the case, and there are a bunch of machines that do report their data from _BIF ACPI method in ampere.
CORE-18969
CORE-19452
KeWaitForSingleObject takes 100ns unit for timeout. Both IOCTL_BATTERY_QUERY_TAG and IOCTL_BATTERY_QUERY_STATUS take a wait for the timeout in milliseconds.
Supposedly a miniport driver wants to supply a wait of 5000 ms (which is equivalent to 5 s), the miniport driver WON'T BE WAITING 5 seconds but 0.5!!!
CORE-18969
CORE-19452
See https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-rtlqueryregistryvalues
The RTL_REGISTRY_OPTIONAL applies to the first parameter of the
RtlQueryRegistryValues() function, not to the Flags member of the
table entries. However, a RTL_QUERY_REGISTRY_REQUIRED flag exists
to mark values whose existence is NOT optional.
Problematic usage was introduced in the following modules:
drivers/input/i8042prt: Commit e7e959fb0 (r30000)
drivers/input/kbdclass: Commit 5a77f871d (r18911)
drivers/input/mouclass: Commit aeeab7d1f (r18906)
drivers/input/sermouse: Commit 3f348259c (r19100)
rosapps/drivers/green : Commit c8a90f769 (r21165)
Rename the Ext2 recognizer to a more generic Ext to be more future-proof with a possible upcoming ext4 support.
Also, it already makes no sense to use the name ext2 as it already recognizes all the FS of the "Ext family".
In addition, add the Ext Recognizer for CDs.
They were reversed, which meant to immediately complete the IRP
if conditions were NOT satisfied.
Remove a now useless/invalid call to QueryStatus, to return the
status which lead to IRP completion.
During investigation into some of the USB stack issues we've been running into I've found that when a USB storage device is already plugged in during boot and removed before it finishes initialization we run into this assert.
The logic in this function removes the pools made for the following entries in DeviceExtension indiscriminately this makes debugging a bit more difficult. Instead of depending on this behavior of ALWAYS being filled with valid data, let's free the following pools ONLY if they're initialized. This change prevents us from bugchecking when USB flash drives are removed early during boot. This makes the debugging experience a little more sane.
At first QueryStatus call, output is written to Irp->AssociatedIrp.SystemBuffer.
Unfortunately, this is also the BattWait buffer.
At return of QueryStatus call, BattWait buffer has been modified, so
following code can't use it anymore.
Fix memory overwrite by copying BattWait buffer on the stack.
- Reimplement WriteWord using the WriteByte helper.
- Remove inline qualifiers from the bus read and write functions.
This code path is considered "cold" and using an inline for it is overkill.
- Don't apply the IRQL restrictions to our PnP state transition helpers.
They are only called at IRQL below dispatch level.
- Properly handle the case when the dependent function is placed
after fixed resources
- Initialize the version and revision fields of resource lists
- Improve validation of resource data
- Add more debug prints
CORE-18562
CORE-17200
Helps reducing debug log noise like:
```
(drivers\storage\port\scsiport\ioctl.c:542) unknown ioctl code: 0x4D0018
```
The other notifications are already implemented there.
These are handled by the volume manager, which is currently
stubbed into ReactOS' partition manager.
See commit ed27d733f7 for what the deprecated versions
of IOCTL_MOUNTDEV_LINK_[CREATED|DELETED] are all about.
CORE-18139
When a partition is created, PartMgr notifies the volume manager
(FTDisk on Windows <= 2003, VolMgr on Vista+) of its presence.
(Note that currently in ReactOS, our partmgr does the job of both
PartMgr *AND* VolMgr.)
The VolMgr then sends a `GUID_DEVINTERFACE_VOLUME` PnP notification,
which is handled by the mount manager (MountMgr) as part of a
`GUID_DEVICE_INTERFACE_ARRIVAL` notification:
```
MountMgr!MountMgrMountedDeviceNotification -> MountMgrMountedDeviceArrival
followed by
MountMgr!MountMgrTargetDeviceNotification
```
When a partition is deleted, via e.g. Disk Management or DiskPart,
it can be observed, on Windows, that the PartMgr gets notified by
the PnP manager, as part of QueryDeviceRelations. Before actually
removing the partition, it notifies the VolMgr. The latter invalidates
any volume mounted on that partition (`*PartitionRemoved*` functions
for basic volumes), then requests (`*DeleteMountPoints` function)
the MountMgr to delete all the mount points associated to the volume:
```
VolMgr!*DeleteMountPoints
-> MountMgr!MountMgrDeviceControl -> MountMgrDeletePoints
```
**** THIS is the new functionality that is implemented for ReactOS ****
**** in the present commit. ****
Following this, a subsequent PnP notification is sent, which calls
```
MountMgr!MountMgrTargetDeviceNotification
-> MountMgr!MountMgrMountedDeviceRemoval
```
(Note that this observation somewhat invalidates the modification
made in ReactOS commit 62a4f9d42b : our MountMgr placed in Windows
*WOULD* receive a `GUID_TARGET_DEVICE_REMOVE_COMPLETE` target-device
notification...)
Finally, a `GUID_DEVICE_INTERFACE_REMOVAL` PnP notification is sent
to the MountMgr:
```
MountMgr!MountMgrMountedDeviceNotification
-> MountMgr!MountMgrMountedDeviceRemoval
```
1. MountMgrMountedDeviceArrival():
Fix the conditions under which the device's online notifications
are skipped (SkipNotifications == TRUE) and fix the code comments.
Now, things make much more sense:
online notifications are skipped when the device is already offline
or is a legacy (NT <= 4) fault-tolerant volume (see point 2 below),
or is NOT mounted (doesn't have a drive letter).
Previously, we were sending an online notification if the device
was NOT mounted (why?!...) or if it was deemed as "valid" (wrongly
determined, see point 2 below).
2. QueryDeviceInformation():
* The usage of the "Valid" parameter didn't make much sense. Indeed,
when a partition/volume device is reported to the Mount Manager,
it's already valid. (Also, setting "Valid" to TRUE only in the case
of an MBR partition while ignoring GPT ones, and resetting it to
FALSE if IOCTL_STORAGE_GET_DEVICE_NUMBER returned success, pointed
to something incorrect was going on.)
Instead, what we are checking here is whether the device is a
legacy fault-tolerant volume: such volume can only reside on an
MBR disk, have the expected partition type, and does not really
reside on a specific storage device (hence the check for
IOCTL_STORAGE_GET_DEVICE_NUMBER returning failure).
* Take also the opportunity to SAL2-ify the function.
This "NoAutoMount" member was not consistently used. Sometimes it was
used correctly, some other times it was used as "not NoAutoMount" i.e.
"AutoMount" enabled.
Fix this consistently throughout the source, and fix also some comments.
Windows has all its network drivers inf files in 8.3.
This is an addendum to 0.4.15-dev-52-g 019f21ee1d
which moved us further away from our target.
The commit on its own was a good idea actually to get the inf into the drivers directory
and therefore simplifies adding and excluding drivers more locally (e.g. excluding works by
adding a single hashtag within the specific drivers CMakeLists.txt now).
But that cool feature doesn't require us to move away from our target.
For the record:
The historic netrtpnt.inf and netisa.inf (both 8.3) have been merged to
netne2000.inf (not 8.3) by 0.4.15-dev-2763-g 6924b8ff39
Unification of that was cool too,
but again: 8.3 is superior. Therefore netne.inf for that.
Worst of all: Since the .inf files did contain their filename within a comment also, that means
the historic renaming by the mentioned commit invalidated that comment.
netamd.inf fixed by restoring the ancient filename before 0.4.15-dev-52-g 019f21ee1d
netrtl.inf fixed by restoring the ancient filename before 0.4.15-dev-52-g 019f21ee1d
netne.inf I fixed the comment manually.
This is the network driver which is used for MSVPC 2007.
I spotted it during a WIP-backport-experiment of the driver, when compiling with GCC4.7.2, which warned about it.
GCC8.4.0 unfortunately is blind to that on master head, for unknown reasons. Not good.
MSVC github buildbot is also blind to that on master head, for unknown reasons. Not good.
We later found that at least Clang did also warn about it on master head.
Fix IOCTL_MOUNTDEV_LINK_CREATED, IOCTL_MOUNTDEV_LINK_DELETED,
IOCTL_MOUNTDEV_UNIQUE_ID_CHANGE_NOTIFY, to Win2k3+ compatible definitions.
The previous versions of these IOCTLs (in Win2000 and XP) were defined without any access protection.
This was noticed here:
https://community.osr.com/t/ioctl-mountdev-link-created-definition-changed/29428
CORE-15575
In addition, fix a PartitionId assignment copy-paste error in PartitionCreateDevice().
The returned standard UniqueId has the following format:
- Basic volume on MBR disk: disk Mbr.Signature + partition StartingOffset (length: 0x0C)
- Basic volume on GPT disk: "DMIO:ID:" + Gpt.PartitionGuid (length: 0x18)
- Volume on Basic disk (NT <= 4): 8-byte FTDisk identifier (length: 0x08)
- Volume on Dynamic disk (NT 5+): "DMIO:ID:" + dmio VolumeGuid (length: 0x18)
- Super-floppy (single-partition with StartingOffset == 0),
or Removable media: DiskInterfaceName.
- As fallback, we use the VolumeInterfaceName.
References:
- https://winreg-kb.readthedocs.io/en/latest/sources/system-keys/Mounted-devices.html
- https://stackoverflow.com/a/72787681/21852502
- Manual testing on Windows.
CORE-15575
Detect whether the disk is a "super-floppy", which is the name given
to partitionless disk having no MBR, with the unique partition volume
starting at sector offset zero and spanning the whole disk.
The name comes from the fact that at the partitioning level, the disk
"looks like" a large-capacity floppy disk.
This is typically how external removable (USB, ...) drives are
partitioned by default by Windows.
https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-and-gpt-faq?view=windows-11#superfloppy
The kernel-mode functions IoReadPartitionTable() / IoWritePartitionTable()
report the drive layout of a "super-floppy" disk as follows:
an MBR-style disk containing only one single partition starting at the
beginning of the disk (StartingOffset == 0) without hidden sectors, and
its type being FAT16 non-bootable.
The disk NTFT signature is set to 0x00000001.
----
Additional bug fixes to make the feature work reliably:
- Make PartMgrGetDriveLayout() also update the FDO DiskData's
PartitionStyle and Signature/GPT DiskId for consistency (code moved
from PartMgrRefreshDiskData()).
- In FdoIoctlDiskSetDriveLayout[Ex](), if the disk is "super-floppy",
but the user wants to create more than one partition, fail the call.
(In the Ex call, fail also if the partition style changes.)
warning C4267: 'function': conversion from 'size_t' to 'ULONG', possible loss of data'
The OutputBufferLength member that was temporarily stored in
outBufferLength is already a ULONG, and IssueSyncIoControlRequest()
takes the length as a ULONG. So there is no need to use 'size_t' here.
