The source code is licensed under MIT license, taken from
"MSDN Code Gallery Microsoft Samples" repository
(https://github.com/microsoftarchive/msdn-code-gallery-microsoft)
The original license was MS-PL, but the driver was later relicensed
as MIT.
Adopted to ReactOS code base by Michael Stamper.
Co-authored-by: Michael Stamper <michaelstamper1@gmail.com>
- Split buffers on page to prevent non-contiguous memory being passed to driver.
- Protect CIrpQueue::GetMappingWithTag, ReleaseMappingWithTag with spinlock to prevent race conditions
(GetMapping, ReleaseMapping do not need spinlock, they are only called from a service routine).
- Remove ASSERT in CIrpQueue::ReleaseMappingWithTag, when mappings are released out of order. Just ignore
the tag argument and release the next one in the list. This is what windows does, confirmed by calling
PortWavePciStream::ReleaseMapping() with tag argument set to 0, absolutly no difference observed.
Allowing out of order release is essential given that a driver is not permitted to hold a spinlock when calling
ReleaseMapping().
- Remove IIrpQueue::HasLastMappingFailed(), it never worked and there is no way it could work.
CPortPinWavePci::HandleKsStream() call MappingAvailable() non-conditionally, this is what Windows does,
verified by debug prints in ac97 driver.
- Implement CIrpQueue::NumData().
- Remove incorrect interlocked operations/volatile variables and several (now unused) class fields.
- usetup: New bootsector page.
- shell32: Copy and paste, and moving elements.
Also, some strings related to the shutdown and logoff.
- Minor Spanish grammar fix - some female words and minor latin american typos.
- First revision of the .inf, that includes the translation of the Services,
audio, processors and other drivers and minor things.
This function may stuck during device installation if there are issues
with interrupts (or with a device itself).
This fixes the boot on my testing ThinkPad x60s
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
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.
Fixes a regression from 99fa38809f, which
replaced the kcom.h/stdunk.h versions (which zero memory) with local
implementations (which don't).
Standard C++ does not guarantee that memory is zeroed but several classes
rely on this, in particular for their m_Ref and m_bInitialized members.
Ideally the constructors should be fixed to initialize all required members,
but that task is error-prone so for now we simply restore the previous
behavior.
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.
We previously only gave the device a hard-coded amount of time to respond,
which could lead to interpreting the contents of uninitialized memory as
a response. This would lead to an unreasonably large number of audio function
groups being detected.
A KSEMAPHORE mirrors what Haiku uses here, though it may not be the optimal
synchronization primitive for this case under Windows.
This protects against crashing in case of faulty/malicious hardware,
but also works around a bug in HDA_SendVerbs that causes it to return
invalid data, thereby suggesting more groups than are actually present.
