Ros-dev

ros-dev@reactos.org

5789 discussions

by Rama Teja G

Dear all, I'm a student interested in working for ReactOS. I've previously worked with ReactOS(not GSOC). I've looked into xHci project, as I don't have prev experience in writing drivers I'm a bit baffled. >From what I've seen Johannes Anderwald , Michael Martin and Hervé Poussineau have contributed most to the development of USB code. Is anyone available to mentor me for this project? Thanks in advance, Rama Teja.G

8 years

Gsoc audio project mentor status

by Pranay Pratyush

Hi there, I am under the impression that no mentor can be assigned to my audio mixer proposal. Can someone confirm this or the opposite? If so I would like to create a proposal on "Improving the quality of our Registry Hive implementation", but since I don't have much time left and I haven't gone through the relevant code, I would really appreciate it if you point me to the mentor for this project. Thank You -- *Pranay Pratyush,* 3rd year undergraduate , Computer Science and Engineering Department Indian Institute Of Technology, Kharagpur --

8 years

Google summer of code.

by atemafac kingsley

Hello . I am call atemafac kingsley. i am an undergraduate computer engineering student. please i will like to take part on google summer of code . this is the time i am applying . so i will like to be directed on how i can contribute . thanks. University of Beua Cameroon.

8 years

Opening up #reactos-dev to the public

by Colin Finck

Hi all! As you all know, our #reactos-dev IRC channel has been a moderated IRC channel for decades, and only operators (devs) and voiced people can talk. While we always tried to keep discussions dev-related there, no topic has ever been enforced on #reactos. The result is that I see a notable number of developers only on #reactos-dev these days. This is a pretty bad situation! Emerging developers hardly have a way to interact with all existing devs on IRC. Often enough, legitimate questions from them remain unanswered on #reactos. Moreover, we don't maintain the list of voiced people thoroughly, so even some contributors have to ask for temporary voice on #reactos-dev. Keep in mind that we're currently in the GSoC phase where students shall submit their proposals and get in touch with the developers. How are they going to do this on IRC if #reactos-dev continues to be an exclusive club? Because of these reasons, I'm proposing to remove the moderation bit on #reactos-dev and let everybody talk there. Its development topic should be enforced though! As soon as people get too off-topic, they should be directed to #reactos and kicked if nothing else helps. Given that all devs are already operators on #reactos-dev, it's fully in their hands. Cheers, Colin

8 years

Re: [ros-dev] Opening up #reactos-dev to the public

by Alex Ionescu

I don't agree. Maintain the auto-voice lists and get someone in charge of operations, like I used to be for many years on IRC. Instead, why not create a #reactos-gsoc or something? Best regards, Alex Ionescu On Fri, Mar 24, 2017 at 11:19 AM, Mark Jansen <learn0more+ros(a)gmail.com> wrote: > We can always try it out? > If it doesnt work, restoring it is a simple as setting a flag on the > channel. > > On 24 March 2017 at 16:31, David Quintana (gigaherz) <gigaherz(a)gmail.com> > wrote: > > I disagree -- if we can be firm about the channel being only for > development > > talk, things should remain mostly as they are now. > > > > In any community, there's inevitably going to be idle talk, offtopic > > conversations, etc. If you only have ONE place to talk in, all those > thigns > > are going to be mixed in with actual dev talk, but if you have clear > rooms > > set for each thing, the majority of people will be happy to leave all the > > offtopic talk to the main channel, and dev talk to the dev channel. > > > > It works for plenty other projects and communities so there's no reason > to > > be pessimistic and think that "our idiots are worse". It's simply not > true. > > > > I vote for trying, and we can always put back the +m if things get out of > > hand. > > > > On 24 March 2017 at 16:13, Hermès BÉLUSCA-MAÏTO <hermes.belusca(a)sfr.fr> > > wrote: > >> > >> I don’t approve the idea. The fact is that if the devs quit originally > >> #reactos, it’s because it was generally too noisy, etc… . If we remove > the > >> moderation irc bit in #reactos-dev, you may expect the same phenomenon > to > >> occur in #reactos-dev too. > >> > >> > >> > >> De : Ros-dev [mailto:ros-dev-bounces@reactos.org] De la part de David > >> Quintana (gigaherz) > >> Envoyé : vendredi 24 mars 2017 11:35 > >> À : ReactOS Development List > >> Objet : Re: [ros-dev] Opening up #reactos-dev to the public > >> > >> > >> > >> I approve the idea. > >> > >> > >> > >> On 24 March 2017 at 11:21, Colin Finck <colin(a)reactos.org> wrote: > >> > >> Hi all! > >> > >> As you all know, our #reactos-dev IRC channel has been a moderated IRC > >> channel for decades, and only operators (devs) and voiced people can > >> talk. While we always tried to keep discussions dev-related there, no > >> topic has ever been enforced on #reactos. The result is that I see a > >> notable number of developers only on #reactos-dev these days. > >> > >> This is a pretty bad situation! Emerging developers hardly have a way to > >> interact with all existing devs on IRC. Often enough, legitimate > >> questions from them remain unanswered on #reactos. Moreover, we don't > >> maintain the list of voiced people thoroughly, so even some contributors > >> have to ask for temporary voice on #reactos-dev. > >> > >> Keep in mind that we're currently in the GSoC phase where students shall > >> submit their proposals and get in touch with the developers. > >> How are they going to do this on IRC if #reactos-dev continues to be an > >> exclusive club? > >> > >> Because of these reasons, I'm proposing to remove the moderation bit on > >> #reactos-dev and let everybody talk there. > >> Its development topic should be enforced though! As soon as people get > >> too off-topic, they should be directed to #reactos and kicked if nothing > >> else helps. Given that all devs are already operators on #reactos-dev, > >> it's fully in their hands. > >> > >> > >> Cheers, > >> > >> Colin > >> > >> _______________________________________________ > >> Ros-dev mailing list > >> Ros-dev(a)reactos.org > >> http://www.reactos.org/mailman/listinfo/ros-dev > >> > >> > >> > >> > >> _______________________________________________ > >> Ros-dev mailing list > >> Ros-dev(a)reactos.org > >> http://www.reactos.org/mailman/listinfo/ros-dev > > > > > > > > _______________________________________________ > > Ros-dev mailing list > > Ros-dev(a)reactos.org > > http://www.reactos.org/mailman/listinfo/ros-dev > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

8 years, 1 month

Re: [ros-dev] [ros-diffs] [gadamopoulos] 74151: [BROWSEUI] -CExplorerBand: Stub QueryService method and set the site of the context menu so as to let the context menu find the SID_IShellBrowser when the open menu item is cl...

by Thomas Faber

On 2017-03-12 10:48, gadamopoulos(a)svn.reactos.org wrote: > // *** IServiceProvider methods *** > HRESULT STDMETHODCALLTYPE CExplorerBand::QueryService(REFGUID guidService, REFIID riid, void **ppvObject) > { > - UNIMPLEMENTED; > - return E_NOTIMPL; > + /* FIXME: we probably want to handle more services here */ > + return IUnknown_QueryService(pSite, SID_SShellBrowser, riid, ppvObject); > } This seems dangerous. If someone requests something other than SID_SShellBrowser, we'll just return them a different object without any indication that something is wrong. Shouldn't we either pass guidService down or fail somehow if it's not asking for ShellBrowser?

8 years, 1 month

Re: [ros-dev] [ros-diffs] [khornicek] 74209: [RAPPS] - Add a custom build of the Mesa 3D Graphics Library. This build contains mesa, gallium and llvmpipe. It provides an enormous performance boost over the software implemen...

by Colin Finck

khornicek(a)svn.reactos.org wrote: > [RAPPS] > - Add a custom build of the Mesa 3D Graphics Library. This build > contains mesa, gallium and llvmpipe. It provides an enormous > performance boost over the software implementation present in > opengl32. That sounds fantastic! I'm just wondering, if it is better than our current OpenGL software rendering in every regard, can't we just have it as the default in our tree? - Colin

8 years, 1 month

Re: [ros-dev] [ros-diffs] [sgasiorek] 74179: [DXG] DdHmgLock - use PLONG instead of PBYTE.

by Kay Dohmann

This looks wrong to me since both lines produce different results. For example: (PBYTE)0x00000000 + 4 == (PBYTE)0x00000004 but (PLONG)0x00000000 + 4 == (PLONG)0x00000010 > if ( Index < gcMaxDdHmgr ) > { > - pEntry = (PDD_ENTRY)((PBYTE)gpentDdHmgr + (sizeof(DD_ENTRY) * Index)); > + pEntry = (PDD_ENTRY)((PLONG)gpentDdHmgr + (sizeof(DD_ENTRY) * Index)); > > if ( VerifyObjectOwner(pEntry) ) > { > >

8 years, 1 month

New dev doubts/questions

by Pranay Pratyush

Hi there, I feel extremely enthusiastic about contributing to reactos through gsoc. I looked into the idea list for 2017 and "Audio Mixer" looks the most interesting to me. But I have absolutely no experience writing windows services, let alone kernel streaming. I have experience with linux internals and I have used Windows APIs in the past. I am really interested in this. How do I get a mental map of what all things I need to do to achieve this? What all stuff do I learn for this and how? Also suggest me if I should drop this entirely and conribute through coding something less "ambitious". -- *Pranay Pratyush,* 3rd year undergraduate , Computer Science and Engineering Department Indian Institute Of Technology, Kharagpur --

8 years, 1 month

Legal advice concerning contribution to ReactOS

by tobias.k＠posteo.de

Hi, I've a question concerning legal restrictions. As mentioned on this page https://reactos.org/wiki/Subversion#Prerequisites I'm not allowed to contribute to ReactOS when I'm an employee of Microsoft or of any subsidiary of Microsoft. In the past, I worked for a German company which was a Certified Partner of Microsoft. As far as I know, it was not a subsidiary of Microsoft. It's not even listed here https://en.wikipedia.org/wiki/List_of_mergers_and_acquisitions_by_Microsoft (but I don't know if this list is complete). Since a Certified Partner is not automatically a MS subsidiary or equivalent to it in a sense (as I think), there shouldn't be a problem for me contributing to ReactOS. Is there anybody who can confirm that? Tobias

8 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev