Re: [ros-dev] [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...

[Aleksey Bragin]

Thanks, of course I've been waiting! :)

WBR,
Aleksey.

On Dec 10, 2010, at 2:24 PM, Ged Murphy wrote:

>   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(a)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=49999&view=auto
>
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev