Ros-dev December 2005

ros-dev@reactos.org

81 participants
142 discussions

by Ge van Geldorp

> From: Brandon Turner > > I just released 0.2.9 to sf.net. A lot of bug fixes since > RC1 so get out there and check it out. File any bugs in in > bugzilla or give us any feedback on the ml. Reminder to devs: with the release of 0.2.9-RC2 we're now in code freeze for the branch. During code freeze, the only allowed commits are bugfixes to release-blocking bugs. These fixes are generally discussed on the mailing list prior to committing a fix. GvG

19 years, 3 months

RC2 networking not working

by Brandon Turner

Hey all, I was about to publish all the files for 0.2.9 RC2 when i releazied that my network is not working in qemu. It worked a few days ago(friday?). But it isnt working for me now. Is anyone else having this problem? www.brandonturner.org/rc2.PNG Brandon

19 years, 3 months

[ros-svn] [sgasiorek] 20238: "MSVCRT memcpy behaves like memmove for overlapping moves"

by WaxDragon

This breaks mingw32-make from the RosBE 0.1 WD -- <Russell> argh <Russell> iterator shenanigans :/

19 years, 3 months

Re: [ros-bugs] [Bug 1149] Calculator bug

by Jerry

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

19 years, 3 months

Patch for review: exception handling

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, 3 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, 3 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, 3 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, 3 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, 3 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, 3 months

← Newer
1
2
3
4
5
6
7
8
9
...
15
Older →

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 December 2005