Hi,
How much work would it take to support a soundcard in ReactOS?
I would like to use it to help me reverse engineer a sound card to get
it working in Linux.
Kind Regards
James
Reformatted, improved and committed (28506 & 28507).
Thanks for contribution.
WBR,
Aleksey Bragin.
On Aug 22, 2007, at 1:53 AM, netzimme(a)aim.com wrote:
>
>
> Sorry the patch was wrong. I have forgot to change the function name.
>
>
> Thanks
> Daniel Zimmermann
Hi!
More voices from the past.
James
-------- Original Message --------
Subject: [ros-kernel] ReactOS status report for 10/12/1998
Resent-Date: Tue, 13 Oct 1998 00:21:40 -0500
Resent-From: ros-kernel(a)sid-dis.com
Date: Mon, 12 Oct 1998 22:24:40 -0700
From: rex <rex(a)lvcablemodem.com>
Reply-To: <ros-kernel(a)sid-dis.com>
To: ros-kernel(a)sid-dis.com <ros-kernel(a)sid-dis.com>
ReactOS status report for Monday, October 12th 1998
Current Kernel Release is 0.0.12
Working drivers: Driver Version
------------ -------
FS/Minix 0.0.1
IDE 0.1.2
Keyboard 0.0.4
Null 0.0.1
Parallel 0.0.1
SDisk 0.0.1
Welcome to Brian and good luck to him as he settles
in and learns of the vast intracacies and subtleties
of the ReactOS kernel.
Benoit Papillault has taken on the task of the
PE program loader.
Francois Asselin sent me a response indicating he
doesnt currently have time to work on the
schedular due to his studies. Perhaps he should
move to the inactive list.
An attempt to send mail to Iwan Fatahi's mail
account bounced. Iwan, if you're there, perhaps
you can let me know if you're working on anything,
and let the webmaster know your current email
address.
I've been sending messages to various people on
the kernel members listing asking for status on
their piece of the system. If I do not get a
responce after three tries I'll assume that person
is busy for the time being, send the info to the
appropriate lead and remove their name from the
status report. If anyone thinks that's not an
appropriate thing to do let me know.
Development Status:
Boot Loader
No Status.
DOS Loader
No Status.
Kernel: Brain Palmer
I/O Manager:
No Status.
Memory Management
No Status.
Process Management:
No Status.
Security Manager
No Status.
Filesystem Interface
No Status.
Miniport Drivers
No Status.
Local Procedure Calls: Giovanni Tapang
No Status.
System Calls:
Networking support: Arindam Das and Jason Eager
No Status.
Plug and Play support
No Status.
PCI
No Status.
Registry
No Status.
ACPI power managment
No Status.
Loader for PE executables: Benoit Papillault
No status.
Ports to other platforms
No Status.
Drivers:
Floppy: Rex Jolliff
No status.
IDE: Rex Jolliff
Worked on bug reports:
Driver crashes on detection of Secondary/Slave
with ATAPI CDROM connected. (I believe I found
the problem, but need an updated test system
to be sure)
Driver creates incorrect symbolic link for
2nd drive. (I'm not sure this bug exists, as
I can't reproduce it.)
Sound: Robert Bergkvist (FragDance Galore)
No status.
VFAT: Jason Filby
First release currently in testing.
Other Filesystems: Dennis Varouxis and Etienne Cochard
No status.
Console
No status.
Mouse: Jason Filby
No status.
Network
No status.
Serial
No status.
Video: Conor Stokes, Iwan Fatahi and Jerome Davadilla
Mail sent to Iwan Fatahi requesting status bounced.
System Libraries:
Stub Generator
No Status.
KERNEL32
No Status.
Identification of remaining libraries
No Status.
Milestones:
Working:
Kernel R13 Brain Palmer Est: 01/01/1999
Boot loader improvements
NASM new release compatability
Buffered I/O bugfix
VFAT R1 Jason Filby Est: 01/01/1999
IDE R2 Rex Jolliff Est: 10/31/1998
Second release will fix the 255 sector read limitation
and add timeout detection code.
Complete:
IDE R1 Rex Jolliff Est: 10/15/1998 Act: 09/20/1998
First release will locate up to 8 drives, make available
devices for the raw device and all dos compatable
partitions and read and write using non DMA I/O.
Kernel R12 David Welch Est: 09/31/1998 Act: 10/04/1998
New:
Multiple processes
System calls (this is already working)
Improved multithreading support
Support for additional filesystem operations
Some support for disk caching
On Hold:
Killed:
On 8/19/07, Colin Finck <mail(a)colinfinck.de> wrote:
> These changes were made to properly compile ReactOS under a Mac OS X host.
> They have nothing to do with MSVC or the Microsoft SDK headers.
Sorry I was not clear about what I meant in my rant and sounded bitchy
> Mac OS X defines its own wchar_t type in "ctype.h". But it uses _WCHAR_T for
> reporting that the type has been defined and not _WCHAR_T_DEFINED like
> Windows does.
> This is why I needed to add a handling for _WCHAR_T in "winnt.h".
> But if "ctype.h" is now included before "winnt.h", these changes don't have
> any effect. This is why I changed the header order.
>
> Of course, there might be other "solutions" to this problem (like adding all
> possible definitions that wchar_t has been defined into the Makefile), but
> this is the simplest one.
> And I see no reason not to do this for fixing this problem.
It makes anyone doing a diff have more stuff to have to workaround.
There are constantly minor updates and fixes to the unicode tables in
Wine because Microsoft did not just generate them from the uncode.org
spec but added a bunch of stuff. Wine currently builds on OS X with
the header order as it stands and figures out someway around it. I
guess its using a define in the makefile for _WCHAR_T generated by
configure or something. I have not looked so don't quote me on that. I
don't really care if you want to change it to make it less of a hassle
to build on OS X for ReactOS but its just going to break again next
time someone syncs the unicode lib so its better if you can work
around it in the makefile.
--
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
Hi,
sorry - no, this is an olpc-specific code in olpc branch, I have to
emulate some PCI hardware (the code is taken from Linux), however
ReactOS's PCI access is more complicated, and thus I slightly
improved the code.
As for that crash - hmm. I will try the real hardware today maybe.
WBR,
Aleksey Bragin.
On Aug 22, 2007, at 7:31 AM, James Tabor wrote:
> Hi!
> Could this be related to 28448? I mean could it fix this? The
> buffer address
> goes down from 8XXXXX to 3fffff (yes backwards, I watch it) and
> faults.
> This fault was before 28448 and on real hardware. Display is normal
> and mouse
> moves.
> Thanks,
> James
>
> Unhandled exception
> ExceptionCode: c0000005
> Faulting Address: 3fffff
> Address: 78010e04 C:\ReactOS\system32\msvcrt.dll
> CS:EIP 1b:78010e04
> DS 23 ES 23 FS 3b GS 0
> EAX: 0010ad41 EBX: 003fffff ECX: 00001000
> EDX: 009a2068 EBP: 0087f5b4 ESI: 00000002 ESP: 0087f5a0
> EDI: 009a2068 EFLAGS: 00010217
> Frames:
> 78000000+122c6 C:\ReactOS\system32\msvcrt.dll
> 400000+742eb C:\ReactOS\explorer.exe
> 400000+609f4 C:\ReactOS\explorer.exe
>
> _write lib/sdk/crt/io/write.c Line 55
> .
> .
> .
> while (_nbyte--) {
> ----> if (*in == 0x0a) {
> .
> .
> .
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
Hi!
Could this be related to 28448? I mean could it fix this? The buffer address
goes down from 8XXXXX to 3fffff (yes backwards, I watch it) and faults.
This fault was before 28448 and on real hardware. Display is normal and mouse
moves.
Thanks,
James
Unhandled exception
ExceptionCode: c0000005
Faulting Address: 3fffff
Address: 78010e04 C:\ReactOS\system32\msvcrt.dll
CS:EIP 1b:78010e04
DS 23 ES 23 FS 3b GS 0
EAX: 0010ad41 EBX: 003fffff ECX: 00001000
EDX: 009a2068 EBP: 0087f5b4 ESI: 00000002 ESP: 0087f5a0
EDI: 009a2068 EFLAGS: 00010217
Frames:
78000000+122c6 C:\ReactOS\system32\msvcrt.dll
400000+742eb C:\ReactOS\explorer.exe
400000+609f4 C:\ReactOS\explorer.exe
_write lib/sdk/crt/io/write.c Line 55
.
.
.
while (_nbyte--) {
----> if (*in == 0x0a) {
.
.
.
Hello,
please provide your real name (this is a must for every commit), and
also how to test it under Windows (maybe you wrote some test app for
this - it would be useful too).
WBR,
Aleksey Bragin.
On Aug 21, 2007, at 3:39 AM, netzimme(a)aim.com wrote:
> Hallo
>
> Have a patch that implemented the function IoCheckEaBufferValidity
> in ntoskrnl\io\iomgr\util.c.
> Tested with Windows 2000 and Vista Ultimate 64 Bit.
> Perhaps some one can comit it for me.
>
> Thanks
> dz
>
On 8/19/07, cfinck(a)svn.reactos.org <cfinck(a)svn.reactos.org> wrote:
> - Always include "wine/unicode.h" before all other headers, when we need the wchar_t type.
Please stop changing the header order. If you need to do this then
something is wrong. The Wine headers are mostly correct as far as the
PSDK/WDK goes and if you build Wine on MSVC you DO NOT have to make
these invasive changes to the source even when using the SDK headers.
Fix the ROS headers or work around system limitations some other way.
--
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
Hi,
I want ReactOS to become free again. From gnu.org,
Free software is a matter of the users' freedom to run, copy, distribute, study, change and improve
the software. More precisely, it refers to four kinds of freedom, for the users of the software:
* The freedom to run the program, for any purpose (freedom 0).
* The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to
the source code is a precondition for this.
* The freedom to redistribute copies so you can help your neighbor (freedom 2).
* The freedom to improve the program, and release your improvements to the public, so that the whole
community benefits (freedom 3). Access to the source code is a precondition for this.
We forget what this is all about. We need to be liberated from the shackles and chains.
Replace "Tainted Developers" with this:
Referring to Proprietary Programs:
Don't in any circumstances refer to any closed source proprietary code for or during your work on
ReactOS! (Or to any other proprietary programs, Unix, Novel, Solaris, Microsoft,.)
If you have a vague recollection of the internals of a closed source program, this does not
absolutely mean you can't write an imitation of it, but do try to organize the imitation internally
along different lines, because this is likely to make the details of the software version irrelevant
and dissimilar to your results.
It's from:
http://www.gnu.org/prep/standards/html_node/Reading-Non_002dFree-Code.html#…
If is good for FSF/GNU it's good enough for us. I don't think we need to vote on this, just
change it! Remember this is GNU/ReactOS! Not SFLC/Wine!
Thanks,
James