Its purpose is to offer an out-of-the-box generic framebuffer video
(a video miniport driver for win32k will be introduced in a future PR)
to ease ReactOS porting to other possibly non-PC-compatible systems,
where no VGA-compatible video is present and only linear framebuffers
are available; for example: XBOX, UEFI with GOP only, AppleTV, etc.
Of course, once ReactOS is ported, one can then (and should) write,
or use existing video drivers tailored to the system of interest.
Together with our FreeLoader, this driver could also be employed for
of porting/modding Windows 2000/XP/2003 attempts to other platforms,
as this has been done by external contributors.
Current limitations:
- Only supports 32 bits-per-pixel ARGB format. This limitation will be
removed in subsequent PR(s).
- May be slow during rendering (region color filling and scrolling);
I will try to improve this as time goes.
This driver's code is loosely based upon preliminary code by Justin Miller
and on the existing XBOX bootvid implementation.
Tested by Justin Miller (@TheDarkFire) for UEFI, and by Sylas Hollander
(@DistroHopper39B) with his AppleTV port.
It has also been tested with VESA linear modes on PC by myself.
Stop pointless target_sources(xxx PRIVATE $<TARGET_OBJECTS:gcc_ssp_nt>). The only effect it has is to force the object file into the target, which was already done by specifying the libraries as OBJECT libraries, which is also pointless, and only leads to problems.
Use `PCSTR` for the type of the (Hal,Inbv,Vid)DisplayString() routines'
`String` parameter, instead of `PCHAR` or `PUCHAR`, since it points to a
NUL-terminated string. (The buffer isn't a counted string.)
And improve SAL annotations along the way.
This makes the code more readable than using e.g. `VidpScrollRegion[0]`,
`VidpScrollRegion[1]` etc. instead of `VidpScrollRegion.Left`,
`VidpScrollRegion.Top` respectively.
Based on a suggestion by Dmitry Borisov.
In addition:
- move back common function prototypes to precomp.h;
- const-ify `VidpFontData` and adjust its usages;
- improve SAL annotations for `InitPaletteWithTable()`;
- rename the (Vid)ResetDisplay() parameter to "SetMode".
These drivers expect PC/AT compatible hardware thus they are unsuitable for PC-98.
Disable the drivers for the time being until we have a proper implementation.
CORE-17977
Fix two similar warnings, that were treated as errors:
- warning C4146: unary minus operator applied to unsigned type, result still unsigned
Addendum to fa1ec0a2ed. CORE-16216 CORE-16219
This patch adds the NETIO.SYS driver to ReactOS. NETIO.SYS
is part of Windows since NT6 (Vista).
The driver is not feature complete (meaning some functionality is
unimplemented) but does its job quite good for what it originally
was written for (which is getting WinDRBD working on
ReactOS/Windows Server 2003 SP2).
The driver re-uses parts of the AFD.SYS driver, namely those
functions that ease communitating with the transport device
interface (TDI). Other than that, following features are implemented
and should work:
* TCP/IP networking: connect, listen, accept, read, write
* UDP/IP networking: write
So in a nutshell TCP/IP support is completed, UDP support is
partially complete and ICMP support does not exist yet.
In particular the listen/accept mechanism allows one to write
kernel side TCP servers that one can connect to via the internet.
The netio driver is licensed under the MIT license, see the file
netio.c for more details.
Have fun with it :)
Signed-off-by: Johannes Khoshnazar-Thoma <[email protected]>
We want to use the TDI helper functions also in the NETIO.SYS
driver which comes with the next commit. The code was modernized
a bit (usage of DPRINT, doxygen style comments) but other than
that it was left unchanged.
* [PCIX] Fix the weird text corruption in PciGetDescriptionMessage
* [PCIX] Return the buffer to the caller PciQueryBusInformation
Co-authored-by: Stanislav Motylkov <[email protected]>
[SDK][WDFLDR] Add kmdf loader driver
[SDK][WDF] Add kmdf drver init static library
[SDK][WDF] Modify kmdf driver for working with wdfldr driver
[SDK][CDROM] Cdrom driver dynamically linking with kmdf
[SDK][WDF] Add kmdfdriver module type
[SDK][WDF][USBDEX][NTOSKRNL_VISTA] Fully enable KMDF
[KMDF][WDFLDR][WDF01000] Fix Windows 10 Compatibility WDFLDR and WDF01000
[WDF01000] NO_KERNEL_LIST_ENTRY_CHECKS for wdf01000 3rd party code
This PR is an accumulation of three peoples work, with the goal of the trying to get WDF to work like it should.
This has been tested in combination with some extra NT6+ ntoskrnl against multiple drivers.
---------
Co-authored-by: Max Korostil <[email protected]>
Co-authored-by: Victor Perevertkin <[email protected]>
Co-authored-by: Adam Słaboń <[email protected]>
Co-authored-by: Hermès BÉLUSCA - MAÏTO <[email protected]>
CORE-20300
- `NdisRegisterProtocol()`: Add a comment about `NDIS51`: the
`NDIS50_PROTOCOL_CHARACTERISTICS` structure is common to both
NDIS 5.0 and 5.1.
This is in contrast to the `NDIS50/NDIS51_MINIPORT_CHARACTERISTICS`
structures, see for example commit 3e169e3cb2 (r49961).
- Remove obsolete SOURCES file. Addendum to commit d9e83ed22d (r40142).
CORE-20343
The 3-second timeout FIXME (instead of waiting indefinitely), made in the
COMPBATT worker thread for the `IOCTL_BATTERY_QUERY_STATUS` case, was done
because _*our*_ BATTC handler expects the batteries to always support the
BTP (Battery Trip Point) feature for signaling a change of battery status,
but in the cases where it isn't supported, any waits it tried for the
battery to notify about a status change would never happen.
Furthermore, following commit 3a6e0d4b65, the `SetStatusNotify()` call
(_which always fails if the battery doesn't support the BTP feature_)
would now always exit the `IOCTL_BATTERY_QUERY_STATUS` handling without
any waiting nor battery polling [^1], and this would cause the COMPBATT
worker thread to busy-poll again forever.
The timeout FIXME is now moved to BATTC, instead of COMPBATT, since the
actual fixes should be in BATTC. In particular, it should queue all the
query IOCTLs and then serve them, either using the StatusNotify (BTP)
functionality if the battery supports it, or if not, do a very-slow
battery polling.
I've also increased the timeout a little bit more (5 seconds and not 3).
[^1]: Per the ACPI specification, it is expected that the operating system
performs battery polling if the battery doesn't support BTP, see:
https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/10_Power_Source_and_Power_Meter_Devices/Power_Source_and_Power_Meter_Devices.html#btp-battery-trip-point
Previously the function waited for the conditions *after* querying the status, and then returned the old status. Also, if querying failed, it waited and when the wait timed out it returned STATUS_SUCCESS without returning any data. If the call to SetStatusNotify failed and there was no timeout, it would wait forever.
This is all fixed now.
- Let it be `"NDIS"`, instead of variations of `"SIMN"`.
- Use matching `ExFreePoolWithTag()`.
- Remove a redundant `KeyInformation = NULL;`.
Addendum to commits e8861acfb2 (r12196) and 5658b2154c (r53045).
CORE-18791
- Remove unused idedma.def
Addendum to commit 1daf74908e (r29256).
- Convert a few files to UTF-8 from ANSI
Plus, 2 tiny formatting fixes.
- id_ata.cpp: Unmark a ReactOS own diff
Addendum to commit 7fdf078134.
- id_init.cpp: Mark a diff
Addendum to commit 09dde2cff9.
- Upgrade to v0.47b from v0.47a
CORE-17876
Split Windows Server 2003 and Windows Vista behaviour in two different cases and make them used separately: when ReactOS target version is NT 5.2, use the 1st case, otherwise use the 2nd one instead.
Also, handle NdisPhysicalMediumNative802_11 case only for NT 6.0 and newer, since that's actually supported starting from NDIS 6.0, according to MSDN:
https://learn.microsoft.com/en-us/windows-hardware/drivers/network/oid-gen-physical-medium
while for NDIS 5.1 and newer it's:
https://learn.microsoft.com/en-us/previous-versions/windows/hardware/network/ff560255(v=vs.85)
This fixes:
1. A critical regression with unavailable networking in ReactOS when 3rd-party NT5-compatible Ethernet/Wi-Fi drivers are used (both in VM and on real hardware) caused by commit 3842b59f75 from @EricKohl.
2. Failure to open Network Properties and Network Status from the Network tray icon (caused by the same commit too).
MSDN tells us this is done so for Windows XP and Server 2003 as well, and IF_TYPE_IEEE80211 is returned only in Windows Vista and newer, so the following Microsoft documentation is actually correct in this case:
https://learn.microsoft.com/en-us/windows/win32/api/iptypes/ns-iptypes-ip_adapter_info
(see the information about "IP_ADAPTER_INFO.Type" member below on that page)
!!!Please note that the behaviour of Vista+ case (e. g., when compiling ReactOS targeted as NT 6.0 and newer) remains unchanged after this fix (networking still may not work), so it still requires the proper support of 3rd-party NT6+ compatible network miniport drivers (by handling this case via the Vista/NDIS6-style way) for NT6 target!!!
CORE-20244
Use a KSEMAPHORE instead of a NotificationEvent to signal availability. This is to prevent satisfying the wait for multiple waiters, when only a single entry is on the list.
Fixes crashes on SMP builds.
Add a SCSI and ATA passthrough support helper library for direct use
from low-level storage drivers.
Tested with: CDRoller, CloneCD, Magic ISO
NOTE: Vbox seems to lack support for CD/DVD burning; tested on real hardware.
CORE-10191 CORE-16452
CORE-14788 CORE-18241
CORE-17256 CORE-13866
ATA passthrough IOCTLs not supported by MS scsiport.
The implementation is optional, especially in SCSI.
IOCTL_SCSI_PASS_THROUGH will be implemented in SPTI library.
CORE-16422
- Move functions from header to main source, keeping their definitions
- Fix typo DefaultPalette -> VidpDefaultPalette
- Add missing PrepareForSetPixel() function
Addendum to 5f2ca473dc and cd91271796. CORE-17617 CORE-17604
Mikhail Tyukin