Ros-dev

ros-dev@reactos.org

5789 discussions

by Ge van Geldorp

The program below (when compiled with MSVC6, multithreaded DLL runtime) only prints "in first handler" on ReactOS and then gets into an endless exception loop: int main(int argc, char *argv[]) { __try { RaiseException(0x55aa, 0, 0, NULL); } __except(EXCEPTION_EXECUTE_HANDLER) { printf("in first handler\n"); } __try { RaiseException(0xaacc, 0, 0, NULL); } __except(EXCEPTION_EXECUTE_HANDLER) { printf("in second handler\n"); } return 0; } I believe the reason is that our RtlUnwind removes the target exception frame too, which it shouldn't do. The following patch seems to solve the issue: Index: lib/rtl/i386/exception.c =================================================================== --- lib/rtl/i386/exception.c (revision 20225) +++ lib/rtl/i386/exception.c (working copy) @@ -333,7 +333,10 @@ RegistrationFrame2 = RegistrationFrame2->Next; /* Remove this handler */ - RtlpSetExceptionList(OldFrame); + if (RegistrationFrame2 != RegistrationFrame) + { + RtlpSetExceptionList(OldFrame); + } } } but I'm no expert on exception issues. Is this indeed the correct fix? GvG

19 years, 6 months

Why??

by WaxDragon

I quote from the ReactOS Weekly Newsletter - Volume 1, Issue 8 "0.2.9? Another One? Yup, we have another release planned for you all. 0.2.9 is our last release before the very-much-anticipated 0.3.0 release." Could we stop saying that? 0.3.0 is not the release after 0.2.9, nor 0.2.8, nor 0.2.5! 0.3.0 will happen when we hit the stated goals, and unless networking gets some serious attention, we will see 0.2.10. So, please, can we stop saying "This is the last release before 0.3.0"? It makes us look bad, and confuses people when we release yet another 0.2.x. Don't get me wrong, we are closer to 0.3.0 than ever before, but there are still many bugs. WD -- <Russell> argh <Russell> iterator shenanigans :/

19 years, 6 months

FW: Strømarbejde i Serverpark Østerbro

by Casper Hornstrup

FYI. svn.reactos.org may be affected. Casper > -----Original Message----- > From: WEBPARTNER Drift Information [mailto:drift@webpartner.dk] > Sent: 15. december 2005 08:21 > To: driftinfo(a)webpartner.dk > Subject: Strømarbejde i Serverpark Østerbro > > Affected customers : Serverpark Østerbro > > We are in the finishing phase of several improvement to our powersupply. Improvements witch gives > us added capacity, to supply current and future power and cooling needs. > > Københavns Energi handle the last part of the work witch is done d. 19.12.2005 at 24:00 to d. > 20.12.2005 at 04:00, while the work is done we are operating on disel generator. We dont expect any > interuptions but in the period above there is an increased risc for outage. > > We are at your disposal if you need our assistance in relation to this work. > > Best regards > WEBPARTNER A/S > > Visit us: http://www.webpartner.dk > Mailing list removal: http://www.webpartner.dk/336

19 years, 6 months

dealing with insecure-by-inattention Windows software

by Wesley Parish

"insecure-by-inattention" - by that I mean software that must run as super-user or otherwise (otherstupidly) it won't run at all. ReactOS is not only intended as a plug-in replacement for MS Windows, if I read this-and-that correctly, it's also intended to "get it done right". And so we can't have super-user as default user, because that is Microsoft's thorn-in-the-flesh, and they can have it. I don't want it. What I've been thinking is there is quite a bit of useful information and knowledge being actively developed and used in the Unix/BSD/Linux field for handling that sort of problem. The BSD chroot jail is one such implementation - there are even some aspects of the MS Windows directory structure that would simplify the adaption of the chroot jail to the ReactOS. [hardware]\Program Files\Abracadabra-Malware-Magnet\ "Abracadabra-Malware-Magnet" is a separate subdirectory within the Program Files directory. Chroot jail, if I remember correctly, requires a separate directory for each chrooted program so it sees itself as the one-and-only love of its kernel's uptime. The MS Windows directory structure already has this separable directory structure. What needs to be done is to ensure that it thinks it's the only one around. There would be some sizeable problems - ensuring that the dlls would be sufficiently robust to avoid being hijacked, is just one, ensuring that it couldn't make any changes to dlls outside its directory is a bigger one, but that could be handled by making sure it installed all its (uniquely) needed dlls in its chroot jail. Which a lot of Win32 programs do anyway. What do people think? Wesley Parish "Sharpened hands are happy hands. "Brim the tinfall with mirthful bands" - A Deepness in the Sky, Vernor Vinge "I me. Shape middled me. I would come out into hot!" I from the spicy that day was overcasked mockingly - it's a symbol of the other horizon. - emacs : meta x dissociated-press

19 years, 6 months

Assertion 'Class->refs == 0' failed at ./subsys/win32k/ntuser/class.c line 69

by Royce Mitchell III

Latest SVN is crashing with the following message: Assertion 'Class->refs == 0' failed at ./subsys/win32k/ntuser/class.c line 69 I created bug report here: http://www.reactos.org/bugzilla/show_bug.cgi?id=1145 This bug only occurs on ANSI build of app, and is 100% reproduceable for me. I suspect this bug may effect 0.2.9...

19 years, 6 months

GPLv3 Launch Event

by Steven Edwards

Hi, I would like to attend the GPLv3 launch event to gain more knowlege about it and how it will affect us. If you guys would like me to go on the FSF dime then please drop my name here http://gplv3.fsf.org/recommend Thanks -- Steven Edwards - ReactOS and Wine developer "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

19 years, 6 months

getfirefox

by Ged Murphy

Although we're in feature freeze, do you think it's worth including the getfirefox utility to the 0.2.9 branch? It's a great little app and I had firefox running for a few hours last night with no real issues. I'm thinking it would be good to get lots of feedback to ensure it's stable for the upcoming network release. As this will be one of our selling points, we need to ensure it's stability. Ged.

19 years, 6 months

Re: [ros-svn] [gvg] 20200: Fix by Royce3:

by James Tabor

gvg(a)svn.reactos.com wrote: > Fix by Royce3: > Don't wait 10 sec after starting an app via a .lnk file (bug 1107) > > > > Updated files: > trunk/reactos/lib/shell32/shelllink.c > So, was that the cause of that? Wow! James

19 years, 6 months

RE: [ros-dev] getfirefox

by Ge van Geldorp

> From: Alex Buell > > GetFirefox doesn't install Firefox properly, thus I can't run > Firefox, but it does leaves some files in the Program Files > subdirectories. > Here's the debugging output if anyone's interested: > > Address: 90ad6065 Unhandled exception > ExceptionCode: c0000005 > Faulting Address: 90ad6065 > Address: 7c91c598 C:\ReactOS\system32\ntdll.dll > CS:EIP 1b:7c91c598 > DS 23 ES 23 FS 3b GS 0 > EAX: 90ad6055 EBX: 00715248 ECX: 0070f1fc > EDX: 006fc8d0 EBP: 00589d8c ESI: 006a1378 ESP: 00589d04 > EDI: 006fc8b0 EFLAGS: 00000286 > Frames: > 7c900000+1c963 C:\ReactOS\system32\ntdll.dll > 60140000+14857 C:\DOCUME~1\ADMINI~1.REA\LOCAL_~1\Temp\ff_temp\xpcom.ns\bin\nspr4.dll Actually, it seems that for you the Firefox installer is crashing, not getfirefox. GvG

19 years, 6 months

RE: [ros-svn] [gvg] 20175: Don't pop-up device installer screen.

by Ge van Geldorp

> From: gvg(a)svn.reactos.com > > Don't pop-up device installer screen. > Fixes bug 1026 I've committed this to the branch only, not sure if it should be committed to trunk also. I'd like to hear how the PnP guys feel about this. GvG

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