- Ros-dev - ReactOS.org

by Mark Jansen

The shell extension 'slayer' will soon be removed. It has been surpassed by the shell extension 'acppage'. Since neither of the modules is yet active, this should not pose a problem. Related issues: CORE-10375 and CORE-13111 Regards, Mark.

8 years, 1 month

1
0
0 0

Test KVM AHK Bot Upgrade

by Sylvain Petreolle

Hello all, I'm currently upgrading my AHK Testbot to Fedora 25, 24 only receives backports and Fedora 26 is already on the way. I never upgraded it before, so I don't know if it will take one or several hours to be back online. Kind regards, Sylvain Petreolle

8 years, 1 month

1
0
0 0

Re: [ros-dev] [ros-diffs] [tfaber] 74305: [NTOS:KE] - Gracefully handle page faults during V86 code execution. This is a bit of a hack because with our limited use of V86 code it is unclear how a page fault can even occur. ...

by Alex Ionescu

So why implement this code path if we have nothing that hits it? Best regards, Alex Ionescu On Fri, Apr 14, 2017 at 4:18 AM, <tfaber(a)svn.reactos.org> wrote: > Author: tfaber > Date: Fri Apr 14 11:18:22 2017 > New Revision: 74305 > > URL: http://svn.reactos.org/svn/reactos?rev=74305&view=rev > Log: > [NTOS:KE] > - Gracefully handle page faults during V86 code execution. This is a bit > of a hack because with our limited use of V86 code it is unclear how a page > fault can even occur. > CORE-12993 #resolve > > Modified: > trunk/reactos/ntoskrnl/include/internal/i386/ke.h > trunk/reactos/ntoskrnl/ke/i386/traphdlr.c > trunk/reactos/ntoskrnl/vdm/vdmexec.c > > Modified: trunk/reactos/ntoskrnl/include/internal/i386/ke.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ > ntoskrnl/include/internal/i386/ke.h?rev=74305&r1=74304&r2=74305&view=diff > ============================================================ > ================== > --- trunk/reactos/ntoskrnl/include/internal/i386/ke.h [iso-8859-1] > (original) > +++ trunk/reactos/ntoskrnl/include/internal/i386/ke.h [iso-8859-1] Fri > Apr 14 11:18:22 2017 > @@ -478,6 +478,12 @@ > NTAPI > VdmDispatchBop( > IN PKTRAP_FRAME TrapFrame > +); > + > +BOOLEAN > +NTAPI > +VdmDispatchPageFault( > + _In_ PKTRAP_FRAME TrapFrame > ); > > BOOLEAN > > Modified: trunk/reactos/ntoskrnl/ke/i386/traphdlr.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ > ntoskrnl/ke/i386/traphdlr.c?rev=74305&r1=74304&r2=74305&view=diff > ============================================================ > ================== > --- trunk/reactos/ntoskrnl/ke/i386/traphdlr.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ke/i386/traphdlr.c [iso-8859-1] Fri Apr 14 > 11:18:22 2017 > @@ -1304,8 +1304,20 @@ > UNIMPLEMENTED_FATAL(); > } > #endif > + > /* Check for VDM trap */ > - ASSERT((KiVdmTrap(TrapFrame)) == FALSE); > + if (KiVdmTrap(TrapFrame)) > + { > + DPRINT1("VDM PAGE FAULT at %lx:%lx for address %lx\n", > + TrapFrame->SegCs, TrapFrame->Eip, Cr2); > + if (VdmDispatchPageFault(TrapFrame)) > + { > + /* Return and end VDM execution */ > + DPRINT1("VDM page fault with status 0x%lx resolved\n", > Status); > + KiEoiHelper(TrapFrame); > + } > + DPRINT1("VDM page fault with status 0x%lx NOT resolved\n", > Status); > + } > > /* Either kernel or user trap (non VDM) so dispatch exception */ > if (Status == STATUS_ACCESS_VIOLATION) > > Modified: trunk/reactos/ntoskrnl/vdm/vdmexec.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ > ntoskrnl/vdm/vdmexec.c?rev=74305&r1=74304&r2=74305&view=diff > ============================================================ > ================== > --- trunk/reactos/ntoskrnl/vdm/vdmexec.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/vdm/vdmexec.c [iso-8859-1] Fri Apr 14 > 11:18:22 2017 > @@ -239,7 +239,7 @@ > KeLowerIrql(OldIrql); > return STATUS_INVALID_SYSTEM_SERVICE; > } > - > + > /* Now do the VDM Swap */ > VdmSwapContext(VdmFrame, &VdmTib->MonitorContext, &VdmContext); > > @@ -269,7 +269,7 @@ > > /* Make a copy of the monitor context */ > Context = VdmTib->MonitorContext; > - > + > /* Check if V86 mode was enabled or the trap was edited */ > if ((Context.EFlags & EFLAGS_V86_MASK) || (Context.SegCs & > FRAME_EDITED)) > { > @@ -291,7 +291,7 @@ > /* Remove real IF flag */ > VdmTib->VdmContext.EFlags &= ~EFLAGS_INTERRUPT_MASK; > } > - > + > /* Turn off VIP and VIF */ > TrapFrame->EFlags &= ~(EFLAGS_VIP | EFLAGS_VIF); > VdmTib->VdmContext.EFlags &= ~(EFLAGS_VIP | EFLAGS_VIF); > @@ -362,4 +362,45 @@ > return TRUE; > } > > - > +BOOLEAN > +NTAPI > +VdmDispatchPageFault( > + _In_ PKTRAP_FRAME TrapFrame) > +{ > + NTSTATUS Status; > + PVDM_TIB VdmTib; > + > + PAGED_CODE(); > + > + /* Get the VDM TIB so we can terminate V86 execution */ > + Status = VdmpGetVdmTib(&VdmTib); > + if (!NT_SUCCESS(Status)) > + { > + /* Not a proper VDM fault, keep looking */ > + DPRINT1("VdmDispatchPageFault: no VDM TIB, Vdm=%p\n", > NtCurrentTeb()->Vdm); > + return FALSE; > + } > + > + /* Must be coming from V86 code */ > + ASSERT(TrapFrame->EFlags & EFLAGS_V86_MASK); > + > + _SEH2_TRY > + { > + /* Fill out a VDM Event */ > + VdmTib->EventInfo.Event = VdmMemAccess; > + VdmTib->EventInfo.InstructionSize = 0; > + > + /* End VDM Execution */ > + VdmEndExecution(TrapFrame, VdmTib); > + } > + _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > + { > + Status = _SEH2_GetExceptionCode(); > + } > + _SEH2_END; > + > + /* Consider the exception handled if we succeeded */ > + DPRINT1("VdmDispatchPageFault EFlags %lx exit with 0x%lx\n", > TrapFrame->EFlags, Status); > + return NT_SUCCESS(Status); > +} > + > > >

8 years, 1 month

2
1
0 0

Re: [ros-dev] Definite Decision about ISO lifetimes at iso.reactos.org

by Colin Finck

Am 16.03.2017 um 00:00 schrieb Giannis Adamopoulos: > I was wondering if it is possible to delete every second iso instead of purging all isos before some time? That's a good idea and makes sense for the bootcd-dbg ISOs. So my final proposal is this one: bootcd-dbg: 5 years (after that every second ISO is purged) bootcd-dbgwin: 0.5 years bootcd-rel: 0.5 years bootcdregtest: 1 week livecd-dbg: 0.5 years livecd-dbgwin: 0.5 years livecd-rel: 0.5 years I'll be away until the beginning of April, so there is enough time for any objections. Otherwise, it will be set up exactly this way when I'm back. - Colin

8 years, 1 month

1
1
0 0

Building/Testing infrastructure back on steroids!

by Colin Finck

Hi all! As of today, our high-performance servers Carrier, Mothership and Testee are finally back in service for building and testing! They take over many tasks from HotelLux, the generously provided server from Aleksey, which had to bear the load of previously 3 separate machines for over a year. You should notice faster builds on the Windows buildslaves, a returned VBox testslave, and more reliable ISO downloads. The VMware testslave is not back yet, but I'll be reinstalling this one as well. In June, we also plan to upgrade our best-performing server even more, using the donated 64GB of RAM and CPU upgrades that are cheaply available these days. This should decrease build times even more! Cheers, Colin

8 years, 1 month

1
0
0 0

Vgal USB patches

by Alexander Rechitskiy

8 years, 1 month

8
13
0 0

Re: [ros-dev] Retiring rapps

by Can Tasan

Hi! What does new RAPPS bring compared to old one, could you summarize main points? I need this for Community Changelogs. Thanks! Can

8 years, 1 month

2
2
0 0

GSoC drivers mentor status

by Alexander

Cheers, I am student and i want help to develop ROS in GSoC. In part, i got intereted in drivers idea. I on 3rd year undergraduate by speciality applied mathematics and informatics and i have experience in C/C++. I would like to work in part intel high defenition audio bus driver. Can you point me to the mentor? Thank you. Best regards, Alexander

8 years, 1 month

1
0
0 0

GSoC Terminal Services mentor status

by Dumitru Savva

Greetings, I am a student that wants to work on developing ReactOS during this summer. I got interested in Terminal Services idea. I have experience with C++ (and bit of C) and Transport/Application layers network programming. I would like to work on the part that is network related. Is anyone available to mentor me for this task? Thank you. Best regards, Dumitru

8 years, 1 month

2
1
0 0

GSoC Mentor

by Muhammad abdul Rehman

Hello everyone, I am a Masters student and want to do the GSoC with this organization this summer. I have gone through the list and found some projects domain interesting but I couldn't research in the depth of the project due to resource and time constraint at the moment. I have some professional background in working with embedded software development (mostly C programming), networking stacks and an RTOS porting. Did some work in Linux development as well. I will be thankful if someone can guide me chose the best suitable project that is beneficial for myself and the organization at the same time. Currently, I have a look at following projects: Bluetooth Stack Integrating SMB into ReactOS Kernel mode test suite WebKit-based MSHTML implementation Support for the GPT Partitioning Scheme Taskbar Shell extensions If someone is interested in mentoring anyone of the above project, I will be happy to talk more on that and submit a timely proposal. Thanks a lot and best regards, -- M Abdul Rehman

8 years, 1 month

2
1
0 0

GSOC, mentor status for USB xHCI,

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, 1 month

2
1
0 0

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, 1 month

2
3
0 0

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, 1 month

3
2
0 0

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, 1 month

14
18
0 0

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

9
14
0 0

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, 2 months

1
0
0 0

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, 2 months

10
13
0 0

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, 2 months

2
1
0 0

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, 2 months

1
0
0 0

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, 2 months

4
4
0 0

JIRA/FishEye upgrade on March 8

by Colin Finck

Hi all! Let me announce a definite date for our JIRA/FishEye upgrade: Wednesday, March 8, around 9:00 UTC Expect downtimes of several hours at https://code.reactos.org and https://jira.reactos.org around this time. I can say for sure that I will have enough time on this day and the following to deal with all possible incidents that could happen during the complex upgrade. This also allows me to get direct in-person feedback from all the devs attending CLT on the weekend after that :) The upgrade to JIRA 7.x is a major one, and Atlassian recommends everyone to have a look at the new features: https://confluence.atlassian.com/migration/jira-7/server_jira_product-chang… Best regards, Colin

8 years, 2 months

6
10
0 0

Re: [ros-dev] New ideas added to GSoC Ideas list

by Can Tasan

Wine still maintains and even improves Windows 3.x support! I hope they don't give up! Can we use Wine code while implementing WoW16?

8 years, 2 months

2
3
0 0

YNT: New ideas added to GSoC Ideas list

by Can Tasan

Dear Ricardo, Firstly, Win16 application support doesn't interrupt our project. It strengthens us. On technical view, supporting them doesn't make any design change to NT architecture, apps won't be able to access hardware directly. Like any app, they'll obey the rules. Secondly, there are a number of reasons to support Win16: 1) Many people and corporations still use DOS and Win16 apps today, thus their system can't be upgraded easily. Most of the cases, DOSBOX will do the job but what if any problem occurs, or integration with system is needed? With Win16 support out of the box, people will get much more technical support and security updates. 2) Many apps released in 90s have 16 bit setups, even they are actually 32-bit. In this case, compatibility and usability of ReactOS greatly decreases. 3) Sometimes emulation may be not enough for special cases. 4) There are many games from 16 bit age which is still played today. Supporting them makes a bonus. In my opinion, this cases makes WoW16 support viable. Apologizes if I forget something and sending this twice, accidentally pressed the send button. Best regards, Can

8 years, 2 months

2
1
0 0

Re: [ros-dev] New ideas added to GSoC Ideas list

by Can Tasan

Wine still maintains and even improves Windows 3.x support! I hope they don't give up! Can we use Wine code while implementing WoW16?

8 years, 2 months

1
0
0 0

Re: [ros-dev] New ideas added to GSoC Ideas list

by Can Tasan

I also have some ideas here, not fully sure about their feasibility. Tried to be wise as much as I can. -Continuing USB work that vardanm started. Yes, I know a developer is working on that. Another joining student would be great and speed up things. -Continuing TCP/IP stack work if noone is working on rewrite. -Working on DirectX support: bringing new features, fixing bugs, optimising, if possible fixing some driver issues... -Fixing driver unloading/fallback problem (CORE-8294) I think it's a hurdle on our hardware compatibility, but not sure its priority. -Would some kind of Win32 subsystem work be too hard? -Implementing some missing things in shell. -Implementing more user mode stuff, or is it enough for now? -Extending printing support. -Fixing current audio support, if our devs don't want to tinker with it. -Implementing WoW16 support. I suppose that'll draw attention. And as said before, proper application compatibility database. :) By the way, I'm too pleased to join and see you here all! With my best regards, Can Taşan

8 years, 2 months

7
9
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev