From: Emanuele A. <eal...@ho...> - 2001-03-14 19:03:12
|
>I suspect that if one had access to ntdll sources one would see something >like: > >RtlMoveMemory(RtlMoveMemory (VOID* Destination, CONST VOID* Source, >SIZE_T >Length ) >{return memove( Destination, Source, Length)}; > >and similarly for othe Rtl*Memory functions; > >(memmove and friends are in ntdll.dll as well as the C runtime lib) http://mok.lvcm.com/cgi-bin/reactos/ros-cvs/reactos/lib/ntdll/rtl/mem.c?rev=1.9&content-type=text/x-cvsweb-markup _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. |
From: Chris H. <pop...@so...> - 2001-03-14 21:23:42
|
-----Oprindelig meddelelse----- Fra: min...@li... [mailto:min...@li...]På vegne af Emanuele Aliberti Sendt: 14. marts 2001 20:05 Til: min...@li... Emne: RE: [Mingw-users] New missing defines >I suspect that if one had access to ntdll sources one would see something >like: > >RtlMoveMemory(RtlMoveMemory (VOID* Destination, CONST VOID* Source, >SIZE_T >Length ) >{return memove( Destination, Source, Length)}; > >and similarly for othe Rtl*Memory functions; > >(memmove and friends are in ntdll.dll as well as the C runtime lib) Those memory functions ARE simular to the C ones in MSVCRT. But when programming some Windows functions and collecting them in a DLL, I think about the dependencies. And I don't like using memset as the only MSVCRT function, when I can use the functions in the Windows kernel and get rid of the C runtime library. Otherwise I don't care if I use RtlFillMemory or memset. Regards Chris Hansen |
From: <dan...@ya...> - 2001-03-14 23:16:52
|
--- Chris Hansen <pop...@so...> wrote: > -----Oprindelig meddelelse----- > Fra: min...@li... > [mailto:min...@li...]På vegne af Emanuele > Aliberti > Sendt: 14. marts 2001 20:05 > Til: min...@li... > Emne: RE: [Mingw-users] New missing defines > > > >I suspect that if one had access to ntdll sources one would see something > >like: > > > >RtlMoveMemory(RtlMoveMemory (VOID* Destination, CONST VOID* Source, > >SIZE_T > >Length ) > >{return memove( Destination, Source, Length)}; > > > >and similarly for othe Rtl*Memory functions; > > > >(memmove and friends are in ntdll.dll as well as the C runtime lib) > > Those memory functions ARE simular to the C ones in MSVCRT. But when > programming some Windows functions and collecting them in a DLL, I think > about the dependencies. And I don't like using memset as the only MSVCRT > function, when I can use the functions in the Windows kernel and get rid of > the C runtime library. > > Otherwise I don't care if I use RtlFillMemory or memset. > > Regards > Chris Hansen > > Chris, Ah, thanks for that. My point is that the macro version should still be available as well as the function version. Probably, those macros should get shifted to right after the function declarations in winnt.h. Having both, of course, would mean that you have to do this to call the function: (RtlFillMemory)() rather than this: RtlFillMemory() Danny _____________________________________________________________________________ http://store.yahoo.com.au - Yahoo! Store - The fastest, easiest way to open an online store. |
From: Chris H. <pop...@so...> - 2001-03-15 06:58:24
|
-----Oprindelig meddelelse----- Fra: min...@li... [mailto:min...@li...]På vegne af Danny Smith Sendt: 15. marts 2001 00:19 Til: min...@li... Emne: RE: [Mingw-users] New missing defines > Chris, > Ah, thanks for that. > My point is that the macro version should still be available as well as the > function version. Probably, those macros should get shifted to right after the > function declarations in winnt.h. I don't want to be rude but why? By using ZeroMemory, as an example, you must assume that RtlZeroMemory is the function wanted to be called. Otherwise you would use STRING.H and call memset(b,0,s)? > Having both, of course, would mean that you have to do this to call the > function: (RtlFillMemory)() > rather than this: RtlFillMemory() Rtl*Memory is supposed to be called by the *Memory macros. Sorry, but I still don't get it :o/ Kindly Chris Hansen |
From: <dan...@ya...> - 2001-03-15 08:55:08
|
--- Chris Hansen <pop...@so...> wrote: > -----Oprindelig meddelelse----- > Fra: min...@li... > [mailto:min...@li...]På vegne af Danny Smith > Sendt: 15. marts 2001 00:19 > Til: min...@li... > Emne: RE: [Mingw-users] New missing defines > > > > Chris, > > Ah, thanks for that. > > My point is that the macro version should still be available as well as > the > > function version. Probably, those macros should get shifted to right > after the > > function declarations in winnt.h. > > I don't want to be rude but why? I expect the macro version to be faster. In my tests with RtlMoveMemory, calling the macro version (or calling memmove) was about 12% faster than the function version. >By using ZeroMemory, as an example, you > must assume that RtlZeroMemory is the function wanted to be called. > Not necessarily. By using ZeroMemory *I* would want the RtlZeroMemory macro to be called. Because its faster. > Otherwise you would use STRING.H and call memset(b,0,s)? > And that would mean rewriting somebody else's code, which I don't need to do, if the macro is available. Now if I were writing VisualBasic code I would be forced to link against the __stdcall function version. > > Having both, of course, would mean that you have to do this to call the > > function: (RtlFillMemory)() > > rather than this: RtlFillMemory() > > Rtl*Memory is supposed to be called by the *Memory macros. Agreed. but I don't agree that the *Memory macros are "supposed" to refer to (Rtl*Memory) functions. Not unless there's is some advantage to doing so. Danny > > Sorry, but I still don't get it :o/ > > Kindly > Chris Hansen > > > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options at: > http://lists.sourceforge.net/lists/listinfo/mingw-users _____________________________________________________________________________ http://store.yahoo.com.au - Yahoo! Store - The fastest, easiest way to open an online store. |