include/msvcrt/crtdbg.h

[Saulius Krasuckas]

I am trying to extend functionality of the MSVCRTD_operator_new_dbg(), so 
did #include "msvcrt/crtdbg.h" in the file dlls/msvcrtd/debug.c .  Is that 
OK?

I have found some differences in used parameter types of some functions, 
like:

int       <->  long int.
void (*)  <->  void (__cdecl *_CRT_DUMP_CLIENT) (void *, size_t)

Then I see all the declared function are defined to be non-operational:

| #endif /* _DEBUG */
| 
| #define _CrtCheckMemory()               ((int)1)
| #define _CrtDbgReport(...)              ((int)0)
| #define _CrtDoForAllClientObjects(f,c)  ((void)0)
| #define _CrtDumpMemoryLeaks()           ((int)0)

Yet then I see lots of declared functions are prefixed with __cdecl and 
_CRTIMP prefixes.

| #ifndef _CRTIMP
| #ifdef  _DLL
| #define _CRTIMP __declspec(dllimport)
| #else   /* ndef _DLL */
| #define _CRTIMP
| #endif  /* _DLL */
| #endif  /* _CRTIMP */

Do we need to sync crtdbg.h with native one?  What parts then, all 
mentioned?  (Maybe I should direct this q exceptionally to Alexandre)

[Saulius Krasuckas]

It seems I was too in hurry.  Some comments follows.

* On Tue, 19 Jul 2005, Saulius Krasuckas wrote:
> int       <->  long int.
> void (*)  <->  void (__cdecl *_CRT_DUMP_CLIENT) (void *, size_t)

I mean differences between native version and a Wine's one.
> Then I see all the declared function are defined to be non-operational:
>
> | #endif /* _DEBUG */
> | 
> | #define _CrtCheckMemory()               ((int)1)
> | #define _CrtDbgReport(...)              ((int)0)
> | #define _CrtDoForAllClientObjects(f,c)  ((void)0)
> | #define _CrtDumpMemoryLeaks()           ((int)0)

These are defined in the Wine tree.  They are out of the #ifndef _DEBUG - 
#else - #endif statement, so they make inclusion of a header file 
impossible.

Definitions should be transfered into two parts:  operational (_DEBUG 
defined) and non operational (no _DEBUG defined).  Right?
> Yet then I see lots of declared functions are prefixed with __cdecl and 
> _CRTIMP prefixes.

...
> | #define _CRTIMP __declspec(dllimport)

And that comes from native header file.  Should we do the same in the Wine 
header?

Maybe someone is working on this already?

[Boaz Harrosh]

Saulius Krasuckas wrote:
> It seems I was too in hurry.  Some comments follows.
> - On Tue, 19 Jul 2005, Saulius Krasuckas wrote:
> > int       <->  long int.
> > void (*)  <->  void (__cdecl *_CRT_DUMP_CLIENT) (void *, size_t)
>
> I mean differences between native version and a Wine's one.
> > Then I see all the declared function are defined to be non-operational:
> >
> > | #endif /* _DEBUG */
> > | 
> > | #define _CrtCheckMemory()               ((int)1)
> > | #define _CrtDbgReport(...)              ((int)0)
> > | #define _CrtDoForAllClientObjects(f,c)  ((void)0)
> > | #define _CrtDumpMemoryLeaks()           ((int)0)
>
> These are defined in the Wine tree.  They are out of the #ifndef _DEBUG - 
> #else - #endif statement, so they make inclusion of a header file 
> impossible.
>
> Definitions should be transfered into two parts:  operational (_DEBUG 
> defined) and non operational (no _DEBUG defined).  Right?
> > Yet then I see lots of declared functions are prefixed with __cdecl and 
> > _CRTIMP prefixes.
>
> ...
> > | #define _CRTIMP __declspec(dllimport)
>
> And that comes from native header file.  Should we do the same in the Wine 
> header?
>
> Maybe someone is working on this already?

Not many apps (source code) use these functions. Mainly MFC and 
ATL/WTL and derived applications.
If it is the later case (MFC/ATL) than one can just get native header 
together with where he gut MFC/ATL from, and just make sure that it is 
in a folder with higher precedence than wine's. It will compile.
  If your code can make do without MFC/ATL and only thing missing is CRT 
memory debugging tools, than you can go head and implement them. (Or use 
native msvcrtd.dll which is of the same license as crtdebug.h. Debug 
version is of a different license than release)
  What I've seen done by people is Leave these off, as wine is doing 
now, but use other (gcc type tools) compiled into wine to debug memory 
leaks. Was that Valgrind (http://valgrind.org/) or something? See list 
archives for instructions how to use it.

Free Life
Boaz

[Saulius Krasuckas]

* On Tue, 19 Jul 2005, Boaz Harrosh wrote:
> - Saulius Krasuckas wrote:
> > > Yet then I see lots of declared functions are prefixed with __cdecl 
> > > and _CRTIMP prefixes.
> >
> > ...
> > > | #define _CRTIMP __declspec(dllimport)
> >
> > And that comes from native header file.  Should we do the same in the 
> > Wine header?
>
> Not many apps (source code) use these functions. Mainly MFC and ATL/WTL 
> and derived applications. If it is the later case (MFC/ATL)

I have none of these targets in my mind.  My goal is to fix failure in 
dlls/msvcrtd/tests/debug.c .  That requires to extend code in 
dlls/msvcrtd/debug.c , to fix the bug.  This by itself requires to change 
include/msvcrt/crtdebug.h , if I don't want to hide bug that is relvealed 
by running tests on native platform.  Hence arose my question.
> If your code can make do without MFC/ATL and only thing missing is CRT 
> memory debugging tools, than you can go head and implement them.

So as I need no memory debugging, lets suppose minimal changes in this 
header file will be sufficient.
> (Or use native msvcrtd.dll which is of the same license as crtdebug.h. 
> Debug version is of a different license than release)

Interesting to know, haven't noticed that earlier.  Thanks.