Hi,
I use GCC 4.4 for ReactOS for a long time, and have not yet found any major issues. Test results are similar to those from the server. Looking into GCC 4.5 (has two regressions) and LLVM-GCC (one major bug and some lesser).
Hi Dmitry,
Does that mean you have patches to fix all the warnings (and errors) in the log? Or have you just hacked the .rbuild files to ignore them? ;-)
What about C++ support, how did you solve that?
Happy to hear the test results are similar, however.
Best regards, Alex Ionescu
On Mon, Aug 24, 2009 at 11:00 AM, Dmitry Gorbachevd.g.gorbachev@gmail.com wrote:
Hi,
I use GCC 4.4 for ReactOS for a long time, and have not yet found any major issues. Test results are similar to those from the server. Looking into GCC 4.5 (has two regressions) and LLVM-GCC (one major bug and some lesser).
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Does that mean you have patches to fix all the warnings (and errors) in the log?
There are no errors. No need to fix all warnings at once. Though ReactOS is compiling with -Werror, there are (commented out) options in ReactOS-generic.rbuild, which demote some errors to warnings again, so they will not be forgotten.
Or have you just hacked the .rbuild files to ignore them? ;-)
I unhacked them. ;-)
What about C++ support, how did you solve that?
I have not noticed any problems with C++.
Happy to hear the test results are similar, however.
Everything is just fine! :-)
Hi,
I'd be curious about how you solved these issues:
modules\rostests\dxtest\ddraw\testlist.cpp:29: error: deprecated conversion from string constant to 'CHAR*' base\shell\explorer\shell\pane.cpp:58: error: deprecated conversion from string constant to 'WCHAR*' modules\rosapps\applications\devutils\gdb2\gdb2.cpp:97: error: deprecated conversion from string constant to 'char*' modules\rostests\dxtest\ddraw/debug.cpp:8: error: deprecated conversion from string constant to 'CHAR*' modules\rostests\dxtest\ddraw/Surface/caps_tests.h:8: error: deprecated conversion from string constant to 'char*'
And especially:
modules\rostests\winetests\kernel32\thread.c:22:1: warning: "_WIN32_WINNT" redefined (and similar)
And also the linker errors regarding unwind functions in C++, and the lack of a libgcc? How were you able to build ntoskrnl when the function to make the stack executable imports from VirtualProtect?
Thanks!
Best regards, Alex Ionescu
On Mon, Aug 24, 2009 at 1:43 PM, Dmitry Gorbachevd.g.gorbachev@gmail.com wrote:
Does that mean you have patches to fix all the warnings (and errors) in the log?
There are no errors. No need to fix all warnings at once. Though ReactOS is compiling with -Werror, there are (commented out) options in ReactOS-generic.rbuild, which demote some errors to warnings again, so they will not be forgotten.
Or have you just hacked the .rbuild files to ignore them? ;-)
I unhacked them. ;-)
What about C++ support, how did you solve that?
I have not noticed any problems with C++.
Happy to hear the test results are similar, however.
Everything is just fine! :-)
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Hi!
I'd be curious about how you solved these issues:
error: deprecated conversion from string constant to 'CHAR*'
As it is not a real error, I turned it into a warning again with "-Wno-error=write-strings" in ReactOS-generic.rbuild.
And especially:
modules\rostests\winetests\kernel32\thread.c:22:1: warning: "_WIN32_WINNT" redefined
GCC from RosBE also emits warnings like "_WIN32_IE" redefined, it does not make impossible to use it.
And also the linker errors regarding unwind functions in C++
Maybe your GCC is configured differently? What "gcc -v" says?
and the lack of a libgcc?
How it can be?!
How were you able to build ntoskrnl when the function to make the stack executable imports from VirtualProtect?
At first, patched GCC. But when Daniel said he failed to build GCC, I replaced __enable_execute_stack() in libgcc instead. See bug #4810.
Cheers, Dmitry
Dmitry Gorbachev wrote:
Hi!
I'd be curious about how you solved these issues:
error: deprecated conversion from string constant to 'CHAR*'
As it is not a real error, I turned it into a warning again with "-Wno-error=write-strings" in ReactOS-generic.rbuild.
And especially:
modules\rostests\winetests\kernel32\thread.c:22:1: warning: "_WIN32_WINNT" redefined
GCC from RosBE also emits warnings like "_WIN32_IE" redefined, it does not make impossible to use it.
And also the linker errors regarding unwind functions in C++
Maybe your GCC is configured differently? What "gcc -v" says?
and the lack of a libgcc?
How it can be?!
How were you able to build ntoskrnl when the function to make the stack executable imports from VirtualProtect?
At first, patched GCC. But when Daniel said he failed to build GCC, I replaced __enable_execute_stack() in libgcc instead. See bug #4810.
Cheers, Dmitry
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
D:\SVNTree\ReactOS>gcc -v Using built-in specs. Target: mingw32 Configured with: ../gcc-4.4.0/configure --enable-languages=c,ada,c++,fortran,jav a,objc,obj-c++ --disable-sjlj-exceptions --enable-shared --enable-libgcj --enabl e-libgomp --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enab le-version-specific-runtime-libs --prefix=/mingw --with-gmp=/mingw/src/gmp/root --with-mpfr=/mingw/src/mpfr/root --build=mingw32 Thread model: win32 gcc version 4.4.0 (GCC)
Hi,
--disable-sjlj-exceptions
This causes linker errors when compiling C++ programs which use exceptions. I also add "--disable-shared" option, as in RosBE, too. I don't know, whether it can be solved without rebuilding GCC or not. Maybe you should ask MinGW people. About bug 4810, perhaps it would be good to have a compile time option which returns the old behavior. It should be easy to add such an option.
On 25-Aug-09, at 2:18 AM, Dmitry Gorbachev wrote:
Hi!
I'd be curious about how you solved these issues:
error: deprecated conversion from string constant to 'CHAR*'
As it is not a real error, I turned it into a warning again with "-Wno-error=write-strings" in ReactOS-generic.rbuild.
Overwriting constant strings is a very real error and should be fixed. Code like this would crash in Windows, for example.
Perhaps you don't understand the issue: in C, declaring a string "const" means it will never be modified. Most linkers will place the string in .rdata, consequently.
Writing to such a string is both dangerous, because you're breaking a contract, and will also generate a page fault, since you're trying to write to a read-only section (.rdata).
And especially:
modules\rostests\winetests\kernel32\thread.c:22:1: warning: "_WIN32_WINNT" redefined
GCC from RosBE also emits warnings like "_WIN32_IE" redefined, it does not make impossible to use it.
It is still a very big error to redefine the target version.
And also the linker errors regarding unwind functions in C++
Maybe your GCC is configured differently? What "gcc -v" says?
and the lack of a libgcc?
How it can be?!
How were you able to build ntoskrnl when the function to make the stack executable imports from VirtualProtect?
At first, patched GCC. But when Daniel said he failed to build GCC, I replaced __enable_execute_stack() in libgcc instead. See bug #4810.
So as I said, ReactOS need an in-tree version of libgcc with proper support for __enable_execute_stack for kernel-mode.
Cheers, Dmitry
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards, Alex Ionescu
Overwriting constant strings is a very real error and should be fixed. Code like this would crash in Windows, for example.
These warnings do not mean overwriting, simply passing a string constant to a function which takes char *; a potential, not necessarily a real error. It is allowed in C, not in C++.
Of course, it would be good to check all warnings, some can be bugs. Not all useful warnings are included in -Wall. It may be worth to activate more.
But warnings should not deter from adoption of GCC 4.4.
So as I said, ReactOS need an in-tree version of libgcc with proper support for __enable_execute_stack for kernel-mode.
It is not needed in user-mode, too. Nested functions are only used by PSEH2, and it works well without __enable_execute_stack()
Hi,
On 25-Aug-09, at 12:48 PM, Dmitry Gorbachev wrote:
Overwriting constant strings is a very real error and should be fixed. Code like this would crash in Windows, for example.
These warnings do not mean overwriting, simply passing a string constant to a function which takes char *; a potential, not necessarily a real error. It is allowed in C, not in C++.
So they still deserve fixing :)
Of course, it would be good to check all warnings, some can be bugs. Not all useful warnings are included in -Wall. It may be worth to activate more.
But warnings should not deter from adoption of GCC 4.4.
I agree, but switching compilers is a great time to fix some warnings. It would take less then a day to fix the ones present today.
So as I said, ReactOS need an in-tree version of libgcc with proper support for __enable_execute_stack for kernel-mode.
It is not needed in user-mode, too. Nested functions are only used by PSEH2, and it works well without __enable_execute_stack()
Sure, but that's not the only reason why an in-tree libgcc is a good idea.
Is your GCC 4.4 built on Windows or Linux? If Windows, perhaps it could become part of RosBE -- they have not been able to figure out how to build the compiler, hence my idea to use the MinGW binaries.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards, Alex Ionescu
Alex Ionescu wrote:
Hi,
On 25-Aug-09, at 12:48 PM, Dmitry Gorbachev wrote:
Overwriting constant strings is a very real error and should be fixed. Code like this would crash in Windows, for example.
These warnings do not mean overwriting, simply passing a string constant to a function which takes char *; a potential, not necessarily a real error. It is allowed in C, not in C++.
So they still deserve fixing :)
Of course, it would be good to check all warnings, some can be bugs. Not all useful warnings are included in -Wall. It may be worth to activate more.
But warnings should not deter from adoption of GCC 4.4.
I agree, but switching compilers is a great time to fix some warnings. It would take less then a day to fix the ones present today.
So as I said, ReactOS need an in-tree version of libgcc with proper support for __enable_execute_stack for kernel-mode.
It is not needed in user-mode, too. Nested functions are only used by PSEH2, and it works well without __enable_execute_stack()
Sure, but that's not the only reason why an in-tree libgcc is a good idea.
Is your GCC 4.4 built on Windows or Linux? If Windows, perhaps it could become part of RosBE -- they have not been able to figure out how to build the compiler, hence my idea to use the MinGW binaries.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards, Alex Ionescu
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Maybe he can just look at our wiki: http://www.reactos.org/wiki/Compiling_GCC_From_Windows and fix it so that it works ;-)
So? What's the status on this? It's almost been a month.
Best regards, Alex Ionescu
On Wed, Aug 26, 2009 at 6:33 AM, Daniel Reimer daniel.reimer@stud-mail.uni-wuerzburg.de wrote:
Alex Ionescu wrote:
Hi,
On 25-Aug-09, at 12:48 PM, Dmitry Gorbachev wrote:
Overwriting constant strings is a very real error and should be fixed. Code like this would crash in Windows, for example.
These warnings do not mean overwriting, simply passing a string constant to a function which takes char *; a potential, not necessarily a real error. It is allowed in C, not in C++.
So they still deserve fixing :)
Of course, it would be good to check all warnings, some can be bugs. Not all useful warnings are included in -Wall. It may be worth to activate more.
But warnings should not deter from adoption of GCC 4.4.
I agree, but switching compilers is a great time to fix some warnings. It would take less then a day to fix the ones present today.
So as I said, ReactOS need an in-tree version of libgcc with proper support for __enable_execute_stack for kernel-mode.
It is not needed in user-mode, too. Nested functions are only used by PSEH2, and it works well without __enable_execute_stack()
Sure, but that's not the only reason why an in-tree libgcc is a good idea.
Is your GCC 4.4 built on Windows or Linux? If Windows, perhaps it could become part of RosBE -- they have not been able to figure out how to build the compiler, hence my idea to use the MinGW binaries.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards, Alex Ionescu
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Maybe he can just look at our wiki: http://www.reactos.org/wiki/Compiling_GCC_From_Windows and fix it so that it works ;-)
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Alex Ionescu wrote:
So? What's the status on this? It's almost been a month.
Best regards, Alex Ionescu
On Wed, Aug 26, 2009 at 6:33 AM, Daniel Reimer daniel.reimer@stud-mail.uni-wuerzburg.de wrote:
Alex Ionescu wrote:
Hi,
On 25-Aug-09, at 12:48 PM, Dmitry Gorbachev wrote:
Overwriting constant strings is a very real error and should be fixed. Code like this would crash in Windows, for example.
These warnings do not mean overwriting, simply passing a string constant to a function which takes char *; a potential, not necessarily a real error. It is allowed in C, not in C++.
So they still deserve fixing :)
Of course, it would be good to check all warnings, some can be bugs. Not all useful warnings are included in -Wall. It may be worth to activate more.
But warnings should not deter from adoption of GCC 4.4.
I agree, but switching compilers is a great time to fix some warnings. It would take less then a day to fix the ones present today.
So as I said, ReactOS need an in-tree version of libgcc with proper support for __enable_execute_stack for kernel-mode.
It is not needed in user-mode, too. Nested functions are only used by PSEH2, and it works well without __enable_execute_stack()
Sure, but that's not the only reason why an in-tree libgcc is a good idea.
Is your GCC 4.4 built on Windows or Linux? If Windows, perhaps it could become part of RosBE -- they have not been able to figure out how to build the compiler, hence my idea to use the MinGW binaries.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards, Alex Ionescu
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Maybe he can just look at our wiki: http://www.reactos.org/wiki/Compiling_GCC_From_Windows and fix it so that it works ;-)
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
- Colin wants to build a GCC with more optimal settings than the official one when he got some spare time. - I added a new log three days ago which shows the linking errors too. - Some devs started to fix warnings and errors we get.
So in other words, in a month minus 3 days:
* The release engineer has expressed a desire (to do something that has already been attempted for 7 months and counting)
and
* A couple of developers (Stefan, mainly) have, at least, fixed a couple dozen warnings (thank you!)
So:
* No Libgcc has been imported into the tree yet (to solve some of the linker errors) as KJK has suggested he will do * No additional attempts/efforts (expressing a desire/want does not count as effort) have been made to recompile Mingw32-gcc-4.4 as Dmitry does. * Two months after Aleksey promised me that "he will write something about this", I still don't see any e-mail regarding GCC 4.4 (ie: I was bullshitted to).
I think more effort needs to be put into this, honestly.
Daniel, on the log:
1) Could you please separate trunk vs rosapps/rostests errors? 2) "In file included from modules\rosapps\applications\net\ncftp\sio\SClose.c:1: modules\rosapps\applications\net\ncftp\sio/syshdrs.h:36:1: warning: "strncasecmp" redefined" is spamming half the log -- the actual error is only one (and pretty easy to fix, but that's another story), so I suggest you remove the 50 duplicate entries. 3) There used to be errors related to PSEH2 and executable stack -- have those been fixed or...?
Thank you.
Best regards, Alex Ionescu
On Sun, Sep 13, 2009 at 3:21 PM, Daniel Reimer daniel.reimer@stud-mail.uni-wuerzburg.de wrote:
Alex Ionescu wrote:
So? What's the status on this? It's almost been a month.
Best regards, Alex Ionescu
On Wed, Aug 26, 2009 at 6:33 AM, Daniel Reimer daniel.reimer@stud-mail.uni-wuerzburg.de wrote:
Alex Ionescu wrote:
Hi,
On 25-Aug-09, at 12:48 PM, Dmitry Gorbachev wrote:
Overwriting constant strings is a very real error and should be fixed. Code like this would crash in Windows, for example.
These warnings do not mean overwriting, simply passing a string constant to a function which takes char *; a potential, not necessarily a real error. It is allowed in C, not in C++.
So they still deserve fixing :)
Of course, it would be good to check all warnings, some can be bugs. Not all useful warnings are included in -Wall. It may be worth to activate more.
But warnings should not deter from adoption of GCC 4.4.
I agree, but switching compilers is a great time to fix some warnings. It would take less then a day to fix the ones present today.
So as I said, ReactOS need an in-tree version of libgcc with proper support for __enable_execute_stack for kernel-mode.
It is not needed in user-mode, too. Nested functions are only used by PSEH2, and it works well without __enable_execute_stack()
Sure, but that's not the only reason why an in-tree libgcc is a good idea.
Is your GCC 4.4 built on Windows or Linux? If Windows, perhaps it could become part of RosBE -- they have not been able to figure out how to build the compiler, hence my idea to use the MinGW binaries.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards, Alex Ionescu
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Maybe he can just look at our wiki: http://www.reactos.org/wiki/Compiling_GCC_From_Windows and fix it so that it works ;-)
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
- Colin wants to build a GCC with more optimal settings than the
official one when he got some spare time.
- I added a new log three days ago which shows the linking errors too.
- Some devs started to fix warnings and errors we get.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
So and that everyone is happy on IRC: My answer on the TOP.
Regarding Nr 3. I used the suggestion of HTO from this bug, the ar line and his uploaded "fix" http://www.reactos.org/bugzilla/show_bug.cgi?id=4810
Alex Ionescu wrote:
So in other words, in a month minus 3 days:
- The release engineer has expressed a desire (to do something that
has already been attempted for 7 months and counting)
and
- A couple of developers (Stefan, mainly) have, at least, fixed a
couple dozen warnings (thank you!)
So:
- No Libgcc has been imported into the tree yet (to solve some of the
linker errors) as KJK has suggested he will do
- No additional attempts/efforts (expressing a desire/want does not
count as effort) have been made to recompile Mingw32-gcc-4.4 as Dmitry does.
- Two months after Aleksey promised me that "he will write something
about this", I still don't see any e-mail regarding GCC 4.4 (ie: I was bullshitted to).
I think more effort needs to be put into this, honestly.
Daniel, on the log:
- Could you please separate trunk vs rosapps/rostests errors?
- "In file included from modules\rosapps\applications\net\ncftp\sio\SClose.c:1:
modules\rosapps\applications\net\ncftp\sio/syshdrs.h:36:1: warning: "strncasecmp" redefined" is spamming half the log -- the actual error is only one (and pretty easy to fix, but that's another story), so I suggest you remove the 50 duplicate entries. 3) There used to be errors related to PSEH2 and executable stack -- have those been fixed or...?
Thank you.
Best regards, Alex Ionescu
On Sun, Sep 13, 2009 at 3:21 PM, Daniel Reimer daniel.reimer@stud-mail.uni-wuerzburg.de wrote:
Alex Ionescu wrote:
So? What's the status on this? It's almost been a month.
Best regards, Alex Ionescu
On Wed, Aug 26, 2009 at 6:33 AM, Daniel Reimer daniel.reimer@stud-mail.uni-wuerzburg.de wrote:
Alex Ionescu wrote:
Hi,
On 25-Aug-09, at 12:48 PM, Dmitry Gorbachev wrote:
> Overwriting constant strings is a very real error and should be > fixed. > Code like this would crash in Windows, for example. > > > These warnings do not mean overwriting, simply passing a string constant to a function which takes char *; a potential, not necessarily a real error. It is allowed in C, not in C++.
So they still deserve fixing :)
Of course, it would be good to check all warnings, some can be bugs. Not all useful warnings are included in -Wall. It may be worth to activate more.
But warnings should not deter from adoption of GCC 4.4.
I agree, but switching compilers is a great time to fix some warnings. It would take less then a day to fix the ones present today.
> So as I said, ReactOS need an in-tree version of libgcc with proper > support for __enable_execute_stack for kernel-mode. > > > It is not needed in user-mode, too. Nested functions are only used by PSEH2, and it works well without __enable_execute_stack()
Sure, but that's not the only reason why an in-tree libgcc is a good idea.
Is your GCC 4.4 built on Windows or Linux? If Windows, perhaps it could become part of RosBE -- they have not been able to figure out how to build the compiler, hence my idea to use the MinGW binaries.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards, Alex Ionescu
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Maybe he can just look at our wiki: http://www.reactos.org/wiki/Compiling_GCC_From_Windows and fix it so that it works ;-)
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
- Colin wants to build a GCC with more optimal settings than the
official one when he got some spare time.
- I added a new log three days ago which shows the linking errors too.
- Some devs started to fix warnings and errors we get.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Firstly, that text is written for usenet not email, which IMO is both ancient and very unix orientated. Secondly, it's rather difficult to write emails in that format using outlook, which is by far the world's most popular and best email client.
So, I would argue that that link is rather obsolete.
Ged.
p.s. this reply is in the world recognised (and enterprise standard) outlook format ;)
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Danny Götte Sent: 13 September 2009 22:03 To: ReactOS Development List Subject: Re: [ros-dev] GCC 4.4
Hi,
sorry for OT, but http://learn.to/quote/
thanks
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Hi,
Ged Murphy wrote:
Firstly, that text is written for usenet not email, which IMO is both
It's a mailing list. So it's closer to usenet than to "normal" email IMO.
ancient and very unix orientated.
What does usenet have todo with unix?
Secondly, it's rather difficult to write emails in that format using outlook, which is by far the world's most popular and best email client.
Maybe that would be a good reason to switch the email client? ;-)
So, I would argue that that link is rather obsolete.
Well, it contains several points that make reading messages in mailings lists more readable. Especially: - Quoting the whole email that you answer to (including headers and signatures etc) is useless and only wastes traffic and the readers time. - Writing your message on top of the original might work once, but as soon as multiple replys are written, everything starts to turn into an upside down mess.
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Danny Götte Sent: 13 September 2009 22:03 To: ReactOS Development List Subject: Re: [ros-dev] GCC 4.4
Lots of useless information here. It's already in the headers if you really need it. Everyone should know where this stuff came from and to what it answers. That's what your client should keep track of.
Hi,
sorry for OT, but http://learn.to/quote/
thanks
Quotes should start with leading ">" to make it more readable.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Quoting signatures / footers is a waste of space.
Regards, Timo
Ged Murphy wrote:
Firstly, that text is written for usenet not email, which IMO is both ancient and very unix orientated.
Usenet has nothing to do with Unix today. Even your favourite software company still maintains active Usenet newsgroups, whose members usually follow the quoting guidelines :-P
Secondly, it's rather difficult to write emails in that format using outlook
Oh, and I'm currently using Outlook for writing this mail :-) It maybe takes 10 more seconds to reformat the mail in accordance to the quoting guidelines.
All in all, I second Timo's opinion about this. If you want to quote certain parts of a mail here, please abide by the mentioned guidelines.
Best regards,
Colin
10 seconds?
I'd need to go into outlooks email settings, change the 'when replying to a message prefix each line with with '>'', then I can click on reply without having to manually add a '>' at the start of every line. Next delete the header and add a 'Joe Bloggs wrote:' in its place and then format your message. Then go back into my email settings and swap everything to default outlook settings, so that normal people I reply to in work, etc don't think I've lost the plot.
Nope, not gonna happen. :)
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Colin Finck Sent: 14 September 2009 20:00 To: 'ReactOS Development List' Subject: Re: [ros-dev] Quoting [was: GCC 4.4]
Ged Murphy wrote:
Firstly, that text is written for usenet not email, which IMO is both ancient and very unix orientated.
Usenet has nothing to do with Unix today. Even your favourite software company still maintains active Usenet newsgroups, whose members usually follow the quoting guidelines :-P
Secondly, it's rather difficult to write emails in that format using outlook
Oh, and I'm currently using Outlook for writing this mail :-) It maybe takes 10 more seconds to reformat the mail in accordance to the quoting guidelines.
All in all, I second Timo's opinion about this. If you want to quote certain parts of a mail here, please abide by the mentioned guidelines.
Best regards,
Colin
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ged Murphy wrote:
I'd need to go into outlooks email settings, change the 'when replying to a message prefix each line with with '>'',
Yes, that needs to be done once.
Then go back into my email settings and swap everything to default outlook settings, so that normal people I reply to in work, etc don't think I've lost the plot.
Well, you're aware that the prefix settings only apply to plain text E-Mails and not HTML?
If you and your colleagues at work deem the default Outlook E-Mail format settings alright, this change shouldn't be a problem for you. Outlook by default only sends HTML E-Mails as well :-)
Best regards,
Colin
Alex Since you are subscribed to ros-diff ml, you should be aware, that ros development, rated by commit number, has come almost to standstill.
2009/9/13 Alex Ionescu ionucu@videotron.ca
So in other words, in a month minus 3 days:
Wrong. Many ppl work on their parts, but noone finished enough worth a commit yet. Just wait a bit
Olaf Siejka wrote:
Alex Since you are subscribed to ros-diff ml, you should be aware, that ros development, rated by commit number, has come almost to standstill.
2009/9/13 Alex Ionescu <ionucu@videotron.ca mailto:ionucu@videotron.ca>
So in other words, in a month minus 3 days:
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Alex Ionescu wrote:
- No additional attempts/efforts (expressing a desire/want does not
count as effort) have been made to recompile Mingw32-gcc-4.4 as Dmitry does.
This is simply not true and a misunderstanding of Daniel's point.
Daniel, Samuel and me did _many_ attempts to compile a Windows version of GCC 4.4.1 under MSYS and Cygwin, but none of them succeeded. Of course, such efforts don't result in a visible outcome if they fail.
Now my last resort would be to try cross-compiling a Windows compiler under a Linux host and that's what Daniel's point was all about. I'm trying to find time for that in the next few days. Note that I'm currently in my last year at secondary school, so I have definitely less time than about two years ago. Apart from that, I'm currently also busy with the server administration, regression testing system, German foundation, etc. Don't know about you, but I deem these issues at least as important as GCC 4.4.x.
Best regards,
Colin
Hi,
I have built GCC 4.4.2 for Windows, I will upload it somewhere and post a link to it.
Hi, pleeeease modify this one: http://www.reactos.org/wiki/Compiling_GCC_From_Windows so that we can build it too and understand what you did.
Thx, you rock! :-D
Finally.
I apologize if I sounded rude but as you can see, asskicking works.
Best regards, Alex Ionescu
On Tue, Sep 15, 2009 at 10:18 AM, Daniel Reimer daniel.reimer@stud-mail.uni-wuerzburg.de wrote:
Hi, pleeeease modify this one: http://www.reactos.org/wiki/Compiling_GCC_From_Windows so that we can build it too and understand what you did.
Thx, you rock! :-D
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
rude? you? never! :P
On Tue, Sep 15, 2009 at 9:26 PM, Alex Ionescu ionucu@videotron.ca wrote:
Finally.
I apologize if I sounded rude but as you can see, asskicking works.
Best regards, Alex Ionescu
On Tue, Sep 15, 2009 at 10:18 AM, Daniel Reimer daniel.reimer@stud-mail.uni-wuerzburg.de wrote:
Hi, pleeeease modify this one: http://www.reactos.org/wiki/Compiling_GCC_From_Windows so that we can build it too and understand what you did.
Thx, you rock! :-D
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Heheh. Asskicking is a good way to get stuff done. I post a new GCC 4.4 Log in the IRC Topic telling to fix this crap and as result is: FIXX0rz
Javier Agustìn Fernàndez Arroyo schrieb:
rude? you? never! :P
On Tue, Sep 15, 2009 at 9:26 PM, Alex Ionescu <ionucu@videotron.ca mailto:ionucu@videotron.ca> wrote:
Finally. I apologize if I sounded rude but as you can see, asskicking works. Best regards, Alex Ionescu On Tue, Sep 15, 2009 at 10:18 AM, Daniel Reimer <daniel.reimer@stud-mail.uni-wuerzburg.de <mailto:daniel.reimer@stud-mail.uni-wuerzburg.de>> wrote: > Hi, pleeeease modify this one: > http://www.reactos.org/wiki/Compiling_GCC_From_Windows so that we can > build it too and understand what you did. > > Thx, you rock! :-D > > _______________________________________________ > Ros-dev mailing list > Ros-dev@reactos.org <mailto:Ros-dev@reactos.org> > http://www.reactos.org/mailman/listinfo/ros-dev > _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org <mailto:Ros-dev@reactos.org> http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
GCC 4.4.2, binutils 2.20.51 with delay import feature by Timo, w32api 3.13, mingwrt 3.16, nasm 2.07.
http://rapidshare.de/files/48356479/i386.7z.html Iserv: Groups/Testers/Tools/i386.7z
Will x64 addon be updated as well? It seems the x64 addon for Windows NT version of RosBE is quite old, and there isn't an x64 addon for Unix RosBE either.
On Wed, Sep 16, 2009 at 9:14 AM, Dmitry Gorbachev d.g.gorbachev@gmail.comwrote:
GCC 4.4.2, binutils 2.20.51 with delay import feature by Timo, w32api 3.13, mingwrt 3.16, nasm 2.07.
http://rapidshare.de/files/48356479/i386.7z.html Iserv: Groups/Testers/Tools/i386.7z
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Yes, version 1.0 is old. try the one from reactos.colinfinck.de, its newer, but i will make a new official one too
King InuYasha schrieb:
Will x64 addon be updated as well? It seems the x64 addon for Windows NT version of RosBE is quite old, and there isn't an x64 addon for Unix RosBE either.
On Wed, Sep 16, 2009 at 9:14 AM, Dmitry Gorbachev <d.g.gorbachev@gmail.com mailto:d.g.gorbachev@gmail.com> wrote:
GCC 4.4.2, binutils 2.20.51 with delay import feature by Timo, w32api 3.13, mingwrt 3.16, nasm 2.07. http://rapidshare.de/files/48356479/i386.7z.html Iserv: Groups/Testers/Tools/i386.7z _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org <mailto:Ros-dev@reactos.org> http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
I've ran a build attempt using GCC 4.4.2 (Thanks Dmitry ;) ) and I've attached a log containing only the issues (warnings and errors)
Regards, Amine.
On 16/09/2009 15:14, Dmitry Gorbachev wrote:
GCC 4.4.2, binutils 2.20.51 with delay import feature by Timo, w32api 3.13, mingwrt 3.16, nasm 2.07.
http://rapidshare.de/files/48356479/i386.7z.html Iserv: Groups/Testers/Tools/i386.7z
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Btw, Beta1 of RosBE 1.5 is available here: http://reactos.colinfinck.de
As Amine said, right now we still have some issues in the tree to be fixed, so its not useful for normal users/testers right now.
Amine Khaldi schrieb:
I've ran a build attempt using GCC 4.4.2 (Thanks Dmitry ;) ) and I've attached a log containing only the issues (warnings and errors)
Regards, Amine.
On 16/09/2009 15:14, Dmitry Gorbachev wrote:
GCC 4.4.2, binutils 2.20.51 with delay import feature by Timo, w32api 3.13, mingwrt 3.16, nasm 2.07.
http://rapidshare.de/files/48356479/i386.7z.html Iserv: Groups/Testers/Tools/i386.7z
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Another build (for Pentium3 and later processors, as it was in RosBE-1.4.3; the target is still Pentium.) Previous build was for PentiumPro because of a GCC bug.
Uploaded to http://rapidshare.de/files/48366344/i386-p3.7z.html and to iserv.