pschweitzer(a)svn.reactos.org wrote:
>
> ASSERT(Name->Length);
> ASSERT(Expression->Length);
> ASSERT(!FsRtlDoesDbcsContainWildCards(Name));
It'd be preferable to wrap that last ASSERT so it isn't compiled into release builds.
Adding functions into asserts adds overhead on release builds as they're called for no reason.
Ged.
Hello all,
I'm currently developing two project tools which are going to be used by
the German ReactOS foundation (custom IRC Server and plugin for Jameica
- http://www.willuhn.de/products/jameica/).
They shall be committed into a public ReactOS SVN repository.
Since I believe that these tools are hardly useful for the average
ReactOS developer, I don't want to commit them to our current
/trunk/tools directory in the "reactos" repository. Among other
disadvantages, every commit to them would trigger a useless BuildBot
build, source checkouts would include unnecessary stuff, etc.
As this is generally the case with most of the stuff in /trunk/tools,
I'd like to move everything below this directory and the /irc directory
into a new repository called "project-tools".
We have already done a similar step in the past for the former "web"
directory.
Additionally, the "press-media" directory would be a similar candidate
for an own "press-media" repository. After these steps, our "reactos"
repository would finally contain only OS development related stuff.
For comparison, Wine already keeps its main repository free from
unrelated stuff and has several similar repositories (see
http://source.winehq.org/git/).
If there are no objections to my idea within the next two weeks, I will
proceed and set up "project-tools" and "press-media" repositories
(preserving as much SVN history as possible).
Cheers,
Colin
A worthy commit for r50000.
You've been waiting for this revision, haven't you .... haha.
Ged
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of fireball(a)svn.reactos.org
Sent: 10 December 2010 09:33
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [fireball] 50000: [HEAP] - Time has come to get rid of a slightly modified implementation of WINE's heap, which is a hack based on Windows 95's heap implementation, itself a hack of DOS memory mana...
Author: fireball
Date: Fri Dec 10 09:33:20 2010
New Revision: 50000
URL: http://svn.reactos.org/svn/reactos?rev=50000&view=rev
Log:
[HEAP]
- Time has come to get rid of a slightly modified implementation of WINE's heap, which is a hack based on Windows 95's heap implementation, itself a hack of DOS memory management. It supported 3 out of the 18 possible NT Heap Flags, did not support custom allocation/deallocation routines, and was about 50-80x slower with fragmentation rates up to 500x higher when compared to NT's LFH (WINE is lucky because the advanced NT Heap features are used in kernel-mode usually, not in user-mode, and they are crossing their fingers for this being the same). Several high-end SQL/Database applications would significantly benefit from custom heap features provided by NT. Not to say about removing crappy support for a custom Commit routine and crappy support for User-defined flags and the User-defined value.
- So, the glorious moment for a new heap manager, which is (to remind you) a totally new heap manager, resembling real NT heap manager, based on data structures similar to Windows 2003 and Vista+'s heap structures, supporting advanced heap flags (e.g. useful for debugging), having substantially lower fragmentation rates (and thus speed and reliability), having native support for user-defined flags and user-defined values, also native support for a custom commit routine, which is very important for trunk's win32 subsystem. It also reserves, commits, decommits and frees memory on the fly, unlike existing heap manager which prefers to reserve and commit as much as possible, and doesn't decommit when it's no longer necessary. Not to say about support for per process heaps, with a proper lock, and a further support for a special so-called debug heap allocator (to be implemented in heapdbg.c) which will be useful for finding heap corruptions.
Yeah, I'm not a fun person :D
Added:
trunk/reactos/lib/rtl/heap.c
- copied unchanged from r49999, trunk/reactos/lib/rtl/heap_rewrite.c
Removed:
trunk/reactos/lib/rtl/heap_rewrite.c
[This mail would be too long, it was shortened to contain the URLs only.]
Removed: trunk/reactos/lib/rtl/heap_rewrite.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/rtl/heap_rewrite.c?rev…
greatlrd(a)svn.reactos.org wrote:
> Sent: 03 December 2010 09:20
> To: ros-diffs(a)reactos.org
> Subject: [ros-diffs] [greatlrd] 49912: all code are in
> ReactOS trunk for ReactX delete the old branch and prepare
> create new one Most of the code will be focus on dxg.sys and
> few part of gdi32.dll in the new branch of ...
Hells bells, it's gratelood!
Good to see you back mate.
Ged.
