Ros-dev

ros-dev@reactos.org

5788 discussions

by reactos-development＠silverblade.co.uk

Hi guys, I've been in touch with the guy that ported OSS to Haiku (open-source BeOS) after some discussion with the folks over at #winehackers to get some help with audio development. Anyway, basically the idea so far is to use OSS as a "fall-back" audio driver implementation. So unless there is a "better" driver installed (ie an official one for an audio device), ReactOS can use an Open Sound System driver instead. The result? There will at least be sound functionality. OSS is designed to be mostly platform-independent. By rewriting a few of the core modules, the entire set of drivers will be able to work with whatever platform you desire. This can be implemented on top of the existing MME API architecture for the moment, and can later be translated to use the WDM audio framework. Anyway, having stuck the OSS code into my local ReactOS source tree, I'm trying to figure out how to get it to compile using rbuild. The first hurdle I have come across is that there is extensive use of ioctl. Indeed it seems that most ports of OSS work on platforms based on Posix (Unix?) So my main question at this time is how to handle this? The calls in question appear to be documented inside a file called "soundcard.h" in the OSS sources however this just seems to be definitions for the ioctl codes. So I suspect a majority of the drivers are calling ioctl. Therefore, I figure the best way around this is probably to provide a fake ioctl that provides the expected functionality, and make this wrap DeviceIoControl with something that can translate the ioctl parameters into whatever... The only other way I see around this is to rewrite all calls to ioctl, and rewrite the IOCTL codes with NT-style ones. Thoughts/ideas? -------------------------------------------------------------------- mail2web.com - Microsoft® Exchange solutions from a leading provider - http://link.mail2web.com/Business/Exchange

17 years

Documentation

by Colin Finck

Hello, Recently, some developers wrote documentation about certain stuff related to ReactOS. But this documentation was only placed on their own web servers. In my opinion, it would be better if such stuff would (also) be committed to the "documentation" directory in SVN. Having documentation there makes sure that it does not get lost. Additionally, if the source file is committed (not a PDF or something like that), another person could extend the documentation further. I agree that not all documentary stuff needs to be on SVN. An example might be Magnus' Win32k syscall tables. But for example Andrew Greenwood's documentation about the Windows Multimedia Subsystems looks like something, which should be committed in my opinion. If you don't agree on committing this stuff, it would be nice if we could at least agree on an official document format, which should be used in the SVN tree. >From what I see, most documentations were created by using OpenOffice, so I think the OpenDocument Text format (ODT) would be a great choice. It is also supported by most word processors, thus most people should be able to open an ODT file. Up to now, I used RTF for formatted text documentations in SVN, but this format does not support things like shapes. Regards, Colin

17 years

Re: [ros-dev] Bugzilla's bug assigning process

by Aleksey Bragin

There is a list linked from that wikipage, which has a simple 1:1 relationship between developer and some development area. If it's wrong, please edit it. WBR, Aleksey Bragin. On Sep 21, 2007, at 3:04 AM, Ged wrote: > Aleksey Bragin wrote: >> If there are any questions, please post them right away here. >> > > How are these bugs being assigned? > I've been watching and most of the bugs which have been assigned have > been assigned to the wrong developer. > > Ged.

17 years

rbuild and HALs module optimization

by Marc Piulachs

If we don't have a ntoskrnl rbuild module for every supported architecture I don't understand why we do have a separate HAL rbuild module for every architecture (X86 , PowePC) and sub architecture (x86-Generic , x86-xbox , PowerPC-Generic) Currently we have a very complicated logic to compile the appropriate HAL with conditions (IF) and alias that point to the correct module for the target architecture. At the end always two dlls are going to be generated for every architecture hal_up and hal_mp so what's the reason to have a specific module for every architecture and not two generic modules that represent the two possible HAL modes (uniprocessor and multiprocessor) that dynamically include the appropriate source code for the platform (Architecture + Sub Architecture) being build? For example : <module name="hal_generic" > (common code to all architectures, sub architectures , UP and MP HALs) </module> <module name="hal_up" installname="halup.dll"> <library>hal_generic</library> <library>.. (common files to all UP HALs) <if property="ARCH" value="i386"> (X86 common files to all X86 UP HALs) <if property="OARCH" value="xbox"> (xbox specific files) </if> </if> </if propery="ARCH" value="powerpc"> (PPC common files) </if> </module> And the same for multiprocessor <module name="hal_mp" installname="halmp.dll" /> both files can be simply copied to the install cd and usetup will install the correct HAL renamed as hal.dll depending on the user selection. IMHO it greatly simplifies the process and is a more elegant solution than the current one.

17 years

Bugzilla's bug assigning process

by Aleksey Bragin

Hello, as you may already noticed Amine started his work as a bugzilla maintainer today, and some people were surprised by bugs being assigned to them. Amine does a preliminary bugs assignment, according to developers' work history in ReactOS. You are free to reassign to another dev, or reasign back to Ros-bugs(a)reactos.org if you don't want to fix that bug. Also, it's very important that you put your valid email address to the bugzilla account, so that it works correctly and emails you when needed. If there are any questions, please post them right away here. With the best regards, Aleksey Bragin.

17 years

Re: [ros-dev] Documentation

by Aleksey Bragin

Not a problem, but this should be done on a standalone machine, preferably the server at Christoph's place, or I can utilize my own machine for this too. WBR, Aleksey Bragin. On Sep 20, 2007, at 6:00 PM, Ged wrote: > Timo Kreuzer wrote: >> So we should think about updating our >> doxygen and probably keeping it at a quite up to date state (only >> a few >> days old if possible). > > I fully agree. > Aleksey, is there any reason this can't be stuck in a cron job and run > weekly? > Doxygen is a great tool which we can't really make much use of at the > moment. > > Ged.

17 years

29102 - Fix an old rbuild bug: .gch file now depends of intermediate module directory, and can create it if needed

by Timo Kreuzer

Revision: 29102 Autor: hpoussin Datum: 11:34:05, Mittwoch, 19. September 2007 Meldung: Fix an old rbuild bug: .gch file now depends of intermediate module directory, and can create it if needed ---- Verändert : /trunk/reactos/tools/rbuild/backend/mingw/modulehandler.cpp Does this fix bug 2369? http://www.reactos.org/bugzilla/show_bug.cgi?id=2369

17 years

Re: [ros-dev] Problems with resources or something else

by carlo.bramix

Hello, I saw the bug #2225. In my opinion the bug isn't into the CopyImage() but into DrawIconEx() instead. I checked the copyico test app and after debugging a little I discovered that CopyImage() received an already corrupted pixel map. But probably, this fact is known to you too. Sincerely, Carlo Bramini. ---------- Initial Header ----------- >From : ros-dev-bounces(a)reactos.org To : "ReactOS Development List" ros-dev(a)reactos.org Cc : Date : Fri, 14 Sep 2007 21:14:55 +0200 Subject : Re: [ros-dev] Problems with resources or something else > Hi, > > This problem has nothing to do with resource compilation. > It's a bug in our CopyImage function, which exists since some time. If you > try the current builds from our BuildBot, you will have the same problem. > > Regards, > > Colin > > > > -----Original Message----- > > From: ros-dev-bounces(a)reactos.org > > [mailto:ros-dev-bounces@reactos.org] On Behalf Of carlo.bramix > > Sent: Thursday, September 13, 2007 10:22 AM > > To: ros-dev > > Subject: [ros-dev] Problems with resources or something else > > > > Hello, > > it's long time that I compile ReactOS and I have some errors > > into the start menu bar. > > My results are almost identical to this screenshot: > > > > http://www.reactos.org/media/screenshots/2007/ros_033_xara3d.jpg > > > > As you can see, the two icons after the start button and the > > '1','2','3','4' buttons are corrupted. > > Actually I'm using the windres.exe that I received from here: > > > > http://www.reactos.org/archives/public/ros-dev/2007-July/009548.html > > > > Do you have some idea? > > > > Sincerely, > > > > Carlo Bramini > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ------------------------------------------------------ Leggi GRATIS le tue mail con il telefonino i-mode di Wind http://i-mode.wind.it/

17 years

Bugzilla maintainer

by Aleksey Bragin

Hello, Amine Khaldi is going to be a bugzilla maintainer, starting tomorrow. This is the first step from the a number of efforts I'm going to announce soon, which aim significant improving of the development process, resulting in less breakages and more smooth development progress. You can see what the work of a bugzilla maintainer is at the following wikipage: http://www.reactos.org/wiki/index.php/ Bugzilla_Maintainer With the best regards, Aleksey Bragin.

17 years

ReactOS status

by Carlos Alexandre Pires

Hi, my name is Carlos Pires, and i've been tracking this project since 2006, and now I've managed to get some time for me to get involved in it. I've fetched the svn sources, and past this last 3 days looking at the code, trying to find how was going the implementention. I've also download tinykrnl for analsys, and realized that reactOS does not implement some hal fuctions like HaliQuerySystemInformation, trying to find more information one this i've also realize that reactOS does not have a Machine Check Handler. I noticed that a lot of effort is being made in User Mode code, to make software work in reactOS. I've also check svn activity and checked that the Kernel Mode code had minor changes (i've only looked at dates). Now, i've said that, i have a few questions: - How is the Kernel Mode implemention current status? - Looking at Windows architecture, the HAL part is one of the most important thing in making Windows device drivers work in reactOS, shouldn't this be ReactOS first goal? - Isn't more important to create a fully working Kernel (executive,hal,etc) before going into User Mode? Sorry if i've said something that is not correct, this are only thoughts i've had, while i was looking at the code. I'm a developer and want to help as much as i can this project, so if anyone can help in getting some lights about the current status, i appreciate. The best regards

17 years

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev