Re: [ros-dev] [ros-diffs] [gedmurphy] 67563: [DDK] Fix the FS filter callback definitions

[Ged Murphy]

Well this is a weird one, the DDK says these callbacks are cdecl (missing NTAPI) and anyone building against the DDK will obviously declare their callbacks to match this convention.  However internally, windows uses stdcall for these callbacks.

I can't find much by way of problems people have encountered with this, so why aren't people seeing problems with the way the stack is cleaned up? Anyone have any ideas before I blindly revert this change?

Ged.

-----Original Message-----
From: Ros-diffs [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: 05 May 2015 19:54
To: [e-mail]
Subject: [ros-diffs] [gedmurphy] 67563: [DDK] Fix the FS filter callback definitions

Author: gedmurphy
Date: Tue May  5 18:54:28 2015
New Revision: 67563

URL: http://svn.reactos.org/svn/reactos?rev=67563&view=rev
Log:
[DDK]
Fix the FS filter callback definitions

Modified:
    trunk/reactos/include/ddk/ntifs.h

Modified: trunk/reactos/include/ddk/ntifs.h
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/ddk/ntifs.h?rev=675...
==============================================================================
--- trunk/reactos/include/ddk/ntifs.h	[iso-8859-1] (original)
+++ trunk/reactos/include/ddk/ntifs.h	[iso-8859-1] Tue May  5 18:54:28 2015
@@ -4890,12 +4890,12 @@
 } FS_FILTER_CALLBACK_DATA, *PFS_FILTER_CALLBACK_DATA;

typedef NTSTATUS
-(NTAPI *PFS_FILTER_CALLBACK) (
+(*PFS_FILTER_CALLBACK) (
   _In_ PFS_FILTER_CALLBACK_DATA Data,
   _Out_ PVOID *CompletionContext);

typedef VOID
-(NTAPI *PFS_FILTER_COMPLETION_CALLBACK) (
+(*PFS_FILTER_COMPLETION_CALLBACK) (
   _In_ PFS_FILTER_CALLBACK_DATA Data,
   _In_ NTSTATUS OperationStatus,
   _In_ PVOID CompletionContext);

[Timo Kreuzer]

MS DDK often misses NTAPI, since the compiler uses it by default.
So unless there is a __cdecl in the DDK definition, your change is most 
likely wrong.

PS: I guess it's time to finally autogenerate headers at build time, so 
that nobody even gets tempted to hack ntifs/ntddk/wdm/winnt directly 
instead of adding stuff to XDK... :)

Timo

Am 05.05.2015 um 21:41 schrieb Ged Murphy:
> Well this is a weird one, the DDK says these callbacks are cdecl (missing NTAPI) and anyone building against the DDK will obviously declare their callbacks to match this convention.  However internally, windows uses stdcall for these callbacks.
>
> I can't find much by way of problems people have encountered with this, so why aren't people seeing problems with the way the stack is cleaned up? Anyone have any ideas before I blindly revert this change?
>
> Ged.
>
> -----Original Message-----
> From: Ros-diffs [mailto:[e-mail]] On Behalf Of [e-mail]
> Sent: 05 May 2015 19:54
> To: [e-mail]
> Subject: [ros-diffs] [gedmurphy] 67563: [DDK] Fix the FS filter callback definitions
>
> Author: gedmurphy
> Date: Tue May  5 18:54:28 2015
> New Revision: 67563
>
> URL: http://svn.reactos.org/svn/reactos?rev=67563&view=rev
> Log:
> [DDK]
> Fix the FS filter callback definitions
>
> Modified:
>      trunk/reactos/include/ddk/ntifs.h
>
> Modified: trunk/reactos/include/ddk/ntifs.h
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/ddk/ntifs.h?rev=675...
> ==============================================================================
> --- trunk/reactos/include/ddk/ntifs.h	[iso-8859-1] (original)
> +++ trunk/reactos/include/ddk/ntifs.h	[iso-8859-1] Tue May  5 18:54:28 2015
> @@ -4890,12 +4890,12 @@
>   } FS_FILTER_CALLBACK_DATA, *PFS_FILTER_CALLBACK_DATA;
>
> typedef NTSTATUS
> -(NTAPI *PFS_FILTER_CALLBACK) (
> +(*PFS_FILTER_CALLBACK) (
>     _In_ PFS_FILTER_CALLBACK_DATA Data,
>     _Out_ PVOID *CompletionContext);
>
> typedef VOID
> -(NTAPI *PFS_FILTER_COMPLETION_CALLBACK) (
> +(*PFS_FILTER_COMPLETION_CALLBACK) (
>     _In_ PFS_FILTER_CALLBACK_DATA Data,
>     _In_ NTSTATUS OperationStatus,
>     _In_ PVOID CompletionContext);
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Ged Murphy]

Yeah I get that, and I realise the change is wrong. (I blindly followed the
headers). I just wanna understand it before I revert.

What I don't get is that if I were to write code which uses this API, I
would write my callbacks without NTAPI  as per the headers. I'm guessing
most other devs would too. So how are people building with cdecl and being
called by Windows with stdcall  without stack issues?

In fact, explicitly going against the DDK and adding NTAPI to your callbacks
would generate a compiler warning.

Ged.

-----Original Message-----
From: Ros-dev [mailto:[e-mail]] On Behalf Of Timo Kreuzer
Sent: 05 May 2015 21:25
To: ReactOS Development List
Subject: Re: [ros-dev] [ros-diffs] [gedmurphy] 67563: [DDK] Fix the FS
filter callback definitions

MS DDK often misses NTAPI, since the compiler uses it by default.
So unless there is a __cdecl in the DDK definition, your change is most
likely wrong.

PS: I guess it's time to finally autogenerate headers at build time, so that
nobody even gets tempted to hack ntifs/ntddk/wdm/winnt directly instead of
adding stuff to XDK... :)

Timo

Am 05.05.2015 um 21:41 schrieb Ged Murphy:
> Well this is a weird one, the DDK says these callbacks are cdecl (missing

NTAPI) and anyone building against the DDK will obviously declare their
callbacks to match this convention.  However internally, windows uses
stdcall for these callbacks.
> I can't find much by way of problems people have encountered with this, so

why aren't people seeing problems with the way the stack is cleaned up?
Anyone have any ideas before I blindly revert this change?
> Ged.
>
> -----Original Message-----
> From: Ros-diffs [mailto:[e-mail]] On Behalf Of 
> [e-mail]
> Sent: 05 May 2015 19:54
> To: [e-mail]
> Subject: [ros-diffs] [gedmurphy] 67563: [DDK] Fix the FS filter 
> callback definitions
>
> Author: gedmurphy
> Date: Tue May  5 18:54:28 2015
> New Revision: 67563
>
> URL: http://svn.reactos.org/svn/reactos?rev=67563&view=rev
> Log:
> [DDK]
> Fix the FS filter callback definitions
>
> Modified:
>      trunk/reactos/include/ddk/ntifs.h
>
> Modified: trunk/reactos/include/ddk/ntifs.h
> URL: 
> http://svn.reactos.org/svn/reactos/trunk/reactos/include/ddk/ntifs.h?r
> ev=67563&r1=67562&r2=67563&view=diff

============================================================================
==
> --- trunk/reactos/include/ddk/ntifs.h	[iso-8859-1] (original)
> +++ trunk/reactos/include/ddk/ntifs.h	[iso-8859-1] Tue May  5 18:54:28

2015
> @@ -4890,12 +4890,12 @@
>   } FS_FILTER_CALLBACK_DATA, *PFS_FILTER_CALLBACK_DATA;
>
> typedef NTSTATUS
> -(NTAPI *PFS_FILTER_CALLBACK) (
> +(*PFS_FILTER_CALLBACK) (
>     _In_ PFS_FILTER_CALLBACK_DATA Data,
>     _Out_ PVOID *CompletionContext);
>
> typedef VOID
> -(NTAPI *PFS_FILTER_COMPLETION_CALLBACK) (
> +(*PFS_FILTER_COMPLETION_CALLBACK) (
>     _In_ PFS_FILTER_CALLBACK_DATA Data,
>     _In_ NTSTATUS OperationStatus,
>     _In_ PVOID CompletionContext);
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Ged Murphy]

Wait, I misread your previous post. The compiler uses cdecl by default, so
unless you specify NTAPI then you get cdecl

-----Original Message-----
From: Ged Murphy [mailto:[e-mail]] 
Sent: 05 May 2015 21:35
To: 'ReactOS Development List'
Subject: RE: [ros-dev] [ros-diffs] [gedmurphy] 67563: [DDK] Fix the FS
filter callback definitions

Yeah I get that, and I realise the change is wrong. (I blindly followed the
headers). I just wanna understand it before I revert.

What I don't get is that if I were to write code which uses this API, I
would write my callbacks without NTAPI  as per the headers. I'm guessing
most other devs would too. So how are people building with cdecl and being
called by Windows with stdcall  without stack issues?

In fact, explicitly going against the DDK and adding NTAPI to your callbacks
would generate a compiler warning.

Ged.

-----Original Message-----
From: Ros-dev [mailto:[e-mail]] On Behalf Of Timo Kreuzer
Sent: 05 May 2015 21:25
To: ReactOS Development List
Subject: Re: [ros-dev] [ros-diffs] [gedmurphy] 67563: [DDK] Fix the FS
filter callback definitions

MS DDK often misses NTAPI, since the compiler uses it by default.
So unless there is a __cdecl in the DDK definition, your change is most
likely wrong.

PS: I guess it's time to finally autogenerate headers at build time, so that
nobody even gets tempted to hack ntifs/ntddk/wdm/winnt directly instead of
adding stuff to XDK... :)

Timo

Am 05.05.2015 um 21:41 schrieb Ged Murphy:
> Well this is a weird one, the DDK says these callbacks are cdecl 
> (missing

NTAPI) and anyone building against the DDK will obviously declare their
callbacks to match this convention.  However internally, windows uses
stdcall for these callbacks.
> I can't find much by way of problems people have encountered with 
> this, so

why aren't people seeing problems with the way the stack is cleaned up?
Anyone have any ideas before I blindly revert this change?
> Ged.
>
> -----Original Message-----
> From: Ros-diffs [mailto:[e-mail]] On Behalf Of 
> [e-mail]
> Sent: 05 May 2015 19:54
> To: [e-mail]
> Subject: [ros-diffs] [gedmurphy] 67563: [DDK] Fix the FS filter 
> callback definitions
>
> Author: gedmurphy
> Date: Tue May  5 18:54:28 2015
> New Revision: 67563
>
> URL: http://svn.reactos.org/svn/reactos?rev=67563&view=rev
> Log:
> [DDK]
> Fix the FS filter callback definitions
>
> Modified:
>      trunk/reactos/include/ddk/ntifs.h
>
> Modified: trunk/reactos/include/ddk/ntifs.h
> URL: 
> http://svn.reactos.org/svn/reactos/trunk/reactos/include/ddk/ntifs.h?r
> ev=67563&r1=67562&r2=67563&view=diff

============================================================================
==
> --- trunk/reactos/include/ddk/ntifs.h	[iso-8859-1] (original)
> +++ trunk/reactos/include/ddk/ntifs.h	[iso-8859-1] Tue May  5 18:54:28

2015
> @@ -4890,12 +4890,12 @@
>   } FS_FILTER_CALLBACK_DATA, *PFS_FILTER_CALLBACK_DATA;
>
> typedef NTSTATUS
> -(NTAPI *PFS_FILTER_CALLBACK) (
> +(*PFS_FILTER_CALLBACK) (
>     _In_ PFS_FILTER_CALLBACK_DATA Data,
>     _Out_ PVOID *CompletionContext);
>
> typedef VOID
> -(NTAPI *PFS_FILTER_COMPLETION_CALLBACK) (
> +(*PFS_FILTER_COMPLETION_CALLBACK) (
>     _In_ PFS_FILTER_CALLBACK_DATA Data,
>     _In_ NTSTATUS OperationStatus,
>     _In_ PVOID CompletionContext);
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Timo Kreuzer]

Am 05.05.2015 um 22:35 schrieb Ged Murphy:
> I don't get is that if I were to write code which uses this API, I
> would write my callbacks without NTAPI  as per the headers. I'm guessing
> most other devs would too. So how are people building with cdecl and being
> called by Windows with stdcall  without stack issues?

As I said: the compiler (you are supposed to use Visual Studio with a 
driver project and nothing else, and that will have the option "Calling 
Convention" set to "__stdcall (/Gz)") will use stdcall by default. So 
unless you see __cdecl, the function or function pointer is stdcall. 
Have  a look at WDK sample sources. Almost completely lacking NTAPI.
If you mess with VS settings or use a different compiler ... well, you 
are screwed.

Timo

[Ged Murphy]

Ahh interesting.
So why don't we force /Gz  in our build env?

-----Original Message-----
From: Ros-dev [mailto:[e-mail]] On Behalf Of Timo Kreuzer
Sent: 05 May 2015 22:01
To: ReactOS Development List
Subject: Re: [ros-dev] [ros-diffs] [gedmurphy] 67563: [DDK] Fix the FS
filter callback definitions

Am 05.05.2015 um 22:35 schrieb Ged Murphy:
> I don't get is that if I were to write code which uses this API, I 
> would write my callbacks without NTAPI  as per the headers. I'm 
> guessing most other devs would too. So how are people building with 
> cdecl and being called by Windows with stdcall  without stack issues?

As I said: the compiler (you are supposed to use Visual Studio with a driver
project and nothing else, and that will have the option "Calling Convention"
set to "__stdcall (/Gz)") will use stdcall by default. So unless you see
__cdecl, the function or function pointer is stdcall. 
Have  a look at WDK sample sources. Almost completely lacking NTAPI.
If you mess with VS settings or use a different compiler ... well, you are
screwed.

Timo

[Timo Kreuzer]

GCC doesn't support that.

Am 05.05.2015 um 23:11 schrieb Ged Murphy:
> Ahh interesting.
> So why don't we force /Gz  in our build env?
>
> -----Original Message-----
> From: Ros-dev [mailto:[e-mail]] On Behalf Of Timo Kreuzer
> Sent: 05 May 2015 22:01
> To: ReactOS Development List
> Subject: Re: [ros-dev] [ros-diffs] [gedmurphy] 67563: [DDK] Fix the FS
> filter callback definitions
>
> Am 05.05.2015 um 22:35 schrieb Ged Murphy:
> > I don't get is that if I were to write code which uses this API, I
> > would write my callbacks without NTAPI  as per the headers. I'm
> > guessing most other devs would too. So how are people building with
> > cdecl and being called by Windows with stdcall  without stack issues?
>
> As I said: the compiler (you are supposed to use Visual Studio with a driver
> project and nothing else, and that will have the option "Calling Convention"
> set to "__stdcall (/Gz)") will use stdcall by default. So unless you see
> __cdecl, the function or function pointer is stdcall.
> Have  a look at WDK sample sources. Almost completely lacking NTAPI.
> If you mess with VS settings or use a different compiler ... well, you are
> screwed.
>
> Timo
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Hermès BÉLUSCA - MAÏTO]

And also, for correctness/exactness/documentation purposes/any other
reason... we should keep explicit the calling conventions, so that people
who have other compilers which cannot enforce on a module basis STDCALL, or
people who want to play with msvc by changing the default calling
convention, do not become screwed.
The easy way "solution" à la MS is NOT *the* solution (it looks more like a
hack as in: "heck we don't want to modify all of our headers to add the
needed STDCALL/NTAPI/WINAPI stuff so keep them as they are but then ask the
compiler to always use STDCALL").

H.

-----Message d'origine-----
De : Ros-dev [mailto:[e-mail]] De la part de Timo Kreuzer
Envoyé : mercredi 6 mai 2015 00:12
À : ReactOS Development List
Objet : Re: [ros-dev] [ros-diffs] [gedmurphy] 67563: [DDK] Fix the FS filter
callback definitions

GCC doesn't support that.

Am 05.05.2015 um 23:11 schrieb Ged Murphy:
> Ahh interesting.
> So why don't we force /Gz  in our build env?
>
> -----Original Message-----
> From: Ros-dev [mailto:[e-mail]] On Behalf Of Timo 
> Kreuzer
> Sent: 05 May 2015 22:01
> To: ReactOS Development List
> Subject: Re: [ros-dev] [ros-diffs] [gedmurphy] 67563: [DDK] Fix the FS 
> filter callback definitions
>
> Am 05.05.2015 um 22:35 schrieb Ged Murphy:
> > I don't get is that if I were to write code which uses this API, I 
> > would write my callbacks without NTAPI  as per the headers. I'm 
> > guessing most other devs would too. So how are people building with 
> > cdecl and being called by Windows with stdcall  without stack issues?
>
> As I said: the compiler (you are supposed to use Visual Studio with a 
> driver project and nothing else, and that will have the option "Calling

Convention"
> set to "__stdcall (/Gz)") will use stdcall by default. So unless you 
> see __cdecl, the function or function pointer is stdcall.
> Have  a look at WDK sample sources. Almost completely lacking NTAPI.
> If you mess with VS settings or use a different compiler ... well, you 
> are screwed.
>
> Timo
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Ged Murphy]

I'm not suggesting to remove the NTAPI from the headers, I'm just suggesting
switching /Gz on for our MS toolset.
Code that builds using the MS toolset and MS WDK doesn't build using the MS
toolset and the ReactOS DDK.

-----Original Message-----
From: Ros-dev [mailto:[e-mail]] On Behalf Of Hermès
BÉLUSCA - MAÏTO
Sent: 06 May 2015 13:35
To: 'ReactOS Development List'
Subject: Re: [ros-dev] [ros-diffs] [gedmurphy] 67563: [DDK] Fix the FS
filter callback definitions

And also, for correctness/exactness/documentation purposes/any other
reason... we should keep explicit the calling conventions, so that people
who have other compilers which cannot enforce on a module basis STDCALL, or
people who want to play with msvc by changing the default calling
convention, do not become screwed.
The easy way "solution" à la MS is NOT *the* solution (it looks more like a
hack as in: "heck we don't want to modify all of our headers to add the
needed STDCALL/NTAPI/WINAPI stuff so keep them as they are but then ask the
compiler to always use STDCALL").

H.

-----Message d'origine-----
De : Ros-dev [mailto:[e-mail]] De la part de Timo Kreuzer
Envoyé : mercredi 6 mai 2015 00:12 À : ReactOS Development List Objet : Re:
[ros-dev] [ros-diffs] [gedmurphy] 67563: [DDK] Fix the FS filter callback
definitions

GCC doesn't support that.

Am 05.05.2015 um 23:11 schrieb Ged Murphy:
> Ahh interesting.
> So why don't we force /Gz  in our build env?
>
> -----Original Message-----
> From: Ros-dev [mailto:[e-mail]] On Behalf Of Timo 
> Kreuzer
> Sent: 05 May 2015 22:01
> To: ReactOS Development List
> Subject: Re: [ros-dev] [ros-diffs] [gedmurphy] 67563: [DDK] Fix the FS 
> filter callback definitions
>
> Am 05.05.2015 um 22:35 schrieb Ged Murphy:
> > I don't get is that if I were to write code which uses this API, I 
> > would write my callbacks without NTAPI  as per the headers. I'm 
> > guessing most other devs would too. So how are people building with 
> > cdecl and being called by Windows with stdcall  without stack issues?
>
> As I said: the compiler (you are supposed to use Visual Studio with a 
> driver project and nothing else, and that will have the option 
> "Calling

Convention"
> set to "__stdcall (/Gz)") will use stdcall by default. So unless you 
> see __cdecl, the function or function pointer is stdcall.
> Have  a look at WDK sample sources. Almost completely lacking NTAPI.
> If you mess with VS settings or use a different compiler ... well, you 
> are screwed.
>
> Timo
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

_______________________________________________
Ros-dev mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-dev