Ros-dev

ros-dev@reactos.org

5790 discussions

by Casper Hornstrup

Hi. I've been working on getting ReactOS to build faster. By compiling fewer, but larger source files (compilation units), we can build ReactOS much faster. I estimate that we can build ReactOS 200-300% faster if we do this. See the attached patch for kernel32 for an example. On my slow box (Windows), I get the following numbers: kernel32 (1 compilation unit per file): build time: 32 seconds space consumed by object files: 52MB kernel32 (fewer compilation units): build time: 11 seconds space consumed by object files: 14MB Another advantage is the less disk space requirements. I estimate ~700-800MB will be needed for object files after this change. Compare that to the 2GB that is needed today. Gé did some testing on Linux: kernel32 (1 compilation unit per file): build time: 11.3 seconds kernel32 (fewer compilation units): build time: 4.4 seconds Some issues: * You can't mix source code files with different file name extensions in the same compilation unit (currently only *.c is supported) * There must not be duplicate definitions in the same compilation unit even though it is spread over several source code files (duplicating code is bad practice anyway). * Like when you compile a big source file, memory usage during compilation is higher than when compiling several smaller source code files, one at a time. This puts a practical limit on how large the compilation unit can be. * Every source code file in the compilation unit is recompiled after a change to one or more source code files within the compilation unit. The time needed for linking may however be significantly less (due to the fewer, much smaller object files) so it may be faster in the end. * Pre-compiled headers are not easy to support, while at the same time maintaining compatibility with MSVC and one source code file per compilation unit mode. Currently PCHs are disabled for a module if the module has compilation units with more than one source code file in it. While compiling kernel32 as one big compilation unit, GCC required 60MB of virtual memory. What is an acceptable memory usage? It determines how large we can make the compilation units and affects how fast we can build ReactOS. Now we have 300+ modules that need to be split into compilation units. Are there any volunteers that wish to help with these tasks? Thoughts? Casper

19 years, 10 months

PC poll

by Ged Murphy

Just a quick note to say I set up the Project Coordinator poll this morning. It appears the auto mail functionality isn't working. It can be found here : http://www.reactos.org/forum/viewtopic.php?t=1193

19 years, 10 months

Java and Mono

by Rick Langschultz

I have been developing a port of Java and Mono for ReactOS. Is anyone doing this already???

19 years, 10 months

RE: [ros-diffs] [sedwards] 19482: porting fixes

by Casper Hornstrup

Why not just remove it, if it isn't needed? _____ From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of sedwards(a)svn.reactos.com Sent: 23. november 2005 07:34 To: ros-diffs(a)reactos.com Subject: [ros-diffs] [sedwards] 19482: porting fixes porting fixes Modified: trunk/reactos/apps/utils/net/tracert/tracert.c _____ Modified: trunk/reactos/apps/utils/net/tracert/tracert.c --- trunk/reactos/apps/utils/net/tracert/tracert.c 2005-11-23 06:02:15 UTC (rev 19481) +++ trunk/reactos/apps/utils/net/tracert/tracert.c 2005-11-23 06:33:19 UTC (rev 19482) @@ -28,7 +28,7 @@ */ -#include <windows.h> +//#include <windows.h> #include <winsock2.h> #include <tchar.h> #include <stdio.h> @@ -726,7 +726,7 @@ */ int main(int argc, char* argv[]) { - if (!ParseCmdline(argc, _argv)) return -1; + if (!ParseCmdline(argc, argv)) return -1; Driver();

19 years, 10 months

Security Suite

by David Hinz

As recently the discussion about a firewall and a virus-scanner came up again, I thought of a new thing, that is a bit different than the already known things. My idea is not to use a firewall and a virus-scanner, I want to create a new service, that may be configured by a gui, a console app or by other apps, that might use some of its features. This service should do the following things: - Having a look at the network traffic, which includes the following: - Controlling, which application may use the network connections - Controlling, how many traffic they cause, which could warn the user about suspicious actions - Watching the running processes for unusual events - Checking every file that is read or written for viruses - Scanning the http-traffic for ads and viruses But the most important thing for me is that if this service is shutdown without the user agreeing to that, which may be checked by ntoskrnl, the user should be informed about it and nearly all network traffic should be blocked. Then the network-card should be deactivated, all userprocesses should be paused and all drives should be checked for viruses. I think this is hard, but it will make it much harder for worms to spread, as they don't have the chance to deactivate our securitysuite and so they will be detected within two days and if they try to shutdown the securitysuite they have no chance to spread. That would be more secure than any other existing OS. This are just a few thoughts, feel free to change it the way you like it. Greets, David Hinz

19 years, 10 months

RE: [ros-diffs] [cwittich] 19320: got a lot of crypt32 stuff working

by Casper Hornstrup

We cant send this back to Wine so were going to get lots of conflicts when synchronizing with Wine and thus wasting a lot of Gé's time. What is needed is to make the ReactOS environment more like Wine or submit patches to Wine to make the Wine environment more like Windows' environment. So removing WINE_EXCEPTION_FILTER is not the way to do it since then it won't work on Wine. ReactOS grew 40% in 2004 just because of reusing code from Wine, so sharing code is definitely beneficial to both ReactOS and Wine.

19 years, 10 months

Call for discussion: release process

by Ge van Geldorp

Our current release process is documented at http://www.reactos.org/wiki/index.php/Release_Management_Overview. With the outcome of the TC function description vote, we need to change it to incorporate the TC role in the release process. I'd like to propose the following changes: - change "Once the project coordinator signals that a release is to be made, dates are set for all three stages and the release process begins." to "Once the testing coordinator (in consultation with the release engineer) signals that a release is to be made, tentative dates are set for all three stages and the release process begins.". Rationale: TC involvement, dates are not fixed but dependent on blocker bugs. - change "At the time of feature freeze, the first release candidate is produced by the release engineer." to "At the time of feature freeze, a release preview is produced by the release engineer.". Rationale: "release candidate" is probably not the best term to describe the state of the .iso. "Beta" is confusing since we're in alpha. "Preview" seems a nice generic term. - change "Code freeze is the next stage of the release process." to "Code freeze, the next stage of the release process, is entered when the testing coordinator indicates that all blocker bugs in the release branch have been fixed.". Rationale: TC involvement. - change "At the time of code freeze, the second and final release candidate is produced by the release engineer." to "At the time of code freeze, a release candidate is produced by the release engineer.". Rationale: I think we can safely call this one a release candidate. Gé van Geldorp.

19 years, 10 months

RE: [hpoussin] 19463: Fix sublanguage IDs in .rc files:

by Ge van Geldorp

> From: hpoussin(a)svn.reactos.com > > Fix sublanguage IDs in .rc files: > - LANG_ENGLISH -> SUBLANG_ENGLISH_US > - LANG_JAPANESE -> SUBLANG_DEFAULT > - others -> SUBLANG_NEUTRAL For reference, this is the search order currently used by ReactOS (copied from Wine, I'm not claiming Windows uses this same exact search order too, haven't tested): 1. specified language 2. specified language with neutral sublanguage 3. neutral language with neutral sublanguage if no explicitly specified language 4. current thread locale language 5. user locale language 6. user locale language with neutral sublanguage 7. system locale language 8. system locale language with neutral sublanguage 9. LANG_ENGLISH/SUBLANG_DEFAULT If searching for all of these fails, the first resource item found in the resource file matching the resource type and resource id is used. You can find this in lib/ntdll/ldr/res.c function LdrFindResource_U(). GvG

19 years, 10 months

RE: [ros-dev] Change of Project Coordinator

by Murphy, Ged (Bolton)

Considering there were no objections to the job description now in the wiki, it would be good to get the ball rolling again on this and start up the 1 week discussion period. Can any candidates wishing to put their name forward for this role please do so. Current list includes: - Steven Edwards. http://www.reactos.org/wiki/index.php/ReactOS_Project_Coordinator -----Original Message----- From: Casper Hornstrup [mailto:ch@csh-consult.dk] Sent: 10 November 2005 10:41 To: 'ReactOS Development List' Subject: RE: [ros-dev] RE: Change of Project Coordinator Better draft and vote on the project coordinator description first. It's good to know the job description when you apply for a job ;-) Casper > -----Original Message----- > From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Murphy, Ged > (Bolton) > Sent: 10. november 2005 10:14 > To: 'ReactOS Development List' > Subject: [ros-dev] RE: Change of Project Coordinator > > Jason Filby wrote: > > > I've decided that now is the best time to step down as Project > > Coordinator. The process to vote for a new PC will be - as previously > > decided for this type of decision - that only registered committers > > can vote. > > > This topic seems to have died a death, so I'm bringing it back up now as the > new voting system is in place. > I was speaking to Steven last night who advised he is now available to run > as PC. > Can any other candidates put their name forward again for the 1 week > discussion period. > > Ged. ************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)exideuk.co.uk <mailto:postmaster@exideuk.co.uk> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com

19 years, 10 months

Re: [ros-svn] [weiden] 19406: fixed the ProbeForWriteLargeInteger and ProbeForWriteUlargeInteger macros

by Thomas Weidenmueller

weiden(a)svn.reactos.com wrote: > fixed the ProbeForWriteLargeInteger and ProbeForWriteUlargeInteger macros I'm sorry, I meant to write ProbeForReadLargeInteger and ProbeForReadUlargeInteger. - Thomas

19 years, 10 months

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