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.
Related
My application has a collection of .json files some being user created, and others to be included with the application by default with the potential to be changed (removed, contents updated). I am also trying to find a way to store them so the user can easily access their location (ie "...\AppData\Local\Program\Files" or "...\Program\Files"), atleast on Desktop.
I've read the about using the app sandbox that xamarin provides for cross-platform access to a local storage; though to me it doesn't seem like a fit for what I'm trying to do, as from my understanding it's a location to store files created at runtime.
I also looked into using Visual Studio's Build Action property, which feels closer to working in the way I need; but I'm not sure which setting is the best; I tried using 'Content' but I couldn't seem to find a reliable way to access the files across all platforms, even when using conditional compilation.
A point in any direction is helpful, I was hoping Xamarin might have something built in for this, but if I have to use an outside system I will.
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.
I'm deploying a .NET application with VS2010. My application creates .txt file in the logs folder in the same directory with .exe:
app.exe
add.exe.config
logs (folder)
I used setup project to create a MSI installer. When I installed in the client machine C: drive or any drives I have no problem to create the .txt file, but when I installed in C:\Program File\myAppFolder or C:\Program File(x86)\myAppFolder I cannot to create the .txt file.
It is a poor design to write to install location for your application. It is better to write to the ApplicationDataFolder. The ApplicationDataFolder is under the user profile and the application will have access to write there when run as that user. #Ken White provided a very good pointer to an existing StackOverflow answer about this.
If this is a legacy application that must write to that folder, then you'll need to modify the permissions on the log folder such that all users can write to the folder. This is possible to do with the Windows Installer (aka: MSI) but I'm not sure that the Visual Studio setup projects expose it. The WiX toolset definitely supports doing such things.
An old post but I needed to do similar recently so I guess it is still valid! While I don't advocate bad design, in the real world sometimes we have to bend to requirement.
Writing to the application folder is possibly under Win7 and it is possible to set this up via an installer class in an MSI created by VS2010. You just need to give a relevant group (suggest either the "Users" group, or if you want to give more control over who gets what, supply a selection screen) Write-Data access.
Using DirectoryInfo on a path you can then get the security data from GetAccessControl.
When you have your Group known, get the SID for the group and AddAccessRule also supplying the required ControlType value.
Then set the access control on the DirectoryInfo object (SetAccessControl) using the security data object.
You can get the SID from the Groups principal object if you do a search with PrincipalSearcher.
Hope this helps
paul
This generally all depends on:
Whether your app requires to be run as administrator for other reasons and..
Whether your app is provided for limited users.
If the app requires elevation for a bunch of other reasons (and not just updating files in restricted locations) then the normal way is to have an elevation manifest embedded in your app. This isn't a good thing from the security point of view, but if you absolutely need admin privilege then this is the way to do it.
If the only operation requiring elevation is updating/creating data in the Program Files folder then don't put the file there. Every case of this that I've seen has been lazy programming where the code just refers to the file name and consequently it goes in the Program Files folder (more accurately in the same folder that the app runs in). The cure for this is to put the data file in the correct location (such as User's Application Data folder). As Rob Mensching says, you should alter the permissions on the install folder only if this is a legacy app that you cannot change.
I am using a Mac and have a Nokia phone. Therefore I cannot sync it with my computer, but I found out, that making a backup on the creates a .nbf-file, which contains all the data I want (contacts and messages).
The contacts are stored easily accessible as vCards, so that's cool. Unfortunately the messages are stored each text separately in one file, which looks pretty weird when I open it with a text editor (for example TextWrangler). I can see the numbers and the text, but no information about date.
I uploaded the file here: http://www.4shared.com/file/7LNsuPbF/00000A123EB640F500002010005000.html
I already tried out different encodings, but it never looks good.
Maybe someone has a clue how to read that file? Could it be encrypted or something?
Try https://sourceforge.net/projects/nbuexplorer/ - it should be able to open .nbf files.
It is/was a C# project, and it only provides Windows exe as release download, however, I could get this .exe to run on Ubuntu 18.04 using mono; and I could also get the project sources to compile on Ubuntu using xbuild (the result again being an .exe file that can be run with Mono), see comments in my build script get-nbuexplorer.svn.sh.
we are making an Application for OS X, however, when the .app is copied on another MAC, we have problems with reading and writing files
on one MAC, everything works great from the start...
the other one will not write certain files and another 2mac will not write certain different files
if i go to show application contents and wants to edit the file by myself, i get a writing permission denied
how to distribute an MAC application so there are no such issues? so all files can be read and write by the current user
does there have to be some authorization or code sign, or smth. different in this form, in addition to normal code?
thank you
It sounds like your application tries to write files within its own application bundle. The correct solution here is: DON'T DO THAT! The only time your application bundle should be written to is when it's installed or updated.
Files that the application needs to write to should be stored in the user's home folder, generally under ~/Library. See this note in Apple's dev docs.
Preference and settings files in ~/Library/Preferences/<appbundleid>.plist; use NSUserDefaults.
Data the app manages for the user in ~/Library/Application Support/<appname> (the docs say to use the bundleid, but everyone -- Apple included -- uses the app name instead).
Cache files in ~/Library/Caches/<appbundleid>.
Temp files, use NSTemporaryDirectory
If you need to share settings & files between users, that should generally go in /Library/Application Support/<appname>, except that you really shouldn't be doing that at all.
In the past I've always used PackageMaker to create installers. An installation package can authenticate with root privileges so you can set permissions after the install. I don't have it in front of me right now but if you look around you should be able to see a Post-Installer script line. Write a shell script that manually sets the permissions of each file you have in question and then have the package execute that script after the install is finished.
You can find PackageMaker at /Developer/Applications/Utilities/PackageMaker