Ros-dev

ros-dev@reactos.org

5789 discussions

by Александр

12 years

Re: [ros-dev] [ros-diffs] [hbelusca] 58770: [REACTOS] Merge of the ros-csrss branch created with a three-fold purpose: - Use the new Windows-compatible Client-Server Runtime Subsystem (csrss + csrsrv) written by Alex Ionesc...

by Ged Murphy

Fantastic work Hermes! Congrats On 15/04/2013 20:32, "hbelusca(a)svn.reactos.org" <hbelusca(a)svn.reactos.org> wrote: >Author: hbelusca >Date: Mon Apr 15 19:32:00 2013 >New Revision: 58770 > >URL: http://svn.reactos.org/svn/reactos?rev=58770&view=rev >Log: >[REACTOS] > >Merge of the ros-csrss branch created with a three-fold purpose: > >- Use the new Windows-compatible Client-Server Runtime Subsystem (csrss + >csrsrv) >written by Alex Ionescu to replace the old hacked one. Also the CSR >client part, >residing in ntdll, is updated. Some work also done on the dlls side, which >communicate with CSR, namely kernel32. > >- Replace our very old win32csr.dll CSR server by the collection >basesrv.dll / >winsrv.dll as it is done under Windows. > >- Since the console subsystem is (for historical purposes on Windows) the >only subsystem which exploits all the possibilities of the CSR, I decided >to >put it in a new CSR dll called 'consrv.dll', even if on Windows it is >included >together with other APIs inside the winsrv dll (since Windows NT 3.1 >release) >(I took the name 'consrv' from the dll where it was included in Windows >NT 3.1 >beta from October 1991). Some work was also done on its internal >architecture >(the external interface is of course unchanged for compatibility reasons) >and a >two-layer approach was developed, using the existing idea of console >functions + >GUI or TUI we already had in win32csr: > * the "console server" which dialogs with the console applications, >and which maintains a list of all the created consoles. > * different "front-ends" corresponding to where you want to output >the information (~= console hardware) (Work-In-Progress). >Another idea would be to make those front-ends dynamically-loadable >(instead >of being compiled inside consrv). >- I also fixed some parts of the console properties dialog box. > >More information can be found in >http://www.reactos.org/archives/public/ros-dev/2013-April/016121.html > >CORE-122 CORE-2510 CORE-7002 #resolve #comment Committed in revision >r58xxx.

12 years

TR: Future merge of the ros-csrss branch into the trunk

by Hermès BÉLUSCA - MAÏTO

Hello everybody, This message is to remind you that the merge will happen on Monday 15. (of this month) in the evening (~= 19 or 20:00 UTC). Hermès -----Message d'origine----- De : Hermès BÉLUSCA - MAÏTO [mailto:hermes.belusca@sfr.fr] Envoyé : mardi 9 avril 2013 12:48 À : 'ReactOS Development List' Objet : Future merge of the ros-csrss branch into the trunk Hi all ! I'm writing this mail to announce to you that in one week (if everything works as expected till this time) I will be ready to merge my ros-csrss branch into our current codebase. [...]

12 years

KVM testbot upgraded

by Pierre Schweitzer

Hi guys, the KVM testbot has been upgraded from 0.12.3 to 1.0. This means that you could find new regressions. On testman, the starting revision at which it has been used is: 58727. It's interesting to note that previously the KVM testbot was running headless (no VNC display on ReactOS VM). With newer release, this is impossible. Either ReactOS or KVM locks up because of this. See: http://build.reactos.org/builders/Linux_AMD64_1%20KVM-Test/builds/2710/step… With my best regards, -- Pierre Schweitzer<pierre(a)reactos.org> System Administrator ReactOS Foundation

12 years

Future merge of the ros-csrss branch into the trunk

by Hermès BÉLUSCA - MAÏTO

Hi all ! I'm writing this mail to announce to you that in one week (if everything works as expected till this time) I will be ready to merge my ros-csrss branch into our current codebase. The ros-csrss branch (http://svn.reactos.org/svn/reactos/branches/ros-csrss/?view=log) was started 5 months ago (October 14, 2012 to be precise) with a three-fold purpose: - Use the new Windows-compatible Client-Server Runtime Subsystem (csrss + csrsrv) written by Alex Ionescu, unused at the moment and which currently lives in trunk/reactos/subsystems/csr/, and as such was a replacement for the older one in trunk/reactos/subsystems/win32/csrss/. This last one was progressively hacked to include functionalities from the new csrss; however most of the old code remained and as such it was a big hack. Also the CSR client part, residing in ntdll, was updated (thanks to comments put by Alex inside it). To communicate between the server-part and the client-part, some messaging protocol is used (thanks to LPC); the used structures were not so up-to-date, but the new ones were in the code, not used. So I could use them instead of the older ones. That meant that some work was needed in ntdll (as previously stated). Disregarding the details (you can see them in the commit log), I also had to rework a little bit on the dlls which communicate with CSR, namely kernel32. - Replacing our very old win32csr.dll csr server by the collection basesrv / winsrv as it is done under Windows. For that I tried to match accurately our existing code with what should exist on Windows according to this list of CSR servers APIs : http://j00ru.vexillium.org/csrss_list/api_list.html . - Since the console subsystem is (for historical purposes on Windows) the only subsystem which exploits all the possibilities of the CSR, much of the work in the branch was done to make it working with the new csrss. Even if on Windows it is included together with other APIs inside the winsrv dll (since Windows NT 3.1 release), I decided to put it in a separate dll, called consrv, on ReactOS (I took the name from the dll where it was included in Windows NT 3.1 beta from October 1991). Also, because I believe that the console subsystem is something that, on Windows, was somewhat neglected (no ANSI control, (almost?)no TTY-like flavour...) I decided to work on its internal architecture (the exterior one being unchanged for compatibility reasons) such as to exacerbate the following things: * the "console server" which dialogs with the console applications, and which maintains a list of all the created consoles. * different "front-ends" corresponding to where you want to output the information (~= console hardware) (it is of course work-in-progress). At the moment only one is working: the GUI console. I have to make the TUI interfacing correctly with the rest of the code (but since it's not used for now, it's not extremely urgent). The idea would be to have also a front-end for serial ports, so that we could interact with the serial port (with Putty if running ROS on a virtual machine, or with a serial console, etc...). And another idea would be to make those front-ends dynamically-loadable (instead of being compiled inside consrv). - I also fixed some parts of the console properties dialog box. Here is the JIRA report for the merge: http://jira.reactos.org/browse/CORE-7002 Here are the test results with revision 58723 (plus comparison with revisions 58722 and 58720): http://old.reactos.org/testman/compare.php?ids=16213,16218,16219,16221 You will see that the ntdll:exception seems to run 24 more tests, but 4 failed compared to non-patched r58723. The errors are "exception.c:821: Test failed: Eip at 0x77f2b2a3 instead of 0079000B". It would be interesting to investigate further on these failings. Also, gdi32:font executes 33 more tests, and 10 more fail, due to the Fixedsys font. A problem, already existing in trunk, remains: http://jira.reactos.org/browse/CORE-6397 (see description inside). You are encouraged to make comments, etc... etc... Cheers, Hermès. ~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~= ~=~= Documentation I've used : ========================= - The oldest trace of CSRSS in NT 3.1 beta (where I've found the existence of csrsrv.dll, which was merged with winsrv.dll in the 3.1 release and the subsequent versions of NT): http://www.logotypes.se/NT310CSRSS.txt - "Windows CSRSS cross-version API Table" http://j00ru.vexillium.org/?p=349 and the subsequent links. - "Windows CSRSS Write Up: the basics (part 1/1)" http://j00ru.vexillium.org/?p=492 - "Windows CSRSS Write Up: Inter-process Communication (part 1/3)" http://j00ru.vexillium.org/?p=502 - "Windows CSRSS Write Up: Inter-process Communication (part 2/3)" http://j00ru.vexillium.org/?p=527 (the messaging system CSR server <--> client is explained here) (the part 3/3 seems to not exist) - "CVE-2011-1281: A story of a Windows CSRSS Privilege Escalation vulnerability" http://j00ru.vexillium.org/?p=893 and http://mysterie.fr/blog/2011/07/31/cve-2011-1281-privilege-escalation-in-csr ss-proof-of-concept/ - Something that would be interesting for console and thread desktops : "Defeating Windows Driver Signature Enforcement #2: CSRSS and thread desktops" http://j00ru.vexillium.org/?p=1393 - " Windows Subsytem Csrss" (in French) http://www.ivanlef0u.tuxfamily.org/?p=188 - "Story of a dumb patch", Cesar Cerrudo, http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf - CsrWalker : http://forum.sysinternals.com/csrwalker-processes-detection-from-user-mode_t opic15457.html - Concerning console modes flags: https://sites.google.com/site/marckupper/utilities/setconsolemode - Documentation about consoles on MSDN: http://msdn.microsoft.com/en-us/library/windows/desktop/ms682010(v=vs.85).as px - "Custom console hosts on Windows 7 (Hack in the Box Magazine #4)" http://magazine.hitb.org/issues/HITB-Ezine-Issue-004.pdf - "Windows CSRSS Tips & Tricks (Hack in the Box Magazine #5)" http://magazine.hitb.org/issues/HITB-Ezine-Issue-005.pdf - "Win32 Console (Wikipedia)" and the note 3 of the article: http://en.wikipedia.org/wiki/Win32_console#cite_note-3 - Undocumented flags of ConsoleProcess: http://www.catch22.net/tuts/undocumented-createprocess

12 years

Fwd: [ReactOS] Your organization application has been rejected.

by Amine Khaldi

-------- Original Message -------- Subject: [ReactOS] Your organization application has been rejected. Date: Mon, 08 Apr 2013 18:43:14 +0000 From: no-reply(a)google-melange.appspotmail.com To: amine.khaldi(a)reactos.org Thank you for submitting "ReactOS" organization application to Google Summer of Code 2013. Unfortunately, we were unable to accept your organization's application at this time. Every year we receive many more applications than we are able to accommodate, and we would encourage you to reapply for future instances of the program. If you would like some general feedback on why your organization was not accepted, please consider attending the IRC meeting in #gsoc on Freenode on Friday, April 19, 2013 at 16:00 UTC. Best regards, Google Open Source Programs

12 years

Linux builder offline

by Pierre Schweitzer

Hi, due to hardware issues, the Linux builder is currently offline. Can't provide any ETA for recovery yet. Sorry for the troubles. With my best regards, -- Pierre Schweitzer<pierre at reactos.org> System Administrator ReactOS Foundation

12 years

Re: [ros-dev] [ros-diffs] [jgardou] 58660: [MESA32] * Disable SSE optimizations, as they only cause mayhem.

by Timo Kreuzer

What exactly does it cause? And shouldn't we rather fix that, instead of disabling optimizations? mesa is already slow enough. Am 03.04.2013 14:02, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Wed Apr 3 12:02:58 2013 > New Revision: 58660 > > URL: http://svn.reactos.org/svn/reactos?rev=58660&view=rev > Log: > [MESA32] > * Disable SSE optimizations, as they only cause mayhem. > > Modified: > trunk/reactos/dll/opengl/mesa/src/mesa/CMakeLists.txt > > Modified: trunk/reactos/dll/opengl/mesa/src/mesa/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/opengl/mesa/src/mesa/C… > ============================================================================== > --- trunk/reactos/dll/opengl/mesa/src/mesa/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/dll/opengl/mesa/src/mesa/CMakeLists.txt [iso-8859-1] Wed Apr 3 12:02:58 2013 > @@ -33,17 +33,18 @@ > x86/3dnow_xform3.S > x86/3dnow_xform4.S > x86/3dnow_normal.S > - x86/sse_xform1.S > - x86/sse_xform2.S > - x86/sse_xform3.S > - x86/sse_xform4.S > - x86/sse_normal.S > + # x86/sse_xform1.S > + # x86/sse_xform2.S > + # x86/sse_xform3.S > + # x86/sse_xform4.S > + # x86/sse_normal.S > x86/read_rgba_span_x86.S) > add_definitions( > -DUSE_X86_ASM > -DUSE_MMX_ASM > -DUSE_3DNOW_ASM > - -DUSE_SSE_ASM) > + # -DUSE_SSE_ASM > + ) > endif() > > list(APPEND SOURCE > > >

12 years, 1 month

Re: [ros-dev] [ros-diffs] [akhaldi] 58662: [PSDK] * Import DEFAULT_UNREACHABLE from Wine.

by Timo Kreuzer

The last definition is not correct, it will not compile. You need "default: (void)0;" or "default: break;" And the thing should also go to ntdef.h Am 03.04.2013 23:17, schrieb akhaldi(a)svn.reactos.org: > Author: akhaldi > Date: Wed Apr 3 21:16:57 2013 > New Revision: 58662 > > URL: http://svn.reactos.org/svn/reactos?rev=58662&view=rev > Log: > [PSDK] > * Import DEFAULT_UNREACHABLE from Wine. > > Modified: > trunk/reactos/include/psdk/winnt.h > > Modified: trunk/reactos/include/psdk/winnt.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/psdk/winnt.h?rev=5… > ============================================================================== > --- trunk/reactos/include/psdk/winnt.h [iso-8859-1] (original) > +++ trunk/reactos/include/psdk/winnt.h [iso-8859-1] Wed Apr 3 21:16:57 2013 > @@ -415,6 +415,15 @@ > typedef DWORD FLONG; > > #define C_ASSERT(expr) extern char (*c_assert(void)) [(expr) ? 1 : -1] > + > +/* Eliminate Microsoft C/C++ compiler warning 4715 */ > +#if defined(_MSC_VER) && (_MSC_VER > 1200) > +# define DEFAULT_UNREACHABLE default: __assume(0) > +#elif defined(__clang__) || (defined(__GNUC__) && ((__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 5)))) > +# define DEFAULT_UNREACHABLE default: __builtin_unreachable() > +#else > +# define DEFAULT_UNREACHABLE default: > +#endif > > #include "intrin.h" > > > >

12 years, 1 month

Re: [ros-dev] [ros-diffs] [jgardou] 58650: [CMICPL] - This is a C++ module

by Timo Kreuzer

What about integrating set_cpp() into set_module_type, since that already handles a bunch of other things like UNICODE etc? Am 02.04.2013 22:04, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Tue Apr 2 20:04:31 2013 > New Revision: 58650 > > URL: http://svn.reactos.org/svn/reactos?rev=58650&view=rev > Log: > [CMICPL] > - This is a C++ module > > Modified: > trunk/reactos/drivers/wdm/audio/drivers/CMIDriver/cpl/CMakeLists.txt > > Modified: trunk/reactos/drivers/wdm/audio/drivers/CMIDriver/cpl/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/wdm/audio/drivers/… > ============================================================================== > --- trunk/reactos/drivers/wdm/audio/drivers/CMIDriver/cpl/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/drivers/wdm/audio/drivers/CMIDriver/cpl/CMakeLists.txt [iso-8859-1] Tue Apr 2 20:04:31 2013 > @@ -1,3 +1,5 @@ > + > +set_cpp() > > add_library(cmicpl SHARED > cmicpl.cpp > @@ -10,6 +12,6 @@ > shell32 > msvcrt > kernel32 > - ntdll) > +) > > add_cd_file(TARGET cmicpl DESTINATION reactos/system32/drivers FOR all) > > >

12 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