Ros-dev

ros-dev@reactos.org

5790 discussions

Regarding documentation and attracting new developers
by Maya Posch 31 Oct '08

31 Oct '08

Gentlemen, If you don't mind me intruding, I'd like to propose some things I think may ease life for us poor ROS devs, existing and new ones :) First of all, I'd like to suggest 'apprenticeship programming', also known by other names, but which commonly involves having one seasoned programmer in charge of a particular (sub-)project and one or more programmers following his lead. These latter programmers would be less experienced but could work on relatively advanced stuff due to the lead of the seasoned programmer. This model is commonly used in companies already and if adapted for ROS it should make it much easier for 'newbie' devs to get started, pick up experience and become seasoned devs themselves. My own experience with picking up the USB subproject reflect this as well. It's hard to get started without much of a lead, especially when one's experience with the NT subsystems is limited. This is also where documentation would have helped, bringing me to my second point: Whenever I start a new project or implementation I first write a technical specification detailing the exact layout, APIs and implementation. I've heard that this is common practice in professional programming as well as other areas. Benefits include having a good overview of the project before one starts on it, being able to pick out obvious oversights before writing a single line of code, having a central place of reference (code does _not_ work for this), allows one to quickly pick up on things during maintenance sessions (many months later...). It'd also enable the apprentice programming system and make it easy for the central project leader(s) to get an overview of the progress being made. Documentation and specifications are often ignored by programmers because they're not deemed 'time-efficient', preferring to start programming right away instead. In my experience and those of everyone in high-level jobs involving anything from programming to hardware design (like my housemate who is a senior engineer in a Dutch company which designs chips for the telecom industry), specifications and documentation are the lifeblood of any project. I have elected to use both the apprentice method as well as the documentation approach in my work on the new installer, bootloader and USB stack for ReactOS, attracting two relatively inexperienced but highly motivated devs for the installer (RI2, or ROSE) project already. They have expressed interest in helping me with further projects in ROS as well, even more low-level things. I think that this is a good example of the future ROS should be heading towards. So yeah, that's my rant I guess :) *ducks and runs for cover* Maya Posch

12 28

Re: [ros-dev] [ros-diffs] [janderwald] 37110: - Add Documentation for netshell
by Aleksey Bragin 31 Oct '08

31 Oct '08

You're obliged to keep it up-to-date now :-), so it doesn't become like VFAT "documentation". On Oct 31, 2008, at 2:26 PM, janderwald(a)svn.reactos.org wrote: > Author: janderwald > Date: Fri Oct 31 06:26:23 2008 > New Revision: 37110 > > URL: http://svn.reactos.org/svn/reactos?rev=37110&view=rev > Log: > - Add Documentation for netshell > > Added: > trunk/reactos/dll/win32/netshell/README (with props)

1 0

Re: [ros-dev] [ros-diffs] [cfinck] 37104: Hack: Copy the toolbar image on our own instead of using CopyImage to hackfix the messed up toolbar graphics as it was done for previous releases.
by Aleksey Bragin 31 Oct '08

31 Oct '08

I thought this one was fixed? WBR, Aleksey. On Oct 30, 2008, at 9:15 PM, cfinck(a)svn.reactos.org wrote: > Author: cfinck > Date: Thu Oct 30 13:15:00 2008 > New Revision: 37104 > > URL: http://svn.reactos.org/svn/reactos?rev=37104&view=rev > Log: > Hack: Copy the toolbar image on our own instead of using CopyImage > to hackfix the messed up toolbar graphics as it was done for > previous releases. > > Modified: > branches/ros-branch-0_3_7/reactos/dll/win32/comctl32/toolbar.c > > Modified: branches/ros-branch-0_3_7/reactos/dll/win32/comctl32/ > toolbar.c > URL: http://svn.reactos.org/svn/reactos/branches/ros-branch-0_3_7/ > reactos/dll/win32/comctl32/toolbar.c? > rev=37104&r1=37103&r2=37104&view=diff > ====================================================================== > ======== > --- branches/ros-branch-0_3_7/reactos/dll/win32/comctl32/toolbar.c > [iso-8859-1] (original) > +++ branches/ros-branch-0_3_7/reactos/dll/win32/comctl32/toolbar.c > [iso-8859-1] Thu Oct 30 13:15:00 2008 > @@ -2665,7 +2665,33 @@ > TRACE("adding hInst=%p nID=%d nButtons=%d\n", bitmap->hInst, > bitmap->nID, bitmap->nButtons); > /* Add bitmaps to the default image list */ > if (bitmap->hInst == NULL) /* a handle was passed */ > - hbmLoad = (HBITMAP)CopyImage(ULongToHandle(bitmap->nID), > IMAGE_BITMAP, 0, 0, 0); > + { > + BITMAP bmp; > + HBITMAP hOldBitmapBitmap, hOldBitmapLoad; > + HDC hdcImage, hdcBitmap; > + > + /* copy the bitmap before adding it so that the user's bitmap > + * doesn't get modified. > + */ > + GetObjectW ((HBITMAP)bitmap->nID, sizeof(BITMAP), (LPVOID) > &bmp); > + > + hdcImage = CreateCompatibleDC(0); > + hdcBitmap = CreateCompatibleDC(0); > + > + /* create new bitmap */ > + hbmLoad = CreateBitmap (bmp.bmWidth, bmp.bmHeight, > bmp.bmPlanes, bmp.bmBitsPixel, NULL); > + hOldBitmapBitmap = SelectObject(hdcBitmap, (HBITMAP)bitmap- > >nID); > + hOldBitmapLoad = SelectObject(hdcImage, hbmLoad); > + > + /* Copy the user's image */ > + BitBlt (hdcImage, 0, 0, bmp.bmWidth, bmp.bmHeight, > + hdcBitmap, 0, 0, SRCCOPY); > + > + SelectObject (hdcImage, hOldBitmapLoad); > + SelectObject (hdcBitmap, hOldBitmapBitmap); > + DeleteDC (hdcImage); > + DeleteDC (hdcBitmap); > + } > else > hbmLoad = CreateMappedBitmap(bitmap->hInst, bitmap->nID, > 0, NULL, 0); > >

2 1

Re: [ros-dev] [ros-diffs] [hyperion] 37054: deleted wine/mmsystem.h deleted wine/prsht.h deleted wine/winbase.h deleted wine/winnetwk.h deleted wine/winnt.h deleted wine/winuser.h Our SDK is in good enough shape to compile Wine: drop the #include_next hacks Wi
by Steven Edwards 31 Oct '08

31 Oct '08

On Wed, Oct 29, 2008 at 9:19 AM, <hyperion(a)svn.reactos.org> wrote: > Author: hyperion > Date: Wed Oct 29 08:19:21 2008 > New Revision: 37054 > > URL: http://svn.reactos.org/svn/reactos?rev=37054&view=rev > Log: > deleted wine/mmsystem.h > deleted wine/prsht.h > deleted wine/winbase.h > deleted wine/winnetwk.h > deleted wine/winnt.h > deleted wine/winuser.h > Our SDK is in good enough shape to compile Wine: drop the #include_next hacks > Wine compatibility fixes should go either in the SDK headers themselves or in the Wine porting SDK This is a little late but I wanted to let you know that I love you and want to bear your children! -- Steven Edwards "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

Re: [ros-dev] [ros-diffs] [jimtabor] 37099: Implement GetFontUnicodeRanges, port from wine. Tested with wine gdi32 font crosstests.
by Steven Edwards 30 Oct '08

30 Oct '08

Hello, On Thu, Oct 30, 2008 at 9:33 AM, <jimtabor(a)svn.reactos.org> wrote: > URL: http://svn.reactos.org/svn/reactos?rev=37099&view=rev > Log: > Implement GetFontUnicodeRanges, port from wine. Tested with wine gdi32 font crosstests. If your using enough of the original implementation to credit Wine then to me that means someone else at least partly own copyright to these functions. Could you please use git blame or git web and see who the author was of the original implementation from Wine and credit them appropriately in the header? From time to time when someone says 'foo from wine' I get pinged from wine developers who's code is appropriated and they ask for proper attribution. If we don't do it right the first time, then at some point another audit of each commit from SVN will have to happen and we will have to go back and add those copyright holders to the files license header. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

2 3

generic graphics
by Matthias Kupfer 30 Oct '08

30 Oct '08

Hello, I would like to create a /media/graphics directory in trunk to store the template files for graphics we want to use in altered versions or different resolutions. I start with the replacement for the explorere shutdown icon and a question mark for message dialogs. Due to problems with drawing this icons at the moment I store the templates only, later we can create the icons from the templates and include in the resource files. I suggest to store all selfmade graphics (in alterable formats, e.g. svg) in this directory (if there is no other source). What do you think about the change of the message dialogs icons to the tango project icons and the question mark icon i provide, instead of the current icon set? Matthias -- Matthias Kupfer Telefon +49 (0) 371 236 46 52 Wilhelm-Firl-Straße 21 Mobil +49 (0) 160 859 43 54 09122 Chemnitz

1 0

Trunk freeze
by Aleksey Bragin 29 Oct '08

29 Oct '08

Hello, trunk has been frozen until 0.3.7 blockers are fixed. Bugfix team having commit access for this freeze: Colin, Herve, Johannes, me. With the best regards, Aleksey Bragin.

1 1

Win32k Foating Point
by James Tabor 28 Oct '08

28 Oct '08

Hi, I've tooled up libm from http://www.netlib.org/fdlibm/ and a hacked floatlib.c in lib/3rdparty. With -msoft-float added in win32k.rbuild, it works. I built the lib separate on XP mingw build environment and I compiled and ran a fp test program (tst-ieee754.c) than compared the results with standard gcc. The results are almost the same. The thing even boots and draws okay. Floatlib.c is very old and I will soon start testing with SoftFloat to replace the gcc soft float math. So,,,,, is it posiable to build our build environment (RosBE) to support full soft-float? So we can avoid more source in ReactOS..... Well, except libm.a ~ 93k. or,,, Just support the hardware floating point and move on........ Thanks, James

2 2

Re: [ros-dev] [ros-diffs] [janderwald] 37023: - Add PROVIDER_INFO_1 and PROVIDER_INFO_2 struct
by Aleksey Bragin 28 Oct '08

28 Oct '08

Is this providEr or providOr ? On Oct 27, 2008, at 6:16 PM, janderwald(a)svn.reactos.org wrote: > Author: janderwald > Date: Mon Oct 27 10:16:05 2008 > New Revision: 37023 > > URL: http://svn.reactos.org/svn/reactos?rev=37023&view=rev > Log: > - Add PROVIDER_INFO_1 and PROVIDER_INFO_2 struct > > Modified: > trunk/reactos/include/psdk/winspool.h > > Modified: trunk/reactos/include/psdk/winspool.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/psdk/ > winspool.h?rev=37023&r1=37022&r2=37023&view=diff > ====================================================================== > ======== > --- trunk/reactos/include/psdk/winspool.h [iso-8859-1] (original) > +++ trunk/reactos/include/psdk/winspool.h [iso-8859-1] Mon Oct 27 > 10:16:05 2008 > @@ -700,6 +700,24 @@ > ACCESS_MASK DesiredAccess; > } PRINTER_DEFAULTSW,*PPRINTER_DEFAULTSW,*LPPRINTER_DEFAULTSW; > > +typedef struct _PROVIDOR_INFO_1A{ > + LPSTR pName; > + LPSTR pEnvironment; > + LPSTR pDLLName; > +} PROVIDOR_INFO_1A, *PPROVIDOR_INFO_1A, *LPPROVIDOR_INFO_1A; > +typedef struct _PROVIDOR_INFO_1W{ > + LPWSTR pName; > + LPWSTR pEnvironment; > + LPWSTR pDLLName; > +} PROVIDOR_INFO_1W, *LPPROVIDOR_INFO_1W; > + > +typedef struct _PROVIDOR_INFO_2A{ > + LPSTR pOrder; > +} PROVIDOR_INFO_2A, *PPROVIDOR_INFO_2A, *LPPROVIDOR_INFO_2A; > +typedef struct _PROVIDOR_INFO_2W{ > + LPWSTR pOrder; > +} PROVIDOR_INFO_2W, *LPPROVIDOR_INFO_2W; > + > BOOL WINAPI AbortPrinter(HANDLE); > BOOL WINAPI AddFormA(HANDLE,DWORD,PBYTE); > BOOL WINAPI AddFormW(HANDLE,DWORD,PBYTE); > @@ -833,6 +851,10 @@ > typedef PRINTPROCESSOR_INFO_1W > PRINTPROCESSOR_INFO_1,*PPRINTPROCESSOR_INFO_1,*LPPRINTPROCESSOR_INFO_1 > ; > typedef FORM_INFO_1W FORM_INFO_1,*PFORM_INFO_1,*LPFORM_INFO_1; > typedef PRINTER_DEFAULTSW > PRINTER_DEFAULTS,*PPRINTER_DEFAULTS,*LPPRINTER_DEFAULTS; > +typedef PROVIDOR_INFO_1W PROVIDOR_INFO_1; > +typedef LPPROVIDOR_INFO_1W LPPROVIDOR_INFO_1; > +typedef PROVIDOR_INFO_2W PROVIDOR_INFO_2; > +typedef LPPROVIDOR_INFO_2W LPPROVIDOR_INFO_2; > #define AddForm AddFormW > #define AddJob AddJobW > #define AddMonitor AddMonitorW >

2 1

[ros-diffs] [dreimer] 36968: ok, Binutils and ccache reverted.
by Dmitry Gorbachev 26 Oct '08

26 Oct '08

Hi! Why not use newer GCC 4.3.2 and Binutils 2.19.50 in RosBE, they seems to work well with only a few changes in ReactOS sources.

4 4

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