Ros-dev August 2007

ros-dev@reactos.org

38 participants
58 discussions

ReactOS and Sound cards.
by James Courtier-Dutton 24 Aug '07

24 Aug '07

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

2 1

Re: [ros-dev] IoCheckEaBufferValidity
by Aleksey Bragin 24 Aug '07

24 Aug '07

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

1 0

[Fwd: [ros-kernel] ReactOS status report for 10/12/1998]
by James Tabor 23 Aug '07

23 Aug '07

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:

1 0

Re: [ros-dev] [ros-diffs] [cfinck] 28423: - Always include"wine/unicode.h" before all other headers, when we need the wchar_t type. unicode.h includes windef.h, which includes winnt.h, which has the handling for the wchar_t type. As it's the firstinc
by Steven Edwards 22 Aug '07

22 Aug '07

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

6 15

Re: [ros-dev] [ros-diffs] [fireball] 28448: - Allow pci read/writes during proving BAR's size operation
by Aleksey Bragin 22 Aug '07

22 Aug '07

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

1 0

[ros-diffs] [fireball] 28448: - Allow pci read/writes during proving BAR's size operation
by James Tabor 22 Aug '07

22 Aug '07

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) { . . .

1 0

Re: [ros-dev] IoCheckEaBufferValidity
by Aleksey Bragin 21 Aug '07

21 Aug '07

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 >

2 2

IoCheckEaBufferValidity
by netzimme＠aim.com 21 Aug '07

21 Aug '07

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 ________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection. =================================================================== --- file.c (revision 28441) +++ file.c (working copy) @@ -1632,6 +1632,7 @@ IN ULONG Options) { KPROCESSOR_MODE AccessMode; + ULONG EaErrorOffset; HANDLE LocalHandle = 0; LARGE_INTEGER SafeAllocationSize; PVOID SystemEaBuffer = NULL; @@ -1732,10 +1733,10 @@ /* Validate the buffer */ Status = IoCheckEaBufferValidity(SystemEaBuffer, EaLength, - NULL); + &EaErrorOffset); if (!NT_SUCCESS(Status)) { - /* FIXME: Fail once function is implemented */ + DPRINT1("FIXME: IoCheckEaBufferValidity failed with Status: %lx\n",Status); } } } Index: util.c =================================================================== --- util.c (revision 28441) +++ util.c (working copy) @@ -129,8 +129,9 @@ return STATUS_SUCCESS; } + /* - * @unimplemented + * @implemented */ NTSTATUS NTAPI @@ -138,10 +139,58 @@ IN ULONG EaLength, OUT PULONG ErrorOffset) { - UNIMPLEMENTED; - return STATUS_NOT_IMPLEMENTED; + PFILE_FULL_EA_INFORMATION EaBufferEnd; + ULONG LenOfEaBuffer; + UINT IntEaLength; + + IntEaLength = EaLength; + EaBufferEnd = EaBuffer; + + while (IntEaLength >= 8) + { + LenOfEaBuffer = EaBufferEnd->EaNameLength+EaBufferEnd->EaValueLength + 9; + if (IntEaLength >= LenOfEaBuffer) + { + if (EaBufferEnd->EaName[EaBufferEnd->EaNameLength]==0) + { + if (EaBufferEnd->NextEntryOffset == 0) + { + IntEaLength = IntEaLength - LenOfEaBuffer; + if (IntEaLength>=0) + { + return STATUS_SUCCESS; + } + } + else + { + LenOfEaBuffer = ((LenOfEaBuffer + 3) & 0xFFFFFFFC); + if (EaBufferEnd->NextEntryOffset == LenOfEaBuffer) + { + if (EaBufferEnd->NextEntryOffset>0) + { + IntEaLength = IntEaLength - EaBufferEnd->NextEntryOffset; + if (IntEaLength>=0) + { + LenOfEaBuffer = EaBufferEnd->NextEntryOffset; + EaBufferEnd = (PFILE_FULL_EA_INFORMATION)((PBYTE)EaBufferEnd + LenOfEaBuffer); + continue; + } + } + } + } + } + } + break; + } + if (ErrorOffset != NULL) + { + *ErrorOffset = (ULONG)((PBYTE)EaBufferEnd - (PBYTE)EaBuffer); + } + + return STATUS_EA_LIST_INCONSISTENT; } + /* * @unimplemented */

2 2

Re: [ros-dev] [ros-diffs] [cfinck] 28423: - Always include "wine/unicode.h" before all other headers, when we need the wchar_t type. unicode.h includes windef.h, which includes winnt.h, which has the handling for the wchar_t type. As it's the first included he
by Steven Edwards 19 Aug '07

19 Aug '07

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

2 1

Freedom
by James Tabor 19 Aug '07

19 Aug '07

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

3 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev August 2007