Hi,
I wrote a test/debug util (COM monitor) for logging ReactOS dbg/bt messages,
and wonder if it will be better to submit it as a bugzilla patch, or
start a sourceforge
or codeproject page for it ?
Most of you probably have other utils, but ComMon is quite handy with it's
auto enumerated COM ports, extended selection mode list, copy selected
to clip,
save/clear list etc..
I have it in my reactos/tools tree and it currently builds with the
RosBE toolchain
(standalone w C::B, currently not by rbuild).
Would you be interested at all ?
Best Regards
// Love
Has anyone noticed notepad? While user32_winetest win > data, then
notepad data! The balance program go into high speed swapping!!
Bunches of theses:
(ntoskrnl/mm/section.c:2110) Pagint out 692d.
(ntoskrnl/cc/view.c:403) Evicted 256 cache pages
(ntoskrnl/mm/balance.c:167) Trimming consumer 0: Freed 256 pages with
a target of 256 pages
looping over and over~
When all this is going on I managed to get taskman up, notepad using
74,5?? K, wow!
Just wondering,
James
Piece of good news too..
FileZilla FTP Client 3.5.2 (latest) installs and runs with flying colors
by the looks of it.
Would suggest it's added to the Rapps list :D
(http://filezilla-project.org/download.php)
Best Regards
// Love
Filed as #6753.
MinGW / Msys-1.0: Sh.exe deadlock seems to be result of unhandled
exception.
(I.e. got nothing to do with batch processing).
Best Regards
// Love
It may be old news, but the fact that RtlSetUnhandledExceptionFilter is
unimplemented
makes it impossible for many apps to handle their heap allocation
errors, aggravating
the work for the memory manager, and resulting in crashes, leaks, and
heap corruption.
Whoever knows our SEH well enough could do a major improvement by fixing
this.
I came across this while testing MinGW 20100909 on r 54606,
where sh.exe deadlocks after causing leaks in base/shell/cmd/batch.c
[213,116,332].
(I was aiming for a fully bootstrapped system by letting ROS build ROS.)
I'll try to establish a trace on the batch processing bug, and file it.
Best Regards
// Love
I've come across a whopper size bug, likely somewhere in USER or GDI (in
r54606).
If you switch app while you have a modal dialog open, and the new window
covers that dialog,
then when you come back that dialog is invisible, but it's window proc
still active, meaning
you have no way to back out of it, and you have to kill the app with
taskman (if you can).
I would nominate this a real blocker, it's just too embarrassing to release.
I'll try to figure a repeatability and file a bug, and I'd recommend
that USER and GDI
devs heed Alekseys request for feature freeze and roll up their sleeves
on this one.
Best Regards
// Love
Hello testers,
your help is greatly needed.
Trunk needs to be tested using this template as a guideline
http://www.reactos.org/wiki/Tests_for_0.3.14
Imagine that trunk is a 0.3.14 RC (I don't want to branch because I
already called for a feature freeze, so essentially trunk is in "release
mode" right now, and branching would just require merging all revisions
from trunk to the branch).
Fill in the revision number in the "comments" section of that page when
you test.
Also, please be prepared that this might be a double work because after
testing more changes (fixes) would come in and eventually require
retesting, but it is vital to get clear non-biased understanding on how
well trunk performs right now.
Thank you,
looking forward to see results,
Aleksey Bragin.
Quick typo, your param checks in LdrpCheckForKnownDll come after your initialization
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of fireball(a)svn.reactos.org
Sent: 07 December 2011 17:51
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [fireball] 54606: [NTDLL/LDR] - Improve LdrpCheckForKnownDll by adding parameters validation, return status value, better failure paths handling.
Author: fireball
Date: Wed Dec 7 17:51:18 2011
New Revision: 54606
URL: http://svn.reactos.org/svn/reactos?rev=54606&view=rev
Log:
[NTDLL/LDR]
- Improve LdrpCheckForKnownDll by adding parameters validation, return status value, better failure paths handling.
Modified:
trunk/reactos/dll/ntdll/include/ntdllp.h
trunk/reactos/dll/ntdll/ldr/ldrutils.c