- Ros-dev - ReactOS.org

Re: [ros-dev] [ros-bugs] [Bug 6035] Abiword 2.8.6: confirmation messagebox without text
by thomas＠parker.iz34.com 09 Aug '12

09 Aug '12

http://www.reactos.org/bugzilla/show_bug.cgi?id=6035 --- Comment #7 from hbelusca <hermes.belusca(a)sfr.fr> 2012-08-09 14:02:29 CET --- According to Edijs, the confirmation message box isn't in top-most position with respect to the Abiword's window : [15:57:09] <Edijus> hbelusca: When save changes dialog appears, change focus to explorer or some other window. http://www.reactos.org/bugzilla/show_bug.cgi?id=6035 [15:57:26] <Edijus> hbelusca: Save changes dialog is not top most. Report it, please. :) [15:59:47] <hbelusca> Edijus: you mean that the confirmation message box of Abiword can "disappear" (ie. go behind another window) ?! [16:00:25] <Edijus> hbelusca: Yeah. Check if it reported or not, before reporting. [16:00:32] <Edijus> Thanks. -- Configure bugmail: http://www.reactos.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. _______________________________________________ Ros-bugs mailing list Ros-bugs(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-bugs

1 0

Re: [ros-dev] [ros-diffs] [tfaber] 57044: [LIBTIFF] - Fix a warning
by Timo Kreuzer 08 Aug '12

08 Aug '12

Hmm, this is not 64 bit safe. Also I don't understand the modification. It doesn't look right. libtiff uses this differently: http://tiff.sourcearchive.com/documentation/4.0.0~beta4/fax2tiff_8c-source.… #if defined(_WIN32) && defined(USE_WIN32_FILEIO) TIFFSetClientdata(faxTIFF, (thandle_t)_get_osfhandle(fileno(in))); #else TIFFSetClientdata(faxTIFF, (thandle_t)fileno(in)); #endif And we don't even seem to use that function at all. Can anyone explain this? Am 04.08.2012 20:19, schrieb tfaber(a)svn.reactos.org: > Author: tfaber > Date: Sat Aug 4 18:19:19 2012 > New Revision: 57044 > > URL: http://svn.reactos.org/svn/reactos?rev=57044&view=rev > Log: > [LIBTIFF] > - Fix a warning > > Modified: > trunk/reactos/dll/3rdparty/libtiff/rosdiff.patch > trunk/reactos/dll/3rdparty/libtiff/tif_open.c > > Modified: trunk/reactos/dll/3rdparty/libtiff/rosdiff.patch > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/3rdparty/libtiff/rosdi… > ============================================================================== > --- trunk/reactos/dll/3rdparty/libtiff/rosdiff.patch [iso-8859-1] (original) > +++ trunk/reactos/dll/3rdparty/libtiff/rosdiff.patch [iso-8859-1] Sat Aug 4 18:19:19 2012 > @@ -7,7 +7,7 @@ > { > thandle_t m = tif->tif_clientdata; > +#ifdef USE_WIN32_FILEIO > -+ newvalue = (thandle_t) _get_osfhandle(newvalue); > ++ newvalue = (thandle_t)_get_osfhandle((int)newvalue); > +#endif /* USE_WIN32_FILEIO */ > tif->tif_clientdata = newvalue; > return m; > > Modified: trunk/reactos/dll/3rdparty/libtiff/tif_open.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/3rdparty/libtiff/tif_o… > ============================================================================== > --- trunk/reactos/dll/3rdparty/libtiff/tif_open.c [iso-8859-1] (original) > +++ trunk/reactos/dll/3rdparty/libtiff/tif_open.c [iso-8859-1] Sat Aug 4 18:19:19 2012 > @@ -517,7 +517,7 @@ > { > thandle_t m = tif->tif_clientdata; > #ifdef USE_WIN32_FILEIO > - newvalue = (thandle_t) _get_osfhandle(newvalue); > + newvalue = (thandle_t)_get_osfhandle((int)newvalue); > #endif /* USE_WIN32_FILEIO */ > tif->tif_clientdata = newvalue; > return m; > > >

1 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 57009: [NTOSKRNL] Try to fix crash detection in sysreg
by Timo Kreuzer 01 Aug '12

01 Aug '12

Hi I don't exactly know how testman is supposed to detect kernel crashes, by hope was that the crash detection failed, because of the strange characters at the beginning of the line, but that was obviously not the case. Can someone look into it and fix it, we are wasting a lot of testing time due to this. Thanks, Timo Am 31.07.2012 22:58, schrieb tkreuzer(a)svn.reactos.org: > Author: tkreuzer > Date: Tue Jul 31 20:58:37 2012 > New Revision: 57009 > > URL: http://svn.reactos.org/svn/reactos?rev=57009&view=rev > Log: > [NTOSKRNL] > Try to fix crash detection in sysreg > > Modified: > trunk/reactos/ntoskrnl/kdbg/kdb.c > > Modified: trunk/reactos/ntoskrnl/kdbg/kdb.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/kdbg/kdb.c?rev=57… > ============================================================================== > --- trunk/reactos/ntoskrnl/kdbg/kdb.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/kdbg/kdb.c [iso-8859-1] Tue Jul 31 20:58:37 2012 > @@ -1472,12 +1472,12 @@ > > if (BreakPoint->Type == KdbBreakPointSoftware) > { > - KdbpPrint("Entered debugger on breakpoint #%d: EXEC 0x%04x:0x%08x\n", > + KdbpPrint("\nEntered debugger on breakpoint #%d: EXEC 0x%04x:0x%08x\n", > KdbLastBreakPointNr, TrapFrame->SegCs & 0xffff, TrapFrame->Eip); > } > else if (BreakPoint->Type == KdbBreakPointHardware) > { > - KdbpPrint("Entered debugger on breakpoint #%d: %s 0x%08x\n", > + KdbpPrint("\nEntered debugger on breakpoint #%d: %s 0x%08x\n", > KdbLastBreakPointNr, > (BreakPoint->Data.Hw.AccessType == KdbAccessRead) ? "READ" : > ((BreakPoint->Data.Hw.AccessType == KdbAccessWrite) ? "WRITE" : > @@ -1545,7 +1545,7 @@ > return kdHandleException; > } > > - KdbpPrint("Entered debugger on unexpected debug trap!\n"); > + KdbpPrint("\nEntered debugger on unexpected debug trap!\n"); > } > } > else if (ExceptionCode == STATUS_BREAKPOINT) > @@ -1560,7 +1560,7 @@ > return kdHandleException; > } > > - KdbpPrint("Entered debugger on embedded INT3 at 0x%04x:0x%08x.\n", > + KdbpPrint("\nEntered debugger on embedded INT3 at 0x%04x:0x%08x.\n", > TrapFrame->SegCs & 0xffff, TrapFrame->Eip - 1); > } > else > @@ -1574,7 +1574,7 @@ > return ContinueType; > } > > - KdbpPrint("Entered debugger on %s-chance exception (Exception Code: 0x%x) (%s)\n", > + KdbpPrint("\nEntered debugger on %s-chance exception (Exception Code: 0x%x) (%s)\n", > FirstChance ? "first" : "last", ExceptionCode, ExceptionString); > > if (ExceptionCode == STATUS_ACCESS_VIOLATION && > > >

1 0

MSVC build breakage
by caemyr＠myopera.com 31 Jul '12

31 Jul '12

Its been over a day since http://build.reactos.org/builders/CMake_x86_MSVCWin%20Debug/builds/1672 Can someone please fix it or revert the guilty revision? Thanks in advance -- With best regards Caemyr

1 0

First Contract Issued
by Zachary Gorden 31 Jul '12

31 Jul '12

The ReactOS Project is proud to announce the first of the development contracts that will be funded by the recent donation campaign. Edijs Kolesnikovics joined the ReactOS development team very recently and has been working extensively with Amine Khaldi and Olaf Siejka to create an application test suite based around the AutoHotkey (AHK) automation system. AutoHotkey is a tool for scripting keyboard and mouse actions in order to automate running of programs on Windows. While the current test suites exercise a considerable amount of functionality, the true test for ReactOS remains when it is used to run applications. As such, Edijs has been working to create tests using AHK to run a variety of applications, starting with those on the Golden Apps list. The basic framework is already in place along with a few tests, but much more can be done to expand the selection of applications tested. As such, the Foundation has elected to grant Edijs a development contract to develop additional tests. The project congratulates Edijs on a job well done so far, and would also like to thank Amine, Olaf, and the AHK developers for their help mentoring and advising Edijs. Contract Details Time: 84 hours minimum Wage: €168 Expected Duration: 1 month Objective: Within the designated time period, develop as many AHK test scripts for applications to be used with the automated regression testing as possible. The intended goal is to have at least all remaining Golden Apps testable. This project seeks to help developers catch regressions more quickly so that stabilizing ReactOS for releases becomes less time consuming. This task will be monitored by Amine Khaldi. Sidenote: Due to a variety of circumstances unrelated to the donation campaign, Edijs' contract wage is significantly lower than what would be the standard contract wage for the project.

1 0

Re: [ros-dev] [ros-diffs] [akhaldi] 56973: [CLASSPNP] * Explicitly mark the functions as stdcall (NTAPI).. -mrtd changes the default calling convention, but name-decoration isn't affected by this. The -mrtd feature has its ...
by Timo Kreuzer 29 Jul '12

29 Jul '12

While this works for us, we should consider trying to get this feature back. When it's considered for removal, then they obviously "fixed" something now that noone needs (and that makes absolutely no sense at all), while the feature as it was before is very useful to compile 3rd party code for Windows. One possibility (since we compile gcc ourselves anyway), is finding out where they "fixed" it and revert that revision for our builds. If they completely remove it, we rename the option and send the old code in as a new feature for MSVC compatibility ;-) Am 29.07.2012 03:49, schrieb akhaldi(a)svn.reactos.org: > Author: akhaldi > Date: Sun Jul 29 01:49:24 2012 > New Revision: 56973 > > URL: http://svn.reactos.org/svn/reactos?rev=56973&view=rev > Log: > [CLASSPNP] > * Explicitly mark the functions as stdcall (NTAPI).. -mrtd changes the default calling convention, but name-decoration isn't affected by this. The -mrtd feature has its origin in some older linux-code-mode, and it's considered for removal in GCC 4.8. > * Fix some warnings. > > Modified: > trunk/reactos/drivers/storage/classpnp/CMakeLists.txt > trunk/reactos/drivers/storage/classpnp/autorun.c > trunk/reactos/drivers/storage/classpnp/class.c > trunk/reactos/drivers/storage/classpnp/classp.h > trunk/reactos/drivers/storage/classpnp/classwmi.c > trunk/reactos/drivers/storage/classpnp/clntirp.c > trunk/reactos/drivers/storage/classpnp/create.c > trunk/reactos/drivers/storage/classpnp/dictlib.c > trunk/reactos/drivers/storage/classpnp/lock.c > trunk/reactos/drivers/storage/classpnp/obsolete.c > trunk/reactos/drivers/storage/classpnp/power.c > trunk/reactos/drivers/storage/classpnp/retry.c > trunk/reactos/drivers/storage/classpnp/utils.c > trunk/reactos/drivers/storage/classpnp/xferpkt.c >

2 2

Monthly meeting - July 2012
by Aleksey Bragin 26 Jul '12

26 Jul '12

Hello, Let me invite you to the monthly status meeting taking place last Thursday of this month, 26th of July, 19:00 UTC. The meeting will be at irc://fezile.reactos.org (Port 6667, no SSL) in the channel #meeting. Note that the IRC service will only be started shortly before the meeting. Your participation passwords will be emailed to you shortly before the meeting starts. If someone still is not getting passwords sent before a meeting - please email Colin or Pierre before the meeting started to get one. In order to save time, let's choose who is going to be the minute taker on the upcoming meeting. As usual, volunteers are welcome. he agenda will be posted shortly before the meeting, suggestions are welcome (send them to my email as usual). With the best regards, Aleksey Bragin.

4 3

Re: [ros-dev] July Meeting- May I come?
by Ben Rossington 26 Jul '12

26 Jul '12

May I attend? I am not a developer, nor do I know the way these types of meetings take place. I would like to observe and possibly take notes for PR releases. I apologize for my late request; I just signed up for this 'dev list'. If nothing else, could someone send me the log from the meeting? Thank you in advance. :) Ben Rossington On Wed, Jul 25, 2012 at 8:00 AM, <ros-dev-request(a)reactos.org> wrote: > Send Ros-dev mailing list submissions to > ros-dev(a)reactos.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.reactos.org/mailman/listinfo/ros-dev > or, via email, send a message with subject or body 'help' to > ros-dev-request(a)reactos.org > > You can reach the person managing the list at > ros-dev-owner(a)reactos.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Ros-dev digest..." > > > Today's Topics: > > 1. Re: Monthly meeting - July 2012 (Javier Agust?n Fern?ndez Arroyo) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 24 Jul 2012 20:48:25 +0200 > From: Javier Agust?n Fern?ndez Arroyo <elhoir(a)gmail.com> > To: ReactOS Development List <ros-dev(a)reactos.org> > Subject: Re: [ros-dev] Monthly meeting - July 2012 > Message-ID: > < > CAAHf8rfhEmOvydFSfJPrY1Y3ArPZU8oeAr4as0tQ_Fn1pKwenA(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > hi there > im on holydays, so i wont be at the meeting > > Sorry, > > On Tue, Jul 24, 2012 at 11:52 AM, Sylvain Petreolle <spetreolle(a)yahoo.fr > >wrote: > > > I may be unable to attend this meeting. > > I don't know if www/IRC will be available at my holidays place. > > > > Kind regards, > > Sylvain Petreolle > > > > ------------------------------ > > *De :* Aleksey Bragin <aleksey(a)reactos.org> > > *? :* ReactOS Development List <ros-dev(a)reactos.org> > > *Envoy? le :* Mardi 24 juillet 2012 11h10 > > *Objet :* [ros-dev] Monthly meeting - July 2012 > > > > Hello, > > Let me invite you to the monthly status meeting taking place last > Thursday > > of this month, 26th of July, 19:00 UTC. > > > > The meeting will be at irc://fezile.reactos.org (Port 6667, no SSL) in > > the channel #meeting. Note that the IRC service will only be started > > shortly before the meeting. Your participation passwords will be emailed > to > > you shortly before the meeting starts. > > If someone still is not getting passwords sent before a meeting - please > > email Colin or Pierre before the meeting started to get one. > > > > In order to save time, let's choose who is going to be the minute taker > on > > the upcoming meeting. As usual, volunteers are welcome. > > > > he agenda will be posted shortly before the meeting, suggestions are > > welcome (send them to my email as usual). > > > > With the best regards, > > Aleksey Bragin. > > > > _______________________________________________ > > Ros-dev mailing list > > Ros-dev(a)reactos.org > > http://www.reactos.org/mailman/listinfo/ros-dev > > > > > > > > _______________________________________________ > > Ros-dev mailing list > > Ros-dev(a)reactos.org > > http://www.reactos.org/mailman/listinfo/ros-dev > > >

3 3

Re: [ros-dev] [ros-diffs] [dreimer] 56956: Update rapps to recent versions. FF 3.6 and Thunderbird 3 is no more and thus is hosted on the same spot as the older FF versions are. Fox Audio is updated to 0.9.1 including head ...
by Pierre Schweitzer 24 Jul '12

24 Jul '12

Hi, FireFox 3.0.19 can be found here: ftp://archive.mozilla.org/pub/firefox/releases/3.0.19-real-real/win32/en-US… I definitely don't see why we should host it. This link won't change (since it's Mozilla archive). Why uploading Click-N-Type on our server while they provide a link that won't change with version upgrade: http://cnt.lakefolks.com/CNTzip.exe Once again, I definitely don't see why we should host it. Same with FireFox 3.6.28: ftp://archive.mozilla.org/pub/firefox/releases/3.6.28/win32/en-US/Firefox%2… So, there's no reason why we should host it. TotalCommander can be found on an official mirror site here: http://www.slo.ru/download/total_commander/tcm80x32.exe Since it's a shareware software, I see no reason why we should host it. Furthermore, it might cause issues with license. Finally, as for the rest, Thunderbird 3.1.20 can be found here: ftp://archive.mozilla.org/pub/thunderbird/releases/3.1.20/win32/en-US/Thund… So, I definitely don't see why we should host it. Please delete all the the files above from our server, and use the links I provided. Only host applications that we cannot find in a TRUSTED place, or applications that we ship with our own modifications. With my best regards, -- Pierre Schweitzer <pierre(a)reactos.org> Systems Administrator ReactOS Foundation

2 4

Re: [ros-dev] [ros-diffs] [jgardou] 56951: [WIN32SS/NTGDI] - Do not assume that DC has a valid surface attached in GreExtTextOutW
by Timo Kreuzer 23 Jul '12

23 Jul '12

I don't think it makes sense to draw text into the default bitmap :) Am 23.07.2012 17:35, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Mon Jul 23 15:35:42 2012 > New Revision: 56951 > > URL: http://svn.reactos.org/svn/reactos?rev=56951&view=rev > Log: > [WIN32SS/NTGDI] > - Do not assume that DC has a valid surface attached in GreExtTextOutW > > Modified: > trunk/reactos/win32ss/gdi/ntgdi/freetype.c > > Modified: trunk/reactos/win32ss/gdi/ntgdi/freetype.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/freetype… > ============================================================================== > --- trunk/reactos/win32ss/gdi/ntgdi/freetype.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/ntgdi/freetype.c [iso-8859-1] Mon Jul 23 15:35:42 2012 > @@ -3391,6 +3391,7 @@ > DC_vPrepareDCsForBlit(dc, DummyRect, NULL, DummyRect); > > psurf = dc->dclevel.pSurface ; > + if(!psurf) psurf = psurfDefaultBitmap; > SurfObj = &psurf->SurfObj ; > > EXLATEOBJ_vInitialize(&exloRGB2Dst, &gpalRGB, psurf->ppal, 0, 0, 0); > > >

1 0

Re: [ros-dev] [ros-diffs] [jgardou] 56947: [WIN32SS/GDI]
by Jérôme Gardou 23 Jul '12

23 Jul '12

OOPS.. Sorry. Changelog should have been: [WIN32SS/NTGDI] - Associate NULL surface for newly created memory DCs. jgardou(a)svn.reactos.org a écrit : > Author: jgardou > Date: Mon Jul 23 10:12:53 2012 > New Revision: 56947 > > URL: http://svn.reactos.org/svn/reactos?rev=56947&view=rev > Log: > [WIN32SS/GDI] > > Modified: > trunk/reactos/win32ss/gdi/eng/engbrush.c > trunk/reactos/win32ss/gdi/ntgdi/bitblt.c > trunk/reactos/win32ss/gdi/ntgdi/bitmaps.c > trunk/reactos/win32ss/gdi/ntgdi/dclife.c > trunk/reactos/win32ss/gdi/ntgdi/dcobjs.c > > Modified: trunk/reactos/win32ss/gdi/eng/engbrush.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/eng/engbrush.c… > ============================================================================== > --- trunk/reactos/win32ss/gdi/eng/engbrush.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/eng/engbrush.c [iso-8859-1] Mon Jul 23 10:12:53 2012 > @@ -67,6 +67,9 @@ > pebo->crCurrentText = pdc->pdcattr->crForegroundClr; > > pebo->psurfTrg = pdc->dclevel.pSurface; > + /* We are initializing for a new memory DC */ > + if(!pebo->psurfTrg) > + pebo->psurfTrg = psurfDefaultBitmap; > ASSERT(pebo->psurfTrg); > ASSERT(pebo->psurfTrg->ppal); > > > Modified: trunk/reactos/win32ss/gdi/ntgdi/bitblt.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/bitblt.c… > ============================================================================== > --- trunk/reactos/win32ss/gdi/ntgdi/bitblt.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/ntgdi/bitblt.c [iso-8859-1] Mon Jul 23 10:12:53 2012 > @@ -807,9 +807,11 @@ > SURFACE *psurf; > POINTL BrushOrigin; > BOOL ret; > - PBRUSH pbrush = pebo->pbrush; > + PBRUSH pbrush; > > ASSERT(pebo); > + pbrush = pebo->pbrush; > + ASSERT(pbrush); > > FIXUP_ROP(dwRop); > > > Modified: trunk/reactos/win32ss/gdi/ntgdi/bitmaps.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/bitmaps.… > ============================================================================== > --- trunk/reactos/win32ss/gdi/ntgdi/bitmaps.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/ntgdi/bitmaps.c [iso-8859-1] Mon Jul 23 10:12:53 2012 > @@ -259,6 +259,7 @@ > DIBSECTION dibs; > INT Count; > PSURFACE psurf = Dc->dclevel.pSurface; > + if(!psurf) psurf = psurfDefaultBitmap; > Count = BITMAP_GetObject(psurf, sizeof(dibs), &dibs); > > if (Count == sizeof(BITMAP)) > > Modified: trunk/reactos/win32ss/gdi/ntgdi/dclife.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/dclife.c… > ============================================================================== > --- trunk/reactos/win32ss/gdi/ntgdi/dclife.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/ntgdi/dclife.c [iso-8859-1] Mon Jul 23 10:12:53 2012 > @@ -180,7 +180,7 @@ > pdc->dclevel.pSurface = NULL; > > // FIXME: HACK, because our code expects a surface > - pdc->dclevel.pSurface = SURFACE_ShareLockSurface(StockObjects[DEFAULT_BITMAP]); > + // pdc->dclevel.pSurface = SURFACE_ShareLockSurface(StockObjects[DEFAULT_BITMAP]); > > pdc->erclBounds.left = 0; > pdc->erclBounds.top = 0; > @@ -271,12 +271,9 @@ > pdc->dclevel.ptlBrushOrigin.x = 0; > pdc->dclevel.ptlBrushOrigin.y = 0; > pdc->dcattr.ptlBrushOrigin = pdc->dclevel.ptlBrushOrigin; > - > - /* Initialize EBRUSHOBJs */ > - EBRUSHOBJ_vInit(&pdc->eboFill, pdc->dclevel.pbrFill, pdc); > - EBRUSHOBJ_vInit(&pdc->eboLine, pdc->dclevel.pbrLine, pdc); > + > + /* Init text brush */ > EBRUSHOBJ_vInit(&pdc->eboText, pbrDefaultBrush, pdc); > - EBRUSHOBJ_vInit(&pdc->eboBackground, pbrDefaultBrush, pdc); > > /* Setup fill data */ > pdc->dcattr.jROP2 = R2_COPYPEN; > @@ -424,9 +421,8 @@ > pdc->dclevel.pbrFill = BRUSH_ShareLockBrush(pdc->pdcattr->hbrush); > pdc->dclevel.pbrLine = PEN_ShareLockPen(pdc->pdcattr->hpen); > > - /* Update the EBRUSHOBJs */ > - EBRUSHOBJ_vUpdate(&pdc->eboFill, pdc->dclevel.pbrFill, pdc); > - EBRUSHOBJ_vUpdate(&pdc->eboLine, pdc->dclevel.pbrLine, pdc); > + /* Mark them as dirty */ > + pdc->pdcattr->ulDirty_ |= DIRTY_FILL|DIRTY_LINE; > > /* Allocate or free DC attribute */ > if (ulOwner == GDI_OBJ_HMGR_PUBLIC || ulOwner == GDI_OBJ_HMGR_NONE) > @@ -796,7 +792,7 @@ > DC_bAllocDcAttr(pdcNew); > > // HACK! > - DC_vSelectSurface(pdcNew, psurfDefaultBitmap); > + //DC_vSelectSurface(pdcNew, psurfDefaultBitmap); > > DC_UnlockDc(pdcNew); > > > Modified: trunk/reactos/win32ss/gdi/ntgdi/dcobjs.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/dcobjs.c… > ============================================================================== > --- trunk/reactos/win32ss/gdi/ntgdi/dcobjs.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/ntgdi/dcobjs.c [iso-8859-1] Mon Jul 23 10:12:53 2012 > @@ -230,9 +230,10 @@ > } > > /* Is this a valid palette for this depth? */ > - if ((BitsPerFormat(pdc->dclevel.pSurface->SurfObj.iBitmapFormat) <= 8 > - && (ppal->flFlags & PAL_INDEXED)) || > - (BitsPerFormat(pdc->dclevel.pSurface->SurfObj.iBitmapFormat) > 8)) > + if ((!pdc->dclevel.pSurface) || > + (BitsPerFormat(pdc->dclevel.pSurface->SurfObj.iBitmapFormat) <= 8 > + && (ppal->flFlags & PAL_INDEXED)) || > + (BitsPerFormat(pdc->dclevel.pSurface->SurfObj.iBitmapFormat) > 8)) > { > /* Get old palette, set new one */ > oldPal = pdc->dclevel.hpal; > @@ -383,7 +384,7 @@ > pdc->dclevel.sizl.cy = 1; > > // HACK > - psurfNew = SURFACE_ShareLockSurface(hbmp); > + //psurfNew = SURFACE_ShareLockSurface(hbmp); > } > else > { > >

1 0

Forced To Clean for Every Line Change!
by James Tabor 23 Jul '12

23 Jul '12

Hi, Around 56843 to 56917 I've been forced to do a mass clean to build the bootcd!!!! This has put a halt for me to work on ReactOS while it takes 33+ minutes to build. Example, makex XXXXX_clean does not work at all even when removing bootcd.iso! Forcing to clean in the main checkout directory! Posted this twice on IRC!

2 2

Meeting with JaixBly
by Aleksey Bragin 21 Jul '12

21 Jul '12

Hello, I want to share that I just had a pleasure to meet Jan "JaixBly" two days ago in Sweden once again. We discussed many ReactOS-related topics, and had fun with a newly delivered Raspberry Pi. We've covered future plans for ReactOS development, testing infrastructure, Samba integration, ARM processors support and many other things. A photo when we took a break from trying to get WiFi working in Raspberry Pi and went outside: http://savepic.org/2407687.jpg Best regards, Aleksey Bragin.

2 1

ReactOS and accessibility
by simon.eigeldinger＠vol.at 19 Jul '12

19 Jul '12

Hi all, My name is Simon and I am blind. I saw in the archives that there was a short subject about accessibility in ReactOS in 2010. The NVDA screenreader was tested there and wasn't working. Can someone tell me the current status of this? Maybe there could be a collaboration between ReactOS devs and NVDA devs to get accessibility in ReactOS? NVDA can be found on www.nvda-project.org. Daily snapshots can be found on http://nvda.sf.net/snapshots/.index.html Just some thoughts. Greetings from Austria, Simon

1 0

Re: [ros-dev] [ros-diffs] [ion] 56906: [NTOSKRNL]: Implement support for session pool (not yet enabled) and session space (implemented and enabled, but nobody is calling the APIs yet). [NTOSKRNL]: Implement MmMapViewOInSess...
by Ged Murphy 16 Jul '12

16 Jul '12

Fantastic! Smss2 will be happy :) -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of ion(a)svn.reactos.org Sent: 16 July 2012 00:42 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [ion] 56906: [NTOSKRNL]: Implement support for session pool (not yet enabled) and session space (implemented and enabled, but nobody is calling the APIs yet). [NTOSKRNL]: Implement MmMapViewOInSess... Author: ion Date: Sun Jul 15 23:42:27 2012 New Revision: 56906 URL: http://svn.reactos.org/svn/reactos?rev=56906&view=rev Log: [NTOSKRNL]: Implement support for session pool (not yet enabled) and session space (implemented and enabled, but nobody is calling the APIs yet). [NTOSKRNL]: Implement MmMapViewOInSessionSpace, MmUnmapViewInSessionSpace. Win32k needs to use these to we can test them. Modified: trunk/reactos/ntoskrnl/mm/ARM3/i386/init.c trunk/reactos/ntoskrnl/mm/ARM3/miarm.h trunk/reactos/ntoskrnl/mm/ARM3/pfnlist.c trunk/reactos/ntoskrnl/mm/ARM3/pool.c trunk/reactos/ntoskrnl/mm/ARM3/procsup.c trunk/reactos/ntoskrnl/mm/ARM3/section.c

1 0

ROS-Diffs fails on special characters in commit message
by Thomas Faber 12 Jul '12

12 Jul '12

Hi, I've noticed that the ROS-Diffs list (or rather the hook sending to it) consistently fails on revisions that have special chars in their commit message. E.g. there is no message for r56846, r56844, r56763, r56754 etc. (sorry Hermès :p) This goes back as far as r23711 (August 2006), for which the archive shows no message [1]. It apparently did work at some point because r20354 (December 2005) and earlier seem to have ROS-Diffs messages [2] (although possibly because special chars didn't make it into the mails' subjects). Is there a chance this could be fixed? And in the meantime, could I ask the devs to refrain from using special chars? (don't know about you, but the missing messages are quite an annoyance to me, as this is the most convenient platform for code review) Thanks! -Thomas [1] http://www.reactos.org/pipermail/ros-diffs/2006-August/thread.html [2] http://www.reactos.org/pipermail/ros-diffs/2005-December/010731.html

2 1

July 2012 Meeting A Minutes
by Zachary Gorden 10 Jul '12

10 Jul '12

July 2012 Meeting A Minutes 2012-07-05 19:00 UTC dev.reactos.org, #meeting Proceedings =========== * Meeting started at 19:16 UTC by Aleksey Bragin. * Point 0: CD/Product Store * Point 1: Update/Team Plan * Point 2: Website Update * Point 3: Internet Declaration Due to scheduling constraints by some participants, the question of a team store and sale of ReactOS CDs was moved to be the first topic. * Point 0 Ziliang Guo presented the question of CD sales and merchendise sales in general. Amine Khaldi updated the team on the work he and others have done to get storefronts up and going. The primary concern was a lack of decent designs for the stores. Ziliang was tasked with contacting graphic artists he knows in the community to see if this can be remedied. The decision of what to do with the promo CDs was left to Ziliang as well. * Point 1 Aleksey Bragin stated that he intended to help with Jira integration with the new site, which is necessary as a replacement for bugzilla. He also hopes to help with making the build environment more user friendly. Olaf Siejka reported on a variety of regressions in freeldr and the win32 subsystem that he wants fixed as they are blocking further development and testing. Other developers asked for specific reports to be assigned to them and reviewed whether they thought they knew the cause of regressions. Collaboration with the UniATA developer was also discussed, with reports that upstream patches have been accepted and suggestions on further work that can be done. * Point 2 Danny Gotte was not present so this point was skipped. * Point 3 Pierre Schweitzer presented the Internet Declaration (http://www.internetdeclaration.org/freedom), a statement of beliefs drafted by various groups that wish the internet to remain free of censorship and ensure user privacy. Many other organizations have signed onto it and Pierre asked whether the ReactOS Foundation should also do so. This was put to a vote and passed with overwhelming support. * Other Decisions Ziliang requested that all developers be added onto the public relations mailing list. This was approved. Meeting was closed at 20:38 by Aleksey Bragin Minutes were prepared by Ziliang Guo

1 0

Monthly meeting rescheduled
by Aleksey Bragin 05 Jul '12

05 Jul '12

Hello! I was away this week, so the meeting at the usual time got canceled. I propose to conduct meeting next thursday, 5th of July. If someone would not be able to make it - please email me. Regards, Aleksey Bragin.

3 3

ReactOS on ARM, working on the iPhone
by Richardo Stallmanu 05 Jul '12

05 Jul '12

Hello everyone! I just got freeldr working properly (sort of) on the iPhone 4! Currently, I use Apple's iBSS (first stage DFU bootloader), with the go command patched to always branch to 0x41000000. 0x41000000 contains the actual LLB, which is relocated to 0x42000000. The LLB will initialize the ReactOS loader console and ARM loader block, which is sent to FreeLoader, just like on Omap3/Zoom2MDK and Versatile/PB. Time to get ramdisks working. :) http://goput.it/uc5.jpg <- There's your picture. -- winocm

6 7

Meeting Thursday 7/5/2012
by Zachary Gorden 03 Jul '12

03 Jul '12

Barring any last minute hiccups, we expect to have a meeting this Thursday. I am sending out this email because we have a PR topic we need to discuss and I would like as many devs present as possible, and considering Aleksey is likely asleep by now, I felt we needed this out before "tomorrow" to give people enough heads up. Aleksey can make a more formal announcement with other agenda points if he has them. Z

2 2

Re: [ros-dev] [ros-builds] Trunk_x86_GCCLin Debug: build failed
by Pierre Schweitzer 26 Jun '12

26 Jun '12

Hi, we are currently working on the failed server to fix it definitely (we hope). I have set up a temporary solution to ensure ISOs are well stored. They cannot be downloaded though. Sorry about all that troubles. With my best regards, P. Schweitzer On Tue, 2012-06-26 at 08:43 +0000, buildbot(a)reactos.org wrote: > The Buildbot has detected a failed build on builder Trunk_x86_GCCLin Debug while building ReactOS. > Full details are available at: > http://build.reactos.org/builders/Trunk_x86_GCCLin%20Debug/builds/998 > > Buildbot URL: http://build.reactos.org/ > > Buildslave for this Build: Linux_AMD64_1 > > Build Reason: scheduler > Build Source Stamp: 56807 > Blamelist: tfaber > > BUILD FAILED: failed shell > > sincerely, > -The Buildbot > > -- Pierre Schweitzer <pierre(a)reactos.org> System Administrator ReactOS Foundation

7 9

Re: [ros-dev] [ros-builds] Trunk_x86_GCCLin Debug: build failed
by Pierre Schweitzer 25 Jun '12

25 Jun '12

Hi, this is unfortunately due to our entry server to network storage that has crashed once again tonight. All attempts to remotely reboot it failed. A human intervention will be required. It will not happen before several hours. The responsible person for the server has been informed. In case it was not possible to restore the server in a correct time, a workaround solution will be deployed once again. We are sorry for the caused inconvenience. With my best regards, P. Schweitzer Le dimanche 24 juin 2012 à 21:10 +0000, buildbot(a)reactos.org a écrit : > The Buildbot has detected a failed build on builder Trunk_x86_GCCLin Debug while building ReactOS. > Full details are available at: > http://build.reactos.org/builders/Trunk_x86_GCCLin%20Debug/builds/989 > > Buildbot URL: http://build.reactos.org/ > > Buildslave for this Build: Linux_AMD64_1 > > Build Reason: scheduler > Build Source Stamp: 56800 > Blamelist: ekohl > > BUILD FAILED: failed shell > > sincerely, > -The Buildbot > > -- Pierre Schweitzer <pierre(a)reactos.org> Systems Administrator ReactOS Foundation

1 1

Newbie to ReactOS
by Lonnie Cumberland 21 Jun '12

21 Jun '12

Greetings All, I am new to ReactOS but have much experience with with Windows, Linux, etc... as well as programming mainly in C/C++. Recently, I have decided to looking into ReactOS from a learning perspective after which, once the learning curve has been completed, I may try to get involved with some of the development efforts as well as work on some additional projects. >From what I have seen, ReactOS has come a very long ways in its development and is really turning into a special OS to be recognized. I would like to review some of the documentation on the Wiki but had a question regarding an experiment that I wanted to investigate with ReactOS. The question that I wanted to answer is this. What is the absolute minimum size, as relates to booting and OS files that are needed by ReactOS to run, for example, the notepad.exe program? To caveat this, it would include leaving out all of the OS tools, Explorer, Desktop, and absolutely everything that is not clearly needed to run the notepad.exe application. Basically, I would like ReactOS to boot and go directly into the notepad application. The real point here is to investigate what "absolute" minimum files are needed to run a simple application. Sounds a bit crazy, but that is the question that I would like to answer. Any ideas or information related to this would be greatly appreciated. Thanks and have a great day, Lonnie

9 19

ReactOS and MS XP compatability
by Lonnie Cumberland 20 Jun '12

20 Jun '12

Greetings All, I have been reviewing ReactOS on the website and wiki to get a better feel for the project, which I must say is very impressive. >From what I have read, it seems that ReactOS is initially shooting for a drop-in replacement for WindowsXP and beyond which raised a question for me. The site also seems to suggest, for the most part and with the exception of a few core ReactOS files (ie. kernel plus a couple of others), that ReactOS should be 100% compatible with WindowsXP. With this in mind, I wondered this. If I had an old licensed Windows XP disk, which I do, then shouldn't it be possible to use the base core ReactOS files (ie. the minimalist ReactOS configuration like in my previous inquiry to the mailing list) and then use the WindowsXP subsystem core files? I guess what I was wondering, not to detract from the true developments of ReactOS which I like a lot, is would the WindowsXP system files function the same with the ReactOS kernel, and minimal files that were listed by Alex in a previous email. reeldr (ntldr) ntoskrnl hal bootvid kdcom fastfat ramdisk kbdclass i8042prt ntdll smss What I am getting at, is a development that is still forming, but the idea is to utilize ReactOS to allow for the development of a Super Sandbox system that is run in a specialize VM, and which would allow for each application to be run in their own ReactOS VM. Although I am still playing with the idea a lot, it is forming in such a way that would totally isolate each application in a separate VM that is composed of super minimal ReactOS kernel running. Just playing with ideas that I have had for a while, but at the moment, I am still learning about ReactOS so that I will be able to contribute to it soon. Thanks and have a great day, Lonnie

1 0

(no subject)
by Marc Piulachs 18 Jun '12

18 Jun '12

http://secondlife.zhaarteth.net/wp-content/themes/dark-wood/googles.html?fg…

4 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev