- Do not access uninitialized SymlinkInformation on failure case
and just return
- Do not make an assumption that MOUNTMGR_TARGET_NAME has a zero-string
From MSDN:
It is an error to call KeReleaseSpinLockFromDpcLevel if the specified spin lock was acquired by calling KeAcquireSpinLock because the caller's original IRQL is not restored, which can cause deadlocks or fatal page faults.
- Use PnP storage class drivers
- Make partmgr an upper filter driver for Disk class
- Fill upper filters in txtsetup and usetup/devinst
- Add cdrom driver to the critical device database
CORE-6264
- Pass all SRB flags which Windows scsiport passes
- Correctly reset the queue after completion
This fixes the bug when MS cdrom driver hangs after media ejection
Basic functions are implemented in order to work in PnP stack,
only legacy (non-pnp) miniport drivers are supported.
Tested mostly with uniata
CORE-17132
This driver works as complement to disk.sys/classpnp.sys from Windows 10
Manages partition PDOs and exposes them as volumes to mountmgr.sys.
The driver is almost complete, just some minor IOCTLs missing (will be
added on demand)
- ReparseFile was concatenated with itself, instead of ReparseIndex
- Meanwhile, use RtlAppendUnicodeStringToString for concatenating
strings instead of raw memory operations
- Change INIT_FUNCTION and INIT_SECTION to CODE_SEG("INIT") and DATA_SEG("INIT") respectively
- Remove INIT_FUNCTION from function prototypes
- Remove alloc_text pragma calls as they are not needed anymore
Instead of messing with global variables and the like, we introduce two target properties:
- WITH_CXX_EXCEPTIONS: if you want to use C++ exceptions
- WITH_CXX_RTTI: if you need RTTI in your module
You can use the newly introduced set_target_cpp_properties function, with WITH_EXCEPTIONS and WITH_RTTI arguments
We also introduce two libraries :
- cpprt: for C++ runtime routines
- cppstl: for the C++ standard template library
NB: On GCC, this requires to create imported libraries with the related built-in libraries:libsupc++, limingwex, libstdc++
Finally, we manage the relevant flags with the ad-hoc generator expressions
So, if you don't need exceptions, nor RTTI, nor use any runtime at all: you simply have nothing else to do than add your C++ file to your module
The source code is licensed under MS-PL license, taken from Windows Driver Samples
repository (microsoft/Windows-driver-samples@master/storage/class/cdrom/)
Synched with commit 96eb96dfb613e4c745db6bd1f53a92fe7e2290fc
The driver is written for Windows 10 and uses KMDF so we compile it with ntoskrnl_vista
and wdf01000 statically linked (for wdf01000 this will likely be changed in future)
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/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
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.
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
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.
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.
There is no need to compile our DLLs as shared libraries since we are
managing symbols exports and imports through spec files.
On my system, this reduces the configure-time by a factor of two.
This is needed in order to avoid an infinite recursive loop between
disk!UpdateRemovableGeometry() and ntos!IoReadPartitionTable().
This does not happen with NT5+ disk_new.sys because it doesn't call
IoReadPartitionTable() in that situation.
Do not enable it yet, as it doesn't work in ROS for the moment :-(.
Its place in tree is not optimal (it should be with disk/class/etc.),
but I prefer keeping it close to actual driver for now.
All the work has been done so that it compiles and links with ReactOS
SDK though.
- Implement AcquireSpinlock, ReleaseSpinlock and GetExtendedFunctionTable notifications.
- Implement a bus scan routine, borrowed from scsiport.
Storport and storahci are now able to detect a disk device attached to a Virtual Box AHCI controller.
In spite of what was implemented in our NT DDK sample, this is a legit operation.
This may have been turned legit starting NT5 (reminder, our implementation is
NT4 based...). So, in this situation, just return the information about the whole
disk (and not a random size) and also, mark everything with default values.
See disk_new for an example of how it works in NT5+.
CORE-14124
