Hi,
Alex Ionescu wrote:
> This new hack directly slows down every context switch instead of every
> page fault -- the latter is a less important perf hit.
This slowdown is very small, especially when comparing with other
"Hack of Doom".
I just want to see, is it the only raison d'être of that old hack or not.
Aleksey Bragin wrote:
> Why so, Dmitry? Looks like a hack?
IopEnumerateDevice() loads drivers, but link in ArcName directory for
a boot device
should exist for it.
Hi,
As you're all probably aware, myself and janderwald are in the process
of working on sound. I thought I'd give a brief update on this, but I
also need some feedback on the location of the various sound components
in our tree as I think it needs a little reorganisation.
At present, I am focusing on the user-mode portion of sound support,
with the goal of getting NT4 audio drivers working (legacy Sound Blaster
cards etc.) while janderwald is getting newer style WDM audio drivers up
and running.
I don't want to duplicate code, hence I have been intentionally
developing some helper libraries that can be easily reused. Think of
them as dedicated abstractions of the various Windows APIs with a
dedicated purpose (sound support.)
The components involved or which are planned are:
- Common library for user-mode side of sound support
- Helper library specifically for NT4 device sound support (device
"discovery" etc.)
- sndblst.dll, mmdrv.dll and wdmaud.drv user-mode DLLs (making use of
the above two components, slight variation in functionality for each -
Windows 3.1 used to use the equivalent of these as the actual drivers,
hence why there are multiple.)
- Kernel-mode common library for NT4 style sound drivers
- Sound Blaster library (to be shared between sndblst.sys and PortCls
implementation)
- UART401 library (to be shared between mpu401.sys and PortCls
implementation)
- Kernel Streaming API
- Kernel Streaming components
- Port Class driver
At the moment I have a few things dotted around a "sound" directory
within "include/reactos"
I also have some stuff in our "lib" directory (the helpers I wrote)
Kernel streaming related components seem to be spread around various
places in drivers/wdm and drivers/ksfilter
My attempts so far at NT4 drivers are still sat in drivers/multimedia
Basically, I want to try and structure this better. I don't think
sndblst.dll/mmdrv.dll/wdmaud.drv belong in dll/win32, and I'm wondering
if my helper libraries for sound should sit next to the relevant
components directory-wise. Or are they fine being in "lib"? They're only
used for sound components.
Finally, does anyone object to me removing the entire of the
drivers/multimedia tree as nothing in there works at all? I wrote most
of the code there, there is some redundant code from the very early
ReactOS days in "sound", I can leave that if it's really needed. I want
to start implementing sndblst.sys properly so I want to clean up a bit
first, but thought I'd ask first before I do anything further.
Andrew
Hi All!
When did this start? Why are we hacking application to work with ReactOS?
I see in change 39703 has gone from one kernel call to three.
Performance? We need to fix the real problem and it is a very old one
too.... SetWindowPos is very broken. Placing bandaids over a bullet
wound is not going to fix the problem. Patching around it too!
Remember adding hax on top of other hax rant I've posted over the
years. Creates more problems and these are still the problems we are
having now.
Applications must work on other target systems first prior to working
with ReactOS. TaskMgr must work on the target system first!
Evgeniy Boltik changes are based on good research but testing the
changes after is lacking. Evgeniy! Collect and create your test suite
of application and test them! AbiWord, FF, ReactOS apps and others
that are known to work before your changes. Once you get into a rhythm
of testing it becomes easier...
Thanks,
James
Hi,
we have put our efforts today to upgrade the SVN server machine,
which now runs Subversion 1.5.1, and do some routine maintenance like
recompressing the reactos repository, reconfiguring everything, etc.
As a result, some total (not even readonly access) downtime happened,
however it was only slightly more than a couple of hours, so
hopefully noone's suffered too much.
Now it runs stable, and better than before. Enjoy.
Thanks to Franz, Colin and Christoph for helping with setting up and
transferring the server. Their help is greatly appreciated.
WBR,
Aleksey Bragin.
Hi there everyone,
Thanks for the comments. Yes, i will be on IRC soon. My AIM username
is eek2121.
Thanks,
Richard Campbell
>
>
>
> On Wed, Feb 18, 2009 at 4:04 AM, Aleksey Bragin <aleksey(a)reactos.org> wrote:
>> Hi Richard,
>> very nice to see you back!
>>
>> Do you use IRC? If not, any other IM messenger? I could be reached as
>> fireballrus(a)gmail.com for gtalk, fireballrus in Skype, 3890063 in ICQ.
>>
>> If all the above fails, we'll just exchange emails, this is fine too.
>>
>>
>> I'll add your login to the svn, and let you know the password. Your work is
>> appreciated!
>>
>>
>>
>> WBR,
>> Aleksey Bragin.
>>
>>
>> On Feb 18, 2009, at 8:01 AM, Richard Campbell wrote:
>>
>>> Hi Guys,
>>>
>>> So After a LONG hiatus I've finally decided to get back into writing
>>> code for ReactOS. Some (most?) of you may not remember me. I've been
>>> lurking on the lists since 2000-2001, and was an active developer with
>>> CVS access for a while back in 2002-2003 (check the commit messages
>>> for rcampbell, also submitted quite a few patches). have never stopped
>>> reading (although i was/am using a different email address), but
>>> haven't touched the code before now. I have a couple of questions:
>>> 1) Is my SVN username active? The username is rcampbell. If not,
>>> I'll just use bugzilla. 2) Any documentation on coding guidelines
>>> such as styles, etc. or rules? I'm sure this has changed since my
>>> heyday.
>>>
>>> Thanks,
>>>
>>> Richard Campbell
>>> _______________________________________________
>>> Ros-dev mailing list
>>> Ros-dev(a)reactos.org
>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>>
>
Hi,
Does buildbot have its own custom config.rbuild that it uses? I've
been having a lot of trouble as I've been trying to boot a build in
either vmware or qemu with a virgin ReactOS source tree and RosBE-unix
and I always get hung up at the same place. buildbot builds don't show
the problem I am having so I am trying to nail down what in the
environment could cause the problem.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
I've search around the ReactOS site, the mailing lists, and the Wiki, and haven't seen this subject out there much. We have an older application that runs on Windows over a network connection. The software must be run over the network and must have a mapped network drive to function correctly. I know that Samba-TNG is available for ReactOS, but this seems to only smbclient and no way to mount or map a network share. Are there any plans or current efforts to support mapped network drive functionality?
Thanks - Nick
This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.