A general remark for this revision and r39033.
FsRtlNotifyInitializeSync and CcInitializeCacheMap both raise exception in case of failure, instead of returning a status. Should we consider adding PSEH support and usage to the new driver?
P. Schweitzer
> Date: Fri, 23 Jan 2009 12:18:39 +0000
> To: ros-diffs(a)reactos.org
> From: pschweitzer(a)svn.reactos.org
> Subject: [ros-diffs] [pschweitzer] 39040: Added notifications stuff to VCB
>
> Author: pschweitzer
> Date: Fri Jan 23 06:18:38 2009
> New Revision: 39040
>
> URL: http://svn.reactos.org/svn/reactos?rev=39040&view=rev
> Log:
> Added notifications stuff to VCB
>
> Modified:
> trunk/reactos/drivers/filesystems/fastfat_new/fat.c
> trunk/reactos/drivers/filesystems/fastfat_new/fatstruc.h
>
_________________________________________________________________
Téléphonez gratuitement à tous vos proches avec Windows Live Messenger ! Téléchargez-le maintenant !
http://www.windowslive.fr/messenger/1.asp
Hi,
I am working on a project to parse the Windows image file. To do that,
I must understand the structure of some Windows components, like
_EPROCESS. So I took some headers from ReactOS, and write *userland*
code like below:
----
#include <pstypes.h>
#include <stdio.h>
int main()
{
printf("size of EPROCESS: %d\n", sizeof(struct _EPROCESS));
return 0;
}
----
The I got the problem: g++ reported that _EPROCESS is incomplete.
Clearly this means it doesnt see the structure _EPROCESS, so I took a
closer look, and found that _EPROCESS is not defined in user-mode
(NTOS_MODE_USER). I tried to fix it by putting
#undef NTOS_MODE_USER
in front of #include <pstypes>, but that doesnt help.
Anybody please tell me if there is any way to fix this?
I think I can fix that by modifying the original headers. but that is
way too ugly.
Many thanks,
Jun
sginsberg(a)svn.reactos.org wrote:
> Author: sginsberg
> Date: Sun Jan 18 17:31:26 2009
> New Revision: 38922
>
> URL: http://svn.reactos.org/svn/reactos?rev=38922&view=rev
> Log:
> - Fix more InterlockedCompareExchangePointer warnings in crypt32 -- this to Wine, too
>
> Added:
> trunk/reactos/dll/win32/crypt32/warningfixes.diff
This is a bad idea.
It's painful enough keeping wine libs in sync without adding to the complexity with non-needed warning fixes.
Ged.
hyperion(a)svn.reactos.org schrieb:
> Author: hyperion
> Date: Sun Jan 18 00:25:43 2009
> New Revision: 38872
>
>
...
> Introduce new define __ROS_LONG64__ ("assume 64-bit long"), to use int instead of long in typedefs of 32-bit integers
> __ROS_LONG64__ automatically defined if __WINESRC__ is defined. No, __WINESRC__ alone is not enough
>
If it's defined automatically, why isn't __WINESRC__ alone enough? And
when it's not enough anyway, why define __ROS_LONG64__ automatically at
all?
...
> #else /* !_WIN64 */
> +#if !defined(__ROS_LONG64__)
> typedef int INT_PTR, *PINT_PTR;
> typedef unsigned int UINT_PTR, *PUINT_PTR;
> +#else
> +typedef long INT_PTR, *PINT_PTR;
> +typedef unsigned long UINT_PTR, *PUINT_PTR;
> +#endif
>
If we assume a 64bit long, why define INT_PTR to long on 32 bit target?