I'm writing a cross-platform game (in C++) called Bombz and I need a way to read/write users' settings etc, which will also include records of which levels have been completed. Something like an ini file parser will be fine, and it doesn't really need to be efficient and/or scaleable - I can read all the settings at start-up instead of looking up named keys on the fly.
I've found a few simple ini file parsers but they overlook the question of where to store the files and it looks like I might have to write all this stuff myself. Should I just use something like:
Windows: $APPDATA/realh/Bombz/config
Mac: $HOME/Library/Bombz/config
Linux etc: $HOME/.bombz/config (or use the XDG spec)
where I look up $HOME or $APPDATA with getenv()? I know there are "better approved" ways of looking that up in Windows but I'm a Linux guy and I don't want to have to deal with the Windows API directly.
Well, it's quite interesting -- someone trying to write a game without calling OS-functions. Quite a challenge.
Other than that, if you don't want to call SHGetKnownFolderPath() then environment variables are your only bet. Although for myself, I don't even trust $HOME on Linux -- I use getpwuid_r(). And NSHomeDirectory() on MacOS.
Related
I'm building a barebones Notepad-styled project (console-based, does not have a GUI as of now) and I'd like to track, display (and later use it in some ways) the number of times the console application has been launched. I don't know if this helps, but I'm building my console application on Windows 10, but I'd like it to run on Windows 7+ as well as on Linux distros such as Ubuntu and the like.
I prefer not storing the details in a file and then subsequently reading from it to maintain count. Please suggest a way or any other resource that details how to do this.
I'd put a strikethrough on my quote above, but SO doesn't have it apparently.
Note that this is my first time building such a project so I may not be familiar with advanced stuff... So, when you're answering please try to explain as is required for a not-so-experienced software developer.
Thanks & Have a great one!
Edit: It seems that the general advice is to use text files to protect portability and to account for the fact that if down-the-line, I need to store some extra info, the text file will come in super handy. In light of this, I'll focus my efforts on the text file.
Thanks to all for keeping my efforts from de-railing!
I prefer not storing the details in a file
In the comments, you wrote that the reason is security and you consider using a file as "over-kill" in this case.
Security can be solved easily - just encrypt the file. You can use a library like this to get it done.
In addition, since you are writing and reading to/from the file only once each time the application is opened/closed, and the file should take only small number of bytes to store such data, I think it's the right, portable solution.
If you still don't want to use a file, you can use windows registry to store the data, but this solution is not portable
I've not done much coding for Windows lately, and I find myself sitting at Visual Studio right now, making a small program for Windows 7 in C++. I need some configuration data to be read/written.
In the old days, (being a Borland kind of guy) I'd just use a TIniFile and keep the .ini beside my exe Obviously this is just not the done thing any more. The MS docs tell me that Get/WritePrivateProfileString are for compatibility only, and I doubt that I'd get away with writing to Program Files these days. Gosh I feel old.
I'd like the resulting file to be easily editable - open in notepad sort of thing, and easily findable. This is a small app, I don't want to have to write a setup screen when I can just edit the config file.
So, what is the modern way of doing this?
Often people use XML files for storing preferences, but they are often overkill (and they aren't actually all that readable for humans).
If your needs would be easily satisfied with an INI file, you may want to use Boost.Program_options using the configuration file parser backend, which actually writes INI-like files without going through deprecated (and slow!) APIs, while exposing a nice C++ interface.
The key thing to get right is where to write such configuration file. The right place is usually a subdirectory (named e.g. as your application) of the user's application data directory; please, please, please, don't harcode its path in your executable, I've seen enough broken apps failing to understand that the user profile may not be in c:\Documents and settings\Username.
Instead, you can retrieve the application data path using the SHGetFolderPath function with CSIDL_APPDATA (or SHGetKnownFolderPath with FOLDERID_RoamingAppData if you don't mind to lose the compatibility with pre-Vista Windows versions, or even just expanding the %APPDATA% environment variable).
In this way, each user will be able to store its preferences and you won't get any security-related errors when writing your preferences.
This is my opinion (which I think most of the answers you get will be opinion), but it seems that the standard way of doing things these days is to store config files like these in C:\Users\<Username>. Moreover, it is generally good to not clutter this directory itself, but to use a subdirectory for the purpose of storing your application's data, such as C:\Users\<Username>\AppData\Roaming\<YourApplicationName>. It might be overkill for a single config file, but that will give you the opportunity to have all of your application data in one place, should you add even more.
How can I find the user's home directory in a cross platform manner in C++? i.e. /home/user in Linux, C:\Users\user\ on Windows Vista, C:\Documents And Settings\user\ on Windows XP, and whatever it is that Macs use. (I think it's /User/user)
Basically, what I'm looking for is a C++ way of doing this (example in python)
os.path.expanduser("~")
I don't think it's possible to completely hide the Windows/Unix divide with this one (unless, maybe, Boost has something).
The most portable way would have to be getenv("HOME") on Unix and concatenating the results of getenv("HOMEDRIVE") and getenv("HOMEPATH") on Windows.
This is possible, and the best way to find it is to study the source code of os.path.expanduser("~"), it is really easy to replicate the same functionality in C.
You'll have to add some #ifdef directives to cover different systems.
Here are the rules that will provide you the HOME directory
Windows: env USERPROFILE or if this fails, concatenate HOMEDRIVE+HOMEPATH
Linux, Unix and OS X: env HOME or if this fails, use getpwuid() (example code)
Important remark: many people are assuming that HOME environment variable is always available on Unix but this is not true, one good example would be OS X.
On OS X when you run an application from GUI (not console) this will not have this variable set so you need to use the getpwuid().
The home directory isn't really a cross-platform concept. Your suggestion of the root of the profile directory (%USERPROFILE%) is a fair analogy, but depending what you want to do once you have the directory, you might want one of the Application Data directories, or the user's My Documents. On UNIX, you might create a hidden ".myapp" in the home directory to keep your files in, but that's not right on Windows.
Your best bet is to write specific code for each platform, to get at the directory you want in each case. Depending how correct you want to be, it might be enough to use env vars: HOME on UNIX, USERPROFILE or APPDATA (depending what you need) on Windows.
On UNIX at least (any Windows folks care to comment?), it's usually good practice to use the HOME environment variable if it's set, even if it disagrees with the directory specific in the password file. Then, on the odd occasion when users want all apps to read their data from a different directory, it will still work.
I would like to create a virtual drive for windows. I'm not looking to map a drive or something like that, I'm looking to map it to my DLL functions or something of that sort.
How can I get this accomplished?
I read that I would have to develop a device driver, or a shell extension?
I have a lot of experience with C++ and C#. Where do I get started?
I want to make it as simple as possible at first, how much time do I think it would take me? And what's the simplest way to do it, so that I could build my prototype.
My motivation is to pipe a file into an application, that currently only reads files from the file system. I'm only interested in pumping 1 file, so I think that a whole virtual drive would be an overkill, as well as writing kernel mode code.
If you want to build it from scratch then yes, you have to build a driver. However, it would be much easier for you to use a proxy driver like Dokan, and create the file system in user mode.
Take a look at the Wikipedia article on IFS, there are links to other useful tools at the bottom of the page.
I don't know what it worth, and it's not open source, but I've found this. It's a "fuse" like for windows
I've recalled using little 'filesystems' before that basically provided an interface to something else. For example, I believe there was a GMail filesystem that created an entry in My Computer and could be used like any other drive on your local computer. How can I go about implementing something like this in C++?
Thank you!
Try Dokan. It's like FUSE, except for Windows. I think there are certain limitations to namespace extensions, like they cannot be accessed from the command line, but I'm really not sure as of now.
Writing an actual file-system involves writing a driver; which means kernel-mode code (scary stuff) and paying for getting the IFS DDK. (edit: looks like they don't charge for it anymore)
What you probably want is a “namespace extension”.
Try this: The Complete Idiot's Guide to Writing Namespace Extensions - CodeProject
This may be a starting point to extending NTFS in the way that the GMail filesystem used to do: Windows NT reparse points.
The GMail Filesystem is just the name given; it is not any filesystem as such. It is just a namespace extension for Windows Explorer that links with the GMail account of yours!
I dont know exactly what you are trying to do, but in anyway, I believe, the following link will be of some use to you:
http://msdn.microsoft.com/en-us/magazine/cc188741.aspx
Just as a reference: virtual drives can be created using our Callback File System product, which is a supported, documented and maintained solution.
I was thinking of this too, perhaps some example code ? (email me if i forget plz ;p doin sdk now)
I'm thinking of a similar filesystem that would plug in as a driver and allow dynamic 'soft raid' on larger files mostly by putting them on more than one disk, perhaps some compression options and 'smart' filters to toggle usage in high disk space low usage and other situations more effectively, with status controls and indicators as a normalish program too
Seems like I would load the driver kit,
then i want the file writing event, and am mostly replacing fopen and similar functions automatically as an intermediate driver with a little windows network driver experience
I also heard good things about developing on a virtual machine for less crashing and more debugging
Also perhaps more metainfo on some or all files, including files in special folders with options too, including maybe both fast and simple (obfuscated and/or symmetic key) encryption options on folder, specified, all, letter, etc, or whatever, or the slower version and maybe integrated and optional (also profitable) online cvs-like diff style backups that mostly target changes to hot files for online backup at intervals and prices, mostly perhaps with matching keyboard events and might even be useful as simply a keylogging online backup service that is reasonably secure too
while avoiding common files like windows files or the normal stuff in the 'programs' directory that can be copied easily with pirate tools, unlike all of your documents.