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.
