- Ros-dev - ReactOS.org

Re: [ros-dev] Bugzilla error when sending notifications
by carlo.bramix 08 Oct '07

08 Oct '07

Hello, I got this error too... and I made a little disaster. I got that message when writing into bug #2711. I cleaned the off-line cache, I posted my message again, I got success but the message has been posted twice, because the previous message had been accepted despite the error screen. Sorry... Carlo Bramini >I'm getting the same error since some time. > >But for me, it only occurs when hpoussin at reactos.org is >subscribed to the >bug report (by being the bug reporter or by being on the CC >list). Sending >notifications to other E-Mail addresses seems to work fine. >Also only the E-Mail notification part is affected by this >problem, the >other changes will be saved successfully. >Using Deskzilla with such bug reports also leads to the same >problem. > >Regards, > >Colin > > >> --- Original Message --- > From: ros-dev-bounces at reactos.org [mailto:ros-dev-bounces at reactos.org] On Behalf Of Marc Piulachs >> Sent: Tuesday, October 02, 2007 5:11 PM >> To: ros-dev at reactos.org >> Subject: [ros-dev] Bugzilla error when sending notifications >> >> I'm getting this error when posting/modifying a bugreport >> >> Bugzilla has suffered an internal error. Please save this page and send it to aleksey at reactos.org with details of what you were doing at the time this message appeared. >> >> URL: http://www.reactos.org/bugzilla/process_bug.cgi >> >> There was an error sending mail from 'ReactOS.Bugzilla' to 'hpoussin at reactos.org':error when closing pipe to /usr/lib/sendmail: ------------------------------------------------------ Leggi GRATIS le tue mail con il telefonino i-mode di Wind http://i-mode.wind.it/

1 0

Techwiki start
by Timo Kreuzer 07 Oct '07

07 Oct '07

I have started a techwiki inside our wiki. It can be found at http://www.reactos.org/wiki/index.php/Techwiki/main Currently only some stuff for win32k/gdi. Please add any info about nt functionality / links / tools you'd like to share there. I still think it would be a good idea to move it into it's own wiki, so our wiki doesn't get even more messed up ;-) Timo

1 0

Re: [ros-dev] [ros-diffs] [hpoussin] 29433: ntdll.dll is a native dll
by Alex Ionescu 07 Oct '07

07 Oct '07

Nope, it's not :) On 10/7/07, hpoussin(a)svn.reactos.org <hpoussin(a)svn.reactos.org> wrote: > > Author: hpoussin > Date: Sun Oct 7 16:14:02 2007 > New Revision: 29433 > > URL: http://svn.reactos.org/svn/reactos?rev=29433&view=rev > Log: > ntdll.dll is a native dll > > Modified: > trunk/reactos/dll/ntdll/ntdll.rbuild > > Modified: trunk/reactos/dll/ntdll/ntdll.rbuild > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/ntdll/ntdll.rbuild?rev… > > ============================================================================== > --- trunk/reactos/dll/ntdll/ntdll.rbuild (original) > +++ trunk/reactos/dll/ntdll/ntdll.rbuild Sun Oct 7 16:14:02 2007 > @@ -1,6 +1,6 @@ > <?xml version="1.0"?> > <!DOCTYPE module SYSTEM "../../tools/rbuild/project.dtd"> > -<module name="ntdll" type="win32dll" entrypoint="0" > baseaddress="${BASEADDRESS_NTDLL}" installbase="system32" installname=" > ntdll.dll"> > +<module name="ntdll" type="nativedll" entrypoint="0" > baseaddress="${BASEADDRESS_NTDLL}" installbase="system32" installname=" > ntdll.dll"> > <bootstrap installbase="$(CDOUTPUT)/system32" /> > <importlibrary definition="def/ntdll.def" /> > <include base="ntdll">inc</include> > > > -- Best regards, Alex Ionescu

1 0

rbuild problems/suggestions
by Marc Piulachs 06 Oct '07

06 Oct '07

Having worked with rbuild for a few weeks I have identified some problems that would like to share. I also would like to hear the developers' opinions about all of these issues because I want to start working to solving them. A) The behavior of the "include" + "directory" tags are inconsistent when an "include" is placed inside a "directory" for example: Correct: (expected : ke/i386/boot.S) <directory name="ke"> <if property="ARCH" value="i386"> <directory name="i386"> <file first="true">boot.S</file> Incorrect: (expected : reactos/reactos.rbuild real : reactos/reactos/reactos.rbuild) <directory name="reactos"> <xi:include href="reactos/reactos.rbuild" /> </directory> should be: <directory name="reactos"> <xi:include href="reactos.rbuild" /> </directory> B) The "oldcrt" attribute is no longer used and can be removed. C) The module types "Iso" , "LiveIso" , "IsoRegTest" and "LiveIsoRegTest" are IMHO hacks introduced to be able use the makefile generation code. rbuild is C++ so with a small code refactor they can be easly removed. D) Any module is using the "EmbeddedTypeLib" module type , is really needed or can be removed? E) IMHO the "ElfExecutable" is incorrect . I posted my reasons some time ago: http://www.reactos.org/archives/public/ros-dev/2007-September/009770.html http://www.reactos.org/archives/public/ros-dev/2007-September/009771.html http://www.reactos.org/archives/public/ros-dev/2007-September/009779.html F) The module type "alias" is only used for HAL related modules and IMHO it isn't requiered because the problem it tries to solve can be easly solved using "if" tags and conditional compilation. http://www.reactos.org/archives/public/ros-dev/2007-September/009798.html There are several reasons for this change: - Currently every platform requires 3 new HAL modules. In the future if new platforms are supported for example (X86 , XBOX , PPC , AMD64 , MIPS , IA64 , ARM ... ) 3 x 7 = 21 modules .. see what I'm saying? - It simplifies backends work. No need to include logic for alias handling. - Conceptually wrong . every module represents a particular functionality when you compile the module it should just reconfigure itself to produce the appropriate image for the configured architecture .It a good idea to have a true componentized operating system. Regarding the ModuleType IMHO they should be used to provide information that describes the module output/target not the build process! Iso , LiveIso , Alias , ... all of them are meaningless they are not true metadata. Long term enhancements: X) tags like "linkerflag" or "compilerflag" are gcc/mingw specific and should be replaced with other tags that provide the equivalent functionality using a more abstract aproach so other backends/compilers could benefit from it. rbuild files should only describe the source code and the compilation process without including specific information. /Marc

1 0

Re: [ros-dev] [ros-diffs] [hpoussin] 29378: Add back windres, it is still used after wrc invocation
by Steven Edwards 03 Oct '07

03 Oct '07

speaking of resources, Alexandre is now allowing binary resources in winehq git as it actually handles them in a sane way as opposed to cvs. This means you guys can drop bin2res if your using it anywhere and keeping shell32 resources in sync with Wine will be less of a diff now. Thanks Steven On 10/3/07, hpoussin(a)svn.reactos.org <hpoussin(a)svn.reactos.org> wrote: > Author: hpoussin > Date: Wed Oct 3 18:17:46 2007 > New Revision: 29378 > > URL: http://svn.reactos.org/svn/reactos?rev=29378&view=rev > Log: > Add back windres, it is still used after wrc invocation > > Modified: > trunk/reactos/Makefile > > Modified: trunk/reactos/Makefile > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/Makefile?rev=29378&r1=2937… > ============================================================================== > --- trunk/reactos/Makefile (original) > +++ trunk/reactos/Makefile Wed Oct 3 18:17:46 2007 > @@ -298,6 +298,7 @@ > objcopy = $(Q)$(PREFIX_)objcopy > dlltool = $(Q)$(PREFIX_)dlltool > strip = $(Q)$(PREFIX_)strip > +windres = $(Q)$(PREFIX_)windres > > # Set utilities > ifeq ($(OSTYPE),msys) > > > -- 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

1 0

ReactOS Development Process
by Aleksey Bragin 03 Oct '07

03 Oct '07

Hello, recently, different people raised a question: How should development process evolve with time, when ReactOS has more (much more) developers willing to contribute code? There are many possibilities, however all of them assume more or less an overhead, and need additional human resources. I will outline one suggested method, and want you (developers) to "constructively criticize it", improve it, or offer a better method. Even if it involves changing current version control system, or anything - suggest the method. So, the suggestion I've already got is this: Trunk is writable only by a so-called Integrator person (maybe a few persons). Branches are writable by a big amount of developers. Typical development process is as follows: 1. A developer creates a ticket in issue-tracking system (currently Bugzilla), where he describes what's wrong and what his change fixes/ improves. 2. He creates a branch with a name BZ-XYZ (where XYZ is ticket's number), and commits his changes there. 3. An integrator, daily, goes through all BZ-... branches, does svn merge to trunk of each branch, test it, if no regression occurs, he commits changes to trunk and svn deletes the respective BZ-... branch. Some kind of integration system is definitely needed, so please avoid fast answers like "Let's stay as we do now". Better approach is needed, and I'm looking for it. If you can offer something - do so. With the best regards, Aleksey Bragin.

3 2

Re: [ros-dev] ReactOS Development Process
by Aleksey Bragin 03 Oct '07

03 Oct '07

I considered that, but it's a bad idea. Try to remember what the hell it was to merge changes into release branch ("stable"), done since 0.3.3-RC1 was released? And that was only to do a RC2, about 1-2 weeks, and complete hell to merge so it was decided that a rebranch was easier (and in fact it worked very well). WBR, Aleksey Bragin. On Oct 3, 2007, at 9:03 PM, Magnus Olsen wrote: > Hi > I think we should have something call stable trunk and devloping trunk > > The stable trunk getting all changes that are ready and stable and > it will > be > the release version of trunk. > > the devloping trunk is where everyone working in > > > But the main problem is we do not have any good tools for regress > testing > and we are missing testcase for each api. I am working at moment > writing > testcase for gdi32, I hope this will make lest gdi32 allot more > stable at > end > then I will start making testcase for win32k later maybe for user32 > then start fixing the real bugs and implement things. or working with > everthing same times. we should need a test kit for each api and > test for evertging invaild param, pointers, and real data in all case > I known it is not fun todo but that is what we need to make ReactOS > more stable and less bugs. Testcase for everthing.

1 0

Re: [ros-dev] ReactOS Development Process
by Aleksey Bragin 03 Oct '07

03 Oct '07

Herve suggests using a kind of a continuous integration system, describing it this way: * precommit hook if commit not to trunk, abort precommit hook create a REV-abc branch from trunk and do the commit here * regularly go through all REV-abc branches (increasing ABC numbers) test it if not, inform user or whatever that test failed and go to next branch try to merge to trunk if not, inform user or whatever that merge failed and go to next branch commit to trunk delete the branch go to next branch * pros: devs and users will have new version to trunk once they are tested devs and users only have to know trunk * cons: changes are not immediatly available for everyone, except in REV-abc branch On Oct 3, 2007, at 12:50 PM, Aleksey Bragin wrote: > Hello, > recently, different people raised a question: How should development > process evolve with time, when ReactOS has more (much more) > developers willing to contribute code?

5 4

Bugzilla error when sending notifications
by Marc Piulachs 02 Oct '07

02 Oct '07

I'm getting this error when posting/modifying a bugreport Bugzilla has suffered an internal error. Please save this page and send it to aleksey(a)reactos.org with details of what you were doing at the time this message appeared. URL: http://www.reactos.org/bugzilla/process_bug.cgi There was an error sending mail from 'ReactOS.Bugzilla' to 'hpoussin(a)reactos.org':error when closing pipe to /usr/lib/sendmail:

2 1

Re: [ros-dev] [ros-diffs] [hpoussin] 29352: Do not hardcode cdrom directory
by Pablo Menichini 02 Oct '07

02 Oct '07

> --- trunk/reactos/base/setup/usetup/drivesup.c (original) > +++ trunk/reactos/base/setup/usetup/drivesup.c Tue Oct 2 16:16:45 2007 > @@ -35,7 +35,8 @@ ... > + if (Ptr) > + RtlCreateUnicodeString(SourceRootDir, Ptr); > + else > + RtlCreateUnicodeString(SourceRootDir, L""); > + > if (Ptr != NULL) > - *Ptr = 0; > - > + *Ptr = 0; You can put *Ptr = 0 in the if-else Pablo

1 0

SmartPDF (aka SumatraPDF) in rosapps, linking problems
by Klemens Friedl 02 Oct '07

02 Oct '07

SumatraPDF is a lightweight Win32 pdf viewer app http://blog.kowalczyk.info/software/sumatrapdf/ http://code.google.com/p/sumatrapdf/ The name "sumatra" sounds weird (for an app), so I renamed the directory and the output exe file to "SmartPDF" (based on suggestions from #reactos). SumatraPDF comes with VS 2k5 project files. I have fixed various compile issues so that libjpeg, poppler, fitz/mupdf and sumatra app itself compile without errors in mingw (RosBE 0.3.7.2 Win32). All code changes can be found by grep/search for "@note:", I added a comment to each changed code line. The remaining problem is the linking issue. Currently it does NOT link correctly. Timo Kreuzer mentioned on 2007-09-27 in #reactos something that may be related to the issue: "it [sumatrapdf] imports a function from winspool.drv by number, when you add that number to winspool.def, it starts" Please have a look at it, fixes are appreciated :) Klemens

4 9

Kernel streaming header mess / GUIDs
by reactos-development＠silverblade.co.uk 30 Sep '07

30 Sep '07

Hi, Alex nudged me in IRC about this, but sadly I've not quite figured this out yet. It appears my definitions for Kernel Streaming GUIDs are not quite right. This results in ugly code like so: -- const GUID foo_audio_category = STATIC_KSCATEGORY_AUDIO; DoSomethingWithTheGuid(&foo_audio_category); -- Which consequently results in a barrage of compiler complaints about brace initialization. It should be possible to just do: DoSomethingWithTheGuid(KSCATEGORY_AUDIO); I'm clearly going wrong somewhere in KS.H or KSMEDIA.H but to be honest am blind to whatever is causing the problem. If anyone can figure out what I'm doing wrong here, I'd appreciate it. Thanks. -Andrew

5 4

Re: [ros-dev] [ros-diffs] [fireball] 28351: Dmitry Chapyshev <lentind@yandex.ru>: - Fix so that letters like "p" or "y" are correctly displayed in messageboxes.
by Ged 29 Sep '07

29 Sep '07

IMO, this change is wrong, it's a hack to a problem we have with text placement. Text is cut short on other controls too, not just messageboxes. Check out labels for example. Ged. fireball(a)svn.reactos.org wrote: > Author: fireball > Date: Wed Aug 15 18:49:44 2007 > New Revision: 28351 > > URL: http://svn.reactos.org/svn/reactos?rev=28351&view=rev > Log: > Dmitry Chapyshev <lentind(a)yandex.ru>: > - Fix so that letters like "p" or "y" are correctly displayed in messageboxes. > > Modified: > trunk/reactos/dll/win32/user32/windows/messagebox.c > > Modified: trunk/reactos/dll/win32/user32/windows/messagebox.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/user32/windows/m… > ============================================================================== > --- trunk/reactos/dll/win32/user32/windows/messagebox.c (original) > +++ trunk/reactos/dll/win32/user32/windows/messagebox.c Wed Aug 15 18:49:44 2007 > @@ -491,7 +491,7 @@ > txtrect.right = GetSystemMetrics(SM_CXSCREEN) / 5 * 4; > if(Icon) > txtrect.right -= GetSystemMetrics(SM_CXICON) + MSGBOXEX_SPACING; > - txtrect.top = txtrect.left = txtrect.bottom = 0; > + txtrect.top = txtrect.left = txtrect.bottom = 5; > SelectObject(hDC, hFont); > if (textlen != 0) > { > > > >

7 6

Note for devs about translations
by Heis Spiter 29 Sep '07

29 Sep '07

Hello, I'd just like to do a remark about ReactOS apps, dlls, which be translated. When a dev change something to the interface, or the core app, it could be great to update EVERY language file (*.rc) and not only some of them (or even worse : only english one). It does not take many times to do (I know because I've already done that), and for a translator that's quite easier to see what has changed without having to compare his language file and the english one. And most of all, it avoids uncomplete, or outdated language files. Finally, for end-user, that's better : that's even better to have English string instead of nothing (I mean blank string). Thanks, Pierre Schweitzer, French Language Maintainer

1 0

Re: [ros-dev] Audit
by Aleksey Bragin 24 Sep '07

24 Sep '07

On Sep 22, 2007, at 10:19 PM, João Jerónimo wrote: > The point of a possible 3rd party audit is raising the legal > credibility of > the ReactOS project by ensuring that no tainted code is left in the > source > tree, right? The word "tainted" is actually quite wrong, and is being misused everywhere. A tea was tainted by polonium in a not-so-recent accident in the UK. ReactOS is not a tea, and we have no "polonium" commiters. There will be a WineConf event in 1 or 2 weeks, and they say they are going to clear up the legal situation around Wine, around SFLC audit and around requirements to the developers, whose code may be commited to the tree. When they do it, I would be very glad to know those requirements, and enforce them on ReactOS developers, so that we are on the common ground. > > Well, if the project is going to wait until more modules stabilize, > won't > this stabilization process obfuscate most of the tainted source > code, and > make them hard to find? Your mind is ahead of you. "Taint obfuscated code", "Obfuscate tainted code", ... Your question is obfuscated and may be tainted, I won't answer it. WBR, Aleksey Bragin.

9 19

Re: [ros-dev] Audit
by Aleksey Bragin 24 Sep '07

24 Sep '07

Please stop rumouring this topic. I clearly said "if there are strong circumstances, in future, only then we will think about doing 3rd party audit, and only from agreement of all devs". That's 3 or 4 years away from now, if such legal problems ever happen. Also noone ever said SFLC is taking up copyrights to themselves. At least it's first time I hear this. I just grepped Wine source code base for word "SFLC" - doesn't appear anywhere. Also, open up any of Wine's source code file, you'll see "Copyright 200x Person's Name". And again, I didn't suggest SFLC or FSF or whoever. Time will show who and if we need, and who and if agrees to. WBR, Aleksey Bragin. On Sep 24, 2007, at 2:58 PM, Magnus Olsen wrote: > It seam u fall into he SFLC traps they are trying push doing the > audlt of > ros from a 3 part project > of ros, and we shall obay theirs rules it mean all api that is not > document > in msdn shall be remove > and so on. That mean 80% of ntoskrnl will go away, for around 80% of > ntoskrnl are not in msdn > 80% of win32k will go aways, for thuse api are not in msdn, then > shall we > not talk about audio > no audio system and so on. > > that mean no ros, if we play after SLFC and we need also write > papper give > up our copyright to > them. no thanks

1 0

Re: [ros-dev] Audit
by Aleksey Bragin 23 Sep '07

23 Sep '07

Well-well, please calm down, we had enough flamewars, a new one is not necessary. No decisions are made, and no decisions are going to be made without agreement with all our developers. WBR, Aleksey Bragin. On Sep 23, 2007, at 3:40 PM, Ged wrote: > James Tabor wrote: >> >> Wine is the Pot calling the kettle BLACK! Bunch of RE coders using >> smoke and >> mirrors when it comes to case testing! It's a easy out! >> > > I agree with Aleksey, we must adopt their way of working in the > hope of > rebuilding the bridges and additionally improving our credability > within > the open source world. If this means offering ourselves to an external > audit, then so be it. We can't be a hobbiest project forever if we aim > to bring ReactOS to the public sector as a viable alternative to > Windows. > > > Ged.

1 0

Re: [ros-dev] Open Sound System porting
by reactos-development＠silverblade.co.uk 23 Sep '07

23 Sep '07

Thanks for all the replies so far. I find it quite insane that MSDN compares ioctl to DeviceIoControl. Whilst they achieve the same results, the actual parameters used etc. are entirely different. I'm not sure if Steven's suggestion would work (ie, use ws2_32) since, to my knowledge, that particular implementation is specific to sockets. Probably the best way around this then, would be to make an ioctl wrapper that takes the OSS-specific IOCTL codes, and translates them into custom NT IOCTL codes. The wrapper would take things like structures being passed via the ioctl and send them via DeviceIoControl instead. It does seem like a fair amount of work but if an appropriate "wrapper" is created, it could work... Original Message: ----------------- From: King InuYasha ngompa13(a)gmail.com Date: Sat, 22 Sep 2007 10:28:50 -0500 To: ros-dev(a)reactos.org Subject: Re: [ros-dev] Open Sound System porting Couldn't the source be patched to use DeviceIOControl instead of ioctl? According to MSDN about porting from UNIX to Win32, ioctl maps directly to DeviceIOControl, so it could be possible to simply change all the instances of ioctl to DeviceIOControl... On 9/22/07, Aleksey Bragin <aleksey(a)reactos.org> wrote: > > I didn't thoroughly look through the OSS source code, but if it has > some kind of platform-independent design in mind, then I would really > recommend porting, and porting with as minimal changes to the > original source code required (you probably are going to need a > wrapper-library, for ioctls at least, plus NT-specific parts). > > I may help too, because of the usb stack wrapping I did a while ago. > > > WBR, > Aleksey Bragin. > > > > > 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? > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > -------------------------------------------------------------------- mail2web.com What can On Demand Business Solutions do for you? http://link.mail2web.com/Business/SharePoint

3 2

Re: [ros-dev] Open Sound System porting
by reactos-development＠silverblade.co.uk 22 Sep '07

22 Sep '07

4Front. Apparently it's "better". Original Message: ----------------- From: King InuYasha ngompa13(a)gmail.com Date: Sat, 22 Sep 2007 16:32:11 -0500 To: reactos-development(a)silverblade.co.uk, ros-dev(a)reactos.org Subject: Re: [ros-dev] Open Sound System porting Which OSS implementation are you looking at? The OSS/Free one, or the OSS one from 4Front? On 9/22/07, reactos-development(a)silverblade.co.uk < reactos-development(a)silverblade.co.uk> wrote: > > Thanks for all the replies so far. > > I find it quite insane that MSDN compares ioctl to DeviceIoControl. Whilst > they achieve > the same results, the actual parameters used etc. are entirely different. > > I'm not sure if Steven's suggestion would work (ie, use ws2_32) since, to > my knowledge, > that particular implementation is specific to sockets. > > Probably the best way around this then, would be to make an ioctl wrapper > that takes the > OSS-specific IOCTL codes, and translates them into custom NT IOCTL codes. > The wrapper > would take things like structures being passed via the ioctl and send them > via > DeviceIoControl instead. > > It does seem like a fair amount of work but if an appropriate "wrapper" is > created, it > could work... > > > Original Message: > ----------------- > From: King InuYasha ngompa13(a)gmail.com > Date: Sat, 22 Sep 2007 10:28:50 -0500 > To: ros-dev(a)reactos.org > Subject: Re: [ros-dev] Open Sound System porting > > > Couldn't the source be patched to use DeviceIOControl instead of ioctl? > According to MSDN about porting from UNIX to Win32, ioctl maps directly to > DeviceIOControl, so it could be possible to simply change all the > instances > of ioctl to DeviceIOControl... > > On 9/22/07, Aleksey Bragin <aleksey(a)reactos.org> wrote: > > > > I didn't thoroughly look through the OSS source code, but if it has > > some kind of platform-independent design in mind, then I would really > > recommend porting, and porting with as minimal changes to the > > original source code required (you probably are going to need a > > wrapper-library, for ioctls at least, plus NT-specific parts). > > > > I may help too, because of the usb stack wrapping I did a while ago. > > > > > > WBR, > > Aleksey Bragin. > > > > > > > > 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? > > _______________________________________________ > > Ros-dev mailing list > > Ros-dev(a)reactos.org > > http://www.reactos.org/mailman/listinfo/ros-dev > > > > > -------------------------------------------------------------------- > mail2web.com What can On Demand Business Solutions do for you? > http://link.mail2web.com/Business/SharePoint > > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > -------------------------------------------------------------------- mail2web - Check your email from the web at http://link.mail2web.com/mail2web

2 1

Audit
by Aleksey Bragin 22 Sep '07

22 Sep '07

Hello, I recently asked Klemens to remove audit progress bar from the frontpage. Some wonder: why? The simple answer is obvious: Audit doesn't have anything to do with end-users, testers, or patch- submitters of the project. Audit is an effort run by ReactOS Development Team, and has only one goal: Reduce possible legal problems in future, when, and if, ReactOS starts to have commercial appliances. The process with file locking-unlocking is only the top of the iceberg, there is a huge amount of work to be done in order to maintain solid legal base for all our code. It can't be measured with a single progressbar, nor it needs to. It can't be done only with the help of ReactOS Development Team, a third party code reviewer is a must. We plan that too, but for later time, when there are more stable modules in ReactOS. Legal base consists of a number of factors: authorship and sources of the code and their legality, availability of documentation for certain interfaces and algorithms, development of test cases showing internal behaviour of certain API functions, licensing issues, 3rd party code reviewing process results, etc, etc, etc. I think it's rather clear to see that measuring all the above factors in a single percentage number can't sound serious for a project, nor can it be a real value of cleannes of the project. The respective Audit wikipage needs to be updated too WRT this email. Also please note, our audit process results are fully seen via SVN commits, so there is no hiding involved. With the best regards, Aleksey Bragin.

2 1

Re: [ros-dev] Open Sound System porting
by Aleksey Bragin 22 Sep '07

22 Sep '07

I didn't thoroughly look through the OSS source code, but if it has some kind of platform-independent design in mind, then I would really recommend porting, and porting with as minimal changes to the original source code required (you probably are going to need a wrapper-library, for ioctls at least, plus NT-specific parts). I may help too, because of the usb stack wrapping I did a while ago. WBR, Aleksey Bragin. > > 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?

2 1

Re: [ros-dev] rbuild and HALs module optimization
by Aleksey Bragin 22 Sep '07

22 Sep '07

David, what does a kernel-dev have to do with rbuild? Also, recent massive commits to the rbuild itself, and to various .rbuild files hardly prove your "rbuild is an umaintained piece of ... stuff" theory. It's, by the least measure, offensive to Herve's (and there were a few different patches submitted by various authors submitted) work he's been doing with rbuild. Or what is a "maintained rbuild", by your definition? How more should it be maintained? Note: not improved (we have a number of improvements pending to be implemented in it), but *maintained*. Another thing is completely wrong and counter-productive: irc is a wrong place for such question, since not all devs are there all the time. Now, back to the actual question. The biggest difference between ntoskrnl and HAL is that the first is as machine-independent as possible (still including some dependent code, but it's conditionally included), while the latter is actually very hardware dependent, so it does not make sense to unite x86 and PowerPC HALs, because they are going to contain just simply different source code. With the best regards, Aleksey Bragin. On Sep 21, 2007, at 8:11 PM, David Hinz wrote: > > Marc Piulachs schrieb: >> Does anyone agree with me on this? Maybe I’m missing something >> here but >> I would like to improve it. > > I don't think you will have much luck getting an answer, as afaik > rbuild > is currently more or less unmaintained and our kernel-dev left the > project. > > Maybe arty or hpoussin do have an oppinion regarding your question, > but > they seem to be rather busy most of the time... > > Have you tried asking on irc? Most devs hang out there... > > Greets, > > David Hinz

3 2

Open Sound System porting
by reactos-development＠silverblade.co.uk 22 Sep '07

22 Sep '07

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

5 5

Documentation
by Colin Finck 21 Sep '07

21 Sep '07

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

7 16

Re: [ros-dev] Bugzilla's bug assigning process
by Aleksey Bragin 21 Sep '07

21 Sep '07

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.

2 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