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
Related
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.
I've been writing bots that run on a platform I do not have control over. Essentially, I can upload a single file, and it only has access to basic JS and the site runtime. I chose to actually develop in TypeScript and transpile, to make things easier (imo). Since the initial bot was written for an individual, I've been asked for a few other customized variants. I do not mind this as there is very little in the bots that need to be changed per person. I have been hardlinking the common files between the projects, so as to not have to update in multiple places. This is, without a doubt, a bad solution. I am developing this in Visual Studio 2015, although I also have Visual Studio Code available, if anyone knows of a better build method. I am not very familiar with either, however. I would prefer being able to keep the common files in one project, and import them as dependencies. Maybe I missed something obvious, but attempting the same as I would do for C# did not seem to work.
From the way you are describing things, it sounds like you need to use some sort of custom build.
I would keep each of your bots in the same project and make sure that they share code appropriately, and then after tsc transpiles your files, concatenate them for each bot. So, each bot will get the files that it needs all stuffed into a single, gargantuan file.
You will need to do some trickiness, like parsing import/require statements, or include some kind of directives in each file that describes what other files are needed.
This doesn't sound too tricky to do and is the approach that I would take given the problem description you have provided.
As it turns out, you can declare a tsconfig.json file, and in there, specify things like included directories and specific files. This wound up being exactly what I needed, and was remarkably easy to set up. I've been updated the apps/bots for a while now using this system, and all the common files are effortlessly "shared" between then, with only recompilation necessary.
Is there anyway within Visual Studio / TFS to identify which project produces which dll?
I'm aware you can look under a particular project's properties and see what the name of the dll is, but in the circumstance where you have loads and loads of projects this doesn't seem very efficient.
I've got the situation where I've got a project that references a dll, which includes a method I want to examine, but I don't know what project produces this dll.
Unfortunately, no. The only way I know is that you may could use a decompile extension. (Strongly not recommend to use) Through the source code after decompile, you can view namespace and judge which project produces the dll. (Under normal circumstances)
And you may also have to face some problems such as:
Legal issues
Need to pay for the extension
Only work for C#/.Net
The source code may be confusion and not standard
This should be a one time activity, you can go ahead and take a look into the project file, in case of C# project the csproj file.
If you do not want to do it opening each file, then i would say write a small tool to read all the project files and look for the name.
BTW, this will be different for different projects, and you need to find out the proper location to look.
This question is kinda similar to this one, but not exactly. I have a game engine in C#, and I'm working with some people who want to use my engine. Originally I designed the engine so that all the assets are external - non programmers can create art, music, xml settings, etc. and that anyone could modify an existing game, and share them amongst each other. Basically the whole thing including the engine itself is open source.
The group I'm working with (one of only two projects using my engine currently) wants to close their assets so they can't be modified. Although it's against my principle, I don't want to turn them away, both because I've already been working with them a while and because the market is very small (both for engines like mine, and for users of those engines).
The Actual Question
Is there a way, maybe some available software, that can take an exe and a bunch of other arbitrary files, and smash them into a single exe, that isn't just an archive? I would like the final exe to behave like it runs the first exe with some command line parameters that refer to the bundled files. For example, running bundle.exe would be just like running original.exe --project_path=/project but the project files are inside the bundle, and cannot be retrieved from it.
My original exe is written in C#. I doubt that matters.
You could pack these files as embedded resources.
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?