Currently, I have an MFC C++ visual studio project that is built to a DLL. Let's call it the FinalDLL.
I need this FinalDLL to be configurable. So, I want a GUI such that the users can generate the FinalDLL based on the information the enter via GUI. Please consider that I don't want to make the sources available at any points.
I do not have a clear idea how to integrate these steps. The solution I came up with was to have something like a button in my GUI, so that when it is clicked, the FinalDLL gets generated based on the information entered via GUI. Is it possible to do something like that? Probably I need another DLL library, as the information entered via GUI can be calls to functions that are used inside the FinalDLL source.
The solution to this would be very complex and complicated, mainly due to the fact that you don't want to disclose the source code of the DLL.
Basically you need to compile those source files every time you want to generate the DLL, and without the user having access to them.
Firstly, this is also required for the users that you want your DLL-generator app distributed to.
Secondly, you'll need to store those files somewhere in the app, and in an encrypted form, so that hackers won't just look at you app binaries and extract the source code for the DLL.
As a prerequisite on the user side, he will need to have a compatible Visual Studio installation, which will be used to compile on the fly the source code files.
What the DLL-generator application will need to do is to compile on the fly those source code files along with the customised ones via the form that the application will present.
So what you will need to do (the list might not be exhaustive due to the complex requirements):
Gather all compiler/linker commands that Visual Studio executes when building your project
Store all source code files into your application, in an encrypted form. Now if you want to allow your application to decode the files then you need to either store the encryption key within the application, and obfuscate it so its not that easy to find, or have the app communicate with your server and ask for the encryption key via https (this is a more secure approach, however neither this is 100% bullet-proof, insistent/trained hackers can still peek into the memory used by your app)
After the user fills all DLL generating details, the app will need to decrypt the source code files, updated the ones affected by the customised parameters, and start the build process by using the commands gathered at step #1. The compiler/linker should allow reading from stdin, so you'll use pipes to write the source code contents to the compiler/linker stdin, and to obtain the compiled/linked objects from stdout.
As I said, the solution is not pretty, and the main problem will be having the users install a Visual Studio that comes with a compiler compatible with the one from your machine, otherwise the commands you gathered at step #1 will not work.
Related
I have a game that was originally written in QuickBasic in the 1990's. I converted it into a Win32 app using QB64. I then used Microsoft's Desktop App Converter to package it as a UWP app and submit it to the Microsoft Store (it's been accepted).
The game seems to work fine, except for saving files. It throws a permission denied error whenever you try to save a file. From what I've been able to find thus far it seems that UWP apps can't save in the install directory and that is likely what my app is trying to do.
There are a number of code samples available online for taking a Win32 app written in C#, C, C++, etc. and having it use LocalAppData instead. Unfortunately, I'm not seeing anything that will help me with this application.
Is there a way to make saving files work in this instance? I'm hoping that there is perhaps a way to say, "Hey, when I say save a file, I mean save it to the LocalAppData folder for this particular application." This probably needs to be abstract, ideally a declarative part of the appx package that isn't in the QB64 code. Any ideas?
There are two options to fix it (and one way to hack it):
If the file saving is done from your code, change it to write to an accessible location instead, such as localappdata or temp.
If the file saving is done in code you can't change, then you can use the new Package Support Framework to apply a fixup at runtime that redirects the file operations. This is a new framework coming as part of the 1809 update for Windows 10. At the time of this writing this may not be an option for you just yet. Here is the documentation:
https://learn.microsoft.com/en-us/windows/uwp/porting/package-support-framework?context=/windows/msix/render
A hacky way to solve it that you could try would be to add a launcher EXE to your package and make that the app's entrypoint. The launcher would then copy your actual EXE to a writeable location (localappdata, etc.) and then launch it from there. All your file writes will then succeed.
Is it hard to compile software so that it is a single .exe file? I have been publishing the program in the traditional manner and the resultant program consists of a setup file and a couple data files. Ideally I would like to have a lone exe that runs program without having to install.
In general, if you're using Visual Basic, you'll always need to, at a minimum, guarantee the target computer has the proper .NET Framework installed.
If that's the case, then you can just deploy your .exe from your Console or WIndows Application project, and it will work, provided you don't use any references or types outside of the standard framework types. If you have any assemblies you use, or require any extra data to exist, then an installer is the correct way to go.
In general, building an installer makes sure that all of the dependencies are in place, which is why it's the "traditional" manner of publishing. Without that, you (or somebody) has to verify the dependencies before running your program manually.
I would like to create a mechanism by which I automatically submit the executable corresponding to the updated code. My development environment is Visual Studio 2005 and I use the windows GUI client to submit changes.
Ideally, I would like to ensure latest binary is submitted in the same change list as the code changes.
My requirements are:
The code should be recompiled and binary should be checked out when source code dependencies change.
Related documentation / non-source files do not affect binary
Perforce should complain when sources are changed and submitted but the binary isn't included in the change list.
How could I enforce these rules? Is it possible to create a P4 script that runs before each submission? Also, is it possible to write a Visual Studio script that automatically checks out the executable before compiling?
Thanks,
Shahar
I think you can accomplish most of this without too much work.
If you include the output directories in your Perforce workspace, you can easily just check them in every time you do a build. (You might want to talk to the Perforce admin about using a 'purge' option so you're not storing thousands of copies of binaries.) You can use a trigger to make sure that source code in certain directories is always submitted with a binary.
I did some basic research, and it seems that there is no one standard to create these. I saw a number of code project pages that had code for building such an exe, but no reference on how to identify one, nor if it possible to extract files without actually running the application.
So the questions are:
Is there a method I can use to identify if a particular file is a self extracting exe?
Are there a few formats that are extremely common in the computing industry
If so, do these formats allow for extraction without running the packaging exe?
If not, is there a method to run such a file in some sort of sandbox environment, allowing us to see the resulting files (on Windows)?
Note I'm open to both programmatic solutions or those using third party utilities/libraries.
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