We Keep Coding

Opening foreign file extensions, like in game files, How is it done?

In the sake of this game I'm modding at the moment, which has archives ending in ".rpf" (which is short for 'rage engine package file')
How exactly is it that programmers, can find ways to open these types of files/archives, without having access to the rage engine?
What would one need to know in order to even begin trying to open a foreign file extension? The files can be opened thanks to the OpenIV Team who created the program necessary for opening the files, but how exactly does a developer, figure out or even know where to start when it comes to developing an application that is to fulfill the task of opening another file?

It's called Reverse engineering
You look into file with hex editor, notice some texts, or numbers that look like offsets. You apply your own experience writing similar stuff, make some assumptions and check if it is correct for multiple entries, and so on and so forth.

There many ways to open such files.
First you can use specific programs to open them like OpenIV for RPF archive.
If you would try to Mod or write a cheat for example, most people disassemble the program or open them with a Hex-Editor.
Programs like HexEdit change the binary values of a program into hexadecimal numbers, for example the byte 10100101 into Hex 0xA5h (A5).
Another way is to disassemble the program. Programs like ollyDbg, IDA Pro or other disassemble the binary values into assembly-code. Now you're able to search for some offsets, adresses and texts and you can remove or edit them to let the program do what you want.
Some programs are able to generate a pseudocode to C or C# e.g. (.NET Reflector) which helps you to understand what the program do.
After you read for example some memory adresses and their offsets, you can change them in the disassemble program itself (JNZ (Jump if not Zero) to JMP (Jump) for example to jump directly in every case) and write these code on the executable or you can implement them in a own program which changes them or patch them.
That is the princip you looking up for to understand how the program does work and then you add some features of your own or write a complete new application to fulfill the task of opening any file. Like Vlad said thats simply called reverse engineering.

visual c# button opens file without specifying drive

I work for an IT company where we all carry around flash drives that have our most used programs on them.In my spare time I am hoping to create a "main menu" item that is kind of a fun and convenient way to access these files. I am working on creating this using Visual Studio 2013 and using visual C# windows forms. I have come across a snag however that I can't seem to find a workaround for. I am by no means fluent in C#, but I need to have a button on the windows form open a file without specifying what drive it comes from. I understand that I have to specify a path, but as these will be stored on the flash drives of myself and my coworkers I cannot foresee that the path will always begin with E:. Depending on what USB slot the drive is plugged into it could be N: or F: or the like. I have provided an example below:
Using what I currently know I am opening files using this line of code:
System.Diagnostics.Process.Start("C:/Users/Myname/Desktop/Asmodeus/Anti-Virus/Anti-Virus Installers/avast_free_antivirus_setup.exe");
Is there any way possible I can have the file open simply from
System.Diagnostics.Process.Start("Asmodeus/Anti-Virus/Anti-Virus Installers/avast_free_antivirus_setup.exe");
or something of that nature?
Thanks in advance.
There must have been some mis-communication when I asked my question previously. what I am looking to do is open an executable file via a button click on the windows form using a relative path. I am not able to specify the absolute path because the application will be run from a flash drive and therefore will change depending on what USB slot it is currently inserted into.
What I am hoping to accomplish is insert a line of code that will allow me to open an executable file that is located in the \bin\debug folder along with the application itself. I have a picture for clarification but apparently do not have enough reputation to post it. Thank you and sorry for the earlier confusion.

Usually you can just use Environment.GetFolderPath (MSDN) to give you what you need. It doesn't do absolutely everything, but if you need Desktop and the like, that is plenty.
Depending on the target version of .Net, the SpecialFolders exposed are not all there. It may turn out that you need more than they provide, but in your case it doesn't sound like it.
If there is more you need that is not covered in the default, check out this project. I'm sure there are others like it, but it does a little more than the default BCL version, using the API directly. It is at least something to read and learn (and translate from vb.. use an online translator, very quick). I haven't looked at it, but it seems like you are learning this c#/.net thingy, so it might be helpful
This article is about accessing Windows special folders.
These folders include your “Favorites”, “Cookies”, system libraries and the like.
Here is code, including a large number of constant definitions, plus documentation,
allowing access to and creation of these folders.

Programmatically assign hotkeys to VSPackage menu commands

I am developing a new version of a Visual Studio extension. In the old version, the hotkeys were stored in the registry and I would like to import these settings into the new version of the software.
The new version uses .vsct format for defining menu commands and you can assign the hotkeys in the .vsct file. However, I can't use this mechanism, as I would like to import the user settings from the registry, whiles the .vsct is a static description.
When my VSPackage is initialized, I can read the old hotkeys from the registry, but I have problems assigning them to my menu commands defined in the .vsct file. I can get a hold on the OleMenuCommand interface and OleMenuCommandService, but they have no property where they can accept key bindings.
How one can assign hotkeys to menu commands programmatically?
A clunky workaround would be that the installer imports the hotkeys, writes them into the .vsct file, compiles the file and puts the .cto into the MyPackage.Resources.dll during the installation. But I'd rather not resort to this...

Though I define my commands through the .vsct file, I still can access them via the EnvDTE.Command interface.
// The commandGuid has to be the same GUID you use in the .vsct file, HOWEVER, you have to include the braces here
Command command = dte.Commands.Item(commandGuid, commandId);
command.Bindings = new object[] { "Global::Ctrl+Alt+Shift+1" };
It works. It is saved and remembered the next time Visual Studio starts up, so there is no need to import the old hotkeys every time.

Since I'm not allowed to comment [despite my 50 years of systems-level programming experience, including 3 books for MS Press :( ], I have to ask this way for Shakaron to post some more of his code. I added a short tree of menu commands to the VS 2015 Tools menu (1-4-1 elements). An enumeration of dte.Commands didn't show any of them. Calling Commands.Item with a string (or an "object" to which I'd assigned a string) containing the GUID, both with and without {}, generated an invalid argument exception.
So, either the EnvDTE80 interface is incredibly fragile, the documentation is wildly wrong, or else Shakaron's solution has some more magic that we haven't seen yet. And I was so hopeful that this would be the last piece of my puzzle...

Answering Shakaron's questions:
I used the .vsct file to add 1 menu with 3 commands and 1 submenu, which in turn had 1 command.
Calling Commands.Item with a guid and an index argument caused an apparently identical invalid argument exception. I was able to enumerate the collection, but my commands were not in the set.
I also couldn't compile your code for the right-hand-side of the Bindings assignment. But, of course, I didn't get that far because I couldn't find the command item in the first place.
There has to be a version dependency at work here. I don't doubt that your code worked a year ago, but I ran into the problems I described using a fresh-out-of-the-virtual-box copy of VS 2015 running on Win 10.

Load needed content from one file fast and easily?

Imagine there is a game with a lot of content, like car models.
I don't want to have them in the RAM all the time to save memory and want to load them only when needed. This would be easily when having one file per car - but I would have so many files at the end and the project would become hard to share etc.
But when I store everything into one file, I don't know where what is.
Is there a way storing everything into one file and navigate to the content as easily as if I do one file per content entry? Only thing I can imagine is saving the byte positions where something begins in a 2nd file (or as header in the content file) but I'm very unsure about that solution.

A simple way to do it is when you write the file you keep track (in memory) where stuff is. Then, at the end of the file you write an index. So your file looks like this:
offset 0: data for object 1
offset 0x0473: data for object 2
offset 0x1034: data for object 3
etc.
You can write this file using BinaryWriter. Before you write each object, you query writer.BaseStream.Position to get the current position of the file. You save that information in memory (just the object name and its position).
When you're done writing all of the objects, you save the current position:
indexPosition = writer.BaseStream.Position;
Then write the index at the end of the file:
name: "object 1", position: 0
name: "object 2", position: 0x0473
etc.
Write an empty index entry to signify the end of objects:
name: "", position: 0xFFFFFFFF
And the last thing you do is write the index position at the end of the file:
writer.Write(indexPosition);
Now, you can open the file with a BinaryReader. Seek to end-of-file minus 8 bytes, read the long integer there. That gives you the position of the index. Seek to the index and start reading index entries forward until you get to one that has a position of 0xFFFFFFFF.
You now have the index in memory. You can create a Dictionary<string, long> so that, given an object name, you can find its position in the file. Get the position, seek there, and read the object.
This kind of thing was pretty common when we were writing games in the late '90s. You can still do it, although you're probably better off going with a simple database.

There are quite a few different compression and archiving methods you could use to hold your files if you're looking to store them temporarily in a larger file for transport. Almost any compression method could work, which you choose is entirely up to you.
Example .zip compression can be found here:
http://msdn.microsoft.com/en-us/library/ms404280.aspx
There's also the .cab file format that you can easily pack multiple files into and unpack later when you have need for them. There's an interesting article on creating .cab files in C# found here:
http://mnarinsky.blogspot.com/2009/11/creating-cab-file-in-c.html
It does require that you add references to Microsoft.Deployment.Compression.Cab.dll and Microsoft.Deployment.Compression.dll but the code itself is fairly simple after that. If you find none of those to be a suitable answer to your question, my only other suggestion is that you better organize the files rather than cramming them all into a single folder as that can make it quite difficult to navigate.
Also try using a collection to keep track of the file names if that helps too. You could define files in the XML and load everything into a dictionary or hash table if it needs to be more dynamic or define it in the code itself if you prefer that.
EDIT:
You can also try using a third party installer for transport. They offer many functions outside of compressing and packing files and will handle the data compression for you. I prefer NSIS personally as I find it to be highly user friendly but any installer can work. A few example installers are:
Installshield: http://www.installshield.com/ (integrates with Visual Studio)
WIX: http://wix.sourceforge.net/ (also integrates with Visual Studio, good if you're looking for something more XML based)
NSIS: http://nsis.sourceforge.net/Main_Page (scriptable, doesn't integrate with Visual Studio, easy guided design with Nsisqssg if you'd prefer not to do the bulk of the scripting on your own)
They all function differently but essentially achieve the same end result. It all depends on exactly what you're looking for.

How to set extended file properties?

I need to set the Company field value for some Word/PDF documents. I am talking about the extended file properties (summary/author/title, etc.) you see under File Properties.
I know how to get them (by using shell32.dll class library). I assumed that I could also set them with the same class library, but it seems like writing extended properties is a little bit more difficult and shell32.dll doesn't allow that.
I found something about taglib-sharp, which seems to have an option to set extended properties, but I don't really understand how it works.

Add following NuGet packages to your project:
Microsoft.WindowsAPICodePack-Shell by Microsoft
Microsoft.WindowsAPICodePack-Core by Microsoft
Read and Write Properties
using Microsoft.WindowsAPICodePack.Shell;
using Microsoft.WindowsAPICodePack.Shell.PropertySystem;
string filePath = #"C:\temp\example.docx";
var file = ShellFile.FromFilePath(filePath);
// Read and Write:
string[] oldAuthors = file.Properties.System.Author.Value;
string oldTitle = file.Properties.System.Title.Value;
file.Properties.System.Author.Value = new string[] { "Author #1", "Author #2" };
file.Properties.System.Title.Value = "Example Title";
// Alternate way to Write:
ShellPropertyWriter propertyWriter = file.Properties.GetPropertyWriter();
propertyWriter.WriteProperty(SystemProperties.System.Author, new string[] { "Author" });
propertyWriter.Close();
Important:
The file must be a valid one, created by the specific assigned software. Every file type has specific extended file properties and not all of them are writable.
If you right-click a file on desktop and cannot edit a property, you wont be able to edit it in code too.
Example:
Create txt file on desktop, rename its extension to docx. You can't
edit its Author or Title property.
Open it with Word, edit and save
it. Now you can.
So just make sure to use some try catch
Further Topic:
MS Docs: Implementing Property Handlers

Ok here is answer to my own question, since I wasn't really able to find my answer in this forum, it could be useful for others.
Solution is to use dsofile.dll and OleDocumentPropertiesClass.
Here is MS article about dsofile.dll - Link
In this link, you can download dsofile.dll with some other files. But most probably, just like I did, you will face some weird problems that are hard to find a solution for.
1) After intalling dsofile.dll, you will need to register the class: oped cmd and navigate to c:\dsofile of to directory, where you have extracted your downloaded dsofile.dll. After that - write line regsvr32 dsofile.dll. You should get a messagebox saying that registeration was succesful. If not, most propably you don't have admin rights. You are going to need admin rights in case you want this to work.
2) After trying to use this class in your program, if you are using .NET 4.0 it is possible, that you will see error saying something like "class cannot be embedded ..."
Well, for that, right click on dsofile in references list, properties -> embed interop files -> set to FALSE.
3) How to use:
//creates new class of oledocumentproperties
var doc = new OleDocumentPropertiesClass();
//open your selected file
doc.Open(pathToFile, false, dsoFileOpenOptions.dsoOptionDefault);
//you can set properties with summaryproperties.nameOfProperty = value; for example
doc.SummaryProperties.Company = "lol";
doc.SummaryProperties.Author = "me";
//after making changes, you need to use this line to save them
doc.Save();

Windows Explorer (using shell32.dll) is able to display the extended properties because it understands a lot of different file formats and can parse these. However, to set an extended property you probably need a file format specific library. E.g. to set the author of an MP3 file file is very different compared to setting the author of an Office document. (Actually Windows Explorer allows you to set some extended properties on Office documents.)
The taglib-sharp only works with media files and is most likely not able to set extended properties of any other type of file.
What you need is a library or a tool you can automate to modify PDF files. You can try to google pdf sdk. If you also need to work with Word files you can use COM automation to automate Word. Depending on the Word file format used you may also be able to work directly with the file without having Word installed (XML being much easier than the old binary "streams" format).

To set properties, you could utilize Windows' Property System. It provides an interface for accessing the "Property Store Cache" (IPropertyStore) where you can read/set any file's properties (regardless of the format), and add your own custom properties (the c library propkey.h has a comprehensive list of all available properties; you can also find these using prop.exe). This is essentially creating a Property Handler that must be later registered to your file extension. It is officially unsupported in managed code, so you might either want to write your own wrapper or use c++ (since this is a c# tagged question).
If you're specifically asking for media properties, check out metadata handlers, which are essentially codecs that extract your properties from the file and also called by explorer by default if you register them correctly.