Ros-dev

ros-dev@reactos.org

5790 discussions

Re: [ros-bugs] [Bug 1149] Calculator bug
by Jerry 19 Dec '05

19 Dec '05

I think I got it fixed. Hear's the diff: Index: subsys/system/calc/winecalc.c =================================================================== --- subsys/system/calc/winecalc.c (revision 20239) +++ subsys/system/calc/winecalc.c (working copy) @@ -755,32 +755,34 @@ { int i; int w = LOWORD(wParam); + int Base; + calcfloat r; + + r = calc_atof(calc.buffer, calc.numBase); if (w == ID_CALC_NS_HEX) { - if (calc.numBase == NBASE_HEX) - return 0; - else - calc.numBase = NBASE_HEX; + Base = NBASE_HEX; } else if (w == ID_CALC_NS_DEC) { - if (calc.numBase == NBASE_DECIMAL) - return 0; - else - calc.numBase = NBASE_DECIMAL; + Base = NBASE_DECIMAL; + } else if (w == ID_CALC_NS_OCT) { - if (calc.numBase == NBASE_OCTAL) - return 0; - else - calc.numBase = NBASE_OCTAL; + Base = NBASE_OCTAL; } else if (w == ID_CALC_NS_BIN) { - if (calc.numBase == NBASE_BINARY) + Base = NBASE_BINARY; + } + + if (calc.numBase == Base){ return 0; - else - calc.numBase = NBASE_BINARY; + } else { + calc.numBase = Base; } + + calc_ftoa(&calc, r, calc.buffer); + for (i=0;i<CALC_NS_COUNT;i++) SendMessage(calc.cb[60+i].hBtn, BM_SETCHECK, w == (ID_CALC_NS_HEX + i) ? 1 : 0, 0); @@ -2944,16 +2946,23 @@ switch (calc->numBase) { case NBASE_HEX: - real = calc_atof(calc->buffer, calc->numBase); - _stprintf(calc->display, TEXT("%lx"), (long)real); + //real = calc_atof(calc->buffer, calc->numBase); + //_stprintf(calc->display, TEXT("%lx"), (long)real); + //_stprintf(calc->display, TEXT("%lX"), calc->buffer); + _stprintf(calc->display, TEXT("%s"), calc->buffer); break; case NBASE_OCTAL: - _stprintf(calc->display, TEXT("%lo"), (long)calc->buffer); + //real = calc_atof(calc->buffer, calc->numBase); + //_stprintf(calc->display, TEXT("%lo"), (long)real); + //_stprintf(calc->display, TEXT("%lo"), (long)calc->buffer); + _stprintf(calc->display, TEXT("%s"), calc->buffer); break; case NBASE_BINARY: - _stprintf(calc->display, TEXT("%lx"), (long)calc->buffer); + + //_stprintf(calc->display, TEXT("%lx"), (long)calc->buffer); + _stprintf(calc->display, TEXT("%s"), calc->buffer); break; case NBASE_DECIMAL: @@ -3229,8 +3238,15 @@ case NBASE_OCTAL: _stprintf(buf, TEXT("%lo"), (long)r); break; - case NBASE_BINARY: // 911 - need routine here - + case NBASE_BINARY: // 911 - need routine here + { + int x; + for(x=0; x < sizeof(calcfloat); x++){ + if (( (long)r & (1<<( (sizeof(calcfloat)-1) -x ))) == 1<<( (sizeof(calcfloat)-1) -x ) ) buf[x] = '1'; else buf[x] = '0'; + + }; + buf[sizeof(calcfloat)]='\0'; + } break; default: break; /* End of Diff */ Tell me if it works or not, please. Thanks. ReactOS.Bugzilla(a)reactos.org wrote: >http://www.reactos.org/bugzilla/show_bug.cgi?id=1149 > > > > > >------- Additional Comments From crashfourit(a)gmail.com 2005-12-18 05:27 CET ------- >No, I hadd the same problem in WinXP. I'm in the process of fixing it. > > >

2 2

Patch for review: exception handling
by Ge van Geldorp 18 Dec '05

18 Dec '05

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

1 0

Why??
by WaxDragon 18 Dec '05

18 Dec '05

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 :/

9 12

FW: Strømarbejde i Serverpark Østerbro
by Casper Hornstrup 18 Dec '05

18 Dec '05

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

1 0

dealing with insecure-by-inattention Windows software
by Wesley Parish 18 Dec '05

18 Dec '05

"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

10 14

Assertion 'Class->refs == 0' failed at ./subsys/win32k/ntuser/class.c line 69
by Royce Mitchell III 17 Dec '05

17 Dec '05

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

1 0

GPLv3 Launch Event
by Steven Edwards 16 Dec '05

16 Dec '05

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

1 0

getfirefox
by Ged Murphy 16 Dec '05

16 Dec '05

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.

10 24

Re: [ros-svn] [gvg] 20200: Fix by Royce3:
by James Tabor 16 Dec '05

16 Dec '05

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

2 1

RE: [ros-dev] getfirefox
by Ge van Geldorp 15 Dec '05

15 Dec '05

> 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

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev