This is likely not a simple topic - I have researched this to the best of my abilities and realize that it is not supported in any typical fashion.
My goal is to enable something similar to .app files from OSX, where the application, as well as its user data, can exist in the same file. I imagine it would require writing a tool to manage this behaviour, but this question is more about how to achieve this in the Windows OS. I am quite flexible regarding the implementation details, but the more straightforward the behaviour, the better (i.e. avoiding copying or compressing/decompressing entire directories/archives at runtime would be ideal).
Approaches I have considered:
Find a way to get explorer to treat a directory as a file, so that it can be associated. I have found a way to get explorer to treat a directory as a control panel item, I have thus far been unable to find a way to use this to associate a custom program. See the infamous "godmode hack" for Windows (name a directory something to the effect of "GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}"). This one seems the most hopeful, but I'm at wits end trying to find information about creating a new association of this type.
Come up with some kind of archive format which can extract executable information to a temporary directory, launch this executable passing the archive as a commandline parameter. This seems like the ugliest solution, from a performance perspective. I would prefer a different solution if at all possible, one which doesn't involve making duplicates of the program or its data to run.
Find a way to associate a directory directly, though I have found no trace of this being supported in Windows, and I assume this is a dead-end.
Find a way to get an executable to include writeable embedded files. I have been unable to make any headway with this- I even tried a resource hacker approach, but obviously you cannot modify the assembly while its in use.
Tried to make a self-modifying JAR file with Java, but the route I took would add the JDK as a runtime requirement, which seems a bit overkill. Even then, it would be limited to Java, and I'm pretty sure it's not actually supposed to allow that in the first place.
Modify Windows Explorer. I shudder at the amount of work this would take, not to mention the at-best gray area it falls under legally. Perhaps there's a way to extend explorer to achieve this, I'm not sure.
A custom archive file. This seems like the most straightforward way to do it. But it would ideally need to be an archive format that has very little overhead for file I/O. Could even be some kind of virtual disk that gets mounted, but I am imagining that would be pretty heavy.
I would appreciate any insight that anyone has on this topic. I won't go into reasons as they are irrelevant to the question itself- I'm aware it is likely not the most practical solution to anything in particular. Consider it a novel pursuit.
It can be done by application virtualization,
Read this wikipedia page theory:
https://en.wikipedia.org/wiki/Portable_application
https://en.wikipedia.org/wiki/Application_virtualization
And two pages about software:
https://en.wikipedia.org/wiki/VMware_ThinApp
https://en.wikipedia.org/wiki/Turbo_(software)
Windows 7 added the ability for a Desktop.ini file to add/change the folder verbs on a per-folder basis. Using that trick it is possible to create a "folders as applications" style setup.
Related
Can I make a ruby file (e.g script.rb) unreadable to a user?
The file is on an Ubuntu (offline) machine. The user will use a local Sinatra app that will use some ruby files. I don't want the user to see the code in some of those files.
How can I do it?
EDIT:
Can I setup the project in a way that the user will be able to start the app but won't have access to specific files in it?
Thanks
Does that correspond to what you are searching for ?
chmod yourfile.rb 711
As I said in my comment it is literally almost impossible to hide the content of your ruby source file, many people try this in many different ways but it is almost always trivial to reverse engineer. There are some "suggestions" for making your code hidden but they never really work still, here are a few;
Obfuscation - The process of making your code executable but unreadable, using a tool like ProGuard for Java (there are ones for most major languages) will try to make your code a mess, and as unreadable as possible while still maintaining execution speed. Normally this consists of renaming variables, using strange characters and generally hiding, moving or wrapping functions in complicated structures.
Package the interpreter - You can use a tool like ocra to package the script up inside an executable with the interpreter and standard library, but anyone with even a tiny bit of experience in reverse engineering will be able to easily tear out the source code given a small amount of time
Write a custom interpreter - Now we are getting somewhere with making it harder. Writing a custom interpreter will allow you to compile your script to a "bytecode" that can then be executed. This is of course a very time consuming, expensive and incompatible solution when it comes to working with other code bases.
Write most of your code in C and then call out to it via extensions - Again this mostly moves the problem but its still there. It will take more time but anyone can easily pull apart the machine code of the C library you load in and bob is your uncle they have the source code.
Many more alternatives - This isn't a comprehensive list, I am probably missing a few ideas or suggestions.
As far as it goes making code unreadable is hard a better solution might just to be consider providing a licence agreement with your code. That way, someone reads or modifies the source file you can take them to court for a legal settlement.
Extract your code and its functionality to an external API. And then provide it as a service. This way you don't have to expose your source code to your 'users'.
I have an existing MFC product and am planning on supporting a couple of other national languages thru the use of resource-only DLLs. I've read a number of articles and tutorials on how to go about this, but admit that I don't have a lot of in-depth knowledge of Windows resources (mostly just use VS 2008's graphical interface).
The major area that I am trying to understand is that it seems like all of the resource source files (i.e., resource.rc) for these DLLs -- and the main program -- should be sharing the same copy of resource.h. After all, all those IDD_xxx values have to be consistent, and it seems like making updates to the resources would be even more complicated by having to keep multiple resource.h files in sync!
So am I correct on this, and does anyone have any tips for how to best implement this? Should I modify resource.rc in the DLL projects to point to the "master" resource.h in the main program directory?
Yes, use the same resource.h file for sure.
One way is to just copy the resources you need to be translated into the the new resource project--stuff like menus, strings, dialogs. Bitmaps and icons probably don't need to be translated unless you put some text on them that is language specific. If you know your localse, at program startup you can call AfxSetResourceHandle() with the resource DLL you manually load.
Another way to approach the problem if you have a multitude of DLLs and EXEs is to use binary resource editing tools. What they do is create token files from your resources. Your translators edit the token file with the binary editing tool. When all is done, you run a tool to apply the translation to the binaries. Basically, you don't distribute resource DLLs, but distribute different versions of your DLLs for each language. The tools are smart enough so that if you make a change like add a string or dialog, it will get picked up and your translator can see that he needs to translate something new. The previously translated work will be saved in the token files. This is how we do it at my shop. We used to use Microsoft's Localization Resource toolkit. I don't know if we still use it or not since it is somebody else's responsibility now.
I found the MSDN article ID 198846 a good starting point for sharing of resources via a dll, though it does need updating for newer versions of visual studio, it was quite easy to follow and understand.
http://support.microsoft.com/kb/198846
I'm looking for a good VB6 source code library (to extend the language) for things like parsing a path into root, directory, filename, extension, does a file exist, etc.
I'm happy to pay for such a resource if it's a good one (ideally with some sort of reviews/feedback).
I've found one already:
SourcePlus from AxTools
Only downside is that all of their source code is in Classes and I have 12 or so different VB6 apps that all share a lot of common code (.bas modules). So if I use one of the classes in on of my Common.Bas routines I then need to add the class to 12 different programs that all use that Common.Bas module.
I'd really prefer to have the code in either one big class or a .bas module so I can add it one time to each VB6 app and be done with it.
FYI, I've also used with good success http://www.planet-source-code.com/vb/ and of course StackOverflow but I'd be happy to buy something comprehensive and well done.
I'm in favour of buying libraries in general, but you really can do a lot of file related tasks with free code. Karl E Peterson's excellent VB6 website has some great objects written entirely in VB6 - I think they're as reliable as most things I've ever bought. You could just put them in a COM DLL if you dislike managing the classes.
Convert a file path to drive and directory only.
Check whether a directory exists.
Check whether a file exists.
...I could go on
Can you build their source as a COM dll and just refer to it from your own projects?
I have embedded an EXE as a resource in my Win32 application.
I'm looking to the registry for a certain value. If the value is there and correct, then i copy the embedded EXE to the local file system an execute it from there.
I don't want it to be extracted from my EXE.
Should i do anything to prevent this, or is it impossible already?
Thanks.
but you could inbed the exe as an .obj or an static array rather than as a resource. That would make it harder for an attacker to find in your code, but still not impossible.
You can use the unix objcopy tool to convert your exe into a .obj file and then link to that in your c code. someone would have to decompile your code in order to find the .exe, which is quite a bit harder than using a resource extractor.
Embed data in a C++ program
Nothing is impossible, and in fact it is quite easy to strip resources out of an executable. Here's the first link from a Google search, for example. On the other hand you're already stripping the exe out and saving it to a file on the user's system, anybody sophisticated enough to find the embedded resource will also be able to find your extracted file. I wouldn't spend too much time worrying about it.
I have to secure an application. I can't modify the application. All i can do is writing small utilities around it, like creating an online serial system, unique hardware information hash storing, a loader exe etc.
But now i see that my intentions are almost useless without modifying the original applications. I'd be apprecieted any help on this.
I'm using Visual Source Safe 6.0d (work requirement) and I've been trying to hack together a little shell script to allow me to easily remove a source tree or warn me if I've got files checked out so I can make sure I don't accidentally delete work. Is there any way to tell if files are checked out other than checking the read-only bit on the files themselves?
VSS doesn't seem to be writing any file (I took a snapshot of the dir before and after checking out a file and there was no difference in the files listed)
I can't seem to find anything by Googling.
I also checked the vssver.scc for differences and didn't find anything.
Mind you, checking for writeable files isn't the worst thing in the world but it seems as if VSS makes several files in the source tree (*.ncb, *.scc, *.sln) writeable without me having checked anything out. I can simply exclude the files but I'm trying to find a bit more elegant solution.
You can use COM to check if a file is checked out. Take a look at the IVSSItem.IsCheckedOut property. For more on using VSS through COM see:
http://msdn.microsoft.com/en-us/library/4d44xhsd%28VS.80%29.aspx
Perhaps the most robust technique is to ask SourceSafe itself what is checked out and/or whether individual files of interest are checked out. Whilst I realize that it's not obvious how to do this in a little shell script, I'd advocate the use of PowerShell for this.
SourceSafe exposes an OLE Automation object model (also known as a COM object model), and PowerShell can talk to COM objects. If you're not familiar with this stuff, it's a lot to learn but ultimately it's worth it.
Alternatively, if PowerShell is too alien, VBScript can also be used to control COM objects.