Ros-dev November 2009

ros-dev@reactos.org

37 participants
22 discussions

by Aleksey Bragin

Hello, the trunk of our SVN server has been locked to prevent even more regression from entering the tree. So far, after more than 3 weeks after I filed the bug report and not including all previous time when people were complaining about rapps which can't download anything at all - either hangs or crashes, I see that now even PCNet network card is being recognized in my VMWare Workstation 6.5. Trunk is writable right now by members of the bugfix team only, that's so far Cameron (because he is the one supposed to fix networking) and me. If someone volunteers to fix any of the existing regressions, please let me know on irc/email, I'll include you into the bugfix team. Thanks for understanding, and patience. My patience is over. WBR, Aleksey Bragin.

15 years

RosBE-Windows' "clean" command

by Colin Finck

Hi everybody, The "clean" command in RosBE has often been criticized for not cleaning what the user expected. While in the past, it had just issued commands to delete the four files/folders "makefile.auto", "obj-i386", "output-i386" and "reactos" in the current directory, it's general behaviour has been changed significantly over time, in particular by these two commits: - 38756 If you set a different object or output directory for the built files through RosBE Options, these directories are always cleaned instead of "obj-i386" or "output-i386" in the current directory. - 39138 If no dedicated object or output directory is set through RosBE Options, we always clean the one set after RosBE has been started or which has been set by "chdefdir". We even do so if this directory is not the current working directory. Especially the latter commit seems to have caused problems for many people as you could easily clean the wrong tree now. Therefore I made some efforts to rework this command a bit and published by current script at http://reactos.colinfinck.de. This script now first checks whether "makefile.auto", "obj-i386", "output-i386" and "reactos" exist in the current directory. If all of them exist, they are cleaned. If not, it checks whether different object and output directories were set using RosBE Options and checks for them instead of "obj-i386" and "output-i386". If they exist together with "makefile.auto" and "reactos" in the current working directory, all of them are cleaned. Of course, this also works for every other architecture we support, i386 was just taken as the most popular example here. I'm posting this here now, because I don't want to upset other people now that the script logic is changed again. If you rather like the current "clean" logic instead of my proposal, please tell me. I leave this discussion opened for several weeks as I currently don't have much time anyway. If there are no negative comments, the new script will be committed afterwards. Best regards, Colin

15 years

Re: [ros-dev] [ros-diffs] [cgutman] 44286: - Initialize SocketError to 0 to prevent a bogus error from GCC

by Colin Finck

cgutman(a)svn.reactos.org wrote: > - ULONG SocketError; > + ULONG SocketError = 0; FYI, I've already reported this bug some days ago at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42145. As it only occurs in GCC >= 4.3 and the necessary code changes for compiling ReactOS with GCC 4.4.x are currently collected in a big separate patch (see http://www.reactos.org/bugzilla/show_bug.cgi?id=4810), no hack from my side has been committed so far. If this hack is going to stay, please mark it as such and add a reference to the GCC bug report. Hopefully, it's properly resolved someday... :-) Best regards, Colin

15 years

Re: [ros-dev] [ros-diffs] [tkreuzer] 44274: Mm64BitPhysicalAddress is a BOOLEAN, not a PBOOLEAN

by Alexander Potashev

Hi, Ok, commenting here... MSDN says that Mm64BitPhysicalAddress is PBOOLEAN: http://msdn.microsoft.com/en-us/library/bb648424.aspx So, there should be another BOOLEAN variable, and Mm64BitPhysicalAddress should point to it. Alexander 2009/11/23 <tkreuzer(a)svn.reactos.org>: > Author: tkreuzer > Date: Mon Nov 23 21:44:21 2009 > New Revision: 44274 > > URL: http://svn.reactos.org/svn/reactos?rev=44274&view=rev > Log: > Mm64BitPhysicalAddress is a BOOLEAN, not a PBOOLEAN > > Modified: > branches/ros-amd64-bringup/reactos/ntoskrnl/mm/mminit.c > > Modified: branches/ros-amd64-bringup/reactos/ntoskrnl/mm/mminit.c > URL: http://svn.reactos.org/svn/reactos/branches/ros-amd64-bringup/reactos/ntosk… > ============================================================================== > --- branches/ros-amd64-bringup/reactos/ntoskrnl/mm/mminit.c [iso-8859-1] (original) > +++ branches/ros-amd64-bringup/reactos/ntoskrnl/mm/mminit.c [iso-8859-1] Mon Nov 23 21:44:21 2009 > @@ -48,7 +48,7 @@ > "LoaderXIPRom " > }; > > -PBOOLEAN Mm64BitPhysicalAddress = FALSE; > +BOOLEAN Mm64BitPhysicalAddress = FALSE; > ULONG MmReadClusterSize; > // > // 0 | 1 is on/off paging, 2 is undocumented > > >

15 years

Regarding moderator status in the Forums.

by Daniel Reimer

Hi, as already said in the #reactos-dev IRC Chat yesterday I, too, think Z98 is right (http://reactos.org/forum/viewtopic.php?f=13&t=7634&start=75#p67090), this is not how a real mod has to behave. But this criticism counts for him, me and all others in the privileged teams IMO! I know that some of my behavior is more childish than anything else you could call useful and professional, but I ask you, what ways to tidy the forums up, do I have, except gallows humor and sarcasm? Lets explain what evilness I did this time again. Every day on my way to university I sit in the train, start Opera Mini on my Mobile and run through the forums to do my job and in recent times more an more posts with harmful and destructive meaning occur. Most are from our well known troll-friend nute, but there are other flaws right now, too. For example the newly registered members, who write one post with SPAM in their signature and hope that noone of the Mods recognizes it, but this is another story. OK, back to the main story. I looked trough his "When will Version 0.3.blablubb finally be done you lame, useless dumbasses of so called Devs"-post, which I already moved to Off Topic because his unintentional negative influence does not belong to the General Forums IMO. Well, I know the very last warning spoken by Z98 against me in the very same Thread and realized that the same behavior he accused from both sides reoccurs after just two days. Flaming and Bashing from both sides again... Well, I lock topics and get bashed, I warn ppl and get bashed, I rename a thread which has nothing to do with any Version 0.4.11 talk and more is meant as a battleaxe against the forum and the project and get bashed too, so I decided to do nothing except a good amount of sarcasm and properly renamed the Thread to "nute's private playground" which it was anyway at that time. Well, I had nothing to loose. All my steps would have resulted in bashing anyway, so I chose the funniest path. Some subjects in the forums play with us and noone cares. They spread crap about us, which could even harm our image and noone cares! And if I dare to try to sentence disciplinary actions, I get kicked from above. Well, why should I behave like a real mod pretending to be one? I have lost all power over the forums, because our own hierarchy fights against me. I have as much power in there like all others users, because most of my steps and actions are being reverted or openly criticised anyway. God its fucking frustrating to have no ways to moderate the forum at all, but being called mod! If we do not finally start to spread some authority in the forums and stop to always see the good person in such harmful subjects without the minimum of aggression needed to be a Mod IMO or giving mods like me ways to do their job without anyone always falling in their back, we can close down the forums immediately anyway. Psychotic trolls like nute and more than enough others need limits, otherwise they dance on our nose as they do right now and a hierarchical system which fights itself is no way to get this done. It did not work in the Weimarer Republik and won't work for us, too. OK this had to be said, now kick me, degrade me, whatever you think is best, but please finally do it once and for all, please. Only the best for Project counts! I don't care what happens to me as long as we get this problem solved. With or without me as mod. Have fun. Daniel "dreimer" Reimer (still for some last seconds) ReactOS Forum Moderator Team Member ReactOS Build Environment for Windows Coordinator

15 years, 1 month

Why the *$#(% are you adding Vista exports?

by Alex Ionescu

Bugs like these would've NEVER happened if you stuck to your TARGET: NT 5.2.3790.1800 SP1: http://www.reactos.org/bugzilla/show_bug.cgi?id=4940 You can't just add Vista APIs and expect shit to work! You should really revert this kind of garbage. Best regards, Alex Ionescu

15 years, 1 month

Re: [ros-dev] [ros-diffs] [fireball] 44225: [rapps] Andrey Yastrebov <menone7@gmail.com> - Fix app uninstallation feature (wrong lparam usage - it's pointer to PINSTALLED_INFO and not an hkey). See issue #4961 for more details.

by Aleksey Bragin

Sorry, I mistyped his name. It's Alexander Yastrebov. On Nov 18, 2009, at 5:37 PM, fireball(a)svn.reactos.org wrote: > Author: fireball > Date: Wed Nov 18 15:37:31 2009 > New Revision: 44225 > > URL: http://svn.reactos.org/svn/reactos?rev=44225&view=rev > Log: > [rapps] > Andrey Yastrebov <menone7(a)gmail.com> > - Fix app uninstallation feature (wrong lparam usage - it's pointer > to PINSTALLED_INFO and not an hkey). > See issue #4961 for more details.

15 years, 1 month

A reimplementation of reactos' cache manager supporting alternate filesystems better (including ext2)

by ayerkes＠speakeasy.net

I'm pleased to announce that I've been able to boot reactos to the shell from an ext2 partition. This is something we've wanted for a long time and many of us have worked on. I've synced up arty-newcc to the current state of my git repository. This work is experimental, not quite complete, and has some important limitations: - It probably won't currently work for a partition larger than 4gig and might even fail for one larger than 2gig. This limitation is lifted by other, unrelated code in my tree that I haven't merged yet. - It probably has a lot more bugs left, especially in block allocation for large files. - Some parts of the new section implementation leak pages. I was planning to, but haven't yet made the new and old cache and cc and section implementations available side by side. The main work of separating the new files involved in the section implementation (now in ntoskrnl/mm/section/*) is done. This will be necessary when I merge it into the main tree, at least for regression testing. Despite the branch being named for me, I invite anyone to work on, modify, or bugfix arty-newcc. This advance has been a long time coming, and I'd like to thank everyone for keeping the faith.

15 years, 1 month

Re: [ros-dev] [ros-diffs] [janderwald] 44136: - Silence (on request of Christoph)

by Aleksey Bragin

It was enabled, kind of, on purpose. When does it happen? During running some regtest? On Nov 13, 2009, at 6:04 PM, janderwald(a)svn.reactos.org wrote: > Author: janderwald > Date: Fri Nov 13 16:04:19 2009 > New Revision: 44136 > > URL: http://svn.reactos.org/svn/reactos?rev=44136&view=rev > Log: > - Silence (on request of Christoph) > > Modified: > trunk/reactos/ntoskrnl/io/iomgr/file.c > > Modified: trunk/reactos/ntoskrnl/io/iomgr/file.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/ > iomgr/file.c?rev=44136&r1=44135&r2=44136&view=diff > ====================================================================== > ======== > --- trunk/reactos/ntoskrnl/io/iomgr/file.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/io/iomgr/file.c [iso-8859-1] Fri Nov 13 > 16:04:19 2009 > @@ -470,7 +470,7 @@ > ((OpenPacket->RelatedFileObject) || (RemainingName- > >Length)) && > (!VolumeOpen)) > { > - DPRINT1("Fix Secure FSD support!!!\n"); > + DPRINT("Fix Secure FSD support!!!\n"); > } > > /* Allocate the IRP */ > >

15 years, 1 month

Re: [ros-dev] Microsoft PDC

by Ged Murphy

This starts on Monday. So nobody's going?? Shocker .... I'll have to drink on my own then. Ged. From: Ged Murphy [mailto:gedmurphy@gmail.com] Sent: 27 October 2009 15:41 To: 'ReactOS Development List'; 'ReactOS General List' Subject: Microsoft PDC I'll be attending this year's Microsoft PDC in Los Angeles and I should be there between 16th November and 20th November. If anyone else is going and wants to meet up for a chat at the conference or a beer in the evening drop me a mail. Cheers, Ged.

15 years, 1 month

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev November 2009