Ros-dev

ros-dev@reactos.org

5788 discussions

Start a nNew thread

Java and Mono

by Rick Langschultz

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

18 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();

18 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

18 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.

18 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.

18 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

18 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

18 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

18 years, 10 months

RE:[cwittich] 19402: WINE 0.9.1 vendor drop

by Ge van Geldorp

> From: cwittich(a)svn.reactos.com > > WINE 0.9.1 vendor drop > > Added files: > vendor/wine/dlls/avifil32/Wine-0_9_1/ Can you "svn copy svn://svn.reactos.org/vendor/wine/dlls/avifil32/current svn://svn.reactos.org/vendor/wine/dlls/avifil32/Wine-0_9_1" instead of re-adding the files to .../Wine-0_9_1? By using "svn copy" you establish a common ancestry between .../current and .../Wine-0_9_1. (Of course, you need to svn delete .../Wine-0_9_1 now before you can do the svn copy). Thanks, GvG.

18 years, 10 months

RE: [ros-svn] [cwittich] 19403: import avifil32 from WINE 0.9.1

by Ge van Geldorp

> From: cwittich(a)svn.reactos.com > > import avifil32 from WINE 0.9.1 Another case where you should use "svn copy". The vendor import process is described here: http://www.reactos.org/wiki/index.php/Using_code_from_other_projects GvG

18 years, 10 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev