Replace call to AllocatedBufferSize(), with BufferSize().
Indeed (quoting https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/portcls/nf-portcls-idmachannel-buffersize ):
> The BufferSize() method returns the buffer size that was set by the previous call to IDmaChannel::SetBufferSize(). If SetBufferSize() has not been called since the IDmaChannel::AllocateBuffer() call, BufferSize returns the allocated buffer size. The DMA-channel object does not actually use this value internally. This value is maintained by the object to **allow its various clients to communicate the intended size of the buffer**.
And this is exactly what we want to do.
The source code is licensed under MS-PL license, taken from Windows Driver Samples
repository (https://github.com/microsoft/Windows-driver-samples/tree/master/storage/class/disk/)
Synched with commit 3428c5feaac7c1a5e2a09db0ed93392f7568f9e6
The driver is written for Windows 8+, so we compile it with ntoskrnl_vista
statically linked and with NTDDI_WIN8 defined
CORE-17129
The source code is licensed under MS-PL license, taken from Windows Driver Samples
repository (https://github.com/microsoft/Windows-driver-samples/tree/master/storage/class/classpnp/)
Synched with commit 88541f70c4273ecd30c8c7c72135bc038a00fd88
The driver is written for Windows 8+, so we compile it with ntoskrnl_vista
statically linked and with NTDDI_WIN8 defined
CORE-17129
'...\write.c(38): error C2373: 'RfsdFloppyFlush': redefinition; different type modifiers'
'...\write.c(45): error C2373: 'RfsdFloppyFlushDpc': redefinition; different type modifiers'
It started to spam when more components of the MountMgr
were coded during 0.4.14dev.
According to Victor Perevertkin it is not crucial for us
to see it, as those are 'optional MountMgr features'.
Imho this points towards unimplemented stuff.
No official ros release has been affected, because I did
revert most of the new MountMgr features for 0.4.14release
earlier.
Some places have been changed to return FILE_DOES_NOT_EXIST, everything
else just returns 0. FastFAT driver from MS does the same (tm),
so I'm not going to have a big research here.
CORE-16623
Co-authored-by: Suraj K Suresh <kssuraj15@gmail.com>
We must not do anything on PDO removal, especially not deleting it.
We are allowed to delete it, only once we successfully completed a IRP_MN_QUERY_DEVICE_RELATIONS without with PDO.
JIRA-user "Illen" reported booting from his Z170 controller worked up to
0.4.12-dev-936-g89aaf0e
and would refuse booting - beginning with uniata commit
0.4.12-dev-937-g
b546130731
For sure this workaround is just a temporary and no proper solution,
but was confirmed to be working by "Illen".
We have no clear understanding of the real bug yet.
Can be replaced by something better at any time.
It was already committed into 0.4.12, 0.4.13, 0.4.14.
We never had an affected release therefore.
Since no one took care of this bug ever,
the workaround will now be committed to master as well.
cherry picked from commit 0.4.13-RC-9-g
11178f38e4
- Add boot video color constants
- Refactor palette initialization
- Move some common stuff in right place
- Get rid of some magic constants and hardcoded values
- Get rid of TopDelta variable (calculated at compile time)
- Update SAL annotations
Addendum to 5f2ca473. CORE-16216 CORE-16219
According to PC-9801 Bible p. 50, divisor for PIT will become unsupported in some cases after having removed the fractional part. Replace 19200 value with 9600 which is supported by both 10 MHz and 8 MHz machines.
When gdb receives a fault, it converts it to "signal", and send "C"
command to server to transfer the signal it couldn't handle.
On ReactOS (and Windows ?) side, we tell KD API that we continue with an
error code, so the exception handler can be called.
This is useful when playing with gflags, especially +soe, with KDGDB.
In ACPI resource descriptors, alternatives are marked with
StartDependent tags. Only the last set is terminated with EndDependent.
Therefore, since we only return the first alternative list for now,
ignore the first StartDependent tag and terminate enumeration at the second.
In the future we will need to build the full set of alternative lists here,
which will also make the unit test succeed fully.
This should fix random resource conflicts and make COM ports usable.
IoCreateDevice() was called too early, when a spinlock was acquired.
Create ISAPNP_LOGICAL_DEVICE structure when a device is detected, and call IoCreateDevice() later, when required.
The DbgBreakPoint() was reported to be continuable without
obvious side-effects by Doug Lyons.
Thank you for your tests Doug.
To prevent what end-users may otherwise perceive as a
freeze-regression caused by enabling the new driver in
0.4.13-dev-1048-g
6392c5a78c
Also convert all sizes and positions of CONSOLE_DRAW to USHORT since
this is the standard type for all console buffer positions & sizes
(minimum value 0, maximum value 0xFFFF == 65535).
Addendum fixes to ca370b49 (r52239) and a965ca6b (r52409).
- Fix the comments to explain what is really happening.
- Fix the boundary calculations in VidDisplayString() so that we can
correctly display a character in the very last column before going
to the next line, and fix similarly the vertical boundary calculation.
- Port the fixes to the ARM code.
CORE-15901
This fixes display reset transition when an external module acquired
INBV ownership and then released it, similarly to what was done in
commit 0ad65796 for VIDEOPRT.
For this a backup screenbuffer is used to store the contents of the
screen just before an INBV screen acquire transition, and these contents
are restored when it is detected that INBV ownership has been released.
Also, the active text font associated with the active console code-page
is restored, as well as the cursor state and shape.
In addition, any user of BLUE.SYS is now required to explicitly issue
a new IOCTL_CONSOLE_RESET_SCREEN to either enable or disable the screen.
This allows avoiding nasty unwanted screen mode switches when a handle
to the \Device\BlueScreen device is opened but no screen mode switch was
actually wanted - This "fixes" this annoyance on ReactOS and Windows,
when these are running witha VGA-compatible video driver and one wants
to look at properties of the \Device\BlueScreen device using
Sysinternals' WinObj.
Following this, we don't need to check anymore for explicit INBV
ownership by issuing calls to InbvCheckDisplayOwnership(), but instead
we check whether the screen has beeen manually enabled using the
aforementioned IOCTL. This partly supersedes commit 8b553a4b, and allows
fixing the second bug, namely that if we start ReactOS without the
/NOGUIBOOT option (and thus, INBV is active during boot), USETUP would
not show up anything because BLUE.SYS wouldn't display anything on screen.
See CORE-15901.
[USETUP][CONSRV] Call IOCTL_CONSOLE_RESET_SCREEN to tell BlueScreen device to enable the screen.
This involves many changes/fixes in the floppy driver:
- Stop creating ourselves our DOS device, it's up to the MountMgr or to the kernel;
- Report each new floppy drive to the MountMgr (this is a hack for now);
- As a consequence, stop storing the symlink name into the DRIVE_INFO structure;
- Store the device name instead;
- On IOCTL_MOUNTDEV_QUERY_DEVICE_NAME, don't return DOS device, but device name;
- On IOCTL_MOUNTDEV_QUERY_DEVICE_NAME, properly return if buffer is way too small;
- Hackplement IOCTL_MOUNTDEV_QUERY_UNIQUE_ID so that it returns device name.
This fixes shutting down ReactOS under certain circumstances, where
the references were incremented, but no worker thread started.
Also, took the opportunity to clarify the WorkerReferences comparisons
where relevant.
CORE-16446
Because our disk.sys doesn't do anything related to PnP
(compared to disk_new.sys), forcibly declare our partitions
to the MountMgr so that it can references them and assign
them a DOS drive letter on demand later on.
This is required so that MountMgr can handle devices that are still
using class2 instead of classpnp.
Given we have no unique ID to return, we'll return device path, which
is far from perfect but which is enough for now to have everything
working.
This fixes memory smashing while attempting to volume
reparse index (we were previously trying to copy the
name on itself, in the middle of itself...).
This code won't go farther on FAT, it requires NTFS.
Now, with this, ReactOS can properly boot with MountMgr
handling DOS devices without any crash or code disabled.
Cf: what was written in 7608ac9.
Modifications in class2, disk, and ntoskrnl are still to
be committed to enable all this.
- Properly quit the active loop when we're out of work items;
- Fix timeout duration (setting it to 1s);
- Fix handling the "Unloading" variable in case of a shutdown
so that waiting loop is properly stopped;
- Documented why we're waiting on VolumesSafeForWriteAccess.
This fixes shutting down ReactOS with work items queued.
This is needed here because no one ever sets that event (properly)
created by SMSS though. A. Ionescu was explaining in 2018 that it's
autochk responsibility, but it doesn't seem to be the case in W2K3.
To be investigated.
This fix with all the previous ones and more uncommitted stuff (yet ;-))
allows reaching the first steps towards a NT5 storage stack:
https://twitter.com/HeisSpiter/status/1186199631740506112
On preflight to compute output size, device name & unique ID were
counted only once per device.
Then, on copy, these two were copied on every MOUNTMGR_MOUNT_POINT
structure. This is counter efficient (data duplication) but also,
it was overruning the output buffer, since the preflight was not
expecting these extra copies.
This is purely a copypasta error fix, which was causing MountMgrNextDriveLetterWorker
to fail as no drive letters were enumerated previously.
With that set of patches, MountMgr now properly assigns drive letters to
new devices!
Being TRUE doesn't mean the device is GPT and has a drive letter. It just
means that it's not a GPT device with GPT_BASIC_DATA_ATTRIBUTE_NO_DRIVE_LETTER
attribute. In short, if TRUE, it means that the device can receive a drive
letter mount point.
This fixes MountMgrNextDriveLetterWorker bailing out for any attempt to
assign a drive letter to a device.
We must query the target device, and not the symbolic link
we attempt to create. The later will always fail as it doesn't
exist yet.
This fixes MountMgrCreatePointWorker not working.
This fixes returning too small structure on an IOCTL_MOUNTMGR_QUERY_POINTS call.
The multiple MOUNTMGR_MOUNT_POINT structures were ignored and thus the data of the
first one were erased by the multiple structures.
MountMgr now returns consistent output on this IOCTL call.
