Ros-dev

ros-dev@reactos.org

5788 discussions

by David Eckert

I keep getting the following error: lib\ntdll\string\ctype.c:280: warning: '_pctype' defined locally after being referenced with dllimport linkage mingw32-make: *** [obj-i386\lib\ntdll\string\ctype.o] Error 1 I found a cheap little trick to it, commenting out line 280 in ctype.c will fix it (for now) -- -David W. Eckert

19 years, 5 months

www.reactos.com back up

by Ge van Geldorp

Most reactos.com services should be available again. The forum is still offline. Mailing lists, main website, wiki and bugzilla are functional again. It might take a little while for the DNS changes to trickle down the system, so if it doesn't work for you yet just try again in half a day or so. Gé van Geldorp.

19 years, 5 months

www.reactos.com back up

by Ge van Geldorp

19 years, 5 months

rdesktop

by Wesley Parish

http://www.rdesktop.org/ Another link in the chain of compatibility. All we need for it is for the networking code to become mature. Wesley Parish -- Clinersterton beademung, with all of love - RIP James Blish ----- Mau e ki, he aha te mea nui? You ask, what is the most important thing? Maku e ki, he tangata, he tangata, he tangata. I reply, it is people, it is people, it is people.

19 years, 5 months

Re: Document pch and linkerflag elements.

by Martin Fuchs

Hello, the main XML build file "ReactOS.xml" is referencing a DTD file "tools/rbuild/project.dtd". But it's not included in the SVN repository. Is there already such a file? And in that case - could you please check it in? Thanks, Martin

19 years, 5 months

Re: [ros-diffs] [weiden] 16941: define common build flags so they can easily be changed for all tools

by Royce Mitchell III

weiden(a)svn.reactos.com wrote: >define common build flags so they can easily be changed for all tools > >Modified: trunk/reactos/tools/cdmake/cdmake.c > > > *Modified: trunk/reactos/tools/cdmake/cdmake.c* > >--- trunk/reactos/tools/cdmake/cdmake.c 2005-08-01 10:21:20 UTC (rev 16940) >+++ trunk/reactos/tools/cdmake/cdmake.c 2005-08-01 10:58:28 UTC (rev 16941) >@@ -423,6 +423,9 @@ > > if (d->extension_on_cd[0] != 0) > identifier_size += 1 + strlen(d->extension_on_cd); > break; > > >+ default: >+ identifier_size = 1; >+ break; > > > } > } > record_size = 33 + identifier_size; > > > ------------------------------------------------------------------------ This change appears to not relate to your commit message. Was it an accident or intentional?

19 years, 5 months

EventLog

by Saveliy Tretiakov

Hi. I'm implementing an EventLog service now. I want to make it 100% compatible with windows. Windows machines will be able to access reactos eventlog via rpc. Undocumented rpc interface is almost reversed now. You can find it in attached archive with some tests. Ansi functions work very well, but I have some problems with unicode ones. When I pass initialized with nulls UNICODE_STRING to a function, it works. When I initialize structure with some other values, exception is raised on server side (1783 Stub received bad data). I don't know why this happens. Advapi32 initializes structures with RtlInitUnicodeString, nothing special. Any ideas? And I don't know how to compile this with widl and gcc. SEH is not implemented in gcc, right? How rpc exceptions are handled in ROS? Widl returns strange errors. Somebody familiar with widl please help me =)

19 years, 5 months

Networking broken in 15400/15402 confirmed

by Gge

I summarize below the networking status for nic rtl8139 in real hardware , with the help of Alex , Filip and Hpoussin - Ping ok with svn 15400 - ping Nok with SVN15402+15404 and > - ping ok with head (svn 16894) + patch 15402/15404 removed The interesting part is this: 1) svn 15400 (ndis/io.c:824)(NdisMRegisterInterrupt) Called. InterruptVector (0xA) InterruptLevel (0xA) SharedInterrupt (1) InterruptMode (0x0) (ndis/io.c:843)(NdisMRegisterInterrupt) Connecting to interrupt vector (0x4A) Affinity (0xFFFFFFFF). (ndis/io.c:848)(NdisMRegisterInterrupt) Leaving. Status (0x0). 2) svn 15402/15404 (ndis/io.c:824)(NdisMRegisterInterrupt) Called. InterruptVector (0x0) InterruptLevel (0x0) SharedInterrupt (1) InterruptMode (0x0) (ndis/io.c:843)(NdisMRegisterInterrupt) Connecting to interrupt vector (0x40) Affinity (0xFFFFFFFF). (ndis/io.c:848)(NdisMRegisterInterrupt) Leaving. Status (0x0). 3) Svn 16860 (ndis\ndis\io.c:824)(NdisMRegisterInterrupt) Called. InterruptVector (0x9) InterruptLevel (0x9) SharedInterrupt (1) InterruptMode (0x0) (ndis\ndis\io.c:843)(NdisMRegisterInterrupt) Connecting to interrupt vector (0x49) Affinity (0xFFFFFFFF). (ndis\ndis\io.c:848)(NdisMRegisterInterrupt) Leaving. Status (0x0). Regards Gerard

19 years, 5 months

Re: [ros-dev] USB mouse support

by reactos

You used the BIOS USB to PS/2 bridge, not a USB driver. Yours sincerely, Jaix Bly ----Ursprungligt meddelande----- From: TwoTailedFox twotailedfox(a)gmail.com Date: Sat, 30 Jul 2005 17:52:59 +0200 To: Andrew Murphy andrewm1986(a)gmail.com Subject: Re: [ros-dev] USB mouse support > Oddly enough, I used 0.2.6 with a USB Mouse on my P4 System. The > cursor did appear, but the mouse sensitivity was way off. I could > roughly get it where I wanted to by moving very, very slowly, but this > wasn't practical, so I switched back to my USB-to-PS/2 way of using > the mouse. > > Good to hear it's near to being useable. > > On 7/30/05, Andrew Murphy <andrewm1986(a)gmail.com> wrote: > > > > > > On 30/07/05, Jonathan Wilson <jonwil(a)tpgi.com.au> wrote: > > > Good to hear. > > > > > > Working support for my Microsoft Optical Intellimouse Explorer USB Optical > > > Mouse is one of the 2 things I want before I will try ROS on real hardware > > > again. (the other is support for my Belikn Wireless Network Card and > > > software and enough networking support so I can talk to the wireless > > router > > > and from there to the internet) > > > > > > > > > _______________________________________________ > > > Ros-dev mailing list > > > Ros-dev(a)reactos.com > > > http://reactos.com:8080/mailman/listinfo/ros-dev > > > > > > > > > _______________________________________________ > > Ros-dev mailing list > > Ros-dev(a)reactos.com > > http://reactos.com:8080/mailman/listinfo/ros-dev > > > > > > > -- > "I had a handle on life, but then it broke" > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.com > http://reactos.com:8080/mailman/listinfo/ros-dev

19 years, 5 months

Re: [ros-diffs] [hbirr] 16901: If a mutex already exist, open it instead of create.

by Joseph Galbraith

Are you sure that we should be acquiring the mutex in the open case? MSDN says: bInitialOwner [in] Specifies the initial owner of the mutex object. If this value is TRUE and the caller created the mutex, the calling thread obtains ownership of the mutex object. Otherwise, the calling thread does not obtain ownership of the mutex.... Thanks, Joseph hbirr(a)svn.reactos.com wrote: > If a mutex already exist, open it instead of create. > Modified: trunk/reactos/lib/kernel32/synch/mutex.c > Modified: trunk/reactos/lib/kernel32/synch/mutex.c > --- trunk/reactos/lib/kernel32/synch/mutex.c 2005-07-30 19:00:33 UTC (rev 16900) > +++ trunk/reactos/lib/kernel32/synch/mutex.c 2005-07-30 19:03:34 UTC (rev 16901) > @@ -92,10 +92,24 @@ > MUTEX_ALL_ACCESS, > &ObjectAttributes, > (BOOLEAN)bInitialOwner); > + if (Status == STATUS_OBJECT_NAME_COLLISION) > + { > + Status = NtOpenMutant(&MutantHandle, > + MUTEX_ALL_ACCESS, > + &ObjectAttributes); > + if (NT_SUCCESS(Status)) > + { > + if(bInitialOwner) > + { > + WaitForSingleObject(MutantHandle, INFINITE); > + } > + SetLastError(ERROR_ALREADY_EXISTS); > + } > + } > if (!NT_SUCCESS(Status)) > { > - SetLastErrorByStatus(Status); > - return NULL; > + SetLastErrorByStatus(Status); > + return NULL; > } > > return MutantHandle;

19 years, 5 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