Is there an official / proper method of getting Windows’ drivers directory or do you just concatenate "\\Drivers" to GetSystemDirectory()?
To be clear, I mean the Drivers directory that is in the system directory (eg System32). Yes, drivers can technically be anywhere, but is there an official way (eg a function) to get this specific directory?
There is no special folder for drivers. The special folders are CSLIDs (see http://msdn.microsoft.com/en-us/library/bb762494(VS.85).aspx.
If it was a special folder then you could use the SHGetSpecialFolderPath (see http://msdn.microsoft.com/en-us/library/bb762204(VS.85).aspx)
It's hard-coded into the kernel, although drivers don't have to be loaded from there. Here's some bits taken from various parts of the I/O subsystem, which loads drivers:
#define SYSTEM32_DRIVERS_DIR (L"\\System32\\drivers\\")
...
pathLength = sizeof(L"\\SystemRoot\\System32\\Drivers\\") - sizeof(UNICODE_NULL);
path = L"\\SystemRoot\\System32\\Drivers\\";
...
Related
I thought extended file attributes existed in NTFS which Windows supports. I cannot find a cmd for accessing/updating attributes.
Is there a flavor of Windows (and its file system) that supports this?
I tried getfattr, setfattr, and a number of other commands. attrib is not it either.
If extended attributes are to remain portable across filesystems (even virtual ones implemented in FUSE) then all target platforms need to present an api in userspace (a cmd or set of cmds).
The closest thing to UNIX attribs are EAs: NTFS stores partition metadata called Extended Attributes (EA), which allow data to be stored as an attribute of a file or folder.
EAs, for instance, are used by IE to identify a file as having been "downloaded from the web".
From Wikipedia:
On Windows NT, limited-length extended attributes are supported by
FAT, HPFS, and NTFS. This was implemented as part of the OS/2
subsystem. They are notably used by the NFS server of the Interix
POSIX subsystem in order to implement Unix-like permissions. The
Windows Subsystem for Linux added in the Windows 10 Anniversary Update
uses them for similar purposes, storing the Linux file mode, owner,
device ID (if applicable), and file times in the extended
attributes. Additionally, NTFS can store infinite-length extended
attributes in the form of alternate data streams (ADS), a type of
resource fork. Plugins for the file manager Total Commander, like NTFS
Descriptions and QuickSearch eXtended support filtering the
file list by or searching for metadata contained in ADS Streams. Ref.
If you want to do something security related you want to take a look at the Discretionary Access Control List (DACL) functionality; http://www.windowsecurity.com/articles/Understanding-Windows-NTFS-Permissions.html
Powershell can help setting the mode and extended file and folder attributes - but this does, unfortunately, only apply to regular attributes (not EAs).
I found something related to NTFS attribs in the 3G-Fuse source that might be helpful. However, I doubt that's truly portable.
Here's a GitHub repo containing a tool that allows to manipulate EAs: https://github.com/jschicht/EaTools - this apparently uses NtCreateFile and NtSetEaFile to set and modify them.
(I also asked specifically about .NET APIs to maybe implement a cross-platform tool: .NET: How to set "extended file attributes" in a cross-platform way? - currently there is no such API.)
I have a library that has a file based interface (it only accept file names/paths).
Since the operations are time critical i would like to load the file to memory.
Is there a way to create create in-memory files that have a file path that is resolvable with the normal file access routines?
For example many programs still work if they get some win32 device path or an UNC path instead of a 'classic' windows path.
or maybe if that is not the case maybe a softlink can be used to map it into 'normal' filesystem.
One obvious way would be to use some ramdisk software but this would require further manual steps and also requires to tell the program the ramdisks letter.
I want to study the source files of some of the device drivers that are installed and loaded on either a raspberry pi(raspian), beaglebone(debian) or a my laptop(ubuntu).
My aim is to learn how to properly implement my own modules by studying the source files of some drivers that actually works.
I am particularly interested in drivers that communicates with actual hardware (USB, I2C, SPI, UART etc).
Can someone tell me how to find these sources? are they available in some particular folder i.e something like /usr/src/**** or do I have to download all of the kernel source files from a particular kernel release?
All advice's, opinions and recommendations are most appreciated.
p.s I have read "Linux Kernel Development 3rd edition" but please tell me if
you know any other free/open-source books on the subject.
Best regards
Henrik
Linux Source directory and description :
arch/ -
The arch sub-directory contains all of the architecture specific kernel code.
Example :
1. 'arch/arm/' will have your board related configuration file.
like 'arch/arm/mach-omap/' will have omap specific source code.
2. 'arch/arm/config' Generates a new kernel configuration with the
default answer being used for all options. The default values
are taken from a file located in the arch/$ARCH/defconfig
file,where $ARCH refers to the specific architecture for which
the kernel is being built.
3. arch/arm/boot have kernel zImage, dtb image after compilation.
block/ -
This folder holds code for block-device drivers. Block devices are devices that accept and send data in blocks. Data blocks are chunks of data instead of a continual stream.
crypto/ -
This folder contains the source code for many encryption algorithms.
example, “sha1_generic.c” is the file that contains the code for
the sha1 encryption algorithm.
Documentation/ -
It has kernel related information in text format.
drivers/ - All of the system's device drivers live in this directory. They are further sub-divided into classes of device driver.
Example,
1. drivers/video/backlight/ has blacklight driver source which
will control display brightness.
2. drivers/video/display/ has display driver source.
3. drivers/input/ has input driver source code. like touch,
keyboard and mouse driver.
4. drivers/char/ has charter driver source code.
5. drivers/i2c/ has i2c subsystem and driver source code.
6. drivers/pci/ has pci subsytem and driver related source code.
7. drivers/bluetooth has Bluetooth driver file.
8. drivers/power has power and battery driver.
firmware/ -
The firmware folder contains code that allows the computer to read and understand signals from devices. For illustration, a webcam manages its own hardware, but the computer must understand the signals that the webcam is sending the computer.
fs/ -
All of the file system code. This is further sub-divided into directories, one per supported file system, for example vfat and ext2.
kernel/ -
The code in this folder controls the kernel itself. For instance, if a debugger needed to trace an issue, the kernel would use code that originated from source files in this folder to inform the debugger of all of the actions that the kernel performs. There is also code here for keeping track of time. In the kernel folder is a directory titled "power". Some code in this folder provide the abilities for the computer to restart, power-off, and suspend.
net/ -
net
The kernel's networking code.
lib
This directory contains the kernel's library code. The architecture specific library code can be found in arch/*/lib/.
scripts
This directory contains the scripts (for example awk and tk scripts) that are used when the kernel is configured.
lib/ -
This directory contains the kernel's library code. The architecture specific library code can be found in arch/*/lib/.
scripts/ -
This directory contains the scripts (for example awk and tk scripts) that are used when the kernel is configured.
mm/ -
This directory contains all of the memory management code. The architecture specific memory management code lives down in arch/*/mm/, for example arch/i386/mm/fault.c.
ipc/ -
This directory contains the kernels inter-process communications code.
**init/ -**The init folder has code that deals with the startup of the kernel (INITiation). The main.c file is the core of the kernel. This is the main source code file the connects all of the other files.
sound/ - This is where all of the sound card drivers are.
There are few more directory certs, crypto, security, include, virt and usr etc....
There are a few different methods that I use for viewing kernel related source, and I'm sure there are a few other good methods out there as well. You will find that the methods are largely the same.
Head on over to kernel.org and download the kernel of your choice. You will find driver related source under /<path to your downloaded kernel>/drivers. For example, I have downloaded and extracted kernel 4.5.5 to /usr/src/linux-4.5.5, and access the source for my drivers via /usr/src/linux-4.5.5/drivers.
Use a linux cross-reference website. Personally, I use the one hosted on free-electrons. These websites are nice for their free-text or identifier searches.
Browse Linus Torvalds' linux repo hosted on github.
Never mind, I found the source files under
~/linux/drivers/
example:
nano ~/linux/drivers/spi/spi-bitbang.c
Sorry, for any inconvenience!
In a 32bit application, I have to copy a file to the 64bit system folder
(C:\Windows\System32\ instead of C:\Windows\SysWOW64\)
For this, I tried to get the folder using the WinAPI function SHGetKnownFolderPath with parameter FOLDERID_ProgramFilesX64 (GUID: 6D809377-6AF0-444b-8957-A3773F02200E).
But unfortunately, this is not allowed (as mentioned in the remarks section) and the function result correctly is 'file not found'.
Is there a way to accomplish this?
You are requesting the PROGRAM FILES folder, not the SYSTEM folder. Look at FOLDERID_System and FOLDERID_SystemX86 instead.
Alternatively, use FOLDERID_Windows to get the Windows installation folder, and then append the special SysNative alias to the end of it, let the File System Redirector locate the actual folder for you, per the documentation:
32-bit applications can access the native system directory by substituting %windir%\Sysnative for %windir%\System32. WOW64 recognizes Sysnative as a special alias used to indicate that the file system should not redirect the access. This mechanism is flexible and easy to use, therefore, it is the recommended mechanism to bypass file system redirection. Note that 64-bit applications cannot use the Sysnative alias as it is a virtual directory not a real one.
I'm confused why you would try FOLDERID_ProgramFilesX64 when you say you want the System32 folder, since the former would (if it worked) give you the Program Files folder. For the System32 folder, you want the GetSystemDirectory function.
You can use the catchily-named Wow64DisableWow64FsRedirection function to disable WOW64 redirection, which allow your 32-bit app to actually access the 64 bit system folder. Then use Wow64RevertWow64FsRedirection to restore the redirection once you're done.
Also note that it's not actually recommended to store your own files in the System folder any more (and hasn't been for quite some time), as this note in the docs for GetSystemDirectory says:
Applications should not create files in the system directory. If the
user is running a shared version of the operating system, the
application does not have write access to the system directory.
Linux has a feature called namespaces, which let you give a different "view" of the filesystem to different processes. In Windows terms, this would be useful for example if you had a legacy program "floyd" that always loaded its configuration from C:\floyd\floyd.ini. If Windows had namespaces, you could write a wrapper script which would create a namespace in which to run floyd, making it so when Alice ran the script, floyd would start up in an environment where C:\floyd existed but actually pointed to C:\Users\Alice\Floyd.
Now you may be thinking, "OK, just use soft or hard links and make C:\floyd an alias for C:\Users\Alice." But with namespaces, Bob can also run the startup script, but his instance of floyd (on the same computer, running at the same time) will see C:\floyd with the contents of, say, C:\Users\Bob\Program Settings\Floyd Config (or any other path we like).
You can do this on Linux with namespaces. Is there something similar or analogous on Windows? It's fine if it requires writing a C program, and it's OK if it only works on recent versions of Windows.
NTFS hard links are really a simple case of reparse points. Reparse points are typed, and can include more advanced behavior. For instance, they're also used for "offline storage" (transparent migration of files to and from secondary storage). You can therefore also use reparse points to implement per-user symbolic links, by creating a new reparse type.
The reparse point type even has an explicit "Name surrogate" bit, which (if set) indicates that reparse points of those types are some kind of symbolic link.
You can even have multiple reparse points in a path. Therefore files inside your symbolic namepace can still be migrated to secondary storage - you'd just have two reparse points in the path.
I think Virtual Store does this automatically for legacy programs that try to write to nonstandard directories. So the legacy program writes to a user- and program-specific directory instead to C:\floyd.
This sounds like Windows Vista's file system virtualization. For example, it can silently redirect c:\Program Files\Floyd to c:\Users\<username>\AppData\Local\VirtualStore\Program Files\Floyd. However, file system virtualization isn't nearly as configurable as Linux namespaces. From what I can tell from reading, file system virtualization should apply any time a 32-bit interactive process opens for writing a file, folder, or registry key that's only writable by administrators. (So you typically end up with some read-only files under c:\Program Files and some per-user writable files under c:\Users\<username>\AppData\Local\VirtalStore.)
An application virtualization product can probably also do this, although those are often more complicated and more expensive.
You can use hardlinks for that, but only with NTFS. http://en.wikipedia.org/wiki/Hard_link
I think windows doesn't have virtual FS view per process.
The most relevant thing is probably special environment folders, such as %temp%, %appdata%, %localappdata%. Not that they're equivalent, but they fulfil the same purpose.
You can define your own environment variables then use '%myspecialplace%\myfile.txt' to access them.
As a horrid kludge (and here I book my passage to programming hell) could you use a NamedPipe for C:\Floyd that mapped the IO operations onto a file specific to the current process user?
I know it's not pretty and I don't know enough about NamedPipes (FIFOs in other dialects) on Windows to know how feasible this is.
Dan
There are several things that come to my mind.
First of all you can create a file system filter driver (or use a ready driver, such as our CallbackFilter product) that would redirect all file system calls, coming from the application, to other location. This is close to virtualization that you mentioned but this won't change the list of drive letters though. Such approach is both powerful and non-trivial, so see the other option first of all.
And the other option is:
there exist several products (Thinstall, Molebox if memory serves) that "wrap" the application redirecting it's file I/O to some other location. There was also some SDK to do the same, but I don't remember it's name at all.
e.g. http://www.msigeek.com/4819/file-re-direction-using-correctfilepaths-shim-to-fix-broken-applications
But I think it's not configurable per user, although the target can vary per-user based on environment variable substitution.
Most programs, though, store configuration in the registry, in which case RegOverridePredefKey would do the trick.
There's a shortage of good solutions for this. For simplicity, I can't improve on using NTFS soft links (junctions) for this - as you correctly point out, this creates issues if you want per-user configuration. As MSalters correctly says, all NTFS soft and hard links are just special cases of reparse points, so you could do something more general by impplementing a new reparse type, if you don't mind some work digging into NTFS..
(Junction is a pretty useful tool when experimenting with NTFS soft links: http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx )
You could just take a direct approach - give each user (or your program initialization if you only care about one piece of software) a logon script that sets up the appropriate junction into their user directory (and make sure you clean it up afterwards). But it's clumsy.
In general the right Windows approach is to put things into the folders pointed at by the %localappdata% (from Vista on) and, more generally, %userprofile% system variables.
Win file system virtualization is intended to ensure this in the cases where it applies.