Hi,
--- Alex Ionescu <ionucu(a)videotron.ca> wrote:
> Nope, with Dbg Filter States we have the ability to create an unlimited
> number of "channels"
Is there a documented list somewhere of the channel names/numbers Microsoft uses for each dll? It
would be nice to have Wine and ReactOS match the Windows implementation.
Thanks
Steven
Discover Yahoo!
Use Yahoo! to plan a weekend, have fun online and more. Check it out!
http://discover.yahoo.com/
--- Hartmut Birr <hartmut.birr(a)gmx.de> wrote:
> Please split the voting for kernel mode and user mode components.
>
> KERNEL MODE: NO
Is there a problem with declairing a debugchannel for each subsystem in Ntoskrnl and using it? One
of the goals of using the Wine system is to have the ability to toggle debug messages at runtime.
Thanks
Steven
__________________________________
Yahoo! Mail Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
http://mobile.yahoo.com/learn/mail
I would like to see a 0.2.7 release soon. 0.3.0 is getting closer
every day, but it's not there yet IMHO. On the other hand, we have
had lots of big patches from Mr. Ionescu (and others), major changes,
go in and appear to be stable since we have released 0.2.6. I would
like to see us have another release in this lull, instead of having a
release right after committing a pile of patches *right before* the
release like we did with 0.2.6.
I know it's been less than a month since 0.2.6, but my the time we
branch and do a couple RC's, it will have been over a month.
I just have this feeling that we miss some regressions from release to
release, since alot of us just use HEAD on a regular basis?
Just my $0.2US
WD
--
"<tinus_> and also win32k should be fixed up a bit"
ion(a)svn.reactos.com wrote:
>Change optimization settings for retail builds. Change to -Os for smaller executables which are not slower, and enable more advanced optimizations. funitatatime is already included by default in GCC 4.0. Strip debug info from retail builds, since we don't parse the symbols anyways. I hope these options don't break anything, they don't for me; Debugging is unaffected.
>
>
The direct result of this is that, for non-debug builds (which don't
support reading data from symbols anyways, not even during bugcheck),
the following data are now true:
1) ntoskrnl is 612kb on my system, down from 1.5MB
2) win32k is 316kb on my system, down from 800kb
3) taskmgr shows 6% idle cpu time, down from 9%
4) memory usage shows 32MB, down from 40MB+
5) total ISO size is now 12.5MB, down from 14.2MB.
Booting up the system to be much faster and everything is more
responsive, probably due to the smaller size and new optimizations.
Nothing has changed for DBG builds.
Best regards,
Alex Ionescu
hbirr(a)svn.reactos.com wrote:
>- Set the IOSB on error for async irp's with a sync FO (fix bug #609).
>
>
>
Clearly, the problem is that someone is reading the Iosb instead of
reading the FileObject->FinalStatus.
Do you know who is doing that? Fixing the caller would fix the bug,
instead of adding the hack into the IRP Code.
Thanks for the commit,
Best regards,
Alex Ionescu
> From: weiden(a)svn.reactos.com
>
> more fixes for GCC4
>
> Updated files:
> trunk/reactos/tools/wrc/lex.yy.c
Hmm, this is going to be a problem, lex.yy.c is a generated file.
Gé van Geldorp.
You will likely need to remove the w32api directory before you "svn up" next time.
Casper
> -----Original Message-----
> From: ros-svn-bounces(a)reactos.com [mailto:ros-svn-bounces@reactos.com] On Behalf Of
> chorns(a)svn.reactos.com
> Sent: 8. maj 2005 19:43
> To: ros-svn(a)reactos.com
> Subject: [ros-svn] [chorns] 15140: Delete old w32api
>
> Delete old w32api
>
>
> Deleted files:
> trunk/reactos/w32api/
You are really abusing the version control system here.
By not using a vendor import for the external project w32api, you make it much harder to keep local changes separate from the
non-local changes to w32api and thus complicating the synchronization of the two. This is what Gé is currently doing with the shared
wine code and eventually all external code should be imported this way to minimize maintenance.
By re-importing the data from trunk instead of merging it from trunk, you effectively screw up the versioning. When the time comes
to merge your changes to trunk, you cannot since there is no common history. The only way to get it to trunk is to use "svn delete"
and "svn copy" and thus you loose any changes made to include/ and w32api/ on trunk since you created the branch.
I'd suggest you read Gé's introduction at http://reactos.com/wiki/index.php/Using_code_from_other_projects and
http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-7-sect-4 and do it this way instead.
Casper
> -----Original Message-----
> From: ros-svn-bounces(a)reactos.com [mailto:ros-svn-bounces@reactos.com] On Behalf Of
> ion(a)svn.reactos.com
> Sent: 8. maj 2005 03:31
> To: ros-svn(a)reactos.com
> Subject: [ros-svn] [ion] 15097: Wipe out current includes to start fresh.
>
> Wipe out current includes to start fresh.
>
>
> Deleted files:
> branches/new_headers/reactos/include/
> branches/new_headers/reactos/w32api/
>
> _______________________________________________
> Ros-svn mailing list
> Ros-svn(a)reactos.com
> http://reactos.com:8080/mailman/listinfo/ros-svn
I just loaded reactos with svn 15089 , built during the night , and
networking is completely broken.
I cannot ping my dsl router ( request timeout )
Regards
Gerard