Ros-dev July 2012

ros-dev@reactos.org

17 participants
18 discussions

by Pierre Schweitzer

Hi, after having finished its 11405th build, the last official RBuild builder has gone offline, forever. The Linux CMake builder has now turned as being the official builder. Thanks RBuild, you served us well :-). Also, the other RBuild builder, the release builder has also gone offline forever. Its hardware was not able to properly handle a ReactOS build, and was hardly upgradable. Daily release builds should replace it any time soon. With my best regards, -- Pierre Schweitzer <pierre(a)reactos.org> Systems Administrator ReactOS Foundation

12 years, 1 month

MSVC build breakage

by caemyr＠myopera.com

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

12 years, 2 months

First Contract Issued

by Zachary Gorden

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.

12 years, 2 months

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

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 >

12 years, 2 months

Monthly meeting - July 2012

by Aleksey Bragin

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.

12 years, 2 months

Re: [ros-dev] July Meeting- May I come?

by Ben Rossington

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

12 years, 2 months

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

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

12 years, 2 months

Re: [ros-dev] [ros-diffs] [jgardou] 56951: [WIN32SS/NTGDI] - Do not assume that DC has a valid surface attached in GreExtTextOutW

by Timo Kreuzer

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); > > >

12 years, 2 months

Re: [ros-dev] [ros-diffs] [jgardou] 56947: [WIN32SS/GDI]

by Jérôme Gardou

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

12 years, 2 months

Forced To Clean for Every Line Change!

by James Tabor

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!

12 years, 2 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev July 2012