Reason for different handling of booleans

[JaniruTEC]

I was looking at the definitions of _DOKAN_FILE_INFO and _DOKAN_ACCESS_STATE in order to fix dokan-dev/dokan-java#46 for the dokan-java project. The defintions are linked below:

dokany/dokan/dokan.h

Lines 155 to 185 in 1694ff1

	typedef struct _DOKAN_FILE_INFO {
	/**
	* Context that can be used to carry information between operations.
	* The context can carry whatever type like \c HANDLE, struct, int,
	* internal reference that will help the implementation understand the request context of the event.
	*/
	ULONG64 Context;
	/** Reserved. Used internally by Dokan library. Never modify. */
	ULONG64 DokanContext;
	/** A pointer to DOKAN_OPTIONS which was passed to DokanMain. */
	PDOKAN_OPTIONS DokanOptions;
	/**
	* Process ID for the thread that originally requested a given I/O operation.
	*/
	ULONG ProcessId;
	/**
	* Requesting a directory file.
	* Must be set in \ref DOKAN_OPERATIONS.ZwCreateFile if the file appears to be a folder.
	*/
	UCHAR IsDirectory;
	/** Flag if the file has to be deleted during DOKAN_OPERATIONS. Cleanup event. */
	UCHAR DeleteOnClose;
	/** Read or write is paging IO. */
	UCHAR PagingIo;
	/** Read or write is synchronous IO. */
	UCHAR SynchronousIo;
	/** Read or write directly from data source without cache */
	UCHAR Nocache;
	/** If \c TRUE, write to the current end of file instead of using the Offset parameter. */
	UCHAR WriteToEndOfFile;
	} DOKAN_FILE_INFO, *PDOKAN_FILE_INFO;

dokany/sys/public.h

Lines 181 to 193 in 1694ff1

	typedef struct _DOKAN_ACCESS_STATE {
	BOOLEAN SecurityEvaluated;
	BOOLEAN GenerateAudit;
	BOOLEAN GenerateOnClose;
	BOOLEAN AuditPrivileges;
	ULONG Flags;
	ACCESS_MASK RemainingDesiredAccess;
	ACCESS_MASK PreviouslyGrantedAccess;
	ACCESS_MASK OriginalDesiredAccess;
	PSECURITY_DESCRIPTOR SecurityDescriptor;
	UNICODE_STRING ObjectName;
	UNICODE_STRING ObjectType;
	} DOKAN_ACCESS_STATE, *PDOKAN_ACCESS_STATE;

I noticed that the definitions use different types to store boolean values. _DOKAN_FILE_INFO uses WCHARs/bytes and compares against 0 to determine if the flag is set; _DOKAN_ACCESS_STATE uses BOOLEANs.
Is this intentional or just a matter of Dokany's history? Does it have to do something with the sys/user-layer?

[Liryna]

@JaniruTEC Hi,

Yes, that only dokan history reason. Also DOKAN_ACCESS_STATE is based on ACCESS_STATE that use BOOLEAN.
Anyway the logic had to be BOOLEAN usage from my point of view, might be a good idea to review it for 2.x.x

[JaniruTEC]

Hey, @Liryna.

Thanks for your quick answer. Reviewing this would be highly appreciated from the wrapper-projects, I guess.
Maybe handling this as a combined bitmask would be another option?

[Liryna]

I do not have an exact idea for now how it needs to look like. There is a ticket open for delete on close that have some good chance to affect it. So better to resolve this one and have a better view before changing it.

[Liryna]

Windows headers:
typedef UCHAR BOOLEAN;
typedef int BOOL;
typedef unsigned char UCHAR;

With UCHAR you are sure of the space used which is needed when the library is x86 and the driver is x64.

Userland could have used BOOLEAN but then you would have to define it for cygwin & msys.