I am trying to create file in main directory of operation system(for example Windows in my "c" disk) using c++.
Is there any better way than iterating all disks and search for "Windows" folder? Also its similar in mac and linux?
In Windows, you can call GetWindowsDirectory function (link). In Linux and Mac (I think), there's no such thing as main system directory.
However, as David noted, you should not put any files there:
This function is provided primarily for compatibility with legacy applications. New applications should store code in the Program Files folder and persistent data in the Application Data folder in the user's profile. For more information, see ShGetFolderPath.
Related
What I'm trying to achieve is to run a program, which thinks a folder exists within its own folder while actually the folder is somewhere else on the system.
So my program would launch a process and say to the process: Folder A which is at C:\A is within your own directory at C:\Program Files (x86)\SomeProgram\A
So the "virtual" directory would only be visible to that process.
I'm using Qt to program my program, so if there are any Qt functions I could use that would be great (in relation to portability). However, plan C++ or any windows-bound API's would be fine.
I was thinking about NTFS junctions or symbolic links but I would have no idea how to create either of those in C++, let alone bind them to a specific process.
Thanks in advance!
EDIT:
In relation to the above, I've found this question: https://superuser.com/questions/234422/does-windows7-support-symbolic-links-folder-shortcuts. However, it only shows how to perform the required actions from the command-line and it wouldn't be process bound.
EDIT 2:
Some extra information: I'm trying to create a virtual directory that is made up of a couple of other directories but then merged (I'm using a priority system to decide which files "win" from other files). These merged directories would then appear to the target process as one directory containing the merged files.
I think I'm going to stick with Window's mklink command. It seems to suit my needs the best.
What I'm going to do is use QFile::link() on all operating systems that aren't Windows, and QProcess with mklink on windows. This should work on every operating system.
For a good example look here: https://stackoverflow.com/a/21013935/979732
Such tasks are accomplished by use of a filesystem filter driver. The driver intercepts OS requests going to the filesystem and lets you insert your own virtual files and directories into the existing directory on the disk. Filter driver can be an overkill for your particular task, though.
Detours approach mentioned in comments requires system-wide hooking of file APIs and will slowdown the whole system(filesystem filter driver is attached to one disk and it's a documented approach, so it's faster and more robust).
I have been using Pismo File Mount for many years, and I have always wondered how it actually works.
Let's say, I am currently working on an application that creates a package format similar to the ZIP format. For ease of access, I want to create a shell extension that works similar to how Pismo File Mount works. For those who have not used Pismo File Mount before, this is how it works:
The user right-clicks a ZIP file in Windows Explorer.
The user then clicks "Mount" to mount the ZIP file.
The user can now access his/her files immediately.
The user does not have to extract the ZIP file to view its contents.
There's a catch. I do not want to use the Pismo File Mount API, perhaps for various reasons like commercial or legal ones.
The question is, how does Pismo File Mount integrate itself into Windows Explorer programmatically, in terms of the Windows API and C++?
I wrote Pismo File Mount, and the ZIP reader included in the PFM Audit Package.
There is no consise or realistically postable answer to the question. To do what PFM does, in C/C++, to Windows API's (kernel and user), it would take 10's of thousands of lines of difficult code and a large time investment.
PFM is built as a file system driver (kernel module), with user mode support DLL's and executables. The driver uses a protocol to talk with user mode formatting code that (for example) decodes the ZIP file format and serves the contents through the kernel mode driver to client applications.
There exist two ways:
Shell namespace extension. The folder created by the shell namespace extension is not an actual filesystem folder and accessibility of the files in such folder is usually limited to Explorer itself and applications aware of shell extensions and the ways to work with them.
Filesystem filter driver which creates a virtual directory on the existing disk. Such directory is seen by all applications as a real directory, where those applications can read and write files and subdirectories. All filesystem operations go through such driver.
Pismo File Mount works via the filter driver, AFAIK.
Our CallbackFilter product provides a way to create virtual directories and files. It includes a driver and calls your user-mode code for actual operations. But filter approach is a bit complicated -- a virtual disk created with a filesystem driver (eg. with our Callback File System product) is easier to implement and manage due to differences in architectures of the filter driver stack and filesystem drivers.
Sounds like a fairly ordinary shell extension. Explorer has a powerful extension mechanism which allows it to list non-file objects such as Printers and the contents of a zip file. The particular details (columns and rows) are provided by a DLL.
You can observe this by zipping up a set of images; the ordinary thumbnail view probably won't work as that part of Explorer is usually not copied.
I am looking for documentation for the Windows API on how to make virtual folders. I am going to make sort of my own file system and would like to have an icon under "Computer" for that file system. I have seen other programs which has this type of solution like programs which allows me to explore a Linux file system under in the Explorer program. Much like the same solution I am going to make. I am yet to find any documentation on how to do this, or am I searching for the wrong stuff? Thanks.
You are looking for a Shell Namespace Extension. An entry Point for documentation is Creating Shell Data Source Objects and Extending the Shell Namespace.
An example of a almost complete Project can be found on codeplex: An almost complete Namespace Extension Sample
Also in the Windows SDK 7, there is an example of using the Shell ExtensionNamespace (can be found in the folder "Microsoft SDKs\Windows\v7.1\Samples\winui\shell\shellextensibility\explorerdataprovider"). In this Folder you will also find a document which describes the programming model (Using the System Folder View.doc).
If you really want to create a "real" file System Driver, you might want to look at this SO article:
Creating a File System "Driver" which mainly referes to the Ext2 file system driver project.
I have created a windows application and a folder with the release executable and appropriate Dlls.
First problem is that I want to package it all into one setup.exe For this task I plan on using windows default iexpress application....(is there better software available for this...must be free though, since this is only for a university assignment)
Second problem is I want to structure the installation so that the actual program along with included libraries are saved in their disk drive, i.e program files(x86) for w7. And at the same time make a desktop shortcut so its easier to run and access for the user.
The issues arising with my second problem is:
Am I wrong to assume that a user will have a 'program file' folder ??
I am thinking of making a vbscript to handle the creating shortcut, but does a vb.exe also need library files to be included ??
Assignment due in 2 days so I would really be grateful if I could get this off my chest
Thx :)
You may be interested in following SW:
Advanced installer
NSIS
WIX
I would recommend first option, it's free for your purpose, you don't need to buy professional license and you can make MSI package in 5 minutes.
No, Program Files folder is common to the valid Windows installation. But you shall not assume that it's always C:\Program Files. You must use corresponding environment string to get program files folder:
%ProgramFiles% - to store 32 bit programs on 32 bit OS and 64 bit programs on 64 bit OS.
%ProgramFiles(x86)% - to store 32 bit programs on 64 bit OS.
VBScript has nothing to do with Visual Basic (VB.exe) itself. It's running by Windows Script Host and does not require any additional libraries. Windows Scripting Host is included by default into any modern Windows OS.
You just create script source file with extension .vbs and run it as any usual executable. Example of creating shortcut could be found here.
You have an environment variable ProgramFiles with in it the path to this folder.
Doesn't include the software you used to build the exe and dll files an installer/packager ?
Otherwise I would search a free packaging program, it should be the easiest way, making the shortcut could also be done by this package. On the other hand if you want to use vbscript you could do it all from there too but your script would have to be executed by the user with administrative rights, not for the everyday user...
free packaging: Some googling gave me http://www.windowsnetworking.com/articles_tutorials/msi-packaging-tools.html, check it out
I come from a C# background and I am working on a C++ project. I need to open files in a directory, then process that data in the files. The problem is on my target environment (Greenhills Integrity), I cannot access a "directory". It seems C++ does not have a concept of a directory. Why not? This problem is simple in C#. I cannot link to any big library(BOOST or dirent) to get the files. I can open a file using fopen, but I won't always know the file names, so I have to "strcat" the directory to each filename in order to "fopen" the files.
I need a way to just get the file names in a directory without using an external API. Is that possible?
The major C++ APIs have directories. Start with readdir on POSIX or FindFirstFile() on Windows. Greenhills seems to support POSIX.
No, it's not possible. C++ has no "built-in" directory functionality - you need to use a library of some sort.
Check with your operating system. Directory handling is different for each. You will have to use the Windows 32 API if you want to list/query directories on Microsoft Windows, and the Linux API (e.g. opendir/stat) if you want to list/query directories on Linux.