I am writing a minifilter driver which would monitor files. The files to be monitored is to be read from a file on startup.
This file is created by a user mode application running independantly
My problem is as follows:-
If the file is ansi or unicode, the routine in the driver works fine
but if the file is created by an MBCS application, then what methods do i use in the driver to find the length etc…
i tried using _mbslen, but the driver gives me linker errors…
Why would this be a file system level issue? The file system is agnostic with respect to the contents of the file, yet from your question you seem to be interpreting the content of the file. In that case, you’ll need to provide your own code (or use any pre-existing code) for handing that data content. If you really want to do string interpretation of multi-byte characters, you’ll have to provide your own library to deal with it. That there are some libraries for dealing with strings already is merely a convenient coincidence in your case…
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
No, i am not reading/examining the contents of the file.
The driver
The list of files to be monitored is read from a file on the disk by the driver. This file on the disk can be created in the MBCS format.
This is to handle filenames containing japanese chars.
So when the driver is reading this file on the disk which contains filenames, it converts the filename into unicode for ease of use.
if the input is an MBCS filename, how do i find its length…
sorry for not stating explicit requirements in my earlier post
Why use MBCS/DBCS? All Windows XP and later systems support UNICODE. Have
the application that creates the file do the conversion. You don’t want to
worry about character mappings in the kernel. You want the application to
put it into a user mode language independent form. The kernel works fine
with UNICODE Japanese characters because I use them for the names of songs
all the time. I have to sometimes switch the user interface to the Japanese
language to get it translated for transferring to CD/DVD or other locations,
but Windows Explorer and Total Commander recognize the Japanese characters
just fine. You do have to load the East Asian language fonts and support,
but the IME is not required unless you want to enter those characters.
wrote in message news:xxxxx@ntfsd…
> No, i am not reading/examining the contents of the file.
> The driver
> The list of files to be monitored is read from a file on the disk by the
> driver. This file on the disk can be created in the MBCS format.
>
> This is to handle filenames containing japanese chars.
> So when the driver is reading this file on the disk which contains
> filenames, it converts the filename into unicode for ease of use.
> if the input is an MBCS filename, how do i find its length…
>
> sorry for not stating explicit requirements in my earlier post
>
>
>
>
> but if the file is created by an MBCS application, then what methods do i use
in
No MBCS in the kernel. At all. In the kernel, all filenames are always Unicode.
In fact, MBCS is dead, since Win9x is dead.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> The list of files to be monitored is read from a file on the disk by the
driver. file
on the disk can be created in the MBCS format.
Mandate it to be Unicode-only.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> Why use MBCS/DBCS? All Windows XP and later systems support
UNICODE.
All Windows NT systems since NT 3.1 support Unicode. 
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com