Ros-dev August 2013

ros-dev@reactos.org

11 participants
14 discussions

Fedroa 19 RosBE bfd.texinfo:325: unknown command `colophon'
by James Tabor 18 Sep '13

18 Sep '13

Hi! Testing our build system 2.0 & 2.1 with Fedora 19, gcc version 4.8.1 20130603 (Red Hat 4.8.1-1) , GNU Make 3.82, from the build log, rm -rf $backupdir; exit $rc ../../../binutils/bfd/doc/bfd.texinfo:325: unknown command `colophon' ../../../binutils/bfd/doc/bfd.texinfo:336: unknown command `cygnus' gmake[3]: *** [bfd.info] Error 1 gmake[3]: Leaving directory `/home/RosBE-Unix-2.1/sources/binutils-build/bfd/do gmake[2]: *** [info-recursive] Error 1 gmake[2]: Leaving directory `/home/RosBE-Unix-2.1/sources/binutils-build/bfd' gmake[1]: *** [all-bfd] Error 2 gmake[1]: Leaving directory `/home/RosBE-Unix-2.1/sources/binutils-build' gmake: *** [all] Error 2 Bug report. http://sourceware.org/bugzilla/show_bug.cgi?id=15183 Possible fix, http://www.mail-archive.com/bug-binutils@gnu.org/msg14429.html Is this a know issue? Thanks, James

2 2

[ros-diffs] [ion] 59868
by James Tabor 04 Sep '13

04 Sep '13

Hi Alex! The stack guards prevent excessive recursions without throwing exceptions and just kills the message loop by returning false. Removing them could regress some misbehaving applications. Only one comes to mind, java installer. Thanks, James

2 1

Re: [ros-dev] Easy job for enhancing our Explorer!
by Ameer Ali 01 Sep '13

01 Sep '13

Hi, I have some great icon with me.... If U request I will give for free Sent from my linux Phone From: Colin Finck Sent: 31-08-2013 PM 03:36 To: ros-dev(a)reactos.org Subject: [ros-dev] Easy job for enhancing our Explorer! Hi all! As suggested in the meeting on Thursday, we need someone to create replacements for all icons used in Windows Explorer. Just have a look at this screenshot of Giannis' recent work to get an idea: http://i.imgur.com/WzxVn7V.png It definitely looks promising, but we obviously can't release it with the XP icons ;) Gladly, the Tango icon library contains a lot of great icons, which may already be suitable for Explorer. Others could be created easily when mixing several icons. For example, the icon for the "Folders" button in Explorer can be created out of two simple folders, and a single folder icon is definitely present in Tango. This only requires basic knowledge of Inkscape (www.inkscape.org). To give you another example: I already needed such "mixed" icons in my PeopleMap. I've released my modified SVG files here: http://svn.reactos.org/svn/web/trunk/resources/peoplemap/?pathrev=700 Apart from the fairly simple Inkscape task, the icons need to be properly converted to ICO files in all required sizes. Giannis or other shell guys can probably tell you about the sizes we need. At least, this requires a proper icon editor with support for 24/32 bit icons (used to be a problem in the past, don't know if it still is). For just creating ICO files out of existing PNG files, I had good experiences with "@icon sushi" (http://www.towofu.net/soft/e-aicon.php). So, there we have it: A job for enhancing our Explorer which doesn't even need a developer! :) If I had time for it, I'd probably do it myself, but I'm pretty sure there are other interested people as well. Cheers, Colin _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev

4 3

Easy job for enhancing our Explorer!
by Colin Finck 31 Aug '13

31 Aug '13

Hi all! As suggested in the meeting on Thursday, we need someone to create replacements for all icons used in Windows Explorer. Just have a look at this screenshot of Giannis' recent work to get an idea: http://i.imgur.com/WzxVn7V.png It definitely looks promising, but we obviously can't release it with the XP icons ;) Gladly, the Tango icon library contains a lot of great icons, which may already be suitable for Explorer. Others could be created easily when mixing several icons. For example, the icon for the "Folders" button in Explorer can be created out of two simple folders, and a single folder icon is definitely present in Tango. This only requires basic knowledge of Inkscape (www.inkscape.org). To give you another example: I already needed such "mixed" icons in my PeopleMap. I've released my modified SVG files here: http://svn.reactos.org/svn/web/trunk/resources/peoplemap/?pathrev=700 Apart from the fairly simple Inkscape task, the icons need to be properly converted to ICO files in all required sizes. Giannis or other shell guys can probably tell you about the sizes we need. At least, this requires a proper icon editor with support for 24/32 bit icons (used to be a problem in the past, don't know if it still is). For just creating ICO files out of existing PNG files, I had good experiences with "@icon sushi" (http://www.towofu.net/soft/e-aicon.php). So, there we have it: A job for enhancing our Explorer which doesn't even need a developer! :) If I had time for it, I'd probably do it myself, but I'm pretty sure there are other interested people as well. Cheers, Colin

1 0

Status Meeting (August 2013)
by Aleksey Bragin 29 Aug '13

29 Aug '13

Hello, Let me invite you to the monthly status meeting taking place last Thursday of this month, 29th of August, 19:00 UTC. Put that into your calendars so you don't forget. IRC service will only be started shortly before the meeting. Your participation passwords and server address will be emailed to you shortly before the meeting starts, and they are going to be different once again as they are not stored in any database. Hopefully it's not much of inconvenience. If someone still is not getting passwords sent before a meeting - please email Colin or Pierre before the meeting started to get one. The agenda will be posted shortly before the meeting, suggestions are welcome (send them to me shortly before the meeting starts). Regards, Aleksey Bragin

2 1

Re: [ros-dev] Ros-dev Digest, Vol 108, Issue 10
by "Железов Михаил" 29 Aug '13

29 Aug '13

Я не проверяю этот почтовый ящик. Новый email: mikezhelezov(a)gmail.com. Пожалуйста, не отвечайте на это письмо.

2 1

[ADVAPI32/SERVICES]: Windows services
by Eric Kohl 28 Aug '13

28 Aug '13

>[ADVAPI32/SERVICES]: Windows services (as per MSDN and testing) must always get at least one parameter -- the service name, in the argument vector. However, in ReactOS, unless optional custom parameters were sent (when starting a service), services got 0 parameters and a NULL argument vector. Since services on Windows know this is impossible, many dereference the vector without checking for NULL (including Windows Svchost.exe). Either way, it's bogus for us not ever sending the name as the first parameter. So I fixed ScBuildUnicodeArgsVector to always either pre-pend the service name (if the caller gave us some parameters already), or do use the name as the sole parameter (if the caller sent none). This now works as on Windows, and should greately help with 3rd party service compatibility. >***NOTE THAT I ONLY DID THIS FOR UNICODE. I DID NOT BOTHER TO FIX THE ANSI VERSION. ERIC KOHL, PLEASE REVIEW & FIX AS APPROPRIATE*** Alex, if you have the time to rewrite svchost, you also have the time to fix the little piece of ansi boredom! Finish the things you start!!!! Do not stop right in the middle and leave the boring parts to others!!! FINISH IT YOURSELF!!!! PS: Btw, you might want to have a look at YOUR ntoskrnl rewrite! CM is still unfinished! Finish it before you open yet another can of worms! Regards, Eric

1 0

Re: [ros-dev] Ros-dev Digest, Vol 108, Issue 9
by "Железов Михаил" 28 Aug '13

28 Aug '13

Я не проверяю этот почтовый ящик. Новый email: mikezhelezov(a)gmail.com. Пожалуйста, не отвечайте на это письмо.

1 0

Re: [ros-dev] [ros-diffs] [fireball] 59733: [WIN32K] - Do not use a internal section object structure type, it's just not necessary and win32k should not ever need to access its fields directly.
by Timo Kreuzer 14 Aug '13

14 Aug '13

\o/ And now please also remove the use of the OBJECT_HEADER structure in win32k ;-) Am 14.08.2013 13:02, schrieb fireball(a)svn.reactos.org: > Author: fireball > Date: Wed Aug 14 11:02:08 2013 > New Revision: 59733 > > URL: http://svn.reactos.org/svn/reactos?rev=59733&view=rev > Log: > [WIN32K] > - Do not use a internal section object structure type, it's just not necessary and win32k should not ever need to access its fields directly. > >

1 0

Re: [ros-dev] [ros-diffs] [cgutman] 59704: [CMAKE] - Define i386 on x86 MSVC builds - Probably fixes the infamous MSVC networking issues caused by tcpip.h assuming it was a big-endian platform and never byte-swapping anythi...
by Timo Kreuzer 12 Aug '13

12 Aug '13

I remember some time ago, I ran into a problem with "i386" definition somewhere, because it was used in a structure or something. I would prefer to use standard definitions as much as possible. And in the case of Windows code, I would consider MS to be standard. So IMO we should use _X86_ or _M_IX86 whenever possible. Am 12.08.2013 03:12, schrieb cgutman(a)svn.reactos.org: > Author: cgutman > Date: Mon Aug 12 01:12:25 2013 > New Revision: 59704 > > URL: http://svn.reactos.org/svn/reactos?rev=59704&view=rev > Log: > [CMAKE] > - Define i386 on x86 MSVC builds > - Probably fixes the infamous MSVC networking issues caused by tcpip.h assuming it was a big-endian platform and never byte-swapping anything > [TCPIP][LAN] > - Fix byteswapping on AMD64 and ARM builds too > > Modified: > trunk/reactos/CMakeLists.txt > trunk/reactos/drivers/network/lan/include/net_wh.h > trunk/reactos/drivers/network/tcpip/include/tcpip.h > > Modified: trunk/reactos/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/CMakeLists.txt?rev=59704&r… > ============================================================================== > --- trunk/reactos/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/CMakeLists.txt [iso-8859-1] Mon Aug 12 01:12:25 2013 > @@ -142,7 +142,7 @@ > > # Arch Options > if(ARCH STREQUAL "i386") > - add_definitions(-D_M_IX86 -D_X86_ -D__i386__) > + add_definitions(-D_M_IX86 -D_X86_ -D__i386__ -Di386) > elseif(ARCH STREQUAL "amd64") > add_definitions(-D_M_AMD64 -D_AMD64_ -D__x86_64__ -D_WIN64) > elseif(ARCH STREQUAL "arm") > > Modified: trunk/reactos/drivers/network/lan/include/net_wh.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/network/lan/includ… > ============================================================================== > --- trunk/reactos/drivers/network/lan/include/net_wh.h [iso-8859-1] (original) > +++ trunk/reactos/drivers/network/lan/include/net_wh.h [iso-8859-1] Mon Aug 12 01:12:25 2013 > @@ -1,6 +1,6 @@ > #pragma once > > -#ifdef i386 > +#if defined(i386) || defined(_AMD64_) || defined(_ARM_) > > /* DWORD network to host byte order conversion for i386 */ > #define DN2H(dw) \ > @@ -26,7 +26,7 @@ > ((((w) & 0xFF00) >> 8) | \ > (((w) & 0x00FF) << 8)) > > -#else /* i386 */ > +#else /* defined(i386) || defined(_AMD64_) || defined(_ARM_) */ > > /* DWORD network to host byte order conversion for other architectures */ > #define DN2H(dw) \ > @@ -44,4 +44,4 @@ > #define WH2N(w) \ > (w) > > -#endif /* i386 */ > +#endif /* defined(i386) || defined(_AMD64_) || defined(_ARM_) */ > > Modified: trunk/reactos/drivers/network/tcpip/include/tcpip.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/network/tcpip/incl… > ============================================================================== > --- trunk/reactos/drivers/network/tcpip/include/tcpip.h [iso-8859-1] (original) > +++ trunk/reactos/drivers/network/tcpip/include/tcpip.h [iso-8859-1] Mon Aug 12 01:12:25 2013 > @@ -65,7 +65,7 @@ > #define NDIS_BUFFER_TAG FOURCC('n','b','u','f') > #define NDIS_PACKET_TAG FOURCC('n','p','k','t') > > -#ifdef i386 > +#if defined(i386) || defined(_AMD64_) || defined(_ARM_) > > /* DWORD network to host byte order conversion for i386 */ > #define DN2H(dw) \ > @@ -91,7 +91,7 @@ > ((((w) & 0xFF00) >> 8) | \ > (((w) & 0x00FF) << 8)) > > -#else /* i386 */ > +#else /* defined(i386) || defined(_AMD64_) || defined(_ARM_) */ > > #error Unsupported architecture > > @@ -111,7 +111,7 @@ > #define WH2N(w) \ > (w) > > -#endif /* i386 */ > +#endif /* defined(i386) || defined(_AMD64_) || defined(_ARM_) */ > > /* AF_INET and other things Arty likes to use ;) */ > #define AF_INET 2 > > >

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev August 2013