Ros-dev

ros-dev@reactos.org

5788 discussions

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

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

15 years, 11 months

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

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

15 years, 11 months

Re: [ros-dev] [ros-diffs] [jimtabor] 37099: Implement GetFontUnicodeRanges, port from wine. Tested with wine gdi32 font crosstests.

by Steven Edwards

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

15 years, 11 months

generic graphics

by Matthias Kupfer

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

15 years, 11 months

Trunk freeze

by Aleksey Bragin

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.

15 years, 11 months

Win32k Foating Point

by James Tabor

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

15 years, 11 months

Re: [ros-dev] [ros-diffs] [janderwald] 37023: - Add PROVIDER_INFO_1 and PROVIDER_INFO_2 struct

by Aleksey Bragin

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 >

15 years, 11 months

[ros-diffs] [dreimer] 36968: ok, Binutils and ccache reverted.

by Dmitry Gorbachev

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.

15 years, 11 months

[ros-diffs] [dreimer] 36968: ok, Binutils and ccache reverted.

by Dmitry Gorbachev

> If the current tree really builds 100% with GCC 4.3.2 or you (or someone > else) could provide patches for getting it to work, the update should be > done as soon as possible (but after 0.3.7 :P) I use GCC 4.3.2 and new binutils for about a month without difficulties; if you need any patches then please email me. Of course, I do not insist on including it in RosBE. Best wishes, Dmitry

15 years, 11 months

[ros-diffs] [dreimer] 36968: ok, Binutils and ccache reverted.

by Dmitry Gorbachev

> Because it would fully break the possibility to build older revs. I dont > know if this counts as argument. With such an argument upgrade will never come...

15 years, 11 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev