> 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
> 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...
I have to disagree with this binutils revert.
If we aren't prepared to keep our tools up to date, then we'll have to resort to dropping RosBE and updating our tools manually.
Build tools should _always_ be kept up to date.
Ged
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of dreimer(a)svn.reactos.org
Sent: 25 October 2008 22:39
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [dreimer] 36968: ok, Binutils and ccache reverted.
Author: dreimer
Date: Sat Oct 25 16:39:26 2008
New Revision: 36968
URL: http://svn.reactos.org/svn/reactos?rev=36968&view=rev
Log:
ok, Binutils and ccache reverted.
Modified:
trunk/tools/RosBE/RosBE-Windows/Root/ChangeLog.txt
trunk/tools/RosBE/RosBE-Windows/RosBE.nsi
Modified: trunk/tools/RosBE/RosBE-Windows/Root/ChangeLog.txt
URL: http://svn.reactos.org/svn/reactos/trunk/tools/RosBE/RosBE-Windows/Root/Cha…
==============================================================================
--- trunk/tools/RosBE/RosBE-Windows/Root/ChangeLog.txt [iso-8859-1] (original)
+++ trunk/tools/RosBE/RosBE-Windows/Root/ChangeLog.txt [iso-8859-1] Sat Oct 25 16:39:26 2008
@@ -5,15 +5,12 @@
- Updated: NSIS to 2.40 (Daniel Reimer)
- Updated: Subversion to 1.5.3 (Daniel Reimer)
- Updated: GDB to 6.8-3 (Daniel Reimer)
-- Updated: Binutils 2.18.50 Build 20080109. (Daniel Reimer)
- Updated: MingW32 Make 3.81-3 (Daniel Reimer)
- Updated: MingW32 Runtime DLL 3.15.1 (Daniel Reimer)
- Other small Fixes here and there (Daniel Reimer)
- Added: Basic PowerShell Version of RosBE (Daniel Reimer)
- Added: YASM 0.72, which supports 64 bit asm too. (Daniel Reimer)
- Added: Update command (Daniel Reimer)
-- Added: A way to include rosapps and rostests into the build and ssvn script by modifying
- one var. Add this var to options.exe (Maciej Bialas and slight changes by me)
- Added: nostrip function (Christoph von Wittich)
- Added: RosBE Debugging Feature which disables the @echo off. just set
_ROSBE_DEBUG=1 (Daniel Reimer)
Modified: trunk/tools/RosBE/RosBE-Windows/RosBE.nsi
URL: http://svn.reactos.org/svn/reactos/trunk/tools/RosBE/RosBE-Windows/RosBE.ns…
==============================================================================
--- trunk/tools/RosBE/RosBE-Windows/RosBE.nsi [iso-8859-1] (original)
+++ trunk/tools/RosBE/RosBE-Windows/RosBE.nsi [iso-8859-1] Sat Oct 25 16:39:26 2008
@@ -201,6 +201,7 @@
SetOutPath "$INSTDIR\4.1.3\bin"
SetOverwrite try
File /r Components\Tools\ccache.exe
+ File /r Components\Tools\cygwin1.dll
SectionEnd
Section "GDB - The GNU Project Debugger" SEC07
I'd like to bring attention to this change, I think it's a rather
interesting one.
So now, for example, if you have a static library A which uses
something from a few small libraries B, C, D, you don't have to
specify in every module that you link with A, B, C and D - you can
just specify once that library A always goes with B,C,D and then link
only to library A in your modules.
WBR,
Aleksey Bragin.
On Oct 25, 2008, at 6:52 AM, hyperion(a)svn.reactos.org wrote:
> Author: hyperion
> Date: Fri Oct 24 21:52:24 2008
> New Revision: 36929
>
> URL: http://svn.reactos.org/svn/reactos?rev=36929&view=rev
> Log:
> modified tools/rbuild/backend/mingw/modulehandler.cpp
> Allow static libraries to "link" to other static libraries
> Removed some dead code
>
> modified dll/nls/normaliz_redist/normaliz_redist.rbuild
> modified dll/win32/kernel32/kernel32.rbuild
> No need to specify icu4ros explicitely anymore, thanks to the
> rbuild changes
> Make kernel32_base include normalize, rather than linking it as
> an external dependency of kernel32
Hello,
I would like to announce, that the call for papers/lectures for the Chemnitz
linux days (Chemnitz LinuxTage) has been started some days ago and will end
at january 5th 2009. If one of you (or the devs in whole) want to present
reactos in any kind (e.g. demonstration, lecture) please let me know. If
there is no other developer, I would be glad to present the project instead
of you, but i'm interested in more involved developers as well. AFAIK in
special cases it's possible to get additional money for travel if necessary,
but bear in mind - it's a non-commercial event. For the German(-speaking)
developers I recommend the website for the event for more details (sorry,
germyn only): http://chemnitzer.linux-tage.de/2009/info/
Comments are very welcome!
Matthias
P.S. I think such events are well suited for recruiting new developers.
--
Matthias Kupfer fon +49 (0) 371 236 46 52
Wilhelm-Firl-Straße 21 mobile +49 (0) 160 859 43 54
09122 Chemnitz
--
Matthias Kupfer Telefon +49 (0) 371 236 46 52
Wilhelm-Firl-Straße 21 Mobil +49 (0) 160 859 43 54
09122 Chemnitz
I would like to hear if this change is agreed with Herve or not, and
if not, what's his opinion about it.
On Oct 22, 2008, at 5:59 PM, sginsberg(a)svn.reactos.org wrote:
> Author: sginsberg
> Date: Wed Oct 22 08:59:01 2008
> New Revision: 36894
>
> URL: http://svn.reactos.org/svn/reactos?rev=36894&view=rev
> Log:
> - Notify umpnpmgr about logon after the shell has initialized
> - This makes it possible to progress if userinit crashes due to
> heavy debug output (due to timing issues in its communication with
> umpnpmgr), which would leave you stranded with no shell. Not really
> a hack, as it doesn't hide or fix the crash -- just limits it to a
> missing "Pending device installations" prompt in case there are any
> pending. Also, it appears to be done the same way on Windows.
Hi there,
I've been snooping into the internals of Win XP and have setup a win32sys SDT
hook on the NtUserCreateWindowEx function.
I'd written sometime back to the list stating that the x,y,nWidth and nHeight
parameters were showing values I couldn't understand - negative values et al.
Since then I realized that this had to do with the fact that the parameter
positions in the prototype I was using seemed to be in a different order
(discovered a window.c file from this project on koders.com and was using
this prototype). I think this could possibly be because maybe the ros team
has been looking at a version of windows that isn't XP (possible??)..dunno
Anyways the parameter ordering I've deduced seems to be :
NtUserCreateWindowEx(DWORD dwExStyle,PUNICODE_STRING
UnsafeClassName,PUNICODE_STRING UnsafeWindowName,DWORD dwUnknown1,DWORD
dwStyle,LONG x, LONG y,LONG nWidth, LONG nHeight,HWND
hWndParent,HMENU,hMenu,HINSTANCE hInstance,LPVOID lpParam,DWORD
dwShowMode,DWORD dwUnknown2)
This seems to be correct with regards the
dwExStyle,dwStyle,x,y,nWidth,nHeight,hWndParent.hMenu,hInstance,lpParam
arguments.
I'm still not able to verify the rest. My immediate concern though are the
UnsafeClassName and UnsafeWindowName arguments.
I'm trying to print out these values...or test out what these values
hold...but can't seem to get anywhere....don't even know for sure if these
are UNICODE_STRING structure vals or LPCTSTR.
I'd like to be able to retrieve/interpret the ClassName and
WindowName......any help would be appreciated.
Bye for now
"It's like NT does" isn't an advantage... cloning *build methods* of
the Core OS Division at Microsoft doesn't do anything positive (nor
negative) to the quality and reliability of the code. You have to look
at *what* the method involves and analyze that way.
Your other argument applies: building RTL multiple times reduces the
need for the small support library ReactOS uses and gives one
consistent place for RTL code.
Disadvantages:
- Building RTL up to 4 times, increasing build time substantially (rtl
is a pretty big library).
- Quadruple-conditional compilation...meaning people will have to test
their rtl changes by BUILDING FOUR TIMES with different conditionals.
Will people really remember to do this? Will people really write code
knowing exactly what do ifdef and where, and how?
- To do this right, you'll need a host-rtl too. Have fun writing one.
- Right now the commit did only half the work -- now compile time is
doubled, but libsupp is still there, making the situation even worse.
The commiter made the assumption "other people" will pick up the
slack, which probably won't happen, and this will rot forever.
Best regards,
Alex Ionescu
On Wed, Oct 15, 2008 at 2:41 PM, Aleksey Bragin <aleksey(a)reactos.org> wrote:
> I knew about this post-factum, so let's gather opinions.
>
> Advantage: It's like NT does, less hacks, possible removal of libsupp
> stuff in ntoskrnl, freeldr, ntdll, etc (which I actually thought
> would be done in the same commit).
>
> Disadvantage: To be proper, you need a bootloader RTL too, otherwise
> RTL will still contain "necessitating hacks" aka libsupp stuff. This
> is gonna make at least 3x time RTL compilation. (thankfully / sadly
> we don't test it directly).
>
>
> WBR,
> Aleksey.
>
>
>
> On Oct 15, 2008, at 10:02 PM, Alex Ionescu wrote:
>
>> Well, you just removed the one thing ReactOS did different from NT and
>> that I thought was really revolutionary and innovative, because it
>> saves on compile time. It's funny, because I've been trying to sell
>> this as a better approach to building RTL (It's built at least 4 times
>> in the real NT tree, I think -- loader, user-mode tools/testing,
>> kernel, user-mode).
>>
>> Best regards,
>> Alex Ionescu
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>