Hi everyone,
Some of you probably remember me. I was involved with trying to get
audio/sound implemented in ReactOS a few years ago.
To be honest, my progress was rather poor, I managed to write a few bits of
code but never really had a proper understanding of kernel/OS development or
CPU/system architectures. Additionally, whilst I could grasp how the
multimedia APIs (MME) in NT4 worked, and how they interacted with the
drivers (audio device X opens device Y and writes buffered data to it) for
Windows 2000 and later, Kernel Streaming was used which partly built on top
of the older implementation but added a load of new stuff.
This complicated matters as firstly, KS uses COM (which I still struggle to
wrap my head around) in kernel-mode, secondly there were multiple components
involved between the application and the hardware (wdmaud.drv -> wdmaud.sys
-> ks.sys -> portcls.sys -> driver as far as I remember), and finally I
really struggled to find example code and thorough documentation describing
how it all worked.
Ultimately I gave up with that and intended to move to another platform to
develop multimedia applications. Not much happened with that.
I remember there were complaints from application developers over Kernel
Streaming offering poor latency - instead developers would turn to other
technologies such as ASIO or DirectSound. So for recent versions of Windows
(Vista onwards?) Microsoft implemented a new, user-mode sound system
(WASAPI) which again uses COM but is pretty nicely documented, with code
samples.
Having done a little reading about this, it renewed my interest. It still
uses COM, and KS.SYS is still present (I assume for compatibility?) but as a
lot of this is implemented in user-space I suspect it'd be easier to
develop/test.
Aside from this, over the past few years I've also gained a better
understanding of topics I didn't know much about previously and I feel more
confident at being able to write lower-level stuff that works properly. I've
also developed more of a keen interest in how Windows works.
So basically I'm considering implementing the current Windows audio system
in ReactOS. I'd imagine we don't need to be too concerned about audio
drivers themselves (at least, initially) as vendors tend to offer these and
it's not like we need sound immediately post-install!
The only thing I really lack now is knowledge of how to implement COM
classes - at least, outside of using Visual Studio. Anyone got recommended
reading or example code for this?
Andrew
This patch, as it, is really dangerous. MS allows null pointer in its
Read/Write routines, but they are wrapped inside a SEH block, to prevent
nasty things to happen in case of a null pointer dereference.
Here we don't, meaning that a null pointer here will cause major damages.
Furthermore, your commit regressed ntdll:file:
https://reactos.org/sites/all/modules/reactos/testman/compare.php?ids=40042…
Regards,
On 08/07/2015 05:30 AM, aandrejevic(a)svn.reactos.org wrote:
> Author: aandrejevic
> Date: Fri Aug 7 03:30:05 2015
> New Revision: 68607
>
> URL: http://svn.reactos.org/svn/reactos?rev=68607&view=rev
> Log:
> [FASTFAT]
> Irp->UserBuffer being NULL doesn't indicate any error. It could be that the
> caller really wants the result stored at address NULL (which can be valid,
> and is valid by default for programs like NTVDM).
>
>
> Modified:
> trunk/reactos/drivers/filesystems/fastfat/rw.c
>
> Modified: trunk/reactos/drivers/filesystems/fastfat/rw.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfa…
> ==============================================================================
> --- trunk/reactos/drivers/filesystems/fastfat/rw.c [iso-8859-1] (original)
> +++ trunk/reactos/drivers/filesystems/fastfat/rw.c [iso-8859-1] Fri Aug 7 03:30:05 2015
> @@ -656,7 +656,7 @@
> }
>
> Buffer = VfatGetUserBuffer(IrpContext->Irp, BooleanFlagOn(IrpContext->Irp->Flags, IRP_PAGING_IO));
> - if (!Buffer)
> + if (!Buffer && IrpContext->Irp->MdlAddress)
> {
> Status = STATUS_INVALID_USER_BUFFER;
> goto ByeBye;
> @@ -927,7 +927,7 @@
> OldFileSize = Fcb->RFCB.FileSize;
>
> Buffer = VfatGetUserBuffer(IrpContext->Irp, BooleanFlagOn(IrpContext->Irp->Flags, IRP_PAGING_IO));
> - if (!Buffer)
> + if (!Buffer && IrpContext->Irp->MdlAddress)
> {
> Status = STATUS_INVALID_USER_BUFFER;
> goto ByeBye;
>
>
--
Pierre Schweitzer <pierre(a)reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
Hello,
i dont know if this list is the correct place to post this,
I found this software some weeks ago, and i thought it would be interesting
to have it running in ReactOS.
But, according its website, support for Windows XP has been stopped. So
question is, what about asking author to reenable XP support via ReactOS? :)
http://sourceforge.net/projects/vcxsrv/
Dear core developers,
Is it possible to use Windows XP based WDM sound drivers with Reactos
0.4-CLT2015?
Is it possible to make something so specific WDM sound driver can be
incorporated to Live CD so it would work out of The box?
If there is issues with using various sound drivers, how complex would
bew for You to add support for general USB audio device.
Last plea.
Which dlls would had to be redesigned so NVDA screen reader would be used?
Oleacc.dll and other mSAA based libraries?
Thank You very much for Yours answers.
With kindness regards.
Janusz Chmiel
Hello. I am Jared Smudde aka. Pi_User5. I propose that we move most of the icons in trunk into a central folder in the media folder. Some icons will need to stay because they might be application specific. The folder can be called icons and it would be organized according to http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.h…. This way, we can eliminate duplicate icons thus making trunk slightly smaller. It will also make changing ReactOS to a different icon theme much easier. This idea was suggested by gigaherz and I would like to see it done. Thanks!
Jared
Hi
On my issue CORE-9641 <https://jira.reactos.org/browse/CORE-9641> Victor
Martinez made a comment saying that Eric Kohl is currently working on
partitions. If that is the case, what kind of changes are being worked on?
Since I created another issue related to that (CORE-9661
<https://jira.reactos.org/browse/CORE-9661>), if this is already worked
on, I don't want to look into it either, otherwise this would be what I
would fix next.
mfg,
Gerhard Gruber
On Wed, Jun 24, 2015 at 9:26 AM, <cfinck(a)svn.reactos.org> wrote:
> cbSize
Well, you may at least want to validate that your dwOffsets are within
cbSize?
Best regards,
Alex Ionescu